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.

Progress report

So it has been just over a week and we have made great progress. on the programming front we have the physics engine tied in with our platformer engine so we have solid body dynamics working in game. can currently script things like rope bridges and catapults with the editor. we also have a charter magic test bed up and running with runes linking and activating upon there own activation conditions.

Things are a little slower on the art front, but as you can see we have the main character designed and a run animation for her.


for the rest of the week we will be getting more art done. A color scheme will be decided upon and we will be animating the slide and jump animations. Chris will be finishing up integrating the physics system as well as writing a state and animation manager, while Sean will be finishing up the charter magic test bed.

And so, it begins...

Looks like everything we set out to do in pre-production has been completed and we're on track to start full-bore today.

Screen Shot

First screen shot showing Andy's placeholder recoloring/leaves and Wade's tree/ledge:

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

Concept Art

First piece of concept art by Wade:

Under Construction

We're currently in pre-production.

Stay tuned.