We are working on our first game. It is perhaps not the game either of us would choose do, nor have we done any research to find out if there is a niche for it. It is an experiment.

One thing I have been doing is reading the experiences of other independent developers out there. There are many development blogs for people working on iPhone games and using Unity.

I am subscribing to new blogs everyday, but three that stand out for me at the moment are:

Tiny Tim Games – Jerrod Putman and Shannon Kay are a husband and wife team the produced Sheep Stacker with Unity and are working on their second game.

GTProductions – Alex Schwartz is putting finishing touches on his first game, Spring Fling, also with Unity.

Retro Dreamer – Craig Sharpe and Gavin Bowman are and artist/programmer team (there seem to be a lot of two person teams out there) who produced Sneezies.

I have to mention Kristopher Peterson who is producing a game call Revolt single handed with Unity. His posts are mainly of test renders of him game, but they are oh so pretty

I have started getting more serious about what is happening in the world of iPhone games. I am following a couple of review sites. I am becoming increasingly aware that there are a lot of developers and a lot of games out there. Creating an iPhone game is not a license to print money. It actually takes time and effort to get your creation noticed. That is were the review sites come in. Getting some exposure on one or more of these sites can help lift a game from obscurity.

Two sites I am following at the moment are Touch Arcade and App Gamer. App Gamer recently ran a feature on marketing iPhone apps.

I am sure there are many more blogs and review sites out there, if you know of any interesting ones let me know.

• Produce a complete game for deployment online and/or on iPhone.
• Work to our strengths – Marc’s, Justin’s and Unity’s strengths.
• Make it polished, but do it quickly.

If we are going to succeed then our guiding principle must be to keep it simple. Keeping things simple works on many levels.

Casual games are played on the spur of the moment, usually in small intervals. To succeed the game must be easy for the user to understand.  Both the object of the game and its controls need to be simple and intuitive.

The target platform will be the iPhone and web browser player. These platforms have limited capacity both in terms of file/download size and computing power. Game assets and logic need to be kept small and simple  not to over-tax the platform.

Casual games, with their need to be intuitive and light, benefit greatly from an iterative development cycle. Assemble the barest minimum game-play needed for the game then test, test and test some more. When new features are added to this minimalist build they then need justify their inclusion through testing. Starting simple allows us to get to testing early and often.

Finally, as a very small team working in spare time the scope of the project has to be something that can be realistically completed in the time we have. The time we have is however long our enthusiasm lasts.

Here are soem other people’s thoughts on casual games and agile development:

• Jacob Williams’  post mortem of Maze Shifter, his first iPhone game.
• Tom Higgins’ Casual Games as a business – I think you have to take the examples of money made with casual games with a large grain of salt, but the points on what makes a good casual game is gold.
• 37signal’s Getting Real ebook – They are writing about creating web applications, but their philosophy of agile, user-centered development is a good fit for indie game development.

When I posted my first wheel collider demo to the Unity forum I got some really good feedback. So now I updated my scene and script to iron out odd behaviours and add new features. I have posted the scene in a web player and the complete updated script again.

Please view the full post to see the Unity content.

For completeness sake here is the updated script.

var rearWheel1 : WheelCollider;
var rearWheel2 : WheelCollider;
var frontWheel1 : WheelCollider;
var frontWheel2 : WheelCollider;

var wheelFL : Transform;
var wheelFR : Transform;
var wheelML : Transform;
var wheelMR : Transform;
var wheelRL : Transform;
var wheelRR : Transform;

var steer_max = 20;
var motor_max = 40;
var brake_max = 100;
var steerSpeed = 20;

private var steer = 0;
private var forward = 0;
private var back = 0;
private var brakeRelease = false;
private var motor = 0;
private var brake = 0;
private var reverse = false;
private var speed = 0;

function Start() {
rigidbody.centerOfMass = Vector3(0, -0.05, 0);
}

