As an indie with a steady income, I have the ability to make prototypes and shelve them as needed. Today is one of these times.
After spending some time to get Mercenaries running on Unity (2 Players + AI Skirmish mode) I find myself unsure whether the idea is worth pursuing altogether.
It's not a question of losing interest in the project, as a matter of fact, Trello is bleeding out with ideas I've been throwing up in the air about Mercenaries' future. I still have a lot of fun when I tinker with it to add features or improve performances. At this point, it's really a question of looking at the amount of work ahead and trying to determine whether it's the best use of my time (and money, for some of the assets). There are a lot of directions I could go with Mercenaries at this point, but I feel that, as a responsible game developer, it is better that I validate whether the core gameplay mechanic is actually any fun before sinking months of work towards getting it to a level that makes sense.
Playtesting with a select few has revealed that the game had a lot of potential (I got some players that really wanted more but I wasn't sure whether it was just their competitive self refusing to let go, or the game that actually created this infatuation). I'd really like to get this game before an audience that I both understand and that is not poised to tell me it's good. In essence, that would be like asking to know how a stranger thinks but having no significant ties: unlikely to happen. The best judge for this game, in my opinion, would be me, assuming I wasn't so close to it.
The most recent video of the prototype
At this point, I feel that the best thing I can do is to shelve the concept and archive it for bit. The intent is to let it age a bit and get back to it in a few months and see whether I find it sufficiently fun to pursue, or spend my time on another project instead.
Mercenaries started out as a prototype for Grand Strategy: Space War's automated combat system and has grown into a very interesting arcade multiplayer local space combat game, so I feel it logical that I take a moment to think about it before continuing.
What about Grand Strategy: Space War you might ask? Well I'd like to think this project is still very much alive, but to a degree, it has suffered several severe design changes. A lot of the lore and underlying logic still applies, but I don't think it would even qualify as a 4X game at this point. That being said, it is a much smaller scope, when I feel confident I can achieve on my own in a tech I understand much better (Unity).
Some of you may already be aware that I was part of the Week of Awesome II jam a few weeks back (and finished 4th! yay!). I've already explained my reasons to participate in this event, and one of them was merely to test Unity and see how it could affect my production workflow. Following the competition, I made the decision to use Unity for my ongoing projects, and scrap all ongoing Dartlang development.
Today, I've taken a few hours to mess around with the original ship assets in Unity, and see how much I could get done.
Movement Unity is a powerful tool indeed, especially when it comes to built-in physics. By leveraging Rigidbody2D, I was able to quickly put together a script that would process input and apply force and torque to my object. The result is a fully maneuverable ship within the environment. I spent a lot of time testing and tweaking acceleration and rotation speeds / drags coefficients to get good results.
Total Time: 20 - 25 minutes Original Dart Time: > 10 hours
Collision I wanted to test collisions, but didn't come up with anything meaningful to trigger upon colliding so I went ahead with a rather vanilla approach, just to see how complex it would be. I now understand that having a single collision box won't be sufficient and that I'll probably need to have several child objects with their own collision boxes to represent all of the ship's systems, but for now, this did just fine. I added collision polygons on both the player-controlled ship and a random npc and tested the outcome, refitting it as needed to match the sprite as much as possible.
Total Time: 15 - 20 minutes Original Dart Time: > 10 hours
Tracking Camera The camera was something that had been quite a pain in Dart, and it was still under severe development. Because I was dealing with different play modes, I had to adapt my camera to a number of different behaviors. In Unity, I wanted to test one first which was the tracking camera: a fairly simple camera that would always have the same coordinates as the player ship and no form of delays, etc.
Total Time: 10 minutes Original Dart Time: > 5 hours (incomplete)
Parallaxing During "The Week of Awesome II". I came up with a quick script to do some parallaxing which I've decided to reuse in order to make space prettier. My intent was to have placeholder stars/asteroids move on two separate layers at different speed and add some kind of a nebula and even a nearby star. Ideally, I wanted everything to move at their own pace so that it would give an illusion of depth. As it turns out, most of my original script worked flawlessly. I cleaned it up a bit and made some quick custom (placeholder) assets to this this out and fixed a few quirks. It is interesting to note that I was also able to apply a foreground using the same logic. I'm not too sure how I feel about having a foreground that actually moves slower, but I think it looks pretty. Obviously, that shouldn't have been my priority for now: I was merely giving myself candy for getting development started again!
Total Time: 1 hour (including assets) Original Dart Time: N/A (Static Background)
All in all, a fairly productive evening given I didn't set out to do anything specific. My original intent was to start with UI as soon as I was proficient with how Unity handles UI, but given that this is not yet the case, and that I've had people over for the majority of the evening, some doodling with the engine felt like it was still a decent step forwards. All of this will be scrapped very quickly, though the scripts themselves will be kept for future reference.
If you wish, you can see the parallaxing effect in action in the video below (please don't mind the placeholder art!).
Posted by Orymus3,
04 September 2014 -
For the longest time, I was hesitant to use Unity. Truth is, I'm not a big fan of editors: I generally feel I don't have sufficient control over what I'm trying to achieve, and this can be quite frustrating. That being said, not meeting desired velocity can be equally (if not more) frustrating however, and after several months of Dart development, I ended up looking up Unity.
My research led me directly to the Unity tutorials, where I've seen absolutely gorgeous entries such as: "Input.GetAxis" (which would roughly translate into poking 3 different classes in my current architecture)
Digging deeper, I've seen how they employed cameras (omg!) and simply had to stop. Further analysis revealed that over 25% of my code was simply handled de facto by Unity.
When my brain cooled down to appropriate levels, I took the very easy decision to move all current developments away from Dart and into Unity. I realize this may be a harsh move, possibly inconsiderate, but the truth is that I had no specific reason to use Dart in the first place: it was just the tech laying around when I started on this project. Given I've been able to re-create months of work in but 2 evenings, I'm quite confident about my efforts in Unity, so much so in fact that I'm wondering why I'm not seeing a lot MORE Unity games around.
Unity 2D Unity 2D is great... for platformers.
Looking at it more and more, I realize that, even though I'm primarily making 2D games, I'm much more likely to opt for a 3D approach.
While 2D Physics may sound appealing, it's interesting to note that the actual inner workings of collision detection will assume that all objects are at the same Z coordinate (0).
While this is theoretically appropriate to a 2D game, let's not forget that, long before there were 3D games, there were 2D layers. For example, in earlier games, such as Zelda: A Link to the Past, it was possible to walk on a bridge that passed over a level, and respond to different collisions. Built "as is" in Unity 2D (using 2D physics), this would be impossible. One would either have to manipulate the Z axis through code to ignore certain collision (troublesome) or resort to using 3D physics and understand that they are not at the same Z position. The latter is a much more WYSIWYG method and far more sustainable in the long run, especially if you plan on having multiple levels and complex collisions.
This is probably not a big deal (especially on this project) and to be fair, it's the "worse" I've found this far about Unity 2D, but it's still reason enough.
Unity: Popularity One of my primary reasons to use Unity (past the initial excitement to achieve the velocity I strongly desired) was it's growing crowd of adepts. There's virtually very little that hasn't been attempted before and this means that there's a lot of code out there that can be used. If I can't do something efficiently myself, or if I can't be arsed to reinvent the wheel, I get to google it and find just what I need. But wait... there's a store for that! All the better.
Worse comes to worse, I can just go directly to the Unity website and open up one of their tutorials and do it on my own... More importantly, I can have a look at live sessions where games are being made before my eyes, with actual commentaries as to why certain choices were made. It doesn't really get any better than this!
Closing Words In retrospect, I'm glad I've bled myself dry on Dart: it allowed me to quickly identify the strengths of Unity and truly appreciate it. That allowed me to force myself into using an editor, which I'm glad I've managed to do so seamlessly. Unity is not all joy and fun, but for this project, it's a big and much needed overhaul that should, hopefully, imply faster development cycles. We shall see!
I was hoping to get this done much earlier, but a lot got in the way... Coming in, I knew this was going to be a tough/long stretch. I wanted to work more on the combat aspect of the game, but I knew I needed to lay the foundations of the 'game flow' before that, so I set out to do just that. Without further ado, I give you, the game flow (at least, for the 'Arena' game mode).
Game Flow When I chose to turn this prototype into an actual game, I had a rough idea of where I wanted to go with it. Solar Winds and Raptor: Call of the Shadows have been my two main sources of inspiration for this installment. Of the two, Raptor was simpler to replicate in the short term (Solar Winds has a more adventure-themed type of gameplay).
To mimick Raptor, I had to come up with a simple routine where the player would organically switch between levels and some form of shop system. The idea is that the player is sent on missions, accumulating cash, and spending it to further upgrade its ships. To do this, I needed to implement a lot of UI which I hadn't done up to this point. It took a lot of re-engineering to get there (it was a prototype after all), but here's the rough cycle the player goes through:
- Main Menu / Landing Page
The player enters the game through this page and chooses a game mode:
- Arena: This is the game mode I've been focusing on. It is a single player (and possibly coop multiplayer) mode in which the player accumulates money in 'missions' and uses it to buy upgrades. It uses a fixed camera and an enclosed combat area (the screen) much like earlier titles (pac-man, spacewar!, etc.) It is meant to have an arcade feel to it.
Enemies spawn in waves, which the player defeats, until the mission is over (all enemies have been killed) or the player is damaged. It allows me to introduce enemies of varying strength and even bosses.
I'm still unsure how I'll handle player death however...
- Skirmish: This is very similar to the Arena except it is actually a PVP mode. All players join the game (preferably using controllers) and choose a custom set of ship components 'on a budget' and fight it out to determine the winner. Can easily implement team-based combat as well. From a logic standpoint, it is almost exactly the same thing as the Arena, only the pre-combat UI varies, and the actual play experience.
- Campaign: This is a mode that will be developed in the future based on Solar Winds. I've toyed with cameras a bit (just enough to make a fixed one) and I know this mode will require a camera that tracks the player's movement efficiently. It is relatively straightforward, but it takes time, and I'd much rather invest time in a simpler design for now and see where the fun factor lies.
I'm hoping this is the mode that will be the most engaging, but I'm glad I get to provide other less immersive modes earlier.
- Single Player setup screen / "Shop Screen"
Once the player has selected the Arena mode, he is prompted with a screen (WIP in the video) that allows him to choose the gear he wants to bring with him. The left side of the screen displays the available inventory (combines everything the player currently owns in storage and everything available for purchase) while the right one displays the current ship gear.
The system is rather simple to use and borrows from RPG inventories. Simply drag from left to right into the appropriate slot and the content of the slot will change.
Currently, all slots are fixed, but my intent is to 're-populate' the actual slots based on the hull selection. If the hull tolerates two weapons and not just one, a new container would be created to accommodate for the change.
- Victory Condition (Combat)
Combat begins, and a victory condition is set (generally, being the only side with any remaining forces, but could also be things such as surviving for X seconds).
I've put a placeholder HUD at the top which displays the cumulative life gauge and shield points for each team (the player is in the first slot, and the aggregated enemy ships are currently in the 2nd, but this will be changed in the future as enemies are bound to be added in waves).
- Outcome screen
Once the combat is over, a result screen is displayed. It tells the player stats about the match, and what he gets from it (money essentially).
Currently, the currency system is just an embryo (every kill nets the player some $) but ultimately, it will be used to unlock new gear in the shop, completing the gameplay loop for this mode.
If the combat ends in a victory, the next combat will be harder, otherwise, a different combat with roughly the same difficulty will be fought next, with un-determined consequences for the recorded loss (I'm still debating whether I want this to be a perma-death / arcade-style game, or a bit more casual / forgiving).
Metagame One of the most important changes I've had to do in the last 2 weeks was the conversion of the current 'dummy data' into a more elaborate and yet flexible metagame data structure. As can be demonstrated in the above video, ships are now assembled from a list of components that are selected by the player, and these components persist in memory thanks to that new data structure. It took a while, but it works great and it helped clean a lot of my prototype code into something much more intelligible / malleable for future implementations. It also forced me to slash my original game class into more specified classes: originally, as this was a prototype, the game class was handling nearly everything as far as game flow is concerned. Now, everything that occurs during a combat is a combatSession that is created from the Game instead. Semantics, I know, but it does make it a lot easier to work with!
Couple of other things I've glossed over:
- Bullet spawning positions (automated template)
Now, ship weapons that fire more than one ammunition with each shot will fire in preset orientations. This makes each attack more predictable and reliable.
- Accuracy variation
Although latent, I've implemented a system that cares about the accuracy of a weapon. It basically derives the course of a shot by an angle based on how accurate the weapon is. I have a few ideas of how this would be best used (shotgun-styled weapons) but I did not want to enabled this feature for now given how low-profile it compares to other development I need to do.
- Weapon Swap / 2nd weapon / Secondary Fire Mode / Special Trigger
I've mapped controls and modified all game systems in such a way that these would be relatively easy to implement (swapping weapons would be laughably simple actually) but I'm still thinking about what's the best approach here.
On the one hand, Raptor: Call of the Shadows' main weakness was the ability to have multiple weapons but rarely ever using this feature (except when purposely cheating the weapons cooldowns). I want to avoid spending time implementing a feature that looks good but serves no purpose.
Solar Winds provided a limited use for this by giving the player 'missiles' which were limited-ammunition power-weapons. My system is already accounting for ordnance (but never decrements it) so this would be easy to implement, but this would have an impact on my current approach to this game.
I'm also interested in seeing possibly 2 weapons firing at once, allowing the player to determine what's the best 'pair' for their ship (similar to how Silpheed did back on D.O.S.)
I've modified how physics worked in my game to give it a more 'space-like' theme. I've also mapped an input key that allows me to modify the 'rules'. When disengaged, the dampeners allow the ship to drift endlessly in the direction it was moving. Re-engaging the dampeners seeks to put the ship to a halt. While dogfighting, a mix of both allows for the best manoeuvres and offers the skilled pilot with more 'lethal' opportunities against the enemies. It is also an element the AI cannot use efficiently, so it gives players an edge, and makes PVP that much more different than Arena mode.
- Weapons: How far can I go?
I've shelved a lot of ideas for later on what to do in terms of weapons (*cough* cluster bombs *cough*) but I still wanted to get an idea of how malleable my current implementation was. Turns out I can actually make a laser without much effort. It is not fully functional as it will require a few modifications to my collision algorithm, but I was surprised to see how 'easy' it was to implement.
Lastly, I've done a few fixes and tweaks, most notably: There are no longer any 'ghost' ships (ships that were half dead so to speak and rendered victory conditions useless). This bug had been around since my early inception of this game, so it was quite a kill!
At the end of this 'stretch' I've got less clarity about where to go next. I should probably polish what I've just done, because it feels very raw (despite also being placeholder). My gut tells me however that I need to fully implement the 'Skirmish' mode now so that I can retain parity between single player and PVP and avoid bad surprises down the road.
I took about 4-5 hours in the last 4 days to look over the dusty code of the now defunct combat simulator for GS:SW and decided to see whether I could salvage it into a spinoff game. Let me examine here the changes it has undergone:
5 Players Mayhem! (Showcased: AIs, but also works as PVP!)
Working Title First and foremost, I had to come up with a tentative title to label it as a standalone from the original game (which is still WIP). I decided to go with the "Mercenaries" suffix. Why?
I wanted something that would convey the look and feel of what this is about. GS:SW is a 4X game, which implies building an empire at macro scale. Mercenaries is to be much more focused on a single ship and is meant to be an arcade/action type of game. I wanted for it to feel a bit like Raptor: Call of the Shadows and Solar Winds (in which you play a bounty hunter / mercenary of sorts). Decided to come up with the Mercenary code-name for now.
Why plural? Because it will have hotseat multiplayer support of course! (both COOP and PVP!)
Debug Before I could start on actually changing the code base, I had to refactor nearly all classes and debug a bunch of crap I had left behind (it was a prototype after all, which was done as quickly as possible). I ended up fixing bugs that had eluded me for a long while. I've been a good boy. That did not amount to much initially, but it really helped me reach the velocity I intended to have (and much faster than I thought!).
In the following 5 hours, I've successfully done:
Multi-player hotseat There are no winning conditions yet, but up to 4 players can join a game. You might think it sucks to have 4 people crammed on the same keyboard right? Well, because I'm both ambitious and lazy, I wanted to have controller support (gamepads) for this game, but since it turns out it is very hard to implement with browsers, I've been using antimicro 2.4 which is a GNU-licensed software that allows you to map keyboard keys to your gamepad. Not perfect, but definitely much more fun, and also allows 4 people to easily join the same join either as a team or to kill one another.
The best part is how this all works. You could play 1v1, 2v2, 1v3, etc, or 3vAIs. But you could even go as far as: P1 has 3 AI allied, P2 has 2 AI allied, etc. The possibilities are endless and I'm having a lot of fun toying with game modes.
That being said, choosing to have up to 4 players meant I had to take very drastic decisions early on. One of my original ideas was to have the ship controlled through WASD (W D for throttle, A D for helm rotation) and the mouse to control the weapons (aim anywhere on the map and blast them). Since there can ever be only one mouse, I had to let go of this idea and make a control scheme (and features) that would map to a very small amount of keyboard keys instead.
I wasn't originall hellbent on the idea of hotseat multiplayer, but as I developed the input, it was the first thought that crossed my mind: this would be great as a couch coop or PvP arcade game! Sometimes you just have to follow a hunch and go with it. I felt that, if GS:SW - Mercenaries had a chance to be different than all of the space shooters out there, I had to seize it. This seemed like it, and it gave me renewed hopes that this concept would translate better to a steambox or console (one can always dream).
Modified "Physics" I wasn't too fond of how rigid the original game felt, but I could live with that. The reason I actually went around and changed it was because, in the original simulator, there was simply no reason for the ships to 'move'. Once they were in optimal firing ranges, all they needed was to make sure their helm was still pointing at their target and dealing as much damage as possible. It didn't feel like it would be possible to circumvent enemy fire and deliver salvos onto their hull.
I've has to refactor the entire movement logic (which turned out to be much easier than I thought, thanks to my very (unnaturally) clean code!). The game now 'assumes' that your ship has thrusters that are used to stabilize it in deep space (effectively stopping your ship altogether), but movement itself may derive slightly from your helm direction because it is somewhat vector-based.
What this opens up is a series of possibilities where you can accelerate and quickly turn your pitch to do some strafing fire on your enemy's flank without fear of retaliation. This is the first major step I've taken to turn this into a skill-based game and the first game design decision I've taken to truly support movement as a key component of this game.
Dummy Balancing We're still very far from getting any decent form of balancing, but the original numbers (random generators) were simply misleading. Furthermore, they were meant to support a static combat playback, not an actual game. Quickly after implementing player input, I've come to the conclusion (through playtesting with my girlfriend and brother-in-law) that it didn't feel even remotely close to what I wanted this game to be.
I've increased all firing rates, made ships more agile and faster, reduced the amount of weapons and made some minimal rules for randomly-generated weapons so that there would be some kind of sense of fairness in combat.
Placeholder UI I've scrapped the original UI that was no longer relevant and put together something hastily to convey the feel of what I'm trying to achieve. It isn't much, yet due to a series of latent bugs, it is the one thing that took the longest to make. It reinforces information that is already on the screen by color-coding players (that has yet to be done on the ship assets themselves).
I don't feel I'm there yet, but I've made some significant steps in the right direction. GS:SW Mercenaries definitely feels different than it's daddy now!
What's next? I've hesitated between two approaches for this game. - 1 - Refine/Polish the main gameplay (combat arena) as much as possible to make sure it is fun or - 2 - Build a complete flow of a game mode I envision would work
I've spent a little time following "1" and I feel it is hard to make final decisions on anything until I know what the entire flow would be like. I have way too many header constants that allow me to turn on/off certain features or behaviors just so I don't lose track of them (in case I want to rollback). Overall, it is hurting my code base and my ability to make decisions. For these reasons, I'll be turning to "2" in the coming days. I'll try to build a game mode / flow / loop and see how fun/addictive it can be prior to revisiting the actual combat.
As per usual, feedback is more than welcome!
Me, taking a beating from a carrier-ship in PvE (1:1)
A year ago, almost day-for-day, I started work on a game project which would later be known as Grand Strategy: Space War. (Don't worry, I'm still working on that!)
A few months ago, we've chosen to scrap the way the combat system is currently handled because it does not meet our expectations of what would fit within the game. However, there was some good progress made with that and I've toyed with the idea of converting this simulator into a mini-game: a GS:SW spinoff of sorts.
Here's the last video of the combat playback that was published through my youtube channel. As you can see, a lot of it was severe WIP. The simulation aspect was fully functional however, and the code was starting to look good.
Two teams fighting with relatively straightforward AIs. Simple eh?
So I've been thinking long and hard about a way to turn this into a mini-game/spinoff, and here are the dilemmas I've ended up with:
1. Game Type
I'm left with 3 main options that I'd like to explore.
A - Make it an arena-type arcade game where the player spawns at the center, and enemies spawn on the edges endlessly. Player accumulates points by surviving as long as possible, and killing as many enemies as possible.
I get to keep most of the development I've already made.
Additional programming is minimal (Score system, enemy spawners and player).
I'm afraid it could be a bit boring over time and a very short-lived experience.
B - Make it an arena-type arcade game where the player spawns at the center, and enemies spawn on the edges in fixed numbers. Player accumulates money for each kill. If he survives the entire wave, he gets to spend this money on ship upgrades for the next level.
I get to keep most of the development I've already made.
Additionnal programming is relatively straightforwards (except for the entire metagame aspect).
There are a lot of unknowns and I'd like to be sure that the "shop" approach is worthwhile before making it part of the gameplay loop.
C - Make it an open game where the player spawns in the universe and can freely move around. He encounters enemies randomly. I could add shops, etc.
Seems like there's a lot of untapped potential in this idea, and very cool gameplay to make.
This is meant to be a prototype spinoff, and I feel this would require a lot of additional code before it is even playable.
I'm afraid of feature creep and I don't want to lose sight of development on GS:SW itself.
Beyond the game type however, there are a number of other questions that need answering...
2. Player Controls
I've investigated a number of ways the player ship could be controlled, and I'm still trying to find what's the most suitable approach in regards to helm rotation, camera and "aiming" weapons:
A - Have the ship's helm rotate based on the mouse coordinates.
This feels "right" and gives some freedom of movement. It might be more intuitive to newcomers and can lead to interesting arcade moments.
On the downside, it would limit my options for aiming controls (see below) and other inputs (gamepad, mobile tap, etc.)
B - Have the ship's helm rotate based on "A" and "D" (Solar Winds)
This can be a bit imprecise and may lead to some frustration. Also, not everyone has a clear understanding of how that works when the ship helm faces south and you press A (it will still go counter-clockwise...)
Definitely not suitable for mobile, even though that's not a current goal.
C - Have the helm adjust automatically by selecting a target (this is how enemy ships AI works: trying to match an angle that's in line with the target).
The enemy ship AI determines a target and moves towards it by adjusting helm as needed. Making it a "point and click" would make this game much less of an arcade game and much closer to a RTS, but it is worth considering the option nonetheless.
A - Fixed Arcade Camera (status quo)
Basically, "as is". the game takes place within the current "box".
I think it suits the game well, but makes keyboard-based controls tougher to implement well.
Opens up Coop and PVP play options.
B - Tracked Camera
Here, the camera always has focus on the player (keeping it at the center of the view).
C - Camera Rotation
Here, the camera keeps track of the player as he moves, but more importantly, as he turns. This effectively means that the ship never turns (always faces up) but that the world around it does.
I feel it could be a bit disorienting in a large map, but could otherwise simplify input challenges.
A - Have the weapon firing from the ship's front (status quo)
Basically, upon a certain keypress or mouse click, the weapons would fire in the direction the ship is facing. The challenge would be to line-up the ship with its target without having the opponent face you back. It's an interesting premise as it forces the player to flank the opponents to destroy them without retaliation. This is reminiscent of Solar Winds.
B - Have the weapon firing in any direction the mouse is pointing
Would give the player a big edge (although I could grant the enemies the same advantage). Positioning becomes less important, and leading targets becomes that much more important. I feel that it could lead to total mayhem on screen though.
This would greatly limit my ability to do 4 player coop or versus (mouse).
C - Have both (primary weapon A, secondary weapon B) where B is used mostly as a counter to missiles and fighters
Have one keypress or mouse click to fire the main weapon (big damage) which has a fixed orientation (front or sides maybe?) and a second input for the secondary weapon - could be a top-mounted turret - that is particularly useful to intercept incoming missiles. May be adjusted into a gamepad joystick feature.
That's where I currently stand with this, and I thought I'd ask for feedback before making a move.
I've made a lot of progress with the combat simulator and I wanted to take the time to validate the current direction. I figured, why not share this introspection in case this could benefit anyone...
At first, the prototype was a very simple system where ships would move towards and/or fire at the closest enemy. Ship rotation was automated (would "wrap" in the right angle") and move direction alrogithm followed the straight line logic.
This approach was sufficient, because our intent was to have a mechanically-efficient way to determine outcome in a deterministic combat system. "Appearance" wasn't really a factor, and we just wanted players to be able to gauge the outcome of a fight based on their previous experiences.
Different AI patterns (movement)
In an effort to make the outcome less predictable and insure that play experience was a factor in figuring out the outcome of a fight, we've attempted to modify the movement AI pattern in various ways.
Two interesting behaviors stood out: 1 - Stop 'n Go: move into firing range, and idle while able to fire. Then, move to the next target and so on. Mechanically, this answered all of our needs, and was efficient.
2 - Continuous Chase: Ships wouldn't stop, and would adjust their helm in "orbit-like" manoeuvres around their enemies. The result was close to "fly-by" sequence as per modern day air strikes, and similar to a lot of sci-fi space battle games. Though it reinforced the theme, it didn't add much depth to strategy per se. For the time being, this mechanic has been shelved (for later use?). Though it introduces a bit of uncertainty and puts more importance on a ship's manoeuvrability, we're still not sure the added complexity (and visual confusion) adds enough to the depth of the simulator to keep it as is.
In an effort to allow players clear access to the "numbers" behind the game and help them learn from the outcome of each battle, we've added some feedbacks:
1 - A life gauge so that players can track the damage delivered to each ship.
2 - Floating numbers that represent damage dealt by each projectile, which helps determine the relative strength of each projectile, and establishes a relationship with the gauge to let players know how "resilient" a ship is.
Up to that point, the game had assumed that each ship would only have one weapon (we had randomized range, firepower, rate of fire, etc.) As we refactored the system, and created a Weapon Component Class, we were able to "attach" these weapons much more easily to different ships. We were then able to have many weapons per ship.
That was a game changer in that we could shift the AI of a ship across its component. For example, the ship itself (later, the engine component) would determine where to move, based on the optimal firing range of the aggregate of its weapons systems. Then, each weapon system would individually determine the "ideal" target from a list of targets currently in range.
This started adding a lot of depth where we could see drastically different overall AI (move and attack) depending solely on which weapons we would put on board. The choice of NOT putting a specific weapon also created interesting scenarios.
For example, as can be seen in the video above, all weapons try to fire at the "weakest" enemy (lowest hp) that is within range. For short ranged weapons, this is generally the same target as the one the engine use to move towards, but for missiles with longer range, this allows them to provide support firepower to distant areas of the combat. Fighting off the "weakest" is desirable most of the time as it can contribute to reducing the opponent's overall firepower more quickly and reduce the total amount of damage taken by your ships over the course of the fight.
As a result, a ship with JUST missiles can provide support to a number of fronts, all the while staying back, but a ship with missiles AND cannons will put itself in harm's way, fighting its vis-a-vis with guns, all the while lending its firepower to distant targets. Depending on the relative resilience of that ship, either of these may be preferable to optimize damage output. The synergy between these two independant AI systems seems to be fertile in emergent strategies.
There are still a lot of missing elements to this simulator, and we're still iterating on that, but we believe there's enough here to criticize on. If you have suggestions, please do not hesitate to jump in and provide us with much welcomed feedback!
Our intent with the video is to acquire feedback from players to see whether we're catering to their needs.
A blend of pixel-art and concept art with Super Metroid-like music in a modern browser interface? What kind of 4X game is THAT?!
We've been hard at work to make our own recipe of old and new trying to redefine the genre we love. Most modern installments of the 4X genre have stagnated in the "more ship customization" and "more tech trees" habits, making the genre less accessible, and less enjoyable.
4X games, before anything else, are games that should be fun to play, and should occur in the environment, not in interfaces. Ship customization can be fun, but its a time-consuming process that hides you Galaxy. Tech trees can be satisfying, but then again, they're pointless if you lose track of the worlds you want to conquer.
Grand Strategy: Space War does away with this. All of our menus are draggable (for a customizable UI) and allow you to always keep track of what happens in the Galaxy (because that's where the fun trully happens).