About

“Weaggles: World War” is a simple physics based 3D arcade shooter with tanks, inspired by the Ninitendo classic “Battle City “. You play as a yellow tank and your goal is to destroy the enemy tanks and their bases while protecting yours. Initially it was my get-to-know-Unity project, but it has evolved a little by little since, until it finally ended up being a proud entry in my portfolio.

Features

• Seemingly simple yet challenging
• Emergent gameplay produced by the interactions between in-game entities and the player, physics also helps
• Early PlayStation inspired graphics style with cartoon-ish look (and a few modern twists)

Planned:

• Eventually it will be available on both PC and Android (maybe iOS); and have
• Seamless local and crossplatform online multiplayer for up to 4 people

Status

The project is currently in active development. Upcoming feature is multiplayer and networking.

Challenges

One problem I had with the first (two) snapshots was the rendering speed. It was being sub-optimal due to a large number of draw calls, caused by the multiple blocks that made up the levels. In Unity4 static batching was not smart enough to combine meshes together, luckily there was already an efficient solution created by Alex Vanden Abeele, so I didn’t have to do a thing. Unity5 came a built-in solution.

There’s a little more to add but I’ll come back to this after I’m done with the multiplayer and networking.

Retrospective

I took on this project, because I wanted to learn Unity. And to be honest it is hard to talk about challenges as Unity made everything easy, learning the API was a no-brainier (they’ve really put a lot of care and effort into the official learning materials), getting familiar with all the engine features was a breeze and applying that knowledge into my game was also straightforward. Indeed the development of this game has been nothing but pleasant, especially for someone coming from a low-level coding background who is used to doing everything manually in code. With Unity most of the time it was just a matter of putting things together and tweaking settings.

What’s more I went into this endeavor with the presumption that it is going to be a small game and in fact the development was supposed to end within a month… it was an attempt to keep things simple for a change. After the first month (and a half) it was in an OK state and I could have taken actions to finalize it, but I wanted to keep working on it… and then another project happened and I had to pause the development only to return one year later.

I was aiming to make a release every so often as a result the game remained simple and easy to keep under control. I was able to incrementally add small features that would appear in the next release. Usually each sprint would last one to two weeks and I would try to mark the end of each sprint with a blog post and a download link.

Because my focus was on learning the Unity API and rapidly adding new features a lot of code was written before I had developed any Unity/C# coding standards and best practices. What’s more this time around I decided not to spend time commenting or formatting my code. Luckily most of it ended up being simple and self-explanatory, but there were the occasional confusing, unsafe or just plain ugly sections of code. There was no overall design, just sporadic design patters here and there as needed. It was like a rebellion against my tendencies to over-engineer and overdo my work, but surprisingly it worked.

After returning to the project I was able to recognize a lot of the mistakes I had initially made (especially the ones related to physics and events) .

Technology