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.

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 :)

Time!

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.

Spin bluuuur shader

When something spins fast, it blurs. It has to otherwise it looks as if it’s rotating by arbitrary angles. Originally I had this effect done by rendering the same image multiple times, each time slightly rotated and more transparently than the previous time. Yesterday I tried doing it the GLSL way, which looks way better (and is faster). Here’s the result:

SpinBlur

And here’s the shader:

uniform float angle;
#define NUM_ROTATIONS 30

vec4 effect( vec4 color, Image texture, vec2 texture_coords, vec2 screen_coords )
{ 
    vec2 center = vec2( 0.5, 0.5 );
    vec2 relPos = texture_coords - center;
    vec4 finalColor = vec4( 0.0, 0.0, 0.0, 0.0 );
 
    float progression = 0.0;
 
    for( int i=0; i<NUM_ROTATIONS; i++ )
    {
        float angleFract = - angle*float(i)/float(NUM_ROTATIONS);
        float cs = cos( angleFract );
        float sn = sin( angleFract );
        
        vec2 newPos = vec2( relPos.x*cs - relPos.y*sn, relPos.x*sn + relPos.y*cs );
        newPos += center;
 
        vec4 tex = texture2D( texture, newPos );
        float rate = pow(float(i),1.2) * (tex.a +0.4);
        progression = progression + rate;
        finalColor += tex * rate;
    }
 
    return finalColor/progression;
}

Spinning Tops

I had prototyped a spinner based game earlier in November (I think) and it was very fun to play against my brother, but I couldn’t get to develop it because of the constantly emerging university deadlines. Finally uni’s over which means I’m free… at last until the exams come.

The game is supposed to be an action/fighting game where 2 or more spinning tops fight to the death. It was mainly inspired by the cheap plastic Chipicao spinners I used to collect as a kid (good times…), and they were in turn based on beyblade. There are a couple of Beyblade video games for different consoles already and they new ones keep coming out. Unfortunately it isn’t a ground-breaking idea, people have been making tops for millennia, but there aren’t great many (enough) spinning top games either (especially for PC), plus I really want to make this one.

It is a seemingly simple scenario – there is an arena or terrain (usually bowl shaped) and 2 or more spinning tops. Gravity moves the tops as low as it can (i.e. towards a local minimum) and rigid body physics sends them flying when they touch. Although simply watching this simulation (over and over) becomes more boring by the second, it peaks the interest when you try to predict the outcome and reason about the underlying system, especially if you have the choice of what top(s) to use. Adding the ability to control one of the tops to a certain degree while it still obeys the laws of physics adds even more fun to the equation as now players are no longer mere spectators. Being able to defy and exaggerate those laws on occasions (or more importantly your opponent’s ability to do so) adds a pinch of unpredictability. To cut it short, just the core concept of it sounds enough to keep players engaged.

Anyways, I’ve been playing with this yesterday and since the first prototype was a complete mess (merely a proof of concept), I had to start from scratch. There are many ideas that will go in the mix (and probably more that will drop out), here are a few of them:

  • Tops are flat 2D images which rotate on the screen and bump into each other.
  • Each top has the following primary stats – WEIGHT, JAGGEDNESS, RADIUS, BALANCE. These are directly calculated based on the image. The more pixels, the more weight, the less of a circle it is the more jaggedness, the more off-center the mass is the less balance… you get the picture.
  • In addition tops will have secondary stats some of which are based on the primary ones – MAX-RPM, PUSH-BACK, ENERGY. Stats are a really boring part of the mechanics so I’ll skip the explanations… :)
  • Special abilities possibly based on the colors from the image
  • Arenas are 2D color images with a depth mask. The depth mask determines the incline and can also be used for lighting (and possibly displace mapping).
  • It is a 2D game (no need for a 3rd dimension) but with a couple of cheap tricks can be given 3D-ish look :)
  • Competitive multilayer on a single machine or over the network.