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.

Meeting Notes

Boss battle idea

• Necromancer boss
• Survive six of the seven bells
• Astarael takes everyone into death where Abhorsen waits to rescue the player and banish the necromancer
• After each bell a wave of zombies
• Each bell may be interrupted or rung
  • Interruption gives the player time to prepare for zombie wave
  • Successful ringing casts a detrimental effect which has a significant chance of causing the player harm indirectly
• Art concerns (too much!)
• Boss battle will improve the game greatly, but time will be a factor

Chase scene

• Example of mirrored level design
• Run from Mordicant
• Battle Mordicant
  • Fire melting ice to defeat?

Charter Marks

• Much discussion on how many to include
• Spells should be aimed with mouse
• Propel mark for force in direction of cursor
• Symmetry in level design should be mirrored in mark effects
  • Tree "circle of life"
    • leaves set on fire with fire
    • fire put out with ice
    • leaves regrown with grow

Physics

• Built-in Torque physics are insufficient
• Use Box2D instead (C# port Box2DX)
• Integration might be challenging without Torque source
  • Builder collision editor requires T2DCollisionComponent
  • We can parse collision vertices and replicate in Box2D
  • Turn off Torque collision, but still there to hold data