(Watch it in HD on Vimeo)

The base mechanic works for both meshes and particles, can be used for fires of different scales (from candle flame to forest fire) and the material’s complexity can be adjusted. More on this in the upcoming “behind the scenes” article.

It will be used to showcase my fire material.

I also added a few example pies for different tasks: UniPie_Examples.pdf

Convenience is the main reason why I find pie menus useful when it comes to accessing frequently used functions: the pie appears under the cursor so a slight movement of the mouse selects an action. That beats targeting toolbar icons, digging through linear menus or reaching for a key combos.

The use of a pie menu can be greatly enhanced by arranging functions in an intuitive manner, where the movement and the invoked action have some sort of a relation. For example here is a pie menu I hacked together for Adobe Illustrator using AutoHotkey:

The brown slices perform arrangement actions: a small move up or down sends the selected shape forward or backward in the stack while a longer push sends it to either end. The movement of my mouse wielding hand resembles the motion of the selected shape in the stack which makes the learning curve quite shallow.

Or take the blue slice containing file operations: The slice points toward the top left corner where the file menu is located. Executing the “save” action requires less effort since I’ll need that quite often. Export is somewhat related but less often used so it occupies the outside slot. By the way, the blue color comes from the 3.5″ floppy disk which is often used as an icon for saving. The other place where slice color is related to action is Remove Anchor where the red indicates a “dangerous”, destructive function.

Another example for the movement-functionality link could be one of the pie menus I use in modo:

The down motion hides the selection (“I hide it under my desk”) while the up movement unhides everything (“I put things back up onto my desk”).

So with some thought intuitive arrangements can be produced and when muscle memory develops the whole workflow becomes transparent.

It takes decal projection width and height as parameters so the texture doesn’t stretch at the corners. Another parameter defines border thickness which is the absolute size of the border slices:

And of course the user can also define the location of the 4 cuts which create the 9 slices.

Generating the proper texture coordinates costs 24 instructions but it could be simplified by sacrificing some of the flexibility (like forcing symmetric cut positions).

GVEffects are abstract entities containing any number of basic building blocks called EffectTypes. We have particle system and decal effect types working, light and sound will be implemented later. A typical setup would look something like this:

[GVEffect: FlashyExplosion]

[0][Particle system: Base explosion]
[1][Particle system: Black smoke]
[2][Particle system: Burning ground]
[3][Decal: Scorch mark]
[4][Light: Explosion flash]
[5][Sound: Explosion sound]

By combining different bits and pieces a wide range of different visuals can be created without the need for authoring new assets. (Of course having a decent library is recommended.) In the example above the black billowing smoke could be replaced quickly with a gray smoke puff sort to experiment with the visuals.

There are many additional parameters for defining the behavior of effect types like start delay or life time. Position, rotation and scale can also be set and randomized for each item.

GVEffects are always embedded in other entities which will create them at runtime when it’s appropriate. For example a pawn might have a GVEffect set up for spawning to make it look like the character was teleported onto the map.

Another example is physics material based interactions (which I implemented last week). What this means is that when two objects are in contact, the right effects are created depending on the interacting materials. For instance if a stone ball hits a reinforced glass surface the following effects will be created:

• Puff of stone dust (particle effect)
• Crack on the stone ball (decal)
• Splinters of chipped off glass (particle effect)
• Cobweb like cracks on the glass (decal)

Each material has its own set of effects for the different types of interactions: impacts, sliding, foot steps for light/medium/heavy characters, bullet/pellet/energy weapon hits, etc. The effects can be dynamically adjusted based on properties of the interaction. For example the force of an impact sets a certain parameter (called “Amount”) in the related particle systems and decal materials. What those assets actually do with that information is up to the author: a decal could change size or opacity, particle systems could vary particle number, size, speed, even turn off emitters entirely for smaller impacts.

While I had no trouble with impact effects, slide detection turned out to be a huge problem. Apparently I have no direct access to contact points in the physics scene which makes it rather difficult to find out which actors are in contact. I did manage to get the necessary data but the workaround is hacky, slow and not very reliable. I might revisit it in the future but it seems that I can not do better without access to lower level functions.

To distract myself from Gavit, I took on a side project: MCEditor. It will be a proper configuration utility for the Razer Hydra controller which to this day lacks that kind of a software. (Razer has a lot to learn from Logitech in this regard…) The programming is handled by a fellow Hydra owner while I’m responsible for the UI. We’re using C# and WPF and this is how it looks at the moment:

This is the second major iteration of the layout. I really enjoy that the challenges are so different from the ones I usually deal with, it’s somehow refreshing. So much so that I intend to start another side project when this one is done.

Next week I’ll work on motion replay for rigid bodies and try to finish my earlier pinball prototype.

On the code side I had to implement proper handbrake functionality which to my surprise was missing, added a few usability tweaks and laid the foundation of a modular car system where one will be able to assemble a car from different parts.
I learned a few lessons while dealing with the less than neat codebase. These are the most screwed up ones:

