<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0">
<channel>
	<title><![CDATA[Aurioch's Journal]]></title>
	<link>http://www.gamedev.net/blog/1561-auriochs-journal/</link>
	<description><![CDATA[Aurioch's Journal Syndication]]></description>
	<pubDate>Thu, 02 May 2013 17:37:39 +0000</pubDate>
	<webMaster>support@gamedev.net (GameDev.net)</webMaster>
	<generator>IP.Blog</generator>
	<ttl>60</ttl>
	<item>
		<title>Temporal silence</title>
		<link>http://www.gamedev.net/blog/1561/entry-2256361-temporal-silence/</link>
		<category></category>
		<description><![CDATA[Hello<br /><br />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.<br />Regarding faculty, this semester I have to write seminary - topic I managed to get is "Pathfinding algorithms". Fun fun.<br /><br />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:<ul class='bbc'><li>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.</li><li>On several occasions, game stops for a little while AI calculates a route =&gt; inefficient pathfinding.</li><li>If I limit pathfinding to only few steps but make it check for paths each cycle, AI goes crazy.</li></ul>Definietly hardest piece of code yet I've had to write. And I feel it will need some time to write a satisfying solution.<br /><br />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.<br /><br />Since I don't have any new pictures, I though I'd at least give a video of game in action.<br /><iframe id="ytplayer" class="EmbeddedVideo" type="text/html" width="640" height="390" src="http://youtube.com/embed/bCCGFzhncyE?html5=1&fs=1" frameborder="0" allowfullscreen webkitallowfullscreen /></iframe><br /><br />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.<br /><br />Thanks for reading!]]></description>
		<pubDate>Thu, 02 May 2013 16:41:00 +0000</pubDate>
		<guid>http://www.gamedev.net/blog/1561/entry-2256361-temporal-silence/</guid>
	</item>
	<item>
		<title>New Battle City update</title>
		<link>http://www.gamedev.net/blog/1561/entry-2255994-new-battle-city-update/</link>
		<category></category>
		<description><![CDATA[Hello again!<br /><br />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.<br /><br /><span style='font-size: 18px;'><strong class='bbc'>Short summary:</strong></span><ul class='bbc'><li>Added level selection screen</li><li>Level progression, scoring and life counting</li><li>Game over and Victory mechanics</li><li>New types of tiles (20 of them)</li><li>Improved collision detection and destruction</li><li>Complete level editor</li><li>Manual (by editing config file) resolution selection</li><li>Framerate counter</li></ul><span style='font-size: 18px;'><strong class='bbc'>New Collision Detection with destructables</strong></span><br /><br />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.<br />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.<br /><br />New CD also helped me to create new types of tiles easily, which brings us to...<br /><br /><span style='font-size: 18px;'><strong class='bbc'>Level Editor</strong></span><br /><br /><span rel='lightbox'><span rel='lightbox'><img class='bbc_img' src='http://i47.tinypic.com/2j35xqd.jpg' alt='Posted Image' class='bbc_img' /></span></span><br /><br />Oh yeah, complete level editor with toolbox (took inspiration from <a href='http://members.aon.at/sapphire/index.htm' class='bbc_url' title='External link' rel='nofollow external'>Sapphire Yours</a>) 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.<br /><br />Since level editor exists, there is also level selection screen:<br /><span rel='lightbox'><span rel='lightbox'><img class='bbc_img' src='http://i48.tinypic.com/34yxiza.jpg' alt='Posted Image' class='bbc_img' /></span></span><br />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.<br /><br /><strong class='bbc'>Configuration file</strong><br /><br />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:<br /><br /><span rel='lightbox'><span rel='lightbox'><img class='bbc_img' src='http://i50.tinypic.com/bdjnt2.jpg' alt='Posted Image' class='bbc_img' /></span></span><br /><br />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:<br /><br /><span rel='lightbox'><span rel='lightbox'><img class='bbc_img' src='http://i49.tinypic.com/1zwj6lx.jpg' alt='Posted Image' class='bbc_img' /></span></span><br /><br />Screenshot is taken on HDReady resolution (1366*768). On this picture you can notice 3 things.<br />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.<br />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.<br /><br /><span style='font-size: 18px;'><strong class='bbc'>Game over, Victory and game exiting</strong></span><br /><br />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? <span rel='lightbox'><span rel='lightbox'><img class='bbc_img' src='http://public.gamedev.net//public/style_emoticons/default/smile.png' alt='Posted Image' class='bbc_img' /></span></span><br /><br />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.<br /><br /><strong class='bbc'><span style='font-size: 18px;'>What is next?</span></strong><br /><br />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.<br />I already have designed the behaviour of new AI, now I "just" need to implement it properly. CPU overload, here I come!<br /><br />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:<br /><div class='bbc_spoiler'>
	<span class='spoiler_title'>Spoiler</span> <input type='button' class='bbc_spoiler_show' value='Show' />
	<div class='bbc_spoiler_wrapper'><div class='bbc_spoiler_content' style="display:none;"><br /><span rel='lightbox'><span rel='lightbox'><img class='bbc_img' src='http://i48.tinypic.com/nbwzdt.png' alt='Posted Image' class='bbc_img' /></span></span><br />It's ugly. Especially when you shrink it on 48*48.<br /></div></div>
</div><br /><br />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.<br /><br />Well, this is it for now, thanks for reading, I hope I wasn't too boring.]]></description>
		<pubDate>Sun, 27 Jan 2013 11:34:00 +0000</pubDate>
		<guid>http://www.gamedev.net/blog/1561/entry-2255994-new-battle-city-update/</guid>
	</item>
	<item>
		<title>Battle City - The Battlefield is forming</title>
		<link>http://www.gamedev.net/blog/1561/entry-2255734-battle-city-the-battlefield-is-forming/</link>
		<category></category>
		<description><![CDATA[Winter vacation is over <span rel='lightbox'><span rel='lightbox'><img class='bbc_img' src='http://public.gamedev.net//public/style_emoticons/default/sad.png' alt='Posted Image' class='bbc_img' /></span></span><br />First things first: I know that it's late, but Happy New Year! Hope you had a good vacation.<br />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.<br /><br />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.<br /><br />This is how it looks currently:<br /><!-- bbcodeImage-js (do not remove or edit this tag) -->
<a href='http://www.gamedev.net/gallery/image/3156-battle-city-alpha-3/' class='bbc_url' title=''><img class='bbc_img' src='http://uploads.gamedev5.net/gallery/album_529/sml_gallery_199880_529_41381.jpg' class='galattach galimageview' title='Battle City Alpha 3'  width='240' height='94'  alt='Battle City Alpha 3' id='sml_image_view_3156' /></a>
<br /><br />On the left side: somewhat bland main menu. On the right side, screenshot of 2 player game featuring destructible walls.<br /><br />Some major features I tackled since my last entry:<br /><br /><span style='font-size: 18px;'><span class='bbc_underline'>Game State Manager</span></span><br /><br />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.<br /><br />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.<br /><br /><span style='font-size: 18px;'><span class='bbc_underline'>Destructible brick walls</span></span><br /><br />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".<br />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.<br /><br />While writing the algorithm I learned the basics of transformation matrixes - utility which will be required later, especially in 3D projects.<br /><br />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.<br /><br />Game finally got some feeling like the one I'm trying to clone.<br /><br /><span class='bbc_underline'><span style='font-size: 18px;'>Funny bugs</span></span> <span style='font-size: 12px;'>(that may come later as "features", because that's what experts do)</span><br /><br />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.<br /><br />So, here they are:<br /><br /><strong class='bbc'>- Star-powered tank</strong><br /><p class='bbc_indent' style='margin-left: 40px;'><strong class='bbc'>*</strong> Description: Player tank is invulnerable, ramming into enemy tanks kills them</p><p class='bbc_indent' style='margin-left: 40px;'>* Status: Resolved</p><p class='bbc_indent' style='margin-left: 40px;'>* Cause: Forgotten conditions when evaluating collision between two tanks</p><br /><strong class='bbc'>- Ghost tank</strong><br /><p class='bbc_indent' style='margin-left: 40px;'><strong class='bbc'>* </strong>Description: After player loses all lives, he respawns looking like enemy tank. Ghost tank can move and shoot and is invulnerable.</p><p class='bbc_indent' style='margin-left: 40px;'>* Status: Put aside (old version of the game)</p><p class='bbc_indent' style='margin-left: 40px;'>* Cause: Oversight on tank respawn involving player tanks</p><br /><strong class='bbc'>- Death by Spawning</strong><br /><p class='bbc_indent' style='margin-left: 40px;'><strong class='bbc'>* </strong>Description: Enemy tank spawns while player's tank is on spawn point and immediately fires bullet, killing player. Reverse also works.</p><p class='bbc_indent' style='margin-left: 40px;'>* Status: Resolved</p><p class='bbc_indent' style='margin-left: 40px;'>* Cause: Non-existant spawn control</p><br /><strong class='bbc'>- Unstable tank</strong><br /><p class='bbc_indent' style='margin-left: 40px;'>* Description: Player's tank dies when touching environment. Respawns immediately on spawn.</p><p class='bbc_indent' style='margin-left: 40px;'>* Status: Resolved</p><p class='bbc_indent' style='margin-left: 40px;'>* Cause: Copied code from one property but forgot to change it.</p><br /><strong class='bbc'>-</strong><strong class='bbc'> Tank possesion</strong><br /><p class='bbc_indent' style='margin-left: 40px;'>* 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.</p><p class='bbc_indent' style='margin-left: 40px;'>* Status: Resolved</p><p class='bbc_indent' style='margin-left: 40px;'>* 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.</p><br />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.<br /><br /><span class='bbc_underline'><span style='font-size: 18px;'>Next step</span></span><ul class='bbc'><li>Player-related stuff (Scoring, lives etc.)</li><li>Level editor and level management</li><li>LAN support</li><li>Graphic polishing</li><li>Sound</li><li>AI improvement</li></ul>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 :/<br />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.<br /><br />Thanks for reading and see ya later. Hopefully, with playable version.]]></description>
		<pubDate>Thu, 10 Jan 2013 02:24:00 +0000</pubDate>
		<guid>http://www.gamedev.net/blog/1561/entry-2255734-battle-city-the-battlefield-is-forming/</guid>
	</item>
	<item>
		<title>Developing Battle City - from beginning till now</title>
		<link>http://www.gamedev.net/blog/1561/entry-2255235-developing-battle-city-from-beginning-till-now/</link>
		<category></category>
		<description><![CDATA[Hello.<br /><br />I hate introductions, I don't know what to say about myself :/ Oh well. Name's Josip and I'm student of Faculty of Electrical Engineering and Computing in Zagreb, Croatia. I started programming in elementary school after discovering QBasic, and since I love video games I decided to become game developer. Over years I passed from QBasic, Pascal, VB.Net and C to C#, where I learn about game developing using XNA framework.<br />I had several "projects" (if you can call them like that), but none of them were real thing, only tests to see how can I make stuff working. After gathering enough knowledge and experience from those "projects", I set up a new goal: Clone of Battle City, a game I loved as a kid (and I'm still loving).<br /><br />First, what is Battle City?<br /><br />Battle City (known to many as Tank or Tank 1990) is a NES game released by Namco in 1985. The player, controlling a tank, must destroy enemy tanks in each level, which enter the playfield from the top of the screen. The enemy tanks attempt to destroy the player's base (represented on the map as a bird, eagle or Phoenix), as well as the human tank itself. A level is completed when the player destroys all 20 enemy Tanks, but the game ends if the player's base is destroyed or the player loses all available lives.<br /><br /><span rel='lightbox'><span rel='lightbox'><img class='bbc_img' src='http://www.mobygames.com/images/shots/l/54741-battle-city-nes-screenshot-demos.gif' alt='Posted Image' class='bbc_img' /></span></span><br /><br />For the nostalgia value and for the sake of practice, I decided to recreate it (hence the same name... for now).<br /><br />I started working on it in August this year (2012). After few days I encountered a slight bug which I couldn't fix immediately - my laziness kicked in day or two after that and I put it on hold.<br />On 12th of October I resumed working on it, and after few hours I located a bug and removed it. From that moment, everything just... started snowballing one thing at a time until it became what is it at the moment of writing.<br /><br />Currently, it looks like this:<br /><!-- bbcodeImage-js (do not remove or edit this tag) -->
<a href='http://www.gamedev.net/gallery/image/2885-battlecity-alpha2/' class='bbc_url' title=''><img class='bbc_img' src='http://uploads.gamedev5.net/gallery/album_529/sml_gallery_199880_529_49935.jpg' class='galattach galimageview' title='BattleCity Alpha2'  width='240' height='188'  alt='BattleCity Alpha2' id='sml_image_view_2885' /></a>
<br /><ul class='bbc'><li>2-player support</li><li>AI controlled opponents</li><li>Indestructable metal walls</li><li>Unpassable water (bullets fly over it)</li><li>Grass conceals</li><li>Working collision detection, hit detection and respawn</li></ul><br />So, what are my goals for the future?<ul class='bbc'><li>Destructable brick walls</li><li>Main menu</li><li>Level system</li><li>Ingame level editor</li><li>LAN support</li><li>Powerup system</li><li>Total Graphic Overhaul (hell yeah, hardest for the end)</li><li>Only sky is limit...</li></ul><br />Maybe I'm expecting too much of myself. Who knows. I plan to finish now what I started, but there is only one problem - I don't know what will I do with it once I finish it. Journal will be updated with new stuff as I progress.<br /><br />Thanks for reading!]]></description>
		<pubDate>Tue, 16 Oct 2012 20:37:00 +0000</pubDate>
		<guid>http://www.gamedev.net/blog/1561/entry-2255235-developing-battle-city-from-beginning-till-now/</guid>
	</item>
</channel>
</rss>