Don’t Let Them Land Documentation, User Guide and References

Final Game vs Original Concept

“No plan survives contact with the enemy” – someone old (seriously like a bunch of people are attributed to saying this first.) This is true of game development too, I think. The enemy ultimately is time and scope. Don’t Let Them Land suffered the same fate ultimately proving its original concept a little too ambitious for me given the circumstances. I think a combination of illness, a new job, other units and honestly a little ego all came into play when it came to not quite meeting the original design. I think I believed given my previous experience making things in Unity I wouldn’t run into issues and for the most part that was true but the issue I did run into was myself. I found myself too often perfecting or experimenting with a feature longer than I probably should have. I had fun with it if I’m honest which I think long term is my goal for game development, but it did complicate completing a specific design in a given time frame.

There were choices not to implement certain features given they made no sense in the current context of the game. Turrets and upgrades couldn’t be added until enemies were in a working. Boss waves and more weapons lacked a reason until the game got more difficult. I think looking back on things I wanted to make a game that was a 15–30-minute experience but I lacked the time to build the content to implement something like that.

Looking back at the original concept now in writing this, more of it ended up out of the game than I thought. This is a little disappointing, but I think I made a good call a week or two ago when I realised that the original concept wasn’t going to be viable in time. I took the time to re-evaluate and decide to work with what I had to build something solid out of that instead of adding new untested and unbalanced features that might be broken by the time this needed to be submitted. While my ambition could not be met, I’m happy to have found a functional (and hopefully fun) game instead of a buggy mess.

Below is a table of all the originally planned features and whether they made it into the game or not:

I think if I had an extra week or two then the rest of the features could have been implemented comfortably but I’m proud of the game I made and am happy with what I’ve submitted.

Also, it’s not all gloom. There are extra features I hadn’t planned on that were added in. Music, sound effects, particle effects and animations were all meant to take a back seat, but all ended up being implemented in full by the end of the project. These ended up pulling the game together. I think without them the game would have felt like a much lesser experience.

Feedback

Having gamer friends who are willing and able to test your game and provide unbiased feedback on their experience was invaluable. Not only did the game improve drastically because of it but many bugs were noticed by them too that nearly made it into the final release. (The game is at 1.2 for a reason.)

One thing I noticed for myself is how much I played the game and how much my experience playing it shaped things. For example, those sound effects and particle systems only got added when I felt like I wanted to get positive feedback for shooting down a UFO.

The feedback throughout the semester I think has been overly quite positive and useful. People really seemed to like the unique aspects of the concept and how well-implemented it was as I progressed. My biggest concern was having the movement around the planet feel fluid and the feedback I got was it did indeed feel that way.

My next concern was how the camera felt and this was well-received for the most part but there were concerns and I personally had concerns for it so I spent a lot of time refining the camera but decided against keeping the planet centred a suggested in some feedback since it would require the camera to zoom out more to keep things in the frame. It was a balance between zoom level and centredness that I hope most people enjoy.

This was aided by adding in the doom arrows, so I didn’t need to zoom things out too much, but the player knew where the threats were coming from. The doom arrows weren’t originally in the concept either, but they just felt right once they were in. So hopefully that helps the camera concerns too.

Later in development there was feedback about it being difficult to get around the planet which honestly is exactly what I was looking for so I didn’t see a need to change things in terms of player speed, but a dash was suggested which if I had time could have added a strong upgrade choice.

There were only a few bugs pointed out by testers that I hadn’t already seen myself. I like to think the current version is bug-free, but I know it likely isn’t. One bug that was helpful in recent feedback was a change I made to lasers that let them shoot through the planet making the game way too easy which thankfully was an easy fix. Another was that the aiming felt a bit off and even included a suggestion for why (which ended up being at least partially accurate) but led to a much smoother shooting experience overall that I otherwise might have missed. Both were great catches. (I can’t believe I didn’t notice that you could shoot through the planet :D)

Asset List

The following will contain a full list of all the assets in the project (some scripts that do similar things will be bundled together), their source and their purpose. For external sources, I’ll have references to their external links at the end of this document. This list is in no particular order, but I am going to leave some to the end that all relate to one another. I’ll bundle them into the folder structure of my project (which is not in any particularly good structure but at least one exists.) Where there are assets that hold references to assets elsewhere, they are not referenced in the holding asset. I.e. Prefabs have reference to external sprites but these are referenced in the sprites section for simplicity.

• Animations
  • Contains all the animation clips for the player along with the animator controller. Source: I made the clips, but the sprites come from Toon Characters 1.
• Audio
  • Ambience
    • Contains two looping ambient clips used for the UFO sounds. Source: Ambiences Sounds Vol 1.
  • Clips
    • Contains several clips for explosions, lasers, shield spawn and an end-game tone. Sources: Digital Audio & Sci-fi Sounds
  • Music
    • Contains music for the menu and the game. Sources: Drum and Bass Music & Lo-fi Atmospheres Music Pack.