function FixedUpdate () {

speed = rigidbody.velocity.sqrMagnitude;
steer = Input.GetAxis("Horizontal");
forward = Mathf.Clamp(Input.GetAxis("Vertical"), 0, 1);
back = -1 * Mathf.Clamp(Input.GetAxis("Vertical"), -1, 0);

if(speed == 0 && forward == 0 && back == 0) {
brakeRelease = true;
}

if(speed == 0 && brakeRelease) {
if(back > 0) { reverse = true; }
if(forward > 0) { reverse = false; }
}

if(reverse) {
motor = -1 * back;
brake = forward;
} else {
motor = forward;
brake = back;
}
if (brake > 0 ) { brakeRelease = false; };

rearWheel1.motorTorque = motor_max * motor;
rearWheel2.motorTorque = motor_max * motor;
rearWheel1.brakeTorque = brake_max * brake;
rearWheel2.brakeTorque = brake_max * brake;

if ( steer == 0 && frontWheel1.steerAngle != 0) {
if (Mathf.Abs(frontWheel1.steerAngle) <= (steerSpeed * Time.deltaTime)) {
frontWheel1.steerAngle = 0;
} else if (frontWheel1.steerAngle > 0) {
frontWheel1.steerAngle = frontWheel1.steerAngle - (steerSpeed * Time.deltaTime);
} else {
frontWheel1.steerAngle = frontWheel1.steerAngle + (steerSpeed * Time.deltaTime);
}
} else {
frontWheel1.steerAngle = frontWheel1.steerAngle + (steer * steerSpeed * Time.deltaTime);
if (frontWheel1.steerAngle > steer_max) { frontWheel1.steerAngle = steer_max; }
if (frontWheel1.steerAngle < -1 * steer_max) { frontWheel1.steerAngle = -1 * steer_max; }
}
frontWheel2.steerAngle = frontWheel1.steerAngle;
wheelFL.localEulerAngles.y = frontWheel1.steerAngle;
wheelFR.localEulerAngles.y = frontWheel2.steerAngle;

wheelFR.Rotate(0, 0, frontWheel1.rpm * -6 * Time.deltaTime);
wheelFL.Rotate(0, 0, frontWheel2.rpm * -6 * Time.deltaTime);
wheelMR.Rotate(0, 0, rearWheel1.rpm * -6 * Time.deltaTime);
wheelML.Rotate(0, 0, rearWheel2.rpm * -6 * Time.deltaTime);
wheelRR.Rotate(0, 0, rearWheel1.rpm * -6 * Time.deltaTime);
wheelRL.Rotate(0, 0, rearWheel2.rpm * -6 * Time.deltaTime);

}

What’s changed?

The truck tended to launch itself into space when going over jumps. Lots of fun but not very realistic. To address this I did two things.

First I scaled the truck down in size so it is about three meters long. In the first version it was over eleven meters long and nine meters tall – it was the size of a small two storey apartment. Using the correct scale is vitally important when using physics. The correct scale is 1:1 with the real world.

Second I increased the drag on the truck. This slows it down faster and makes it feel generally heavier.

I have added smoothing to the steering. Now when you turn left and right the wheels turn smoothly until they reach the maximum steering angle. When you release the steering controls the wheels rotate back to centered.

I changed the way the truck switches into and out of reverse. If you use the brake to stop the truck moving you have to release the brake key and then press it again to have the truck change into reverse (or forward) gear.

I got the middle set of wheels to rotate. I know I said I was not going to do that, but it bugged me that they did not move.

Finally I changed the wrap mode on the skybox textures from repeat to clamp. This got rid of the visible seams between the skybox textures. (Thanks to NickAVV on the forum for that one).

So what do you think? See anything else that could do with improving? If so let me know in the comments.

The best way for us to get more proficient at Unity is to commit to making a simple game with it. We have elected to do a small project, a delivery game, where the player controls courier van picking up and dropping of cargo, in 3rd person camera view. It might not seem as inspiring as Grand Theft Auto, but we have to start small. So many times I seen on game making forums, people posting about how they are going to make the next WOW. Their first project and its gonna be a WOW killer! Not surprisingly, they never do. I just wonder if Justin and I are thinking small enough!

