Game States

Here’s some screens of the new game state system we just put in. With this our game is now re-entrant, meaning we can load and unload levels on the fly. Torque makes this slightly difficult since we have it in between us and XNA (which the state system is build on).

There’s still a minor bug regarding that, where Torque still updates its world during a pause. Box2D correctly isn’t updated, which causes some strange synchronization issues when we un-pause. Unless C# allows us to call a super-class’s function we’ve overridden beyond the immediate base, we’re kind of screwed. XNA provides a base Game class that Torque derives off of and we derive off the Torque derivative… We need a way to update XNA, but not Torque.

Also on display is Andy’s new level. To the right of the player we have some new platform types, the spring platform. These platforms are attached to a spring, so when the player (or any other object) lands on them, they compress downwards and attempt to compensate with spring force. While not pictured, we also have moving platforms (on a track), platforms that rotate around an axis and platforms that change state (like trees light on fire). State changing platforms allow us to do things like platforms that disappear when you stand on them too long.

Engine Update

Not really much screen shot worthy in the realm of updates this week. We’ve been overhauling a lot of stuff behind the scenes, tightening our integration with the editor, etc.

The charter marks now make much more rigid spell chains, thanks to the new cross-hatching joint system Sean devised. We also have a grow mark in its infancy, though nothing to test it on level wise. We’ve added a few hooks into the charter system to allow real-time tweaking of physics properties, much like the previous work on the character.

Collision filtering is now fully integrated into the editor, thanks to a full overhaul/refactoring of the Box2D components that makes it really easy to create new physical objects/triggers. The sandbox level doesn’t really take advantage of this much yet, but Andy has a level in the works that does.

Gameplay wise, we just checked in a new checkpoint/respawn system that saves state. This allows us to rollback the level to its previous state when you die and respawn at a checkpoint.

GUI Casting

More timely update this time! Here’s a screen shot of the new GUI system we just finished up in time for the weekend. The player has three pre-made spells they may cast at any time during the game, depicted as the three slots on top of the bottom large one – the spell book of marks the player currently knows.

The GUI supports full drag and drop between the spell book and each spell. You can drag around marks within spells to re-arrange them and even from one spell to another. When dragging a mark around, it will snap to valid places it can be dropped, giving the player visual feedback about where valid drop points are. Dragging a mark to an invalid spot deletes it from the spell.

Spell casting is achieved simply by pressing the left mouse button – this casts the currently active spell. The player may switch the active spell to one of the three spells with the right mouse button, cycling from left to right. This will probably be bound to the number keys 1,2 and 3 later for fast switching. As of right now there isn’t any way to tell which spell you have selected, which sucks. We will probably place a glow around the spell box of the active one or somesuch once we get UI art.

You may be wondering what the lone propel (thick black arrow pointing right) mark is doing. Well, I’m actually dragging that one around in the screen shot, but for some reason my mouse didn’t get captured with the print screen. The faded question mark runes appear on the ends of spells when you start dragging and disappear when you stop. The idea is to give the player visual hints where obvious places are to drop the rune currently being drug around. We give a little tolerance behind the scenes though, just dropping a mark quickly from your spell book to an empty spot in a spell will automatically place it at the end of the spell – so you don’t have to drop it exactly on the question mark rune.

Debug Overlay

Here’s a screen shot of the new debug overlay that allows us to modify physics parameters in real time. Left clicking on any value increases its value, while right clicking decreases it. The effects are then factored into the physics simulation instantly.

Since our next big feature is a usable GUI, this also works out to be our GUI system testbed. Torque’s GUI system appears to be flat out made of fail, so we’re writing our own GUI and event system. It isn’t going to be fun, but our interface definitely makes or breaks our game.

We also had our first milestone meeting with professor White this week. After a swift application of Murphy’s law on Andy’s laptop, we finally made it up to Dr. White’s office. Meeting went pretty well and we set some further alpha and beta dates. Discussion afterwards descended into D&D talk.

