Well technically 3 and a half. I started this project on Sunday (15th of September). Lest see if we can finish it in one month :) I’ve been wanting to learn Unity for quite a while now, especially because every client seems to demand it nowadays (so many people develop games for the Android). Usually I would go around and try to get inspiration from a number of games, movies, books or plain concepts, then try to blend them and try to get something original. This time around though I decided simply to make a clone of an old Nintendo classic (clones are something I generally despise). No, it’s not Mario.

It’s BattleCity

One of the greatest things about NES games is that they are inherently simple (due to hardware limitations), a tiny set of rules with small number of objects and simple interactions between them. With such constraints it is hard to make something monstrous which goes out of control and never sees the light of day.

Lets see if we can pull this off with Unity.

Up until now I had only launched Unity a couple of times, just to test the waters, but never done anything serious with it.

Mind you, I have been crating games since I was 15, every experienced software developer would say, once you’ve learned a couple of languages it no longer matters what you write code in, C# is no exception (it’s essentially “C++ meets Java”). The user interface and Unity’s API and features was something I had to get more familiar with, so half of the time I spent in tutorials. My impression of Unity is that it’s one of the most powerful RAD tools for game development. Seriously, for a person who’s never used a professional editor with a powerful engine it’s just mind-blowing, and that wasn’t one of the things they thought at my uni.

What used to baffle me about it was the component based architecture, normally I would wrinkle and try to figure out how to make best use of a tool, so that my code can be reused later on (I tend to over-think software design and obsess with quality), this time I decided to just go with it and optimize, redesign and generalize later. After all the generally accepted right way to get things done is the lazy way – YAGNI and “don’t fix it if it ain’t broken”.

Mah game

Surprisingly I was able to prototype a somewhat complete 3D clone in those three days (in terms of mechanics anyways). But why not, if I can make a Ludum Dare game in a weekend using Game Maker Studio, why should I not be able to create a complete game in the same amount of time with Unity.I decided not to deviate from the original game too much, at least at first with an imposed constraint that I can remove features, but not add new ones, so that I can keep the number under control while learning. That turned out to be a little harder than I though (and my game is already starting to differ from its ancestor), but I’m trying to tame my imagination and get to a finish point this week. The current feature set includes:

• Indestructible blocks (steel) and destructible blocks (brick blocks made out of 8 bricks)
• Bush blocks – hide tanks
• Holes – tanks cannot pass through them (like the water in the original)
• Enemy and Player tank spawners (each being able to spawn and upkeep a limited amount of tanks)
• Simple enemy AI – enemy tanks just go around and shoot randomly… like cockroaches with shotguns

Additionally

• Tanks are able to move and shoot in 8 directions
• Provisions have been made for multiple teams (can you feel the PvP :))
• Some work has been made to support Z layers (Y in unity), so that the gameplay is actually 3D (and not just the graphics)

Besides this I have a growing number of features I want to add, but I’m cautious not to start on them too early. There are no power-ups yet and I may or may not add them in the first version.