I am an artist and I want to be modelling, texturing and animating yesterday, but first things first – we need to write a game design document. This is where we’ll explain the game play supported by diagrams and have a list of assets (code and art ) required to make it all happen. Also there is no point designing the whole game right now. We need to design the core repeatable game mechanics, make sure they are fun, before we go full steam ahead. This is the pre-development stage of our game where will make a test level with all of the key game mechanics functioning.

We’ll post our design document when we have finished a presentable draft.

This conversation took place at the beginning of August over IM between Marc and the Doctor. We have reproduced it here with permission because we thought it would be interesting to anyone looking at iPhone development. There has been a minimum of editing done to make the original IM chat presentable.

Marc: You developing for iPhone yet?

Doctor: G’day Marc … have come close a few times, but no, not yet.

Marc: Whats stopping you? There really is gold in them hills.

Doctor: Really? Do you have any in your pocket?

Marc: lol, no! not yet, and will let you know if i do – Justin and I only dusted off the iPhone dev kit stuff 2 weeks ago – life gets in the way.

Doctor: Here’s my list of hurdles (just my own personal list) – no Mac hardware, no experience with ObjectiveC, approval process nightmare stories, personal knowledge of iPhone developer colleagues making less than what I make from Nokia devices. Oh … and time

Marc: Personal knowledge of iPhone developer colleagues – this point is the most concerning. What are the key issues they have had?

Doctor: I have many friends all over the world who are getting very poor returns. The App store is an over crowded swamp of content now, and content discoverability is a real issue.

Marc: Good points

Doctor: The global market of iPhone owners, in ratio to the amount of content, stacks the chips very much with the big development companies and not independent devs. Although of course there are some exceptions and some indies still hit a rich vein for a period of time.

Firemint have struck gold with Flight Control and Real Racer, but they have been in the mobile game business for over 10 years.

Don’t get me wrong – I own an iPhone and the experience with downloading apps is great. However, monetizing those apps for the developer is just as much an issue for that platform as it is for others (IMHO)

Marc: What you have written is really food for thought. The middle ware Justin and I are learning is cross platform mac/pc/iphone – Unity – you must have heard of it. If it doesn’t pan out with iPhone we can always try our hands and some indy games with the same software.

Doctor: Yep, I know Unity

Marc: Well? Tinkered with it?

Doctor: You should also check out Corona as a platform for easier iPhone development. I have some Flash Lite friends who have published apps in the App Store and have used it with quite good success.

No, I haven’t actually used Unity

Marc: Is Corona 3d?

Doctor: http://www.anscamobile.com/corona/

Marc: Thanks for the link

Doctor: No worries mate

Marc: Happy trails Doctor – well, if Justin and I have anything to crow about in the next few months we’ll let you know.

Doctor: I hope you do mate, I’d be the first to congratulate you

Marc: We may be some time….because we are new to it all…

Doctor: I’m personally looking for new opportunities (in mobile and beyond) so I’ll let you know what happens with that.

Marc: Please do mate – all the best

Doctor: Cheers

What do think? Have you had any commercial experience with iPhone apps? If so we would love to hear your opinion in the comments below.

As a conclusion to this short series on the wheel collider I present the finished scene. Enjoy!

Please view the full post to see the Unity content.

Update: I have made some fixes and changes to this scene and script. See the latest version here.

What do you think? I would love to hear your feedback. Post in the comments below.

The Devil in the Details

Now we have a very basic control script in place I am going to add some pretties.

Some Clean Up

If you remember at the end of Part 2 I bemoaning the fact that our truck was very liable to do wheelies and roll over when cornering. The solution to both those problems is to lower the center of mass on the rigidbody on the truck. This will make the truck much more stable.

Moving the center of mass of a rigidbody requires script. It only needs to done once when the scene first starts, so we will add a start function to our script.

function Start(){
rigidbody.centerOfMass = Vector3(0, -0.05, 0);
}

This script moves the center of mass down (the negative Y direction) from its original position at the center of the truck’s rigidbody. I had to play around with the value here to get something that looks right. If the center of mass id too low it can be effectively below the plane of the ground, then when the truck turns at speed it leans into the corner, not out. That’s good if it were a tilt train, but not too realistic for our top heavy truck.

Backing Up