• Fonts
  • Contains fonts used for the text throughout the game. Source: UI Pack - Sci Fi.
• Prefabs
  • Canopy is a prefab that is instantiated onto the UFO enemies. It contains the sprite for the UFO’s canopy and powers the ambient sound effects that the UFOs make. Source: Myself
  • DirectionArrow is a prefab that is instantiated by each enemy and displays to the user on the edge of the screen to indicate approaching enemies. Source: Myself
  • Enemy is a generic enemy prefab that is spawned by the spawner and built up by Scriptable Objects. Source: Myself
  • ExplosionParticles is a prefab of a particle system used to create an explosion effect when things are destroyed. Source: Modified from Tutorial 13.
  • Gun is a prefab that spawns projectiles from it. It is generic and is built up using Scriptable Objects. Source: Myself
  • Projectile is a generic prefab that is built up using Scriptable Objects. It acts as a player or enemy-based projectile that interacts with objects in the world. Source: Myself
  • RocketParticles is a modified version of ExplosionParticles for the rocket propellant effect. Source: Modified from Tutorial 13.
  • Tractor Beam is a prefab that is instantiated onto Abductor UFOs to create the tractor beam effect. Source: Myself
• Scenes
  • Game is the main game scene where the action takes place. It contains multiple prebuilt game objects to allow the game to function. Source: Myself
  • High Scores contains a screen of the highest score ever gotten in the game. Source: Based on Tutorial 4.
  • Start Menu is the first scene the player is presented and allows the player to move to the other scenes and switch on Lindsay Mode. Source: Based on Tutorial 4.
• Sprites
  • “blue” is the background image used throughout the game. Source: Space Shooter Redux
  • “character_robot_sheetHD” is the sprite sheet of the robot used for his animation clips. Source: Toon Characters 1.
  • “cursor_d” is an image used for the DirectionArrow. Source: UI Pack – Sci Fi
  • Two laser sprites for friendly and enemy lasers. Source: Space Shooter Redux
  • Four meteor sprites for the asteroid enemies. Source: Space Shooter Redux
  • “planet06” is the sprite used for the planet itself. Source: Planets
  • “shield” is the sprite used for the shield. Source: Shield
  • “spritesheet_spaceships” is the sprite sheet used for all the different UFO types and the canopy prefab. Source: Alien UFO Pack
  • “tank_bullet4” is used for the rocket’s sprite. Source: Tanks
  • "spritesheet_laser" contains the sprite for the tractor beam. Source: Alien UFO Pack
• Scripts (The game has a lot of scripts. I’ll try my best to summarize them as best as I can and in an order that makes sense, but I’ll admit my code is a bit of a mess and uncommented. Usually, I’m better at that. How variables are displayed is inconsistent and the overall structure is complicated.)
  • Event
    • Contains four simple event-handling scripts for handling *some* collisions and triggers and passing information between the objects when this happens. Source: Myself
  • Game Management contains scripts for running the game itself.
    • CameraRotationFollower rotates the camera (instead of letting CineMachine do so) such that the player is always upright on the screen. Source: Myself
    • EnemySpawner spawns the enemies based on lots of serialized fields. It also manages updates to the target group camera from CineMachine. Source: Myself
    • GetHighScore returns the high score for the High Score menu. Source: Myself based on Tutorial 4.
    • LindsayMode switches god mode on or off based on the check box on the start screen. Source: Myself inspired by Tutorial 4.
    • RestartGame restarts the active scene specifically the game scene and ensures the time scale is reset. Source: Myself
    • SceneSwitcher switches the scene to a specific scene based on a string input and also ensures the time scale is reset. Source: Modified Tutorial 4 script
    • ShieldManager creates and destroys the shield and manages collisions for the shield. Source: Myself
    • TargetGroupManager acts as a buffer/helper script to the CineMachine TargetGroup code. Source: Myself
    • TimeTracker keeps track of the survival time and handles end game mechanics. Source: Myself
  • Gravity
    • Contains three custom gravity scripts for the custom gravity code. Fairly small scripts that do a lot of work. Source: Myself
  • Player
    • PlayerDeath handles the death and respawning of the player along with collision detection. Source: Myself
    • PlayerMovement handles the player inputs and alongside gravity and rigidbody code moves the player left and right along the tangent of the planet. Source: Myself
    • PlayerShooting handles the player's ability to shoot. Ensures the shoot speed is correct and corrects the facing direction before shooting. Source: Myself (peer feedback <3)
  • Sounds
    • Three scripts that handle the background, menu music and ambient UFO sounds. Source: Modified ChatGPT code - https://chatgpt.com/share/683c3a98-60ac-8003-a985-189e2a859d8e
  • Spawnables
    • DieAfterTime destroys the object after a set time. Used on projectiles mostly for the player's wayward shots. Source: Modified Tutorial code
    • Projectile acts mostly as a container for the generic projectile data and behaviour and calls specific behaviour script functions at appropriate times.  Source: Myself
    • Enemy is similar to Projectile but for enemies and does a little more work. On top of being a container, it also handles the direction arrows spawning and updating that need to occur for this specific enemy. Source: Myself
    • Projectile Spawner acts as the spawner for projectiles and is effectively the “gun” for projectile spawning enemies as well as the player’s own weapon. Source: Myself
  • Interfaces contain a single interface script IBehaviour that all behaviour scripts must implement.
  • Helpers
    • BehaviourProxy acts as a way to find and reference the scriptable object behaviour scripts by letting them act as a monobehaviour. (Originally it was working with the behaviours being directly monobehaviours but issues later arose when building the actual objects.) Source: Myself
    • TargetGroupTransform handles the death of enemies in relation to the target group camera. Prevents the camera from flicking rapidly. Source: Myself
  • Data
    • Contains all the data scripts for the scriptable objects. I.e Enemies, projectiles and the shield all grab their data from these scripts. Layered such that all objects inherit from GameData. EnemyData is inherited by all specific enemy types. This means that objects should only have data on them that they actually use. Though admittedly overly complicated for the purpose I’m using it for. Prefabs ultimately would have been simpler and probably better. Source: Myself
  • Behaviour
    • Contains all the scripts that implement IBehaviour and is the meat of the AI in Don’t Let Them Land. They are also ScriptableObjects and are added to the Enemy through the BehaviourProxy when the Enemy type is chosen and instantiated. Each Enemy, Projectile and the Shield has slightly different behaviour which is defined in these scripts. Each UFO Behaviour inherits an abstract BaseUFOBehaviour that implements basic UFO mechanics. Source: Myself
