For months now I’ve been pottering around with various game ideas. I’ll code up a bit, get something working that is miles away from being a game before moving onto the next thing. The reason for this is I’m not treating it like any proper development that I would do, but rather as a learning exercise that leads to me jumping onto the next interesting thing.
If this was my day job I’d be doing the following:
- Try and get an idea as to what the basic requirements for the application are. What do people expect it to do?
- Make something that sort of works for the first bit of functionality as quickly as possible, and always keep it working as a full application. If management are inclined to confuse “working” with “finished, let’s ship it!” then don’t tell them about that bit.
- Add features along the way as needed. Unit test them while working and don’t be afraid to refactor.
I have an idea for a game. It’s a 4X space game, and I’m not exactly making it with the right intentions which is causing some problems. I have a folder full of half coded ideas as I flip between different cool bits and I’ve not really considered what I’ll do about releasing it. The goal would be to get rich and retire of course, but that isn’t going to be this game. This is a chance for me to learn the tools and have a poke under the hood of a genre.
At this point it doesn’t actually matter about anything in the game other than it is 4X. I have pages upon pages of ideas written down and I have the direction sitting comfortably in my head, but for the first goal I need to set a task that satisfies my three points. This means that I have a working game that is winnable and has as much unit test coverage as I can manage.
The first is actually easy enough as the general direction is eXplore, eXpand, eXploit and eXterminate, which are of course the four Xs of 4X. This means I can move onto step 2 without worrying. The genre itself gives enough direction at the start and I imagine that many genres are like that, and many a game has probably been condemned to mediocrity because of it.
Moving onto the design for a fully contained but incredibly basic game I’ve settled on the following:
- Title screen that contains New and Exit.
- Procedurally generated universe. Sounds more difficult than it is, just random numbers for now.
- Links between the systems.
- The systems all displayed on screen with shiny programmer art.
- Return to title screen through a quit button.
- Next turn button that moves the universe on (i.e. increments a turn counter)
- Ability to conquer systems to your own faction through arbitrary means and no resistance.
- When all systems are owned show a win message and return to title screen.
That’s the smallest 4X game I can come up with. Actually it’s just eXpand, but it’ll do for now as it ticks the box for a winnable game even though there is no challenge and you can’t lose. It does however satisfy step 2 though so I can move onto step 3, which is actually implementation.
My tool of choice is Unity but using Visual Studio instead of Monodevelop. This leads to a couple of easy choices such as unit testing can be NUnit or MSTest and fully outside of Unity. It brings up the problem of not being able to test MonoBehaviour derived classes due to the fact it doesn’t work outside of Unity, but that actually leads to better design as it forces me to extract game logic from Unity implementation and means that should I ever want or need to change engine that I’m all set as long as it supports .NET.
This leaves me with a small-ish chunk of code to write and a commitment to publish it here using the Unity web player when it’s done.