Late Update (v0.0.2)

v0.0.2 is out you can play it here:

Play button image

I have not posted anything in over a week, so to avoid falling back any further here is a historically ordered summary of the progress since the last post.

Meet the Weaggles

First and foremost we have the weaggles now – small purple creatures that pilot the tanks and love destroying things. A name born by to unmatched creativity or simply lack of imagination (…cuz they have no arms, they can only wiggle).

A sketch and an in-game screenshot of the weaggle character

Left – a weaggle design sketch (pro art skillz),  Right – a 3D weaggle riding a tank in-game

Lights and Shadows

The next modification was rather minor, but made a huge impact. Making the light brighter changed the gloomy look of the game into a full of color bright and happy toon (which is what we want :)). Dynamic shadows contribute even further, however they come with a big performance hit (my rendering isn’t exceptionally optimal).screenshots of the game with low light, brighter light and shadows enablesOne thing that’s worth mentioning is the color ramp. There is a rule in art/color theory that states shadows are blue… so our ambient light is not the default unity gray, but rather dark blue. Likewise our sun (directional light) is not white, but soft yellow.Unity ambient light and directional light color settings

Spawn Mechanics

Kudos to Yani Genev for helping out on this. The original spawn mechanic was based on an abstract resource that was hidden somewhere, the player had 3 resource points (which are equivalent to 3 lives) and the enemy tanks had 20. If you broke the enemy bases, before the spawn resources were depleted you would be able to achieve victory (which was my way of making the bases an alternative target). The system worked, but it wasn’t as elegant as the one Yani suggested i.e. removing the abstract resource and making spawners pay with their hit points. The reason the new system is better is simple – there are less numbers for the players to keep track of. But there is more, destroying an enemy base or even just damaging it, has a more direct impact on the game (the more damage the less tanks). On the other hand having your base shot at isn’t as punishing – it used to take only 1 hit (and you lose all of your lives), now it drains your lives gradually.

The player base with its hp

Wiser AI

Now that they have someone controlling them it was expected of enemy tanks to become smarter. The AI now targets both the player’s tank and his/her base (as opposed to moving and shooting randomly). See above screenshot :)

Special Effects

EXLOSIONS and brick shattering all over the place, destroying things is now even more fun. When a tank is destroyed it explodes and bricks shatter creating physical particles. Here’s a screenshot showcasing both effects:An explosion and brick shards

What’s in that box?

…who knows, maybe random goodies…

Here’s a quick status update.

My quick and dirty physics implementation has been replaced by the Unity Physics Engine. Everything is now physical; tanks can push other tanks or crates, climb up slopes and fall down in holes. On top of that movement is still grid based (which was actually the hard part).

I added a new kind of crate – the [?] Crate that drops a random power-ups when broken. The selection of power-ups isn’t that great at the moment (only 2), but it should grow bigger by the end of the week. Here’s a screenshot:

Powerup Screenshot

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

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.

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">
		<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]+"/>
		</functionName>
		<className>
			<nameExpr expr="functions*K[^0-9][_A-Za-z0-9.:]+(?=s*[.:])"/>
		</className>
	</function>
</parser>

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.