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.

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