Battle City - The Battlefield is forming

Published January 10, 2013
Advertisement
Winter vacation is over sad.png
First things first: I know that it's late, but Happy New Year! Hope you had a good vacation.
I didn't have much time to invest into project due to all the events surrounding Christmas and New Year so there was another 2 week "rest" from programming. In the evenings I'd rather play a little or watch movies/animes since it would be pretty late for work and I would be mentally and physically exhausted.

Well, I'd like to say that my project is going steadily, but it isn't. It's going in bursts. After finishing as much as I could, I scrapped previous build and wrote a new one, drastically improving it by using structures I never used before (believe it or not, Lists are one of those) and going deeper into object oriented programming. None of my programs before never had more than 3 classes written by myself; current version of Battle City has 16 classes and will gain more. So, while visually it changed little, core of it now works much better than before.

This is how it looks currently:
[sharedmedia=gallery:images:3156]
On the left side: somewhat bland main menu. On the right side, screenshot of 2 player game featuring destructible walls.

Some major features I tackled since my last entry:

Game State Manager



In other words, multiple screens. This system was on the whole different level than I ever wrote before and it took considerable amount of time just to study how it works. In addition to that, I needed to change whole my thought process to be able to grasp the concept. Microsoft's Game State Manager example was a great help in research; I managed to reproduce my own version by looking carefully how that example works.

As a result, game got Main Menu. Yaaay \o/ Other screens (like disabled level editor you can see on screenshot) will be simple to add thanks to it.

Destructible brick walls



This was a little problematic... mainly because I knew "what" and "how" to do it, but didn't know how to properly execute that "how".
First time I tried, I managed to break the game by calling 2 lines of code 16 million times, resulting in several second freeze each time I touched brick wall with my tank. I managed to execute the solution correctly on my 2nd try (meaning I deleted completely that part once and rewrote it from scratch) and got great results.

While writing the algorithm I learned the basics of transformation matrixes - utility which will be required later, especially in 3D projects.

Solution was to go pixel per pixel in area where tank/bullet overlaps with wall, find that pixel's coordinates in both the tank's/bullet's and wall's texture using transformation matrixes and check if it's transparent by looking at alpha parameter. Since checking each pixel is insanely resource consuming, collision must first be confirmed by bounding box test.

Game finally got some feeling like the one I'm trying to clone.

Funny bugs

(that may come later as "features", because that's what experts do)



It's easy to stumble on few unforseen bugs, especially when one is as inexperienced as I am. Some of them are usual, other of them... so funny or cool looking that they beg you to stay. I wanted to share some of them before I forget; sadly, I don't have videos of them and pictures aren't enough in this case.

So, here they are:

- Star-powered tank
[indent=1]* Description: Player tank is invulnerable, ramming into enemy tanks kills them
[indent=1]* Status: Resolved
[indent=1]* Cause: Forgotten conditions when evaluating collision between two tanks

- Ghost tank

[indent=1]* Description: After player loses all lives, he respawns looking like enemy tank. Ghost tank can move and shoot and is invulnerable.
[indent=1]* Status: Put aside (old version of the game)
[indent=1]* Cause: Oversight on tank respawn involving player tanks

- Death by Spawning

[indent=1]* Description: Enemy tank spawns while player's tank is on spawn point and immediately fires bullet, killing player. Reverse also works.
[indent=1]* Status: Resolved
[indent=1]* Cause: Non-existant spawn control

- Unstable tank

[indent=1]* Description: Player's tank dies when touching environment. Respawns immediately on spawn.
[indent=1]* Status: Resolved
[indent=1]* Cause: Copied code from one property but forgot to change it.

- Tank possesion

[indent=1]* Description: When player dies, instead of respawning he assumes control of one of AI controlled tank. In case of multiplayer, Player 1 gains control of Player 2's tank while Player 2 gains control of enemy tank.
[indent=1]* Status: Resolved
[indent=1]* Cause: Due to Player 1 controls being hardcoded to index 0 of the list of tanks and Player 2 - if it's multiplayer - being hardcoded to index 1, when Player 1's tank is removed from list (killed) other tank's indexes are dropping by 1. You can guess what happens next.

As you can see, causes for those bugs are pretty trivial. Regardless of that, I love when bugs like that happen, giving me unexpected bursts of laugher.

Next step


  • Player-related stuff (Scoring, lives etc.)
  • Level editor and level management
  • LAN support
  • Graphic polishing
  • Sound
  • AI improvement

So much stuff to do, but it's getting easier since worst part is done. Graphic polishing will be pretty hard; I'm a coder, not an artist :/
Well, it doesn't matter. I'm happy that I'm doing it and I'll finish it completely so that I can go onto the next project I have in mind for some time.

Thanks for reading and see ya later. Hopefully, with playable version.
1 likes 1 comments

Comments

SuperVGA
Ohh looking really good! Keep pushing these updates.
It reminds me of the battle city game I made in school in 2005,
-you'll never run out of ideas for features and rules,
but I like how you limit the additions to the next step. It looks more organized than my brainstorm "planning" back then.
January 10, 2013 05:10 PM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Advertisement
Advertisement