About this blog
Development Journal for Grand Strategy: Space War
Entries in this blog
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.
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
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
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)
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!).
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)[/font][/color]
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.[/font][/color]
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.[/font][/color]
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.[/font][/color]
Unity 2D is great... for platformers. [/font][/color]
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.[/font][/color]
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.
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!
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!
"Let there be Game!"
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).
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
[indent=1]The player enters the game through this page and chooses a game mode:
[indent=2]- 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.
[indent=2]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.