Archive for January, 2012

In this post I’ll discuss the creation of the Winter Volleyball prototype.

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.

Here is my latest prototype, a homage to Arcade Volleyball:

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.