Jump to content

  • Log In with Google      Sign In   
  • Create Account

Aurioch's Time Machine

Project update

Posted by , 18 March 2014 - - - - - - · 774 views


So, classes started again, and my duties as a student returned. Luckily, my schedule is pretty neat (monday and friday full, wednesday normal, thursday labs here and there, and tuesday empty), so I can pretty much arrange everything to perform at my maximum capacity. Classes I'm attending to are Math 2, Physics 1, Network Programming, Development of Software Applications and Engineering Economics.

So, with that in mind, I've been working last few weeks improving the game from my speedrun and I got it to the pretty satisfying state, requiring only few bugfixes here and there to call it mechanically "complete".

Posted Image

There are three current issues in the game:
  • While ramming into moving solid tiles (walls, switches), ball is capable of becoming stuck into them. In certain situations, player can move the ball into a non-moving solid tile, becoming pernamently stuck. Players also can get stuck when standing into the place of the appearing wall (I have 2 options here - push ball out of the way or kill player. probably both depending if there's free space around or not).
  • Text scripts aren't implemented properly.
  • Background.
For background, I used plasma fractal algorithm to generate it. While it isn't visible from screenshot and requires

or demo to show it, constantly exchanging background can irritate eyes.

What I aimed for is effect similar to this, but the best I can is shown on video. I don't have any idea how to animate even grayscale to make something decent, nor could I find anything while doing research - all my search showed me the algorithm I already implemented.

My next step is to rewrite standalone level editor, which is horrible in the current state. Unlike the game itself, level editor is based on the Windows Form and uses elements like PictureBox, Buttons and others. While the editor... kinda... looks decent:

Posted Image

code behind is unmaintainable and full of bugs.
For example, when I save a fresh level, then load it again, this happens:

Posted Image

The thing is, I don't have any idea why... that... happens.. kill me, I just realized while writing this - when creating an array of tiles (enum), array elements are by default first initialized to 0, which is enum value of gray ball.

So, I've decided to rewrite level editor to use XNA and behaves like a game, trading one set of problems for another. XNA doesn't have controls like windows forms have, so I'll have to write similar things myself. I also hope it will end up visually more appealing, and one day I might even integrate it into game itself as game is close to the end of its lifespan. If I ever get to that point.

Back to the game itself, I'm currently looking to upgrade sprites and music - either by doing them myself, or to find someone willing to do it instead of me, as I suck in both. Maybe even change the background.
Also, Softpedia put both on my games on their page, only notifying me after that. While I was initially suprised, I'm glad they did that.

Plan for the game is this:
  • Finish it completely for Windows using XNA and polish it as much as possible.
  • Convert it to Monogame and release Linux and Mac friendly version
  • Given enough interest, either manually rewrite it into Java for Android and iOS or pay access to Xamarin to be able to simply port it with Monogame.
Thanks for reading!

Post-semester speedrun

Posted by , 28 January 2014 - - - - - - · 919 views

Phew, it's been a while.

Semester finally over, all classes have been passed, now I have free time until summer semester starts full force. Not that I've had to do much anyway as classes were easier...

Anyway. This will be like a personal diary, so my rambling might be incoherent.


Yesterday, after exam passed, I came up on the idea of performing a programming speedrun, in order to see how fast, using tools I know, can I spit out working prototype of the game.
For game, I choose a simple gamplay: a ball which moves vertically at a constant speed, chaging direction when it hits an obstacle. Player navigates through the labyrinth using left and right arrow to control its horizontal movement and has to come to the exit while avoiding hazards.

So, armed with C#, XNA and Photoshop, I started at exactly 0:00 CET from complete scratch. 2 hours later, after basic code was written with some hardcoding of values, I've started to get something which looks like the game I had in mind:
Posted Image

At that moment, only level loading, ball vertical movement and vertical reflection were implemented. Code was a mess even at that point, but I didn't stop and refactor, but continued writing for 1 hour and 40 minutes, finishing the game with horizontal movement, hazard detection, camera movement and exit point:

https://www.dropbox.com/s/glbl4b9y5dmrfnm/BouncyBall.rar (requires .NET 4.0 and XNA Redistributable)

So, in total, 3 hours and 40 minutes (pauses included) were taken for a complete game. And now, I'm in dilemma: what now to do with it? I've got so many questions for myself which I'm unable to answer. I could polish it in few days of pure work, but I don't know if it's worth it. Biggest issue with the game itself is rectangle-rectangle collision between ball and objects, which I left in the game to be faster and should be fixed as it is fake difficulty. Other basic additions are main menu, proper level progression, level editor and multiple obstacles and hazards. Code itself is also a complete and utter mess which should be sliced apart with refactor knife...

Screenshot showing how insane levels can be...
Posted Image

About other topics...

Tank City is still on hold until I raise enough will to finish it. I plan to do it before summer semester starts.

As a player of Star Trek Online and member of one fleet there, I've teamed up with one other programmer for a "fleet project". We've started work on our "Ship Build planner" to incorporate with our fleet site and, if possible, compete with STO Academy's Build planner. I hope I'll learn more about web developing, databases etc. from that.

On the artistic side, I've finally properly took pen and pencil and started drawing. After copying few images only by eye, I've set out to draw characters from my mind with as little references as possible. Results were... well... satisfying for me, considering those are 6th and 7th drawing:
Posted Image

I need to learn to properly draw eyes (big eyes aren't problem, but when I need to draw them small...) and hands. I hope I'll learn to use sister's tablet and be able to redraw them properly in digital format...

Thanks for reading!

Fighting the code backfire

Posted by , 30 July 2013 - - - - - - · 2,383 views


While it's on my mind, I wanted to write here few lessons I learned in last few days.
  • If the language supports polymorphism, USE IT.
  • Design before coding.
  • Having properly structured code helps. A LOT.
  • Keep the objects closely related on one heap.
Those points don't seem to be related, right? Allow me to explain.

I've started to hunt coop related bugs in the game. Code, on the first look, seems to work perfectly; however, most code is structured like:
if (multiPlayer == 0)
    // do single player behavior
    // do co op behavior
or a variation of that code, depending on player which "activates" part of the code.

So, here's lesson 1: Why making numerous comparisons like that through the whole class - some of which are surprisingly volatile - when I can make new class which inherits the current one and override specific methods to adapt them for co-op mode of the game. With that, I'm also avoiding the problem of pointless allocation of resources (time and memory) for object related to co-op mode.

Sound simple, right? Well, lessons 2 and 3 strike here at the same time. Due to "designing on the fly", I have to rewrite and refactor big parts of the code to adapt them for polymorphism. This means a lot of wasted time, due to the though process:

"Hmm, I'd like to add <feature 1>. Well, I can add this code here, and that code there... *writing code* Oh cool, this works! Yaay!"
"Now, to add <feature 2>... *writing* Crap, <feature 1> code isn't good here anymore... *moving and/or rewriting code* Good, now works."
"OK, <feature 3> is next... oh not again, <feature 1> is broken. *rewriting and/or moving code*"
"ARRRRRGH, NOT AGAIN!" (I'm now at this point)

Result: lots of wasted time trying to improve the structure of the game while trying to preserve current functionality (a.k.a. trying to NOT break it).

However, while I'm rewriting the code, I have to be careful. Some parts of the code, with best example being Draw(GameTime) method where last drawn object is on top, require executing in specific order. So, I can't simply do this:
public class A : GameScreen
    // ...

    public override void Draw(GameTime gameTime)
        // ...

public class B : A
    // ...

    public override void Draw(GameTime gameTime)
        // ...
        spriteBatch.Draw(player2texture, player2rectangle, Color.White);

because Player 2's sprite would end on bottom of everything, which may not be desirable.

Solution for that problem that I came up with is to extract relevant parts of A.Draw() and raise them to Protected level:
public class A : GameScreen
    // ...

    public override void Draw(GameTime gameTime)

    protected void PartA() { // ... }
    protected void PartB() { // ... }

public class B : A
    // ...

    public override void Draw(GameTime gameTime)
        spriteBatch.Draw(player2texture, player2rectangle, Color.White);
This is also why properly structured code is necessary. Instead of having massive amount of code inside one method, having the same code split over several methods improves maintainability and readability.

Lesson 4 is connected to 2 and 3 as well. Inside my Gameplay class (the one having actual game logic) I had few... awkward? objects:
Texture2D player1Texture;
byte player1spawnID;

Texture2D player2Texture;
byte player2spawnID;
Why is that?
Player player1;
Player player2;

public override void LoadContent()
    player1 = ScreenManager.Player1;
    player2 = ScreenManager.Player2;
In other words, I have objects related to players, whose objects persist through whole game, being created, disposed and recreated inside the class having game logic. Memory problems aside, not having player sprites stored inside player classes also forces me to needlessly duplicate the code and use additional checks to decide whose texture I need to move. Luckily, I don't need to do much to restructure the code and eliminate that annoyance.

Suddenly, improving level fie doesn't seem so important.

So, what did I learn from all that for next project (which is already defined in my head)?

I wasted too much time restructuring current project to enable modifications and upgrades. In order to avoid this in next project, I need to write Game Design Document and Tech Document in order to precisely define project and save time.

I hope that I won't repeat mistakes in the next project (Snake clone with 3D camera.)

After reading some topics on GameDev.Net, especially this one, I realized I have to learn the following:
  • Garbage collector
  • Making unit tests
Thanks for reading, I'm returning to my code. Posted Image

Salty update.

Posted by , in Battle City development 23 July 2013 - - - - - - · 927 views


Greeting from the sunny (and disgustingly windy) beach in Croatia. It's good to get away from the regular style of life; for some reasons my productivity arises while on vacation. Only problem is the lack of the normal connection to the internet, but I've managed to snatch dad's mobile internet USB stick so I can get here on occasions, so, this journal entry will be short.

Currently, I'm trying to establish the rhythm:
  • Breakfast @ approx 9:15
  • Beach
  • Math study
  • Lunch
  • Gamedev
  • Beach
  • Physics study
  • Dinner
  • Gaming
  • Sleep at 23:00-24:00
For now, I'm more or less abiding to it. I hope I'll manage to prepare myself before next semester.
Coding update

All the major features are finished!
I'm ironing out the bugs and finishing Options screen - only setting controls ingame is now required to implement.

Aside from that, after looking through the code, I started refactoring it. Smart decision when Update method holds 50% of relevant game logic. Only problem is organizing the code; despite refactoring, the most important class still feels clunky. But readable.

Artistic update

Nothing special on this front. Sadly, the workspace here isn't suitable for practicing art... I miss my 32' TV screen and Razer Copperhead.
I'm trying some combinations for improving the HUD and message boxes.

After some talking with jbadams, I said "it's enough" content-wise and decided I'll try and sell the game once polishing is finished - at least to see and learn about marketing/distribution/PR/etc. Otherwise, I'll never stop adding new, possibly questionable, content which can be added later anyway to keep the game fresh and thus never release the game. While I don't have much time to research about that field - at least until my Math and Physics exams finish, hopefully with passing grade - I put my game on IndieDB, where I'll also update status as soon as new material to update with appears.
Thanks for reading!

Back to the (my) past.

Posted by , 29 June 2013 - - - - - - · 1,066 views

I've been working a little on my old laptop. After digging through My Documents in search for some old documents, I've noticed VS2010 folder in it. With my curiosity suddenly awakened, I suddenly found myself staring at the content of the Projects folder.

Reason: some of my old projects were there. Most of them were games. A collection of 1s and 0s, silently waiting for their creator to come back for them. And he came.

After copying all the projects to the PC I work on, I loaded each solution and, after performing some maintenance like retargeting compiler to compile using .NET 3.0, ran debugger for each of them.
And felt like I was back there, looking at younger me sitting in front of PC I had at that time and trying to cope up with a solution to the problem.

So, here there are, the "games" I made before. Please join me in the travel to the past.
Note: I'll post code of each project. Because it's going to be huge, I'll put it in spoilers so that you can skip it if you're not interested.

Year 2006: Duck Shooting

Posted Image

First game I ever made, using Visual Basic (.NET Framework 2.0) with XNA 3.1. I have no idea how long it took me to make it. Gameplay is simple: shoot ducks and dog using the mouse to score points. Blue ducks are the slowest and give least amount of points; green are in the middle and brown are fastest. Dog jumps at random times and gives the most points.

Maybe you, dear reader, recognize the ducks and dog. Yeah, they're from Duck Hunt. And yeah, I hated that dog so much I created a way to get my revenge on him for mocking me each time I missed those damned duck(s). However, game is satisfying to play for maximum 60 seconds.

As for the code... when I look it now, it is atrocious. However, when I calmed myself I realized that... I didn't know better at that time. That was my best. For those who love statistics and code analysis, here's the data Code Metrics gave:
  • Maintanability Index: 59
  • Cyclomatic Complexity: 52
  • Depth of Inheritance: 2
  • Class Coupling: 32
  • Lines of Code: 243
Code for itself is rather easy to follow. However, I violated so many principles that it might be a bit painful to read.

XNAGame class:

DuckGame module:

DefineTextures module:

AnimatedTexture module:

HitDetection module:

Year 2009 (I think): Battle Tanks v0

Posted Image

Wrote with C# (.NET 3.5) and XNA 3.1. This was my first try of making "player" move the objects using keyboard.
This was also the project I learned why many of the modern games (League of Legends, for example) avoid using slick rotations of models unless needed.

Project isn't particulary impressive. Just a box with a barrel moving around and rotating. With one interesting bug I didn't fix: pressing Space during rotation makes bullet stuck at that angle.

Code is actually quite simple:

I could say that the project is abandoned, but I won't; I used this project as a base for the one later.

Year 2010: Nine Men's Morris

Posted Image

Back to the mouse based games. This one is once again written with C# (.NET 3.5) with XNA 3.1. I believe you can recognize the game, but in case you don't know, I'll explain:

Two players, each has 9 pieces. Game is split into 2 phases.
In phase 1, players alternately place their tokens on the board, trying to fill a row or column - make a "mill". After all 18 tokens are placed, each player can take away one of the opponents tokens from the board for each mill that player made. Tokens from mills cannot be taken out.
In phase 2, each turn players can move one token to the adjacent cell. Goal is to take out all opponent tokens by making mills. Once player remains with only 3 tokens, he isn't restricted to the adjacent cells of each token and can "jump" over the whole board.

Sadly, I never wrote a game beyond Phase 1. I might finish it one day... *looks at code* Screw it, if I ever decide to finish it I'll rather remake it from scratch:

I wasn't that young anymore. I just finished high school and entered faculty (college, if you like). I learned QBasic, (Turbo) Pascal, Visual Basic and C# until that point and I was comfortable with Trigger Editor in WarCraft 3 World Editor. So, I have full right to ask this: "WHAT THE HELL WAS I THINKING!!!"

Year 2011: Arkanoid (more like "Half Pong")

Posted Image

This one is also uncomplete. Written with C# (.NET 4.0) and XNA 4.0, I managed to get the basics (paddle moving and ball bouncing) before giving up for some reason. I think the reason was making the collision detection work the way I imagined it. While many people finished it (most recent example being superman3275), I decided to skip it... for now.

Code is actually quite clean, however I think I made it more complicated than I should:

Year 2012: Battle Tanks

BattleCity Alpha2

This one should actually be familiar if you remember anything from my older journal entries. I won't ramble too much about it; based on "Box with barrel", it's actually the 2nd sensible thing I made after a huge gap and a huge step up. I slowly started to do actual object-oriented programming. I've wrote more about it in my earlier entries.

For anyone interested in code:

Game1 class:

Player class:

Tank class:

Year 2013: Battle City

Posted Image

Upgrade of Battle Tanks. I'm still working on it - on both code and art. I won't ramble much about it here, and just add: powerups are added.

Now, take the picture above and compare it with this:
Posted Image

However, the biggest step is not the art - it's the code. Up to the Battle Tanks, I used strictly arrays and simple structures/classes and used only main class (the one automatically created with project), with a lot of copy/pasting, bad code etc. Now, with Battle City, I finally stepped - at least with one leg - into "true" object oriented programming. Skills I learned here helped me to deal with other tasks faster and easier. For example, laboratory tasks (like writing Finite State Machine) took no longer than 20 minutes of writing and debugging.

Battle City is nowhere near completition, but here are code metrics for current state:
  • Maintanability Index: 78
  • Cyclomatic Complexity: 873
  • Depth of Inheritance: 3
  • Class Coupling: 85
  • Lines of Code: 2025
If you wish to try it, head to my last entry and grab the attachement. That version doesn't have powerups but is still playable; I'd appreciate a feedback. I hope I'll be able to provide better version soon enough.

I hope this little trip to the past was at least a little interesting. If nothing, I'll have this journal preserving my memories and as a reminder how I was before as a programmer.

Thanks for reading and, I hope, see you in next entry.

Battle City - Battlefield is opened

Posted by , in Battle City development 27 June 2013 - - - - - - · 1,033 views


I took a break from exams in order to work on the game. For now, I managed to pass Databases exam and Intro to Computer Science exam so I'm a little tired from studying.

Battle City revamped graphics

This time, there are no any big updates on the progress, except for graphical revamp (which is still in progress). Instead, I'd like to share a current version of the game. I'd like to hear your feedback of any kind about the game. Part of this is for selfish reasons - I'm starting to get bored of it due to (somewhat) long production (burnout?); however I don't want to start a new project because I'll never finish this one. Another problem is that I don't know what I'll do with it once I finish it, other than add it to my portfolio. Apart from these concerns, I still enjoy making it.
Any suggestions, comments etc. are appreciated.

Grab the game:
Attached File  Battle City.zip (1.61MB)
downloads: 51
and just extract and run.
Game requires .NET Framework 4.0 installed on the machine to run!

Controls: Up, Down, Left, Right, Enter (Shoot).

For now, I disabled 2 player mode and Options screen. Options screen is incomplete and 2 player mode has too many bugs I need to fix. For example, AI once took control over my tank and suicided it!!! I couldn't believe my eyes.

To change settings, open config.txt file. Parameters are easily recognizable; however, I didn't code in any protective mechanisms so if game suddenly starts crashing, check config file.

Currently known bugs:
  • 2 enemy tanks get stuck in small passages.
  • Sometimes enemy tanks go between two closest tiles.
  • Sometimes enemy tanks can fire a stream of bullets.
  • Brick wall destructions is sometimes too big or too small.
  • On widescreen resolution, mouse cursor and level editor cursor are displaced.
Other than that, alpha is perfectly playable.
One little note - in current state, game has 1897 lines of code (calculated with Visual Studio's code analysis), which also officialy makes it the biggest program I ever wrote.

Thanks for reading.

Learning to draw, pixel by pixel

Posted by , in Battle City development 13 June 2013 - - - - - - · 936 views


Some time has passed from last update. Semester end is coming close and with it summer vacation, valuable time for learning anything programming-related and... Exams. Lots of exams. Oh how I don't want to study from faculty materials, I'd rather invest time on working on projects or study from real life examples where I can learn much faster and more efficient. Sadly, math and physics aren't courses which I can learn that way. At least I had good math professor and managed to pick up most from him; physics was bad so I need to learn by myself.

As far as development goes, AI is in satisfying condition so I left it for now in current state. Most problems have been fixed, there are some issues here and there, but it's playable. With that out of the way, I've turned to the next tasks:
  • Options screen - mostly complete; pure text, serves purpose
  • Powerup system
  • Graphical update
I finally came to the powerups. This is where I can become creative and make major distinction between my clone and the original game. Apart from some powerups which are standard and thus picked up from the original, I can create some of my own as long as I know how to implement it. In preparation for implementation, I have to modify existing code in order to provide better interaction between objects. Hopefully, experience will be satisfying.
There will be two major differences in powerup system between original and clone. One, powerups will be delivered "from the air" instead of appearing after destruction of certain enemy. Two, powerups won't disappear after lying for some time without collecting - after some time from appearance of an powerup, enemy tanks will be able to pick it up as well. Because of that, some powerups will have to have different effects depending on who picks it up. I can't wait to see how will this end up.

Here's a list of the 12 powerups I plan to implement for start.
Powerup list

Now, back to the title. In order to get better assets, I've started to practice artistic skills. Because of its (relative) simplicity, I started with pixel art. Result can be seen on the picture above (I hope - resizing small sprite often brings catastrophe), with powerup icons, new brick wall and new tank. Any feedback would be appreciated.
By using pixel art and vivid colors, I plan to give the game a retro feel suited to the NES and Sega Genesis/Megadrive games.

Special shoutout and thanks to riuthamus for spending his own valuable time in order to help me with art - new tank is mostly his work, I just finished shading it. Without him, I would still be stuck with art skill on absolute zero; thanks to his help, I can produce something at least decent and continue learning from that. It's much harder than coding... time to make pencil, paper and eraser my best friends, huh?

Thanks for reading

Temporal silence

Posted by , in Battle City development 02 May 2013 - - - - - - · 655 views


Well, I've been out for a while. There is a lot going on, my faculty exams are finished. Since I'm busy with faculty I simply don't have enough time to work on what I want - and even when I have I don't have enough motivation to do it.
Regarding faculty, this semester I have to write seminary - topic I managed to get is "Pathfinding algorithms". Fun fun.

For now, I didn't done much. I'm still working on the proper AI for the game. OK, not AI but pathfinding and pathfollowing. I've decided to work on A* algorithm, considering it's one of the easier and effective algorithms. However, I needed to rewrite it several times because... Code was a mess and it just didn't work. Current version is the closest to the what I want, but there are still several problems I'm trying to solve:
  • AI is blind to the changes. Once it finds a route it will follow it no matter what. I've had to remove collision from enemy tanks in order for them to not get stuck.
  • On several occasions, game stops for a little while AI calculates a route => inefficient pathfinding.
  • If I limit pathfinding to only few steps but make it check for paths each cycle, AI goes crazy.
Definietly hardest piece of code yet I've had to write. And I feel it will need some time to write a satisfying solution.

Also, in addition to that, I've been doing some cleanups of the code. Nothing special nor visible - removing of useless structures, replacing parts of code violating "Rule of 3" to accomodate DRY concept etc. - but will at least give me more flexibility later at writing the code. One of those changes is removing structure I've been using to save all points and instead using Player class to store all data connected to the players.

Since I don't have any new pictures, I though I'd at least give a video of game in action.

Little related to the game, May's article contest theme is "Remake the classics". Maybe I join in, considering that original Battle City can be considered "classic"; however, I don't have any idea what to write about, especially considering that my game is unfinished.

Thanks for reading!

New Battle City update

Posted by , in Battle City development 27 January 2013 - - - - - - · 1,058 views

Hello again!

Here's another project status update; unlike last time, this time I made more "visible" stuff rather than tuning the code that operates it. Well... when I think about it... there is plenty of both. This update is rather big (for me) and I cannot express how determined and happy I am because of it.

Short summary:
  • Added level selection screen
  • Level progression, scoring and life counting
  • Game over and Victory mechanics
  • New types of tiles (20 of them)
  • Improved collision detection and destruction
  • Complete level editor
  • Manual (by editing config file) resolution selection
  • Framerate counter
New Collision Detection with destructables

Remember the solution I used in last journal entry for destroying brick walls? If you don't, let me help you: you don't need to. It's gone. Simpler, better and faster solution was implemented instead which gives me greater control over tiles while doing the exactly same thing as pixel-perfect collision detection (PPCD in short) - tile is splitted into multiple segments which are checked if CD detects there is collision with that tile.
There were also performance issues with PPCD on levels where were many bricks which caused framerate drops from 60 FPS to 38 due to multiple checking, transforming etc. due to nature of the code. Maybe I didn't write it perfectly optimized but still, calling 40 000 times same operation is not healthy.

New CD also helped me to create new types of tiles easily, which brings us to...

Level Editor

Posted Image

Oh yeah, complete level editor with toolbox (took inspiration from Sapphire Yours) and little menu with all necessary operations. Level editor is operated by mouse (currently only place where mouse is enabled). In the toolbox you can also see all tiles which currently exist in the game; numerous variations of brick and metal tile were easy to implement thanks to new collision detection. Save and Load Level bring out dialog box where you write which level you want to load or save. Those two will be improved later, together with warning there are unsaved changes when you try to exit the editor, additional level management features and few more safety measures like prevention of saving empty level.

Since level editor exists, there is also level selection screen:
Posted Image
It's ugly. I know. But it's "similar" to the original (NES) version and will suffice for now. Also, game automatically transitions between levels when you kill all enemy tanks through this screen; when it does that, player is prevented from choosing other level.

Configuration file

For easier manipulation over destructibles (read as: I don't wanna mess with non-integers if I don't need to) resolution the game is based is increased from 800*600 to 960*720. Naturally, it caused few minor issues I didn't fix yet (respawn control going berserk, font a little smaller). Game doesn't look much different, except for fresh stuff on the right side:

Posted Image

What happens when you change resolution? For 4:3 resolutions (like 1280*1024) everything's same except bigger. For non-4:3 resolutions, this happens:

Posted Image

Screenshot is taken on HDReady resolution (1366*768). On this picture you can notice 3 things.
First one is a little gray part on the left side which "came out of nowhere". I didn't like horizontal stretching during expansion on 16:9 format so I rather kept the main part in 4:3 format and added more background part to the left, keeping nice square tiles.
For now, resolution is selected by manually editing configuration file. Aside from height and width, there are also Fullscreen and Show Framerate options. I have 32' TV as my monitor screen and game in current format looks really nice on 1920*1080 fullscreen.

Game over, Victory and game exiting

What is on of main components which makes the game "game"? Challenge. Or rather, ability to lose. Now, on the previous picture, look at the bottom right of the game screen. "Game Over" for 2nd player. Yup, it's finally properly supported. I don't need to explain rules, right? Posted Image

I took advantage of Game State Machine to make this little thing that You probably spotted first on that screenshot. I think I don't need to talk about it.

What is next?

Obviously, to raise up the challenge, I need to improve AI of opponents. For now, it utilizes randomizer to create its behaviour which gives little challenge, but I swear that Random Number Generator has its own mind. Luck my ***, there is no other explanation on AIs ability to dodge perfectly fired shots in last second; if I didn't write it myself I would swear that AI tries to sabotage me.
I already have designed the behaviour of new AI, now I "just" need to implement it properly. CPU overload, here I come!

I really don't know what will I do with art and sound. I tried to draw new tank for Player 1 to replace the current one but the result was catastrophic due to overusage of Bevel&Emboss to create a 3D feeling:

I'll try to get new assets as soon as I can but until then I'll work on other things like improving code and performance and adding support for playing in 2 players over LAN.

Well, this is it for now, thanks for reading, I hope I wasn't too boring.

Battle City - The Battlefield is forming

Posted by , in Battle City development 09 January 2013 - - - - - - · 1,003 views

  • Battle City revamped graphics
  • Comparsion
  • Attempts of drawing a tree
  • Powerup list
  • Battle City Alpha 3
  • BattleCity Alpha2
  • BattleCity Alpha1

Winter vacation is over Posted Image
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:
Battle City Alpha 3

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

* Description: Player tank is invulnerable, ramming into enemy tanks kills them

* Status: Resolved

* Cause: Forgotten conditions when evaluating collision between two tanks

- Ghost tank

* Description: After player loses all lives, he respawns looking like enemy tank. Ghost tank can move and shoot and is invulnerable.

* Status: Put aside (old version of the game)

* Cause: Oversight on tank respawn involving player tanks

- Death by Spawning

* Description: Enemy tank spawns while player's tank is on spawn point and immediately fires bullet, killing player. Reverse also works.

* Status: Resolved

* Cause: Non-existant spawn control

- Unstable tank

* Description: Player's tank dies when touching environment. Respawns immediately on spawn.

* Status: Resolved

* Cause: Copied code from one property but forgot to change it.

- Tank possesion

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

* Status: Resolved

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

January 2017 »

15161718 19 2021

Recent Entries

Recent Comments