Two weeks ago I’ve started developing a demo for my game Dimension, a Platformer/Puzzle/RPG I started designing last year, in Unity. For a recent assignment in uni I had to look into something code related that I was unfamiliar with, and since I go through this process everyday I took this opportunity to continue development on my demo. My milestone for this assignment was simple:

• Learn how to code/effectively implement all trigger types in Unity.

After a few hours the magic was done. To keep it brief I’ll skip the technical insights this time.

Gameplay (for this milestone)

     A secret cave must be opened through the light of a butterfly. In order for the butterfly to illuminate the crystal set in the cave door, the player has to chase the butterfly to the cave entrance.

Last weekend I got uScript for Unity and used it to rebuild some elements from Until Dawn/Slender. It’s a GREAT tool to speed up design iteration in Unity. Having worked with it the last few days I learned quite a lot:

• All that time I’ve invested in learning/practicing scripting Javascript/C# for Unity wasn’t wasted. uScript is a low level visual scripting tool that requires at least some basic knowledge about coding and Unity specific class types.

• It’s often hard to identify how some Unity specific functions work and how the resulting output is defined. It is absolutely worth it to take an hour or two to sit down, create a scenario for the function in question and figure out how it works.

• .Rotation, .Euler Angles, and .Quarternion all influence an object’s rotation but work with completely different principles (duuh)

• Building game logic requires time and shouldn’t be rushed. Think through before hand what you want. It can save you a great deal of time.

• Using the Unity engine (scripting, importing, etc.)
• Rigging/Animating models in Maya

For a weekend’s work this project turned out to be…well…seeing in run smoothly on high resolution almost made me cry. I focused on making the character run and built a simple trigger sequence as a learning process with Unity. Rayman is standing in a little valley when you launch the game. Once you find and activate the a the TNT box sitting next to the blocked waterfall it initiates the trigger: the camera pans to the waterfall, an explosion clears out the stones, the water starts flowing and the waterlevel starts rising.

As I am preoccupied with my projects I’m just posting my learning outcomes in bulletpoints just as in my previous post – here are just a few for Unity:

• Learned how to make use of the scripting reference and debugging

• Larger/Complex written scripts are more prone to errors

• isolate segments by out-commenting the rest of the code to get to the root of the problem

• When writing conditional statements be sure to define a clear scope before writing any code. Once you start initiating and assigning variables you will know WHERE in the code they’re needed and can optimize the code accordingly

• e.g. initiated within a function or when the script is loaded

• Animated models need to be set up perfectly according to their type on import

• meshes with skeletons as “humanoid”, other meshes as “legacy” or “generic”

• “start new root”

• While animating meshes, make sure to center the pivots and freeze transformations before exporting to FBX or .mb.

• 100 units in Maya equal 1 unit in Unity

• Different animations for a mesh are created as one animation in Maya and split into clips in Unity.

• BE SURE to make each clip revert back to the original mesh pose at the end of the clip

• The Unity forum offers great solutions. If you think you’re the only one who has encountered a specific problem, you’re wrong.

• Building placement

• Linked information structures

Players create a small “city” by placing roads, utility buildings and zoning three different area types:

• Residential

• Commercial

• Industrial

While residential areas increase the total population commercial zones provide entertainment and a boost to happiness along with income for the city treasury. Industrial zones provide significantly more income however also drain more resources.

Using these limited resources, players are given the tools to build and maintain a simulated society through careful balancing of controlled social and economic growth.

Some learning outcomes:

• Use comments if you are working with complex code, it significantly clears things up later

• <Forever if> can cause problems if you want multiple types of this loop statement

• Use <repeat x> or <repeat until> instead

• Use only if absolutely necessary (e.g. animations)

• Start saving multiple versions early, errors can occur when Scratch compiles the game to Flash

• Test thoroughly in Scratch AND Flash (publish test versions) as output strongly varies

• Don’t drink too much coffee

For my first project in Scratch I chose to emulate some elements from Atari 2600′s Night Driver. The first step to kick off this task was to watch gameplay footage and evaluate its mechanics. How did the game start/end? How did the car move? What peripherals were used to steer the car? What statistics were being recorded (score, speed, etc.)? What visual feedback did the player get in certain scenarios (crashing cars, exceeding road boundaries)? I eyeballed how difficult it would be to recreate certain mechanics and settled on three main aspects I wanted to rebuild:

• Incoming traffic
• Generating the road in perspective
• Translating the steering experience to a PC with its available peripherals