• Data
  • Contains all the built data types for each implemented enemy, projectile and the shield. Also contains the constructed behaviour scripts in their scriptable object form so they can be attached to the respective scriptable objects. This is where a lot of the numbers for the enemies are modified for balancing a testing. Things like health, speed, gravity factor and shoot speed live here. Source: Myself
• Other
  • Random Unity assets that I don’t really know what they do but I’m too scared to delete them. Source: Unity
• Settings
  • Similar to the above. I think Unity made this folder. Source: Unity
• TextMesh Pro
  • Contains assets for TextMeshPro. Source: TextMeshPro

User Guide

Don’t Let Them Land is a 2D survival shooter in which you play as a cute robot trying to defend his home from invading aliens. You need to shoot down the UFOs and any stray asteroids before you get overwhelmed and they manage to land. Using A and D to move side to side you traverse the surface of your planet to make sure you can get the angle to shoot down the enemy. Clicking or holding the left mouse button allows you to shoot your trusty laser gun and take down the crafty aliens. Jumping with the space bar can get you that little bit of extra height you might need to angle your shots just right. If it all gets too much you can hit escape to return to the main menu.

Main Menu

The main menu is where our defence starts. Here you can choose to start the game or see the high score. You can also turn on Lindsay Mode if the game is a little too challenging.

High Score

Here you get the display of the highest survival time of past invasions. Try to survive as long as you can to make your name. You can return to the Main Menu when you’re ready.

Game

Here is the meat of Don’t Let Them Land. Here you defend your planet from the invading forces with the controls above. Keep going for as long as you can. Each UFO type has a different mechanic. Pink aliens shot lasers, yellow ones shot rockets and the beige (?) ones have a tractor beam. Asteroids will also pose a threat so make sure they don’t land either. You have a shield to help with the defence but it won’t hold forever. The robot will get destroyed if he collides with any of the enemies but will respawn after a few seconds. Shoot down the aliens and asteroids with your laser gun for as long as you can. If the shield goes down the aliens will try to rush the planet before it respawns.

New High Score

Getting a new highest survival time prompts you to enter your name and this will be displayed on the High Score screen.

Restart Game

Regardless of if you get a high score or not after the game is concluded you are given the option to restart the game if you want. You also have the option to return to the Main Menu.

References

External assets used:

• Alien UFO Pack - https://kenney.nl/assets/alien-ufo-pack
• Toon Characters 1 - https://kenney.nl/assets/toon-characters-1
• Planets - https://kenney.nl/assets/planets
• Space Shooter Redux - https://kenney.nl/assets/space-shooter-redux
• UI Pack - Sci Fi - https://kenney.nl/assets/ui-pack-sci-fi
• Shield - https://opengameart.org/content/shield-sprite
• Sci-fi Sounds - https://kenney.nl/assets/sci-fi-sounds
• Digital Audio - https://www.kenney.nl/assets/digital-audio
• Lo-fi Atmospheres Music Pack - https://www.gamedevmarket.net/asset/lo-fi-atmospheres-music-pack
• Drum and Bass Music - https://www.gamedevmarket.net/asset/drum-and-bass-music
• Ambiences Sounds Vol 1. - https://www.gamedevmarket.net/asset/ambiences-sounds-vol-1
• Tanks - https://kenney.nl/assets/tanks