Design Adventures in Code

Demo : English weather simulator

jonboris — Sun, 22 Nov 2009 15:39:49 +0000

Unity has a great terrain editor that allowed me to put this demo together very quickly. I’m trying to create a sense of isolation and vulnerability, and will be adding some derelict buildings into the mix next.

Demo: English weather simulator

Alpha Release: Lander X

jonboris — Sat, 14 Nov 2009 02:28:10 +0000

Ta dah! Here’s a link to my lander clone, Lander X.

Alpha Release: Lander X

Please post your best times / comments in the comments thread – or on the unity community thread which can be found here.

Lander : ideas!

jonboris — Fri, 23 Oct 2009 21:54:05 +0000

Here’s all the cool things I could think of for a lander game:

Refuel pad
Does what it says on the tin

Basic checkpoint pad
Land ship on the pad to activate it

Parcel checkpoint pad
Pick up a parcel with the winch and drop it safely on the pad to activate it

Rotating checkpoint
Keep up with a rotating zone to activate it

Bomb parcel
Use bomb parcels to clear boulder blockages (caution – don’t knock it on the way!)

Forward shield
Use to deflect bullets and lasers

Forward gun
Use to take out turrets and other enemies – guns and shields cannot be used at the same time

Megaload Heavy Lifter
Fly inside and control a super-heavy ‘exoskeleton’ vehicle and deliver it to a target pad.

Gun Turret
Fire projectiles at the player – can be shot or deflected

Laser Turret
Slides a beam across an area – can be shot or deflected

SuperMass Balls
So heavy they create their own gravity

Unstable fields
Gravity takes on pulsing, wave-like qualities – very hard to navigate

If I think of any more I’ll add to this list…

Demo : Surface Cruiser

jonboris — Mon, 05 Oct 2009 19:04:22 +0000

So I was playing around with this level where there are loads of crystals that are attracted to your ship’s energy drive. The larger crystals will shatter if you get too close… But fear not! You get a machine gun and a force blast to nail the crap out of them

Also, at the end of the level (if you follow the green arrow) there’s a pretty mean boss that can only be killed from behind. There’s no proper end to the level yet but if you kill the boss it means you’re awesome.

Demo: Surface Cruiser

Demo: Lander

jonboris — Sat, 12 Sep 2009 08:32:28 +0000

Well I said I’d do something different

I can remember really enjoying this game when I was younger, so I thought I’d knock up a quick demo – check this link if you’re interested in the history of Lander. It’s over 36 years old!

Demo: Lander

Engineering physics-based game-play is very easy in Unity and definately a lot of fun, not only to play but also to create. Hope you find it fun too!

PS. My best time is 7.45 seconds. I’m fairly certain that’s an unbeatable score.

Fun games should be fun

jonboris — Sat, 12 Sep 2009 07:52:34 +0000

Ok, I’ve learnt a lot over the past few months. I’ve got into Unity and have even learnt some C#.

But the most important thing I’ve learnt is that my game idea is boring!

I’m going to shelve it for now and do some different stuff.

Demo: Prototype level

jonboris — Mon, 31 Aug 2009 12:46:47 +0000

Ta da! So here’s a prototype level for my game. The receptionist’s behaviour tree is working fine now, and I’ve simplified the level to make things a bit clearer. The player must complete a puzzle to activate the phone and distract the receptionist. If the receptionist sees the player enter the room it becomes suspicious. If suspicion reaches 100% the guards are called. If the guards catch the player it’s game over!

Demo: Prototype level

In this demo I added the following:

My word-split puzzle as a hacking game mechanic
A suspicion meter
Guards
Level-complete and game-over screens
Simplified colour-coded level layout
A goal point.

NOTE: My mate played the level and managed to escape from the guards and complete the level without doing the hacking. I didn’t want that to be possible but he seemed to have a good time doing it! Something to think about I guess…

Demo : Adding some props

jonboris — Wed, 12 Aug 2009 22:27:54 +0000

In this demo I used a new behaviour tree that doesn’t use any decorators – instead it cycles through the tree on every update call. It does this because every action results in a success or failure, never ‘running’. This seems to work, but I found out it has some disastrous side-effects. The first is a hefty performance hit – things began to get a little jerky when running from the editor. The second, and worst, is a timing issue which makes it difficult to measure time between calls to actions at different branches in the tree. Rats!

Still, I managed to get a few other concepts introduced in this demo, like a hackable telecoms unit and a ringing phone. The player can now distract the enemy and sneak past … woohoo!

Demo: Adding some props

In this demo I got the following done:

Implemented a new enemy behaviour tree
Introduced a hackable telecoms unit and a telephone which can ring
Gave my enemy some phone-answering behaviours

Fixing my behaviour tree

jonboris — Sat, 08 Aug 2009 13:27:31 +0000

I’ve run into a couple of fundamental issues with my behaviour tree, plus my understanding of the Behave components.

In a previous post I suggested that the decorator component would return a success even if it’s children or conditions caused it to fail. However, I spent a late one last night (bags under eyes now) trying to figure out why my guard did not update his behaviour accordingly when the player was still in the room.

I eventually resorted to putting debug logs on every tree component to get to the bottom of things (yes… why didn’t I do this first? ) and have deduced the following:

If a decorator returns success, the child of the decorator is ticked and the result of it’s tick is returned by the decorator
This means that if a decorator returns success but it’s child then returns failure, the decorator returns a failure to its parent
If a decorator returns failure, the child of the decorator is NOT ticked and the decorator returns a success (task completed)
This means that if a decorator’s parent is a sequencer, and a condition causes the decorator to return failure, it in fact returns a success to the sequencer (which can then move on) but does not tick any of it’s children
If a decorator returns running, the child of the decorator is ticked, but regardless of what the child returns the decorator always returns running.
This means that if a decorator’s condition causes it to return running, even if the child of the decorator returns a failure the decorator still returns running, meaning we remain in this branch of the tree.

All this information (without the examples) is available in the Behave tree editor but I simply could not grasp it conceptually until I learnt the hard way. Armed with my newly found knowledge I would like to completely restructure my guard behaviour tree – unfortunately due to a bug in Unity on Windows I can’t compile a new tree until Monday (on my mac at work). Argh!

Guess I’ll just have to play some wii sports resort for now…

A note about 3d characters and models

jonboris — Thu, 06 Aug 2009 13:08:31 +0000

3d modelling and animation is a whole world of fun, and one which I dabble in occasionally. However, I don’t want to get bogged down in this side of things yet as I know it can be very time consuming, especially for an amateur.

All my characters and scenery can get fleshed out later after I’ve got some good gameplay going. In the meantime I’m just using stuff lifted from tutorials found on the Unity website.

Gameplay first, then everything else.