Conception

Here's some more concept art. I've been working on trying to create the first boss. It's going to be a giant Bargle controlled mech although we haven't yet figured out how this enormous image will fit on screen. I guess that's why it's merely a concept....

HUD & Grenades

Sooo, I took a little break from working on the game. Another way to put it, I played Fallout 3 for the first time and that kind of shuffled my free time priorities a bit =) Not to say I hadn't been working on the game at all, but pretty close to it. I hit that point where there's a lot of boring stuff that needs to start getting done. Also, the networking challenge keeps getting tougher and tougher, and it's a pain to debug networking issues. I decided to put networking on hold (possibly permanently for the sake of actually finishing this game sometime this year). You probably won't notice the changes in this video, but I made some fixes to the game loading and map changing routines so it's smoother. I'm also in the process of working out a system to change and load worlds. These tasks aren't as much fun because there's not a lot to see when they're completed. I've read and heard of different methods of staying motivated when you reach this point in your game's development. One method is to try to mix up the boring tasks with the fun tasks. For every boring task I complete, I should follow it up with something more fun. So between the loading and changing routines, I also added a new weapon, grenades, and a HUD for the player thanks to Chris' new art addition yesterday. The HUD isn't finalized yet, we're thinking of changing the size, maybe location, and adding more effects and whatnot. Since there is nothing in the single player game that can hurt you yet, I just programmed it so when you fire a shot, you get hurt! Watch the red health bar at the top.

Concept art / Desktop Background

There hasn't been any updates in the last couple of weeks so I figured I would post a bit of concept art that can also double as a kick ass desktop background. I've been exploring some features of my drawing tablet and used it's inking function to make this sketch. The inking function is supposed to emulate an actual pen by gauging the stylus pressure and adjusting the thickness and darkness of the line accordingly. So far I think it does a reasonably good job for a cheap model. Currently, I'm considering doing the cutscenes in this style. ( Click the image to enlarge, the thumbnail looks meh)

Networking Improvements

After reading through the code of the network prediction project provided on the XNA Creator's Club web site, I was able to implement the prediction and smoothing algorithms into our game. Although it didn't completely remove all the stuttering, I'm happy to say it did help a great deal. This worked fine for regular characters, however, I was faced with a bigger challenge of fitting these algorithms into the Tank class which uses Farseer physics. After thinking about it a bunch, I decided to forgo the algorithms for the Tank class and take another look at ways I can improve its stuttering. I studied the data I was sending for the tanks and discovered I had omitted a very important piece of data.. the velocity! The reason I made this mistake is because I use a Vector2 called "Trajectory" for the Character class which is the velocity. But the Tank class, which is derived from the Character class, uses the Trajectory variable to store the force that is applied to the physics object. The velocity itself is kept by the Farseer class "Body". So I added this data to be transmitted over the network for syncing. Through the testing I've done so far, this works well. However, there could be issues I might see only after some real play testing.

Besides the code updates, we also finally decided to pay attention to another critical aspect of the game.. the design. I downloaded a game design doc template and we started going through it, answering a lot of important questions about what we want the game to be like. I can see a lot of time will be spent on this doc, considering we spent an hour working on it and only got about 25% through it. Good times!

Artybartfast

Scenery update time. I changed the awkward looking floating dirt blocks into palm trees to make the environment a look a little more natural.



In addition to the above I also created a completely new environment; the underground cavern.

Performance Problems

I was on vacation last week and so did not work on the game at all. Before leaving for vaca, I found that there were some severe performance issues with the game on the xbox. I was wondering when this was going to happen. I had to do some testing to determine the cause of the performance problems and found some great help for this from Shawn Hargreaves blog here and here. Basically, XNA comes with a really nifty tool you can use to inspect your games heap when its running on your xbox and view all sorts of metrics on the garbage collector and memory usage. This made it easy to discover that I was putting the garbage collector into overdrive because I had 4 objects per map tile allocated for map scripts. This was far too complex. I limited the map scripts to only 20 sets of 4 per map and that solved the problem. This was much harder to do than to type, but I'm glad it's over with. In addition to this change, I've also added the ability to specify a background image for a map in the map editor.

New Tank Art

Chris put together some great looking art for our first vehicle. Inspired by the warthog from the halo series, this will likely be the standard single passenger land vehicle. He also made some slope segments, so now we don't need to look at those ugly white polygons.

I've been working on getting other things networkable in the game, including projectiles, the tank, and the turret. It took a lot of experimenting and effort to get the tank working right, particularly with syncing information such as which character is driving which vehicle. There are still some bugs to kill, but overall things are working well. Currently, I'm working on adding simple gameplay elements such as health, damage, death, powerups, etc. You know, the things that make a game fun to play. Here's a video of our new tank riding on our new slopes on a single player game.