Our truck goes forward and stops, but does not go in reverse. To fix that I want to test if the truck is stationary and the backward (S) key is pressed. If so then we reverse the effects of the forward and back keys: the back key will accelerate the truck in the reverse direction and the forward key (W) will apply the brakes. I will also need to test for changing back into forward gear when the truck stops reversing.

speed = rigidbody.velocity.sqrMagnitude;

steer = Mathf.Clamp(Input.GetAxis("Horizontal"), -1, 1);
forward = Mathf.Clamp(Input.GetAxis("Vertical"), 0, 1);
back = -1 * Mathf.Clamp(Input.GetAxis("Vertical"), -1, 0);

if(speed == 0) {
  if(back > 0) { reverse = true; }
  if(forward > 0) { reverse = false; }
}

if(reverse) {
  motor = -1 * back;
  brake = forward;
} else {
  motor = forward;
  brake = back;
}

There are more variables here. Speed is the velocity of the truck. When it’s magnitude is zero we know the truck is stationary, if only briefly. If the truck is stationary we check to see if forward or back are being pressed and set the state of reverse variable appropriately.

I have changed the capturing of user input so it is separate from the motor and brake. This is so when in reverse we can swap the actions on the user controls.

Turning the Wheels

There are two rotations we need to deal with when it comes to turning the wheels. The first is turning the front wheels to match the steering. The second is to rotate the wheels to simulate their rolling along the ground.

To turn the wheels with the script we first need to let the script know what the wheels are. So I add some public variables for the wheel meshes so we can hook them up in the script inspector.

var wheelFL : Transform;
var wheelFR : Transform;
var wheelRL : Transform;
var wheelRR : Transform;

To simulate the steering we match the Y rotation of the front wheel meshes to the same steerAngle as the corresponding wheel colliders.

wheelFL.localEulerAngles.y = steer_max * steer;
wheelFR.localEulerAngles.y = steer_max * steer;

I used localEulerAngles here because I want to set the wheels to a specific angle. The local version of eulerAngles means the angle is relative to the truck, not relative to the world. I only set the Y component so the wheel is free to rotate around the Z axis.

Then we tie the rotation of the wheel meshes to the (virtual) rotation of the wheel colliders.

wheelFR.Rotate(0, 0, frontWheel1.rpm * -6 * Time.deltaTime);
wheelFL.Rotate(0, 0, frontWheel2.rpm * -6 * Time.deltaTime);
wheelRR.Rotate(0, 0, rearWheel1.rpm * -6 * Time.deltaTime);
wheelRL.Rotate(0, 0, rearWheel2.rpm * -6 * Time.deltaTime);

The rpm of the wheels (handily provided by the wheel collider) is divided by 60 to get revolutions per second, and multiplied by 360 to get the degrees rotated per second (360 / 60 = 6). I found I had to stick a minus sign in here to have the wheels turn in the right direction. We then multiply by deltaTime (the time passed since the last frame in seconds) to find the wheel’s rotation in since the last frame. We rotate the wheel meshes by that amount.

In this case we use rotate rather than eulerAngles because rotate is cumulative.

The Complete Script

var rearWheel1 : WheelCollider;
var rearWheel2 : WheelCollider;
var frontWheel1 : WheelCollider;
var frontWheel2 : WheelCollider;

var wheelFL : Transform;
var wheelFR : Transform;
var wheelRL : Transform;
var wheelRR : Transform;

var steer_max = 20;
var motor_max = 10;
var brake_max = 100;

private var steer = 0;
private var forward = 0;
private var back = 0;
private var motor = 0;
private var brake = 0;
private var reverse = false;
private var speed = 0;

function Start() {
rigidbody.centerOfMass = Vector3(0, -0.05, 0);
}