- SVehicle.MaxSpeed doesn’t necessarily define the actual max speed of a vehicle. One should also set Pawn.AirSpeed high enough too.

- The stock handbrake system does not prevent the wheels from rolling for some reason. It only changes slip values on the tires so actually locking the wheels needs an extra function where you apply throttle based on the local velocity vector.

When I had my vehicle class working I started modeling the car which will be the hero of the next prototype video.

I’m a fan of classic muscle car designs so the vehicle was based on a Plymouth Barracuda but got the undercarriage of a Ford Mustang, tail lights from a Dodge Charger and the hood of an Oldsmobile. (Coincidentally all of them were from 1970.)

I used the Pixar SDS implementation of modo 501 so the high poly mesh is reasonably clean.

The SDS cage was the base for the low poly mesh which sped up the modeling process.

This time around I used modo (instead of Max) for object baking all surface properties: diffuse color, reflection amount and normals. The baking was performed on “exploded” versions of the objects (via a morph map) to prevent baking artifacts on surfaces close to each other:

As you can see not the whole car was baked only one half plus one extra polygon row on the other side of the mirror axis so normals are properly aligned near the cut.

There were extra textures, “mask maps” baked too where the red channel defines the area of the painted body while green indicates decals:

The decal texture is actually a distance field which is used by the in-game shader to produce a sharp decal mask:

Both the body paint’s and the decal’s color can be defined in a material instance along with the thickness of the decals (plus the usual surface properties).

The textures have a 2K native resolution but only the diffuse map is presented that way at the end: the specular map is fine on LOD 1 while both the normal and the mask maps are stored as uncompressed normal textures so they are automatically loaded at half resolution.

The uncompressed normal map not just looks smoother but also fixes the seams along the car’s forward axis where it was mirrored.

The following weeks I’ll tune the cars and add a few special effects like break lights, wheel smoke and damage.

The GVMachine class is basically a bridge between an input (a joystick for instance) and a property of an actor (like the location of a box). When the input changes (the joy is pushed forward) the GVMachine translates the data and adjusts the target property accordingly (the box rises).

GVMachines can receive input from one of two sources: either from the user directly or from matinee. The two are handled the exact same way in a GVMachine so it can not tell the difference between them. One can even switch input sources on the fly, interrupt a matinee playback with live input or vice versa. If everything works properly then we can recreate the exact same events later using matinee.

Well, almost the exact same events. Handling analog data is pretty easy because by its nature changes are relatively slow (in computing terms) and gradual so interpolation between keyframes will create a pretty close representation of the original. However digital button events are a bit trickier to handle because they don’t translate well to matinee curves.

Let’s consider the following graph:

This could be an obvious representation of a button being pressed for a while: At the beginning the curve’s value is 0 then suddenly it becomes 1 when the button is pressed, stays 1 while held, until suddenly falling back to 0 on release.

Trouble is that we can only sample the graph every now and then, depending on how fast the game thread ticks. The time between ticks varies in a pseudo random manner which means that although we have a slim chance of learning about an event at the exact time it happens (getting a tick at 0.2 and 0.5 in this example) most of the time we will be late. A typical bad case would be sampling at 0.199: just short of noticing the state change so the next time we come around we already late by almost a full frame.

At this point one could suggest that if I worry about a button press being too late then why not offset the whole curve by a fixed value so events appear in the system a bit earlier thus more or less cancelling out our inherent sampling lag.
This would be a reasonably good solution but there is something to consider: we can record what a GVMachine does, regardless if it was controlled by live user performance or by matinee.

Imagine that I try to perform a series of car stunts, 2 minutes of length. I could try and repeat the whole sequence over and over until I get every bit right. This approach would not be very efficient as a single mistake in the last second would render the whole performance useless.
A better way of doing it is focusing on one short segment at a time, redoing it over and over while recording each session. When I’m happy with my performance then I convert the recorded data into a matinee and let it replay from then on automatically and consistently. That segment is “in the bank” so I can focus on the next bit: as soon the matinee replay ends (or even before) I take over and carry on the stunts. I’ve just seamlessly extended the previously recorded data. Replay, add a new segment, rinse, repeat.

And this “recording the replay of a previous recording” part which will run into trouble if the matinee button events keep happening consistently too early or too late: with each recording cycle the events will float off further and further in one direction.

To solve this I tried to make those events “wider”, easier to hit so I ended up a graph something like this:

Each button event is preceded by a warmup period (0.1 on the picture but 0.02 in the current implementation): if the sampled value is in the 0..1 range then we know that a “push” event is coming up, while if the value is between -1 and 0 then a release event is imminent. Not just that but we also know when something supposed to happen in the future: if we got the value of 0.5 then we know that a push event supposed to occur WarmupTime*0.5 seconds from now.
By keeping track of the average time between ticks we could take an educated guess which one is closer to the real thing: this tick or the next one. In the former case we fire the event now, a bit earlier while the latter case will produce a late event in the next tick. The important thing is that regardless of too soon or too late, we picked the one which is closer to the ideal time.

