End of the week report.

Alright, it’s Sunday, so lets wrap things up.

Since Thursday…

  • I’ve added background music and 2 sound effects
  • Worked on general accessibility and minor irritating bugs
  • Added a main menu and game over menus
  • Added a second test level
  • Reorganized the project a couple of times

Generally weekends are not a good time for me, so that’s a reasonably good progress considering. I am not happy with all the hacks and cheats I am allowing myself to put in the code. I’m not used to this methodology at all, but it’s all for the sake of efficiency, we’ll fix that tomorrow :)

Anyways, here’s end result:

Play button image

Day 4 – making things pretty… er

Today was mostly dedicated to visuals. I started the day with 3 new block types:

  • ground/grass – which replaced the previous giant ground box, and allowed for making holes
  • water – so that the holes don’t look so awkward (its an impassible indestructible block, which allows for bullets to fly trough)
  • crates – for now they just take two hits, jiggle a bit and get destroyed (a little bit like bricks), but I have huge plans for them

Then I decided to add some texture, because plain colors were starting to look boring. I also meddled with Unity animations and finally got the hang of them (I think). Minor game-play tweaks, minor setting adjustments here and there, but nothing really significant on the functional side.

WIP tank game screenshot

3 days in…

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

BattleCity screenshot 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.WIP tank game screenshotI 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


  • 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.

How to finish your game?

Historically my individual projects have suffered from a syndrome called “feature creeps”, they always start small but grow exponentially in complexity until the point they are impossible to complete. Other times immense amount of time gets spent on features which turn out to be unimportant. Either way the finish line remains out of sight and the passion that started the project eventually burns out.

A healthy response to a problem is to acknowledge that you are not the first person to have experienced it. Others have probably found the solution, in which case Google becomes your best friend.

Here are some resources that aim to answer the question:

NotePad++ Lua Function List (with tables)

This morning was a morning well spent, despite being constantly distracted I managed to roll up my sleeves and do a lua function parser for Notepad++ (rather than wasting my time with actual work). In the process I learned that a) Notepad++ function list doesn’t support lua by default, you have to add them manually, b) the function list looks very pretty and allows not only function but class definitions as well c) regex have lookaheads, lookbacks and K.

I used this StackOverflow question as a starting point, but noticed that the solution that best matched my situation ignores table functions. This was unacceptable because most of my code tends to be structured in classes. After fiddling around with it I got it just about right.

The first thing to do is locate functionList.xml and open it. It may reside in the installation directory or %APPDATA%Notepad++, depending on your installation. Open it and add to <associationMap> the the folloing:

<association langID="23" id="lua_function"/>

The next snipped is added to <parsers>.

<parser id="lua_function" displayName="Lua">
	<function mainExpr="^[t|locals]*functions+[^0-9][_A-Za-z0-9.: ]+s*(" displayMode="$functionName">
			<nameExpr expr="[.:]?s*K[^0-9][_A-Za-z0-9]+s*("/>
			<nameExpr expr="[^0-9][_A-Za-z0-9]+s*("/>
			<nameExpr expr="[^0-9][_A-Za-z0-9]+"/>
			<nameExpr expr="functions*K[^0-9][_A-Za-z0-9.:]+(?=s*[.:])"/>

This will group together functions defined as <class>.<function> and <class>:<function> (or <class>.<class>./:<function>) and place them in their appropriate classes in the Function List viewer. It will also capture lose global or local functions and display them as normal. It will unfortunately accept illegal constructs and definitions, but you get compile errors for those.

Battle Dyzx continued…

It’s been almost a year since I officially started the project, although I haven’t been working on it full-time (I had to leave the project in July and only picked it back up this January). I really wanted to keep a full development log, but got carried away developing… and for a significant amount of time I had no connection to the world (wide web), but enough excuses, lets do a quick recap…

My last post was in May. The first change that occurred after I came back to it was to abandon test-driven development, as once again I got convinced that it is a major buzz-kill and not very appropriate when you have to play with the product (it could be just me though). Once unit testing was out of the way things got wild, in a matter of a few hours there were tops chasing each other and clashing in battles, going in and out of the arena. This only proves how powerful evolutionary prototyping is for games. The first milestone was making the dyzx human controlled, but later I added some basic AI that could chase, go random and/or avoid being kicked out.