The charter mark system also has a few new marks implemented, though they aren’t shown in this image. Ice and sticky marks are now in and working. Another milestone we managed to complete this week was squashing two critical bugs in the magic system that were severely hindering gameplay.

Andy’s been hard at work on a new level, though it too isn’t shown in this screen shot. He also managed to fix rope bridges exploding after being hit with a fire mark, so they actually behave nicely.

Collision filtering has been applied to the world, so we can selectively collide (or not) with any object group in the world. This makes spells much easier to work with now that they all aren’t colliding with the ground.

Our world also has support for “switchable” objects, or those that change state (like a switch) when they are hit with a certain type of mark. We’ve integrated this into the editor nicely, so burnable trees and freezable water are a reality.

Zombies and windmills!

First obvious change here is the new windmill in the middle of the screen. Andy’s lovely programmer art is used to show off our new rotating physics capabilities. The stack of boxes on the far right used to be with the sleeping ones in the middle, but were slapped around by the windmill and into the zombie’s face.

The zombie has some extremely sophisticated AI that allows it to seek the player’s brain in a straight line. Determined to feast on the player’s delicious brain, the zombie pushes on — despite boxes littering the path. If the zombie appears to be intersecting the boxes, you’d be right. This is due to the fact that we were lazy when we ripped Metal Slug art for the zombie and didn’t center the sprite on the bounding box very well, which is just off the screen in the picture.

Work continues on the charter mark system; while we don’t see any marks in this shot, the fire one now has a proper flame trail that isn’t made of peppers (don’t ask). Initial explosion force support is being tested to hilarious results that may or may not have resulted in a jet pack rune that heat seeks your face.

Charter Mark Integration

Screen shot showing off the charter mark integration we just committed.

A few things have changed here, the most obvious being the fact that there is a flying charter mark spell. The marks were cast individually and linked up into a spell chain via attraction forces free radial marks have to each other/ends of spells.

In order to aim the marks, we added mouse support and an aiming reticule that circles around the player, pointing towards the mouse.

Things were a little slow this weekend due to some pretty nasty hardware bad luck, but we’ve managed to duct tape everything together into a working state for now…

Andy’s laptop got so hot it literally melted the solder off the power connector—so it dislodged from the motherboard Friday. After many days of failed attempts at repairing those solder points – and many trips to various hardware stores – we finally just replaced the entire connector with a homemade external solution, with wires in between.

Physics Integration

Another screen shot showing off what we’ve been working on for the past week in the physics/engine department.

The first obvious change is the new level. This is a much smaller level that allows us to iterate changes much more quickly than the huge one we were previously using. It also has a bit of room to run around on flat ground to test the controls. Another big change in this level is the scale; we’re properly scaling 50px = 1m here.

Next would be the addition of Andy’s new character into the game. So far we have idle, blink and run animations.

The crazy outlines probably require some explanation; that’s my mess. This shows off my debug visualization of the physics engine we have integrated. They are color coded based on their physical state: red is a dynamic body that is active, blue is a dynamic body that is asleep and green represents a static body. You can see that the physics system is properly determining which bodies need to be active and which can be put to sleep to save CPU time.

The player is now enclosed in a capsule now, this allows us to smoothly slide up slopes/etc without getting stuck on corners. The addition of an extra body (the circle) also allows the engine to easily detect whether or not the player is on solid ground, which makes determining which state we’re currently in a lot easier. We’ve literally cut down the lines of code to determine this down an order of magnitude.

The screen shot doesn’t really show it well, but the player is currently determined to be in the "on ground" state, meaning we can jump/etc. This is working even though we’re standing on a completely dynamic box. Sounds simple, though Torque did not handle this case very well at all and required a complete extermination of any Torque physics, port to Box2D and rewrite of all the state code -- hence the major accomplishment of it working now.