Early Stages of Networking and Multiplayer

It's been awhile since the last update to the blog and that's because I've been doing a lot of reading and research into game networking, specifically for XNA and XBL. Unfortunately, I've read a lot of negativity regarding it. Though I don't know if it's all true, some say there's not a big audience to play multiplayer games on XBL indie games. About a month ago, we decided we want to make this game a multiplayer only game. But, if there's not a big enough audience for it, we may have to reconsider making it a single player game, perhaps with some multiplayer options. I will have to try some multiplayer indie games and see for myself. I also read that game networking is a major hassle in general, and specifically so with XBL because of the packet overhead added with voice chat and XNA. Not that I'm complaining, XNA makes it super easy to at least use its networking features. It's just that I will face some challenges in making it run smoothly over XBL, especially with the physics engine. I'm already facing some animation issues with my regular characters (not using the physics engine) just over system link in my testing. Right now, I have the ability to host and join system link games working and you can play 2 linked computers together (xbox and PC, or PC and PC) moving the characters about freely. It's a lot of work and a good start, but there's still a lot more to do and improve. I'm going to keep experimenting and also read up on network prediction and smoothing algorithms. Hopefully I will be able to improve the animations and get the physics working decently over the network. Check out the video below, see the two little yellow dots on the minimap?

Vehicles and Physics

I've added the Farseer Physics Engine to our game. I have to say, it's very impressive and a lot of fun to play with. I spent hours tweaking various physics values and trying different functionality. For now, my goal was to get the engine integrated into our game and create a vehicle that can ride around our maps with a mounted turret gun that fires. To do this, I first had to make our map ledges "collidable" with Farseer's Physics Simulator. I changed the map loading routine to automatically create polygon "Geoms" with which objects can collide with when creating the ledges. Then, I went to work with building a prototype vehicle that I (very) roughly modeled after the Warthog from the Halo series. One interesting thing I discovered during this whole process is that most popular platformers don't actually use realistic physics like this. It makes the character difficult to control and the movement just doesn't feel "right" for a human (or human like being). For this reason, I decided to keep the original, simple, physics system I already had developed and include Farseer as an additional physics system to use only for specific entities that require more complex and realistic physics such as vehicles and grenades. Because we don't have art yet for sloped ground or any vehicles, I just draw simple shapes to demonstrate the physics and vehicle.

A Brave New World

It's been a long time since my last update to the blog. It's not because I took a break from the game, but rather that I've tackled my toughest challenge yet. I decided to design my own system for map linking and mini-maps. Instead of looking for help and examples in books, forums, or blogs, I sat down with a pen and paper and planned things out myself. It took me quite awhile to come up with answers to all the problems I faced, but I think I ended up with something decent that works and I'm happy with it. I call a collection of maps a "world", hence the title of this post. I needed to make a new editor to create worlds with, but I'm bored to tears with the UI code so I just put together something super ugly but super quick, copying a lot of code from my previous editors. The video below shows Chris' new shark, which I think is super cool, running through our first test world.







Next up on my TODO list is to fix up a few map transition issues and then experiment with the Farseer 2D physics engine to see if I can get it working with our game.

Shark Attack

We added a new character yesterday, the so far unnamed shark warrior. I've been working on the art for this character on and off over the last two weeks. The shark is going to act as our strength character. While the blind warrior will be our DPS and the Bargle is going to fill the intelligence/tech role. At least, that's our thinking so far, the game is ever changing.



I put some time in after I finished the sprite work and got a pretty decent run sequence going. Since I've been working on this game I've been using the book Cartoon Animation by Preston Blair as a reference. The book is very old school and at first glance looks a bit cheesy but it's actually packed with tons of good information ranging from character creation to animation sequences. It's also very easy to find online for free.



I based the shark's run sequence off of the sequence below. It translated pretty well but I did have to add one more frame to the sequence to get it looking right.

Reading and Writing XNA Game Data on the xbox

This is something that you think would be simple and straightforward but is actually a bit tricky. I found it tricky anyways, because I could not find adequate information on the subject from Microsoft's XNA and MSDN web sites. Surely, I could be missing something somewhere, but it wasn't apparent to me where I could find what I was looking for. After reading about a dozen or so blogs, forum posts, and MSDN pages, and struggling with my game for a few hours, I finally figured it out. This is what you need to know:


1. You need to use the XNA Storage API, which conveniently will automatically work with PC and xbox without having to code separately for each.