The somewhat random timing of the sampling ticks will cause a certain event to be fired earlier in one recording cycle and later in another. This won’t stop the floating of the timing but will slow it down, hopefully to an extent where this won’t ever become a practical problem.

The biggest disadvantage of this approach is that events can not be closer than the warmup time, which is 0.02 seconds currently. I did some measurements and the fastest doubleclick I could reliably perform was 0.022+ long so that value seems fine for now. However this also means that the game thread must run at at least 50 Hz in order to guarantee a hit during any given warmup time, but that is a good idea to maintain for other reasons anyway.

Next time I’ll cover the recording part of the system.

As I mentioned earlier the base mechanic was inspired by the old DOS game Arcade Volleyball. Back in the mid 90′s I played it a lot with my brother and friends so I wanted to make it a two player game. I had also just added a few features to the Razer Hydra integration which needed testing therefore I chose to base the controls on that input device.

The season lent itself as a visual theme and I started using snowmen as main characters. At first they were just sliding back and forth but hitting the ball with the narrow top of the hat was somewhat difficult. Before going with a different avatar I linked up tilting to see if it’s fun. While it needed some tweaking, at the end this additional degree of freedom turned out to be both intuitive and useful.

Jumping was implemented at some point but I removed it because it wasn’t adding that much to the fun. My general goal was to make it as simple as possible so even my non-gamer mother could enjoy it. (And she did indeed, became adept quickly.) However if I ever revisit this prototype I’ll experiment with jumping again because it has the potential to provide some additional complexity, something which more experienced players (like my brother) expect.

Jumping or not, the base control rig for a snowman is the same: the physics driven pieces (hat, head, body) are constrained together with the body also being constrained to a hidden interpolation actor (the orange circular one on the image). That actor is directly controlled by the tilting of the Hydra. It’s attached to another hidden actor (with the arrows on the right), the one which is responsible for movement: swinging the Hydra horizontally makes the in-game actor move back and forth.

At first I used the raw rotation data from the controller but that felt sluggish near the edges of the play field. The solution was to use the tangent of the incoming angle which made the system work almost like aiming with a laser pointer. (Just ‘almost’ because the position of the controller is not factored in at all, something which I’d like experiment with in the future.)

The reason for using separate actors for movement and rotation is simply that it was easier to debug the underlying systems during development, at the current stage I would probably use a single actor.

The constraint between these interpactors and the physics driven snowman is not rigid but behaves more like a rubber band. This makes movement softer, without sudden accelerations or stops. The tightness needed some tweaking so it felt smooth enough but not so much that it affected precision adversely.

Without contour highlights, the hat blended into the background.

After adding the ball (constrained to a plane) I had the core gameplay which allowed me to fine tune restitution, friction, speeds and accelerations on the participating actors. With that done came the first round of two player play testing which revealed several shortcomings from hard to see hats to unintuitive control settings. As soon as I sorted them out I finished replacing the stand-in art assets with proper ones.

Here too I aimed at a tasteful but fast to create visual style, just like for the rest of the Gavit prototypes: basic colors with accentuated edges emphasizing the geometry. I used modo 501 for everything from modeling to texture baking. While I didn’t make high-poly versions of the meshes I did turn their polygons into Pixar-SDS for the duration of the baking so concavity/convexity/accessibility shading produced smoother results:

The subtle differences between the polygonal and SDS cliff.

The next step was adding special effects mainly to provide feedback about game events: the red light inside the ball foreshadows (erhm…) an imminent bounce for example. The glitter suspended in the air is not just for filling empty space with something interesting to look at but also there to help visualizing forces affecting the map.

Since the glitter was actually a PhysX fluid it automatically interacted with nxForceFields and the ball. In the latter case they simply collided with the sphere which didn’t produce an interesting enough particle movement so I tried to fake vortices in the ball’s wake: I made an ActorFollower actor which follows a target as if they were linked with a rubber band. The faster the target moves the more the follower lags behind but it does converge on the exact position at low speeds. With this system in place I simply attached a radial forcefield to this follower to get some extra swirling behind the ball.

There was a bug however: although the ActorFollower scaled the attached force field based on speed, it had no effect at all: its radius and strength stayed the same no matter what. This issue made the stationary ball attract nearby glitter as apparent on the video. I had no time to debug this before finishing the prototype but after posting the video I dived in to see why I can’t change force field properties on the fly. As it turns out it’s a limitation of PhysX so one must keep creating and destroying force field actors instead of changing existing ones. Unfortunately this would break all references (in Kismet for instance) so I had to introduce a new force field class: one which doesn’t actually affect the world, only there to be referenced, to store desired property values and to spawn/remove working force fields when necessary.

Finally here is an image showing the result of a collision hull export problem:

A bowling ball is not an ideal choice for this sort of game.

The players use the Razer Hydra controllers: aiming at the screen moves the snowmen, twisting the wrist makes them headbutt.

This project was finished in about 15 days: the core game mechanics and controls took 5 days, asset authoring was done in 6 and I spent the rest on the special effects.

That’s all for now, I’ll discuss the technical details in an upcoming ‘behind the scenes’ article. EDIT: It’s up.