function FixedUpdate () {

speed = rigidbody.velocity.sqrMagnitude;
steer = Mathf.Clamp(Input.GetAxis("Horizontal"), -1, 1);
forward = Mathf.Clamp(Input.GetAxis("Vertical"), 0, 1);
back = -1 * Mathf.Clamp(Input.GetAxis("Vertical"), -1, 0);

if(speed == 0) {
if(back > 0) { reverse = true; }
if(forward > 0) { reverse = false; }
}

if(reverse) {
motor = -1 * back;
brake = forward;
} else {
motor = forward;
brake = back;
}

rearWheel1.motorTorque = motor_max * motor;
rearWheel2.motorTorque = motor_max * motor;
rearWheel1.brakeTorque = brake_max * brake;
rearWheel2.brakeTorque = brake_max * brake;

frontWheel1.steerAngle = steer_max * steer;
frontWheel2.steerAngle = steer_max * steer;
wheelFL.localEulerAngles.y = steer_max * steer;
wheelFR.localEulerAngles.y = steer_max * steer;

wheelFR.Rotate(0, 0, frontWheel1.rpm * -6 * Time.deltaTime);
wheelFL.Rotate(0, 0, frontWheel2.rpm * -6 * Time.deltaTime);
wheelRR.Rotate(0, 0, rearWheel1.rpm * -6 * Time.deltaTime);
wheelRL.Rotate(0, 0, rearWheel2.rpm * -6 * Time.deltaTime);

}

What Next

At this stage I think we have a simple but serviceable script. There are a few more things that can be added to improve it. In this case our truck has six wheels and I have only added wheel colliders to four of them. Adding the other two would simply be a case of duplicating the rear wheels throughout the script.

There are many cosmetic things that could be done like adding brake and reversing lights that react to the user’s input as well as engine noise.

Speaking of engines the truck does not accelerate like a real vehicle. Hitting forward applies a constant torque to the wheels. In a real vehicle revs, power-bands and gears mean that torque is anything but constant. However simulating that is beyond what I set out to achieve here.

Finally there are the other pieces of setting and behaviour that would make the simulation more game like. Using terrain instead of a dead flat plane would make driving more interesting. Having the camera follow behind the truck would make it much easier to drive.

This is one of my very first scripts in Unity. Feel free to take it, try it and tweak it. I would love to hear any feedback anyone has using it. If you have questions about how it works or know how I could improve it please let me know in the comments below.

The World’s Simplest Car Control Script

In Part 1 I put some wheels on Marc’s truck and let it roll down a slope under the force of gravity. In this post I want to add the simplest of vehicle control scripts to the truck.

So without further ado here is the world’s simplest car control script for Unity:

var rearWheel1 : WheelCollider;
var rearWheel2 : WheelCollider;
var frontWheel1 : WheelCollider;
var frontWheel2 : WheelCollider;

var steer_max = 20;
var motor_max = 10;
var brake_max = 100;

private var steer = 0;
private var motor = 0;
private var brake = 0;

function FixedUpdate () {

steer = Mathf.Clamp(Input.GetAxis("Horizontal"), -1, 1);
motor = Mathf.Clamp(Input.GetAxis("Vertical"), 0, 1);
brake = -1 * Mathf.Clamp(Input.GetAxis("Vertical"), -1, 0);

rearWheel1.motorTorque = motor_max * motor;
rearWheel2.motorTorque = motor_max * motor;
rearWheel1.brakeTorque = brake_max * brake;
rearWheel2.brakeTorque = brake_max * brake;

frontWheel1.steerAngle = steer_max * steer;
frontWheel2.steerAngle = steer_max * steer;

}

So lets go through it bit by bit.

The first four lines create public variables for the car’s wheel colliders. When a script is added to a game object public variables appear in the script inspector. The plan is to add the script to the truck body game object then hook each of the wheel colliders to these variables using the script inspector.

The next three lines define public variables for use in our script. These are the maximum steer angle, motor torque and brake torque. By making them public I can change them easily in script inspector.

The next three lines are some private variables for use in the script. Specifically they will be used to temporarily store user inputs.

The FixedUpdate function is the heart of the script. The FixedUpdate function is run once every frame that the physics of the scene is updated.

In the function I grab the user input for steering, motor and brakes. These are the ASWD keys by default. Input.GetAxis(“Horizontal”) gets the A and D key presses for left and right. I will use this to steer the truck. Input.GetAxis(“Vertical”) gets W and S key presses. In this case I want W to apply the accelerator and S to apply the brake. So I have clamped, or restricted, the vertical input returns so I know when they are positive (the W key, going forward) and negative (the S key, going backward or braking).