2. There are two separate file locations to work with, the TitleLocation and user-specific folders. The TitleLocation is read-only and stores all game related data that ships with the game. In my case, this is where my map and character data files are kept and read from. I simply place the files in the root folder of the project and add them to the project with properties set to "Copy if Newer" and "No Processing Required". The user-specific folders are read/write and this is where you can save/load games, store high-scores, etc. and it is per user (xbox or windows user).


3. When opening a stream to read data from your TitleLocation, be sure the access flag is set to read-only. It will crash if you open it any other way, even if you only plan to read from it.


I'm not going into all the details with code examples, because there's a lot to find on the internet already. I just wanted to point out some of the facts that I thought were missing from what I read in my research.

Turrets!

Originally, we had decided that we wanted to make the game single player, with possible multiplayer and coop additions in the future. However, last week we reversed this decision and opted to go for a multiplayer only game first and then possibly follow it up with a single player and/or coop campaign mode. This would make it easier for us to release the game sooner as less content is required. We started thinking of different types of online games we enjoy playing and although we don't have a definite plan yet, we're leaning towards a sort of 2D Starsiege: Tribes inspired game. There would be two teams, each defending a base where they can deploy turrets, defensive walls, generators, etc. and would heavily rely on setting up cameras and motion sensors to detect and track enemy movement on the map. The map would be divided into many screens to make a big playable arena, so it's not just about combat, but strategy and communication. These are just ideas right now, and we're not sure how well it work out just yet, but that's where all the fun will be trying out different ideas. So this week, we had two major accomplishments: adding the turret, and getting the game to run on xbox. Getting the game to run on xbox was harder than it probably sounds and took me a few hours to figure out. I'm going to post a separate entry on that process for future reference and in case anyone else gets stuck like I did and stumbles across this blog. Anyways, check out the cool turret:

Rock n' Roll Arm

The main addition in this update is what I call the "rock n' roll arm". Last update, I added the ability to aim your shots in any direction, 360 degrees, using a crosshair. Unfortunately, this didn't look very good when shooting in any direction except straight ahead because the animation for the hero just has him aiming straight ahead. I fixed this by replacing his shooting arm from the defined animation with a special arm that will rotate to aim wherever you are aiming. This looks much better, and when you circle his arm around it looks like he's rockin out really hard. Aside from this, I also added character-to-character collision and a hollywood style slow motion effect which can be scripted. The new collision allows for characters to push each other around. The slow motion effect is simply to add some style, and to show it off, I added it as part of the attack combo animation I created a few weeks ago.

AI and the Crosshair

I've done a lot of updates since the last post, so the title doesn't do it all justice. I implemented some simple artificial intelligence for the bad guys. I bought this book on game AI years ago that was written for C++ and shows how to create a state machine for managing character AI states. It's pretty robust allowing for you to have functions that execute when entering and exiting a state, and a global function that executes along with each state. Right now, I just have one state that each enemy type uses called "stroll" which basically has them wandering aimlessly with a 5% chance every half second to either jump or change direction. They are also smart enough not to fall off ledges or to run into walls endlessly.


Besides AI, I spent a lot of time polishing up collision; giving characters, melee attacks, and projectiles their own collision rectangles. The projectiles and melee attacks now collide with characters not on their "team". The team concept will be useful for co-op and multiplayer further down the road.


I also added the crosshair from my previous game attempt. While holding down the left trigger on the gamepad, a crosshair is drawn at your head. You can use the right thumbstick to move the crosshair within a certain radius of your head. This crosshair can be used to aim most weapons in any direction and I'm thinking of incorporating it into combo moves in the future.


The last, and coolest looking, update was to the standard shot. Chris came up with some much nicer looking graphics for the standard shot. One is in motion with a tail, and the other is a ball used for when its revving up to be fired and when it collides. When I saw the ball, I thought it would look awesome as part of a particle system and quickly derived a new one based on the explosion particle system with some tweaks. I set it up so the regular graphic will be used alone for a quick shot, and if you charge it up for more than 2 seconds, you get the cool energy trails.

Projectiles and destructible tiles

We have projectiles! Not fully implemented yet, but I took my old abstract projectile class and derived "standard shot" class from my previous game attempt and fit them into the new game with map collision. The character editor really helps out here because, with my new updates to it, I am able to specify a starting location for the projectile relative to the character animation. In my previous game, I had to hard code that per character which is annoying and messy. With a few updates to the hero's run and fire animations, he is able to shoot while standing idle or while running now. The other nifty update is destructible tiles. In my previous game, I hard coded the destruction animation so every time you blew up a tile, it crumbled the same exact way. That was ok, but this time around I decided to kick it up a notch and create a particle system for destructible tiles. Now whenever a tile is destroyed, the image is broken into 16 smaller pieces that are randomly blasted away from the center in varying directions, speed, and rotation, with gravity acting on all of them. For demoing and testing purposes, I added functionality for me to add destructible tiles to the map while I'm playing so I'll always have something to blow up =) Check out the video below:

