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.
Ta dah! Here’s a link to my lander clone, Lander X.
Please post your best times / comments in the comments thread – or on the unity community thread which can be found here.
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…
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.
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!
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.
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.
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!
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…
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!
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
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…
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.