With the user input giving me steering, motor and brake I then apply those to the wheel colliders. The motor and brake torques are applied to both the rear wheels and the steering angle to the front wheel colliders. MotorTorque, brakeTorque and steerAngle are all properties of the Unity wheel collider.

Using the script

The script is applied the the main truck object. Once applied the public settings for it turn up in the inspector. There are four slots for wheel colliders. Drag the wheel collider ojects from the hierarchy to the appropriate slots in the script inspector.

The script in the inspector

There were a few other tweaks to be made to the scene before testing. First I leveled the ground plane out again. Then I added a box collider to the truck object. Without the box collider the truck mesh will pass though the ground plane with the truck rolls over… and trust me, it will roll over.

Stomp on the gas and you will find the truck goes into a permanent wheelie. Try and turn a corner at speed and the whole thing is liable to tip over. Obviously there are issues about how much the truck weighs and where its centre of gravity is. Having not changed the default weight of the truck from one kilogram it must have a density much less than styrofoam – no wonder it’s flying about. (EDIT: I have subsequently learned that it is the placement of the truck’s center of gravity, see the next chapter for how to fix it.)

Next Steps

You may notice as you drive around that some things are still off with our truck. The tyres do not turn as the truck moves and the front tyres do not turn with the steering. There is also suspension associated with the wheel colliders which is not being reflected in the tyres. We will fix these cosmetic issues in the next part.

Are you following along and have questions or wisdom to share? Leave a comment below.

If I was to explain it to another artist broadly how Unity works, you import your game art into the program and attach scripts to the art to make it do what you want. Literally drag the icon of the scripts you need onto the object. Of course you need to write the scripts, but the tutorial takes you through some of the core scripts that really are the building blocks of games.

I hate scripting, but I found this tutorial easy to follow. You just cut and paste the examples into Unity. It really helped me understand how Unity works. I think I may even have a go at script or two myself. I am more likely to take existing scripts and modify them. You can find loads of them here at the Unify Community

Putting some wheels on the truck

In this part of the mission I am going to step through setting up the truck model with wheel colliders. At the end of it we should be able to have the truck roll down a slope under the effects of gravity.

First a created a new project in Unity and then imported the truck and wheel assets given to me by Marc as 3ds objects. I asked for the wheels separately so I could make them into a prefab and repeat them around the truck. I can also eventually rotate the wheel meshes so they appear to be rolling across the ground.

Little blue truck with wheels attached

The wheel collider is found under Physics components

After attaching the wheels I then attached an empty Game Object to the truck. To this object I added a wheel collider component.

The wheel collider is a component so it has to be added to a game object of some variety. I could have added it to my wheel mesh, but then I would not be able to rotate the wheel without rotating the collider.

As a component, the collider inherits the transform (position, rotation and scale) of the object it is attached to. By using an empty game object I am able to reposition align the collider without having to change any of the meshes.

Marc knows his stuff, so he created the truck and wheel meshes in the correct orientation. However if I had created the wheels using Unity’s  in-built cylinder object they would have started in the wrong orientation – they would have been lying flat on the ground and I would have to rotate them 90 degrees to stand them up. If I then attached a wheel collider directly to them the collider would inherit their transform and be pointing 90 degrees in the wrong direction.

Trust me, just attach them to an empty game object.

Wheel colliders in place

The final object heirarchy

Here is the final object hierarchy. Truckbod has six wheel meshes and four wheel colliders attached.

I only added four wheel colliders because that is the number a vehicle will typically have, and I want to be able to use any scripts I write in future projects. Four colliders on the furthest front and back wheels should be fine for our truck as long as we keep the terrain pretty flat.

Finally I added a plane to act as the ground, and a light and camera to test the scene. I have not added any forces to the objects here, so left to their own devices they do not do much – the truck just sits on the perfectly level plane.

For the simplest of tests I rotated the plane to give it a slight downward slope. Then when the scene is run the truck trundles off down the slope – and eventually drives off the end.

That’s the end of part one. Next up is adding a motor and steering.