The arena had a pretty nice evolution. At first it was darkness (just a normal map), the first natural step afterwards was to use that normal map to lit it up, and so there was (directional) light. Eventually I added point lights as well. But more interesting than the visuals were the gameplay aspects of the arena. At first the dyzx (tops) were merely controlled by the normal map, at some point I had to implement the arena-out event (when dyzx leave the stadium they die) and with that came the holes, it was now possible to place holes anywhere on the arena that would kill dyzx that fall into them. At a later stage I made it possible for dyzx to bump into high arena features, which could be placed at strategic spots to prevent dyzx from flying out of the arena or falling into a hole. When I was doing the dyzk-arena collision I initially planned to make the hit model for the dyzk a circle (just like in the dyzk-dyzk collision), but for simplicity I only implemented it as a diameter line running in the direction of the dyzk velocity. I knew very well the drawbacks of this approach – if the dyzk goes straight towards the fall and hits it front first then it works, but if it goes sideways the collision won’t occur and the dyzk would climb the wall instead (because the slope isn’t as steep when you take it under an angle) – that behaviour was not intended, it was a bug… Then it hit me that was actually a wall-ride trick, you could use it to get to otherwise unreachable places, or gain extra acceleration. Up until that point I thought of the arena as a dyzk container where the main attraction would be the battles, but it can be much more than that – it can easily become a skatepark, a place full of obstacles that brings out the best of action players and becomes a battleground for demonstration of skills other than mere brawling. Shortly after that the gameplay entered the third dimension. X and Y were sufficient when we only had a normal map to navigates us in the 4 directions, but now we needed Z so that we can catch air and fly around the map. After reworking the physics a bit and faking 3D visuals I got to the current state of the project.

Here’s a video:

There is still a whole lot more to do. I’ll be really happy once I manage to get online multiplayer working (but it will probably be some time before that happens).

Finally done

No more exams, no more side distractions, no more time wasters… I know I’ve been saying that for over a month now, but I hope this is the last time I say it.

Unity’s support for android (and iOS) is now free and I’ve been postponing it, but I think it’s high time I actually learned how to use unity, LOVE 2D is awesome (it’s 2d, it’s open source and it’s lua based, what’s not to like) but it’s platform support is still lacking and I was hoping to be able to make games for OUYA by this summer.

Unity’s 3D and even though I don’t particularly mind 3D games I know from experience that they are harder to produce, and not just the art, but the code, and usually 3D is an unnecessary complication in terms of mechanics (few games really benefit from the 3rd dimension).

I also took too long before I started serious work on the Battle Dyzx project, and lost interest, so I’ll drop it (and come back at some time later). I’m starting a strategy game with dice, which I do not have a name for yet. I’ll need to detail the rules in another post, but the main idea is that it is based on constructing a set of dice and cards and reading and manipulating probability in order to win. It should be a game which looks and feels like gambling, but is about making and controlling the odds rather than a series of random events. There are gonna be monsters too :)


Ok, time to do some management. University’s just ended… only formalities are left, which means no more deadlines and restrictions, I have all the time I need, and can use every hour of every day, so let’s make sure I do it efficiently.

A couple of other game ideas ended up in discussion – a traveling merchant in post-apocalyptic world. It was Emo’s idea which is why I was keen on continuing it, but we couldn’t get it to a point where it has any objectives or final goals, so it would end up being a toy and toys aren’t that fun. As it turns Emo wouldn’t be available in the following few months, he’s got a busy schedule, I alone wouldn’t attempt to tackle it especially when I haven’t got a clear idea of the gameplay nor have I prototyped it, besides I would lose interest if I’m not working in a team, therefore I shall continue with “Battle Dyzx” for now. The primary objective is to get a (incomplete) working version ASAP.

TDD is occasionally helpful, but very distracting and slows the process, I start to feel like it better to do RAD instead of XP. Next steps will be to properly address what needs to be done and try to plan at least a few weeks ahead.

Unity has announced that mobile games tools are now free, I have to absolutely learn how to use it and start using it. So there might be a slight change of plans. The game has to be 3D unity based!

21-26 May

This will be the basis for the multilayer and the battle system itself

  • Get a spinning disc working
  • integrate joypad control
  • make a server
  • have two discs remotely controlled on the same server

27 May – 2 June

Dedicate most of this to the battle system,

  • collisi0n
  • clashes
  • more physics battle mechanics

Later on start thinking about progression, how to improve the performance of tops over time, possibly without adding too many artificial numbers I would love to keep all data associated with the image only.

Battle Dyzx

Top War sounds a little generic and uninspired, it was a placeholder after all.

After a giving it some thought I realized that a small flat circular object is not a top, but rather a disc. After tilting it a bit it looks even flatter than it should .

scaled down spinner that looks flat

see what I mean? It’s flat : )

I could of course draw a line or a beam through the center of the image but that would be too easy. Instead I decided to declare the spinning objects to be discs. I thought disx sounds cool, after a while it turned into dizx and I though “I need to get a Y in there” so it became dyzx – seemed to be unique enough in google, especially in combination with “battle” it yelds no results, so I claimed it! :3

Normal Arena

Did creating of a normal map from a depth mask yesterday, which will be used by the game physics. It was quite a challenge to get it right in the first place and then to get to perform well in lua (here’s the relevant source bit). Just for the fun of it I made the top follow the normals and this is the fruit of all those effort:

It still takes about 1 to 5 seconds to process a 1024×1024 image, but at least I’m sure it does it in the most optimal way :)

It is sort of important to save CPU cycles when doing physics stuff because all of this will have to be handled by the server. Love2D allows saving of image data so once computed it could be stored for later. And if bad comes to worse this can always be implemented in C…

Next step will be getting this tested and integrated in the trunk (boring stuff) and making of a server and a client.