ZSpline

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.

In the past 5 weeks I was helping out the programmers however I could, that’s why I didn’t update this blog as regularly as before. In spite of spending less time on making pretty things and more looking at screens full of text, I’m quite happy how the past month turned out.

I’ve been programming (or more like scripting, if a real coder reads this) on and off in the last 15 years (with the first few in high-school) but I only worked on smaller, self contained tools, never on complex systems with other programmers.
In the case of Gavit I still didn’t want to touch the code at all. I figured that system design, documentation, modeling/texturing, game/level design and special effect authoring will be enough on my plate. It will be best if professionals take care of the code side, ones who know the engine inside out so stuff will be done the most efficient way possible.

What I only realized recently is that there is room for me to contribute to the programming tasks, especially when it comes to experimental and engine agnostic solutions.

The programmers I hired live on the other side of the globe and work on many projects at once. When I sleep they work, when I wake up they’re about to leave the office. I have a very limited window to chat with them and they have limited resources to fulfill my wishes. Turnaround time is long and communication is relatively difficult, in spite of the absolute professionalism and total good will of the participants. It’s just an inherent problem with remote work situations.

As the holiday season came up I felt that I can’t avoid chipping-in the programming tasks. I did smaller stuff for the project before but that was just messing around in Notepad++ which was fine but I figured this time around I’ll need proper tools for the job. I installed VisualStudio with nFringe and jumped in.

My productivity instantly increased ten fold.

There are so many things which are basically the waste of the time of a veteran programmer. You don’t need 10 years of experience with Unreal to be able to derive velocity from a series of positions, to smooth mouse input or convert between two coordinate systems. With some common sense and google skills a surprising amount of practical problems can be solved, as they arise.

With a proper IDE having my back the tasks became puzzles to solve. The proper architecture (made by real coders) often guided my hands when I wanted to extend functionality. I knew what I wanted to do, the logical structure made it clear where to put the stuff and after looking up a few examples I knew how to do it properly.

And I can’t stress enough how much help I got and keep getting from James and Sam. They’re patient enough to explain things to me and don’t hesitate to correct my sometimes sloppy programming practices.

All in all, as a technical artist I really enjoy the tremendous freedom casual programming gives me.

We had to cut Gavit’s character related features (for now) but since characters are somewhat important in games and stories I’m looking into alternate means of showing figures and communicating intentions.

The most obvious solution is posing ragdolls, as seen in the following video:

I used the Razer Hydra in both hands to control pairs of reach targets for ragdoll bones: Head and hips, left and right hands, left and right feet. (Those are the red/green wireframe blobs on the video.) The pairs were selected using buttons while the camera was rotated with the thumbstick.

I learned the following lessons during this mini project:

- Input with 6 degrees of freedom is nice although movement perpendicular to the screen is hard to judge.

- Controlling two things at once does not help posing. I ended up focusing on one hand while tried to keep the other in place.

- 6 control points for a human body is the absolute minimum. Controls for shoulder, chest, elbows and knees would’ve made work faster and the result better. (Why didn’t I just copy Motionbuilder…)

- Clay-like, very tight  joints would’ve made things easier but I couldn’t set up the physics asset that way. (For some reason 0,0,0 velocity target with 9999999 force had no effect at all… o_O )

- Actor relative positioning (as opposed to camera relative one) is confusing.

So it seems that ragdoll posing can be helpful provided that the poser rig does the following:
- Select and work with only one control point.
- One hand manipulates control point, other adjusts view.
- Choice between local and camera relative transformations.
(So it would be a poor man’s Motionbuilder.)

Animating a character real-time will need a different, more marionette like setup, which will be the challenge for the next few weeks, after I finished one more prototype in the pipeline: an Arcade Volleyball homage.

I’ve implemented a counter shader in Unreal, similar to the one I made in ShaderFX:

I managed to correct a huge mistake I made back then so now there is no numeric precision related visual degradation present. Float precision still causes a problem but that affects the actual value shown on the counter: at 7 digits the displayed number is occasionally off by 1.

Toward 10 digits the issue becomes much more serious so I’ll need to come up with some sort of a solution. I hope I’ll be able to simplify the math involved (to more operations we perform the more precision we lose) but if nothing else helps then I will just duplicate the tree and process the incoming value in two parts.

The Razer Hydra integration progresses somewhat slowly these days. Position and thumbstick data is handled alright but the rest (rotation, acceleration, velocity) is still not implemented. I’ll need at least rotation to be able to make a minigame where one must bounce a ping-pong ball from one paddle to the other to get points (displayed on a fancy counter).