Week 10 Update

This has been a particularly successful week for me and QTO.  I'm confident that I will have something to be proud of by the time I have to present - four weeks from today.

Progress since last week:

• character swears when loading last bullets
• added an inventory (holds all the items)
• stockpile energy cans, health kits, ammo boxes
• character now can't pick up items when inventory is full
• use energy cans, health kits, or pistol if equipped
• modelled, textured, and added metal and wooden bats
• added melee weapon combat capabilities
• added sounds for bats and machete
• added an inventory screen that shows details
• equip items from inventory screen
• started working on particle systems: created rain, mist, fire, smoke
• added a mission screen (will show map and let player save, change options, see controls, or quit the game)
• implemented quitting and options

Newly discovered bugs:

• shooting up at the very beginning kills random zombies
• zombies attacks constantly - implement a finite state machine
• the input states on the level screen are updating strangely when closing other menus

~John Adam

Midterm Report - Half way there?

It feels like time is flying by too fast, especially since the due date is coming up in mid-April!


Here is a link to the report in full.


And here's how the game looks so far:

A nice and bloody title screen, showing off game menus.

Exchanging Ogre for XNA

Over much debating, I've decided to make Quarantine TO using C# and the game engine XNA, rather than C++ and the graphics engine Ogre3D.  Changing languages and engines while the project is in the making is not something I recommend, but in this case, I think it will be worth it.

Ogre doesn't let me attach a node to a bone, only entities.  Nodes are required for scaling, rotation, and translation.  I was planning to have the characters' items shrink down and vanish while the character puts them away and grow as they take out a new one, but since I can not attach a node to a bone, I can not have changes size or rotation.  The option left is to give each and every item two scaling animations, which is kind of rediculous.

Scenery Leaping

I’ve come up with a cool way to help keep the game light and fast while appearing full.

Each level in my game will be made of a bunch of streets in Toronto, but I don’t have the time to go and model every building, so the game will show a generated approximation of Toronto.  For a residential street, there will easily be over a hundred houses.  Since I will have about 10 different house models, I have to spread them along the street repetitively.

As the character walks forward, the same houses will leap from behind them to in front of them, giving the player a view of a fully designed street, while it’s actually all being built just out of view.  This way, I’ll only have to have a few houses in memory at one time.

I call it leaping.  Although I’m sure something like this has been thought of and done before, I’m still pretty proud I’ve done it myself.  Don't get me wrong, it's simple, but it's very useful.

The same tactic will be used for fire hydrants, street lights, stop signs, etc.  The code doesn’t change between these types of scenery objects, so fleshing out Toronto will be a breeze!

The beginnings of a daily log

I'm starting to keep a daily log of my progress.  I won't go into too much detail, since most of these points are self explanatory.  I'm not a very experienced 3D artist so it takes me a while to do simple things, but I'm taking my time to make the models look decent while being low detail.  This will help keep the game running smoothly.

Sunday, October 16,  ~5 hours

• modeled the shotgun
• started on the inventory prototype
• made item disk graphic using Google drawings
• started working on two dimensional collision physics

The weapons so far.  No textures have been created yet, so they seem kind of flat, round, and off-colour.

Game design document

For those who don't know, a game design document is made to bring all of the creative ideas one has about a game into concrete form. It means making a lot of decisions early on so that you have direction later on, leaving you to focus on development. When working with a team, like I am, it helps make sure everyone has the same concept. The game might not follow every line spot-on, but it should end up being rather close. Here's a screenshot of my completed GDD for Quarantine: T.O. from a bird's eye view.


If you're interested, you can see the whole thing here. I'll be pulling parts from the document and posting about them as I work on those parts to keep you all in the know of how it's coming.

~ John Adam

A fresh start

This blog will be a place for me to publicly record my progress of my capstone project for my game programming course at Humber College.  It will be a zombie apocalypse survival shoot-em-up type game, and hopefully will be pretty complex.  You can read the project pitch here.

I hope to inspire a few programmers wanting to create their own games with this blog.  It's going to be a wild ride!

~ John Adam