What seemed like a difficult task at first proved to be even more challenging as the project went on: Generating the road in perspective. The reason for this was because the visual assets, in this case merely a collection of six red road markers on the left and right side of the car, had to be repeatedly displayed in a way that a) felt absolutely synchronized to the other side b) effectively simulated the speed of the car c) became larger at an exponential speed as they moved closer to the car in order to create the illusion of perspective. And in addition to that, I wanted to create randomly generated curves. Before even touching any code I sat down and drew out the relationships between the different triggers and variables with pen and paper. I decided on a cosine function to simulate the curved road and an exponential function for increasing the size of the road markers  Feeling confident I had mapped out functioning collections of interrelated code blocks I started implementing them one by one, always running tests to make sure they executed flawlessly. One thing I have noticed in Scratch is that some control blocks either conflict with each other or work according to a certain hierarchy – in what order often felt like it was subject to chance. What struck me later was the question of how to implement random curves in the road. Using cosine to simulate the road significantly increased the fluidity in its animation, however left me wondering how I could possibly create transitions between straight and curved roads. After experimenting for three hours I finally decided to cut that feature out completely and move on (while a thousand voices continued crying out inside me). There would have been no easy way to do it without changing the core code blocks that simulated the road. Having spent hours on fine tuning the variables for the road markers  implementing incoming traffic was an easy task. Most of the code snippets from the roadblocks could be reused for the cars with little tweaks to the variable’s values here and there and added collision detection.

I won’t go into anymore detail on the car and scores as the code is pretty much self explanatory: Plus/Minus operations on variables, display variables, deduct/add points on collisions, etc.

A Short Game Summary

After our short insight into the scripting approach let’s take a look at the gameplay for Drunk Driver. The first thing you might ask yourself is “why the name Drunk Driver? Isn’t that a little inappropriate?”. To be fairly honest I haven’t spent too much time and energy on my search for a meaningful name. The only thought I put into finding a suitable name was “who would drive at night into oncoming traffic?”, and there you have it. Another argument might be that you cannot win this game. It simply ends when you run out of lives. If I really tried to convince you of its name I would in all likeliness argue there is an underlying metaphor to it.

But let us not get into semantics here. As I have mentioned before Drunk Driver does not end by reaching a goal or driving for a certain time. You run out of lives and have your final score at the end. The objective of the game is to steer your car by moving your cursor and dodge oncoming traffic. For every half second the player survives points are added to the total

score. It is possible to collect health as well however the spawn time is significantly delayed. One thing I had overlooked when writing the code for the cars is that they should not spawn at the same time. This is ultimately the reason why you cannot win this game. And that is all there is to it. If you would like to try out the game for yourself or create your own version from it feel free to head over to the official Scratch website. Constructive feedback is always welcome!

In addition to that work on my main project, Dimension, is well on the way! (Just a few more design iterations until I can publish the first demo)

At the TEDx talks in Hong Kong, 2nd Feb 2013. Left to right: Professor Rueda, Lindsay Holloway, myself, Claire Thompson, Alex Pribbenow, Thomas Thomas.

The objective of our game was simple: As one of several Tribes in the paleolithic era (fancy for “late stone age”), players must gain strength by claiming caves and resources in order to eventually claim the greatest of all caves: the MOTHER CAVE! Some challenges are determined by chance, some through the principle of first-come-first-served, others by sheer strength.

After a couple of days of conceptualizing we finally had a working system and a solid rule book. Time to test the game. Only a few minor tweaks to the game board and chance system, and the play testing could begin.

The first play-through went pretty smooth. Except for some imbalances in the battle system and pace, everything seemed to work out.

Re-tuned and refined, the game was ready to be tested with a larger group.

It was then when we realized we had to re-evaluate our magnificent ideas and go back to the drawing board: some players would be ridiculously overpowered, one would completely fall behind without any chance of catching up, it took six turns until two players were engaged in battle (what actually should have been the very essence of the game), etc.. Playing our game with three players gave the game a completely different dynamic versus playing it with two. In addition to our own observations, we also gained feedback from our play-testers, Lindsay, Ian, and Paul – among technical things, how much/little fun they had playing the game. I must add at this point it is always an incredible feeling to see other people play the game you have worked so hard on and observe their reactions to it. But having friends and family test your game also carries another huge benefit: A perspective to your game which you might not have considered during the design process, preoccupied with all the variables and relationships between the objects. And it is just at that moment where the significance of play-testing burns itself into your brain, as opposed to just reading about it in various game design literature. Play-test, play-test, play-test. Without an iterative design approach we would have never been able to build a game that is even remotely fun, challenging, and most importantly, balanced. It pays off very well in the end.