The Bargle Collective

After boring myself to tears making map segments for a week I decided to switch things up and make a new enemy. This little guy is tentatively being called a Bargle. They are going to serve as our games version of the koopa troopa, in that we'll have different versions of them doing different things. Some ideas we've been throwing around so far are mech operation and manning gun turrets. They're going to be adorably ferocious.

Game state management, particle systems, and segment painting

Since I last checked in, I decided to add two things to the game that I already had working in my previous game attempt: particle systems and game state management. Both of these systems I borrowed from samples available from the official XNA web site. I like the way they are done and they are easy to expand from to fit the needs of the game. I built a simple but effective cutscene system off of the game state manager where you simply put the art and sound files in a folder with a name that is a number (like 0, 1, 2, etc.) and you can reference it that way to load and run it in the game. It simply displays the art and plays the sound file one at a time as the user hits the continue button. The video doesn't have sound but you get the idea. In the future I might expand this further to include a script file to make things more robust. The last, and most difficult, feature I added was to the map editor. I had come to realize that it is very difficult and annoying to keep having to line the segments up perfectly and repeatedly when I want to use them repeatedly for a scene. I decided to create a paintbrush like functionality where if I click and drag a segment, it will paint it repeatedly, side by side, or one on top of another, depending on which way I move the cursor. Implementing this functionality caused all sorts of bugs due to the simple way I implemented segment adding and manipulation. I went through and reworked the whole system to be more usable and work in harmony with the new painting feature.



This video shows off the segment painting functionality where I create a new sample map to test the new features with.








I script 3 tiles. The first scripted tile will cause an explosion as long as I stand on it. The second will trigger a cutscene that is just some stock images that come with Windows XP, then removes the scripts from itself so it wont play the cutscene again. The third causes an explosion and shoots the player into the air.

Basic Scripting

I read through the chapter on scripting from that book I previously mentioned. He implements a simple, but very effective scripting system for characters. This allows me to chain animations, move the character's position on the map, setup dynamic animations based on user input and a lot more. He teaches by example, showing you how to setup an attack combination that requires the user to time some button presses in sequence. I played around with our hero character and made a fun, over-the-top, attack sequence hollywood style.







After seeing how useful scripting can be for characters, I thought it could be just as useful for maps. After some thought, I decided to try allowing up to 4 script commands to be entered per collision tile. I added script editing functionality to the map editor and whipped up a simple, but fun test using the "SetJump" script command.







I'm thinking I can use map scripting to handle lots of things such as energizing stations, save spots, doors to other maps, teleporting, event triggers, altering map data dynamically, etc. Besides this fun stuff, I fixed up tile collision a good deal. I added platform tiles you can jump from underneath and land on. I added a feature to the character editor to let you define a collision rectangle per character. Lastly, I added a feature to the map editor to cause any map segment piece you pick up to become the topmost piece. This will make it easier for us to hide segments behind other segments.

First Videos

Here's a series of videos demoing early versions of our map and character editors, and a game world to play around in. I found decent, practical guides to implementing editors and simple collision from this book written by the guy that won Microsoft's Dream Build Play contest with a game I quite enjoyed playing called "The Dishwasher: Dead Samurai". I basically worked off his ideas and added some of my own features and GUI code to make the editors much easier to use. I recommend the book to anyone interested in getting started in game development. The first video below is showing the basics of the map editor





The next video is me playing around in the game world with the map I just created from the last video





The next video shows off a bit more of the map editor, creating sloped ground to walk on and using different surface types like ice and conveyor belt.





The next video is me playing around in the game world with the map I just updated from the last video





And finally, here's an early version of the character editor used to create the characters you've seen running around in the game world.

Scenery

I'm finally starting to get some basic map segments and tiles down. The only part of the above picture that isn't part of my map segments is the hasitly thrown together sky.

Variety

The zombie head palette has been expanded by two menacing glares.


We also now have a shooting arm and a front facing idle leg for the hero.

The game so far...

The hero's leg palette has been expanded to include three additional legs. I tried to make the legs a little more expressive this time because the original seemed kind of stiff.
On Sunday I did some work on the zombie's fist. You can see the original fist on the left and the new one on the right. I think the extreme angle on the elbow improves the sprite but it probably still needs some work.


The image above shows the first enemy we have for the game, a very animated zombie. Below you can see the zombie's furious slap attack.