gdquest-demos/godot-2d-space-game

A 2D space exploration and mining game made with Godot and our AI framework

Harvester

Harvester is a Free and Open-Source top-down space mining game made with the Godot game engine. Control your spaceship in forays into an asteroid belt, gather iron, and bring it back to base. Spend them on upgrading your ship's speed and maneuverability and cargo space.

But beware, as you are not alone out here. Pirate miners are out there and want to monopolize the business.

➡ Follow us on Twitter and YouTube for free game creation tutorials, tips, and news! Get one of our Godot game creation courses to support our work on Free Software.

Summary

The player begins with a ship at their space station in a relatively large, procedurally generated map filled with asteroids. Their job is to navigate their way to find asteroid pockets, dock with them to mine, then dock with the station to drop them off and earn an upgrade.

As they accumulate iron, enemy pirates spawn around asteroid pockets. This forces the player to take different paths until they can destroy the interlopers.

The player continues until they are overwhelmed by the mounting difficulty and growing opposition and sees how far they can go.

Contributing

Contributors are welcome!

If you encounter a bug, please open an issue.

If you want to contribute to the project, for instance by fixing a bug or adding a feature, check out our:

1. Contributor's guidelines.
2. GDScript style guide

Development

The game uses the Godot Steering AI Framework while still being a fun time waster.

Player controls

• Travel mode: A and D rotate the ship, while W and S thrust forward and back.
• Shoot with Spacebar. The vessel has energy guns that can become stronger.
• Dock with E: When approaching an asteroid or a station, the player can activate docking mode, and an AI will take over to steer them into position and lock them in place.
• Open the map with M: The player can bring up a navigation map to get a look at where asteroids are and where pirates are.

Pirates

• Spawning: Every time the player deposits a certain amount of cargo in the station, pirates spawn around some of the asteroids.
• Movement: Pirates move in precision mode. They chase the player, get within weapons fire range, but don't get too close. They do avoid asteroids not to crash into them. Once out of range, they steer back to their spawn point.

Upgrades

Depositing iron into the station raises a percentage bar. When it hits 100%, the player can select from a small number of upgrades: health, speed, rotation speed, cargo space, and weapons damage.

Map

The map is made up of a number of asteroid pockets separated by some distance. Asteroids have a certain amount of iron in them and vanish when emptied. More asteroids can spawn on a timer to fill some of the empty gaps.

godot-2d-space-game's Issues

Code review and documentation

Code Review

This entails going through the code base and refactoring chunks of code to clean it up. A few shortcuts were taken in the development, and due diligence wasn't always followed to do clean architecture.

Documentation

While this isn't exactly an educational tool, some documenting and highlighting could still go a long way to helping people learn from it.

The map doesn't scale with the viewport

Possible solution: apply the texture to a TextureRect node set to the Full Rect layout option: it should automatically resize with the viewport and window?

There's another control node dedicated to displaying a viewport as well, that supports that.

Fix game crashes on startup

I'm submitting a...

• [x ] Bug report.
• Feature request.

Bug report

What is the current behavior?
The game crashes on startup because there are some errors in the code.

What is the expected behavior?
The game starts normally.

Tell us the steps to reproduce the bug, and if possible share a minimal demo of the problem.
1.Run the game.

Other

Other information

Can't navigate UpgradeMenu with the arrow keys

The upgrade menu doesn't work when using the dpad

3d verson?

I'm submitting a...

• Bug report.
• Feature request.

Bug report

What is the current behavior?

What is the expected behavior?

Tell us the steps to reproduce the bug, and if possible share a minimal demo of the problem.

Feature request

Describe the problem you're trying to solve.

Tell us which solutions you've explored, the solution you would pick, and why you think it would be the best for everyone.

Other

Other information

Bug: Signal 'force_undock' is already connected to given method '_on_Ship_force_undock'.

I'm submitting a bug report for Signal 'force_undock' is already connected to given method '_on_Ship_force_undock' in that object. that occurs whenever undocking.

• Bug report.
• Feature request.

What is the current behavior?
Although it has no apparent effect on the gameplay (doesn't crash or anything noticeable), the debugger would throw the error Signal 'force_undock' is already connected to given method '_on_Ship_force_undock' in that object. whenever undocking with the E button. The error would point to line 103 of \project\Ships\Player\States\Dock.gd: Events.connect("force_undock", self, "_on_Ship_force_undock")

What is the expected behavior?
The docs regarding the connect method clearly states:
A signal can only be connected once to a method. It will throw an error if already connected, unless the signal was connected with CONNECT_REFERENCE_COUNTED. To avoid this, first, use is_connected() to check for existing connections.

So an obvious fix would be to precede the connect line with a condition:
if not Events.is_connected("force_undock", self, "_on_Ship_force_undock"):

Tell us the steps to reproduce the bug, and if possible share a minimal demo of the problem.

1. Click on the start button.
2. Try undocking from any dockable entity
3. The debugger throws the aforementioned error.

Fix

At line 103 of \project\Ships\Player\States\Dock.gd, precede the connect line with a condition:
if not Events.is_connected("force_undock", self, "_on_Ship_force_undock"):

Pirate ships not removed from minimap when dead

Animate the ore going from the UI to the station when unloading

When mining, we have an animation when the ore goes from the asteroid to the UI widget. We could reuse the animation the other way around when unloading: have the ore go from the UI to the station.

Better guide the player and teach them the game

We lack some indication of what the player should do and the controls they should use. We also lack some kind of tutorial to learn how to play.

Possible improvements

• Show in-game overlays for the buttons the player can press in different contexts.
• Show in-game overlay icons to indicate the location of the nearest station or of pursuers.

In-game tutorial

At the start of the game, we could:

• Spawn an asteroid near the base.
• Direct the player to the nearest asteroid with a bubble, and show how to dock on it.
• Lock input until the player mined the
• Direct the player back to the station, and have them dock on it.
• Lock input until they unlocked the first upgrade.

VFX: add randomness to the mined ore's trajectory

When mining, the ore moves to the ore cargo/counter UI in a straight line. We could have it move in a random, slight arc to give the animation some more appeal.

Redesign the title screen

Already in progress by @henriiquecampos

When asteroid auras overlap, wrong asteroid is removed when mined out

Despite the little asteroid being mined out, its icon is there, but the big asteroid is in game but not on the map.

Minor improvements for Controller Support

I have done the following locally:

• Fire2 Controller mapping. - I recommend dragging fire2 up directly below fire1 in the Input Map.
• Assign Focused texture for upgrade menu so there are indicators for controllers.

Milestone 6: Optional juice, if we get to it

Milestone 6: Optional juice, if we get to it

A coat of paint has been dropped in to improve and unify the graphics, there are particle effects for firing thrusters or shooting weapons, camera shakes on impact, and ships now explode when destroyed instead of popping out of existance.

Audio is now present to common actions.

Milestone 1: Toy starter

Milestone 1: Toy starter

A simple toy starter to get development going. The map is empty, but the player does the basic of flying around.

Goal

Player

• The player is able to move around in travel mode by rotating with A and D/left stick left-right, and going forwards and back with W and S/left-stick up-down.
• The player is able to dock onto and release a placeholder docking point using AI assist

Pirates

• Pirate ships can travel in all 4 directions while facing the player
• The enemy chases the player but maintains an adjustable distance from them

Review and improve control scheme

Initially the game had some mouse controls. I noticed some things are hard to do right now, like slowing down the ship.

It's time to review the keyboard and gamepad controls, do some cleanup if necessary.

Space warp

We could consider adding a space warp to travel to new areas of the map quickly, ignoring collisions, after #42.

We have the motion blur shader and trail already, with some darkening of the background and deformation + lighting effects, we could get something nice. See https://twitter.com/NathanGDQuest/status/1243238789050519557

The pirates can block the player

The pirates try to move to the player's location, and as they don't stay at a distance, this can lead to the player getting stuck like so:

Second enemy faction: Natives

Native organisms that inhabit the asteroid belt. These are space creatures that eat the iron and work in packs.

The natives will be hostile to the player, but will also be hostile to the pirates and vice versa, leading to in-fighting which can give the player opportunities to wade through the chaos.

The natives fight in melee range by ramming.

Milestone 2: Gameplay tests

Milestone 2: Gameplay tests

Player movement is a bit more complex, and the map has some basic necessities.

Player

• The player can change into precision mode by holding down a button. The movement in precision mode corresponds to left-right-up-down relative to y-up.
• The player has a basic ranged attack.
• The player has health.

Pirates

• Pirates have a basic attack.
• Pirates have health.
• Pirates return to their spawning point once they are beyond a certain distance from it

Map

Everything starts preset and manually added for testing.

• A single pocket of dockable asteroids
• A dockable space station
• Some pirates

Once docked, make the ship rotate with the dockable

Doing so would increase the game's polish. Right now, the station rotates and the ship doesn't move.

We should be able to do this with a RemoteTransform2D

Make it easier to hit targets with the gun

The gun shoots slowly in a straight line, with limited range, making it hard to hit targets for the player.
Even if it's not realistic, I would change the weapon's behavior to make it easier to hit and more satisfying.

Possible improvements

• Shoot in a cone
• Increase the fire rare
• Increase the range
• Increase the projectiles' speed
• Add a VFX when a projectile hits something

Helper drones

Use an upgrade slot to create a drone who will fly out to the nearest available asteroid, mine it with its relatively small capacity, then come back to dock and deposit at the station.

It has no defensive capability and will be quite dumb, and pirates (and natives) will want to destroy it, so some babysitting may be required.

In the future, this could be replaced with a more in-depth upgrade and crafting system where you can buy and 'craft' upgrades and drones instead of simply upgrading arcade-style.

Milestone 5: Productify

Milestone 5: Productify

A UI is added to keep track of health and cargo. There is a splash screen to start the game. The game can now be restarted or quit in-game without relaunching/stopping the game scene.

Add possibility to change the controls

• Bug report.
• Feature request.

I have an AZERTY keyboard and the first thing I thought when opening the game was that it could
be nice to be able to change the controls (for keyboard at least, and maybe for controllers later).

Enemies don't react to being shot from afar

When shooting a pirate from a distance, the pirate squad doesn't react, so you can kill them freely. They should maybe start to chase the player?

Add visual effects

Add visual effects for:

• Spacecraft thrusters (player movement). These could be configurable so they can scale with the spacecraft's speed.
• Landing and docking on an asteroid.
• Weapon projectile impact. It's in space, we can assume that the guns shoot lasers. So, laser impact? I'm not sure what this one should be.

Add sound effects

Add sound effects for the most common interactions in the game:

• Flying
  • Starting to move (starting thrusters)
  • Moving continuously
• Landing: slowing down as the ship turns and move towards an asteroid or the station
• Docking: sound that happens when the ship touches the surface on which it's landing
• Mining: the asteroid's scale bounces and a piece of ore flies from its center to the cargo gauge
• Unloading mines resources: unloads ores into the station.
• Firing the plasma gun: fires balls that produce a deformation trail, looking like the deformation of heat.
• Firing the laser beam.
• Exploding: explosion animation when a ship gets destroyed.

User interface:

• Navigation buttons (moving a neighboring button)
• Confirming (e.g. pressing a button on the upgrade menu)
• Canceling or closing the menu
• Opening a menu: animation of the buttons when opening e.g. the upgrade menu.
• Getting an upgrade (sound when you accepted an upgrade)

Make the ship feel faster and more responsive

Even with speed upgrades, the ship feels slow. I would add that moving the ship around isn't too satisfying. It lacks something like thrusters, or some control to make it move at different speeds maybe.

I don't feel like a pilot flying a spacecraft.

Possible improvements

• Increase the base speed
• Increase the rotational speed
• Add a visual effect for the thrusters
• Add a button to go much faster, at the cost of a greatly reduced rotational speed, (and possibly consuming endurance?). This could use an activation effect, e.g. a heatwave shader?

Redesign the life bar and HUD

The lifebar is currently a bit small and part of the game world (it gets deformed by deformation shaders and effects). It could use a nicer design, larger, and separate from the player ship.

See #26

Multiplayer

Multiplayer support for coop or pvp, for 2 - X players

Milestone 4: Difficulty curve

Milestone 4: Difficulty curve

At this point, the game loop fully works.

Player

• Once the player fills the station up, they are given an upgrade choice: health, speed, rotation speed, weapon upgrade, cargo space, mining speed.

Pirates

• Once the player fills the station up and has upgraded, new pockets of pirates are spawned into the map

Map

• The level keeps track of the amount of iron in the level, and will spawn new asteroids in existing pockets or spawn new pockets to keep a certain equilibrium

Lower the initial difficulty: Pirates are too OP

I'm submitting a...

• Bug report.
• Feature request.

Feature request

Currently, the pirate enemies are really overpowered and can defeat the player very quickly which is not fun to play against, especially in the beginning before the player can get any upgrades.

I can think of many ways to balance this:

• Lower the damage of pirates depending on their proximity to the home base (gets harder as the player goes far; easy to implement)
• Player automatically regenerates health at some rate after a few seconds without taking damage (regen speed could be a good idea for a new powerup)
• Home base refills player health (quickly) when docked to (makes most sense).

If I had to choose, I would go for the last option (home base regen) because it makes the most sense, wouldn't make the game too easy, & also rewards strategic gameplay without punishing bold moves.

I would love further suggestions to balancing the difficulty.

Some upgrades don't seem to be working anymore

Following my refactor of the stats and upgrades, the states, e.g. in PlayerShip, upgrades don't seem to be changing the gameplay. I haven't spent a lot of time investigating, but this might be due to not updating values from the Stats class, for example in a given state. We have to either:

• Always call *.stats.get_stat("stat_name")
• Have objects subscribe to stats' stat_changed signal and update a property accordingly

Refactor Minimap to remove coupling with the Ship, Asteroids...

Currently, every object like the ships, the asteroids, etc. has to register themselves on the mini-map. This creates coupling and as I was refactoring the MapView, I noticed I was producing lots of errors in the game.

To remove the coupling we have to make the MapView register all the objects as they spawn. To do so we need the spawners or something to emit a signal whenever an object spawns. The MapView can then use duck typing or check for groups to see if it should register the object or not.

space-game/projects

I'm submitting a...

• Bug report.
• Feature request.

Bug report

What is the current behavior?

What is the expected behavior?

Tell us the steps to reproduce the bug, and if possible share a minimal demo of the problem.

Feature request

Describe the problem you're trying to solve.

Tell us which solutions you've explored, the solution you would pick, and why you think it would be the best for everyone.

Other

Other information

LayeredWorld.gd has unreliable planet retention and spawning issues

I'm submitting a...

• Bug report.
• Feature request.

Bug report

What is the current behavior?
\SpaceInfiniteGeneration\03-LayeredGeneration\LayeredWorld.gd
If you fly far away enough from a planet for it to queue_free() then fly back towards it to reload it, the code will begin to spawn hundreds of instances of that planet over time. This behavior also causes unreliability when planets are loaded. Sometimes they fail to appear at all if attempted to reload them.

What is the expected behavior?
Planets load/unload reliably, and without creating additional nodes every frame.

Tell us the steps to reproduce the bug, and if possible share a minimal demo of the problem.

1. Run LayeredWorld.tscn
2. Travel away from any planet on-screen until it unloads
3. Travel back towards that planet until it should reload
4. Observe the remote tree as it is populated with planets over time

Link off main page to Contributor guidelines is a 404

https://www.gdquest.com/docs/guidelines/contributing-to/gdquest-projects/

I've got a few fixes lined up including one for the laser example. Wanted to make sure you're still accepting PRs for this project.

Add debug tools for faster testing

We could use some tools to test the game faster, e.g. a developer's panel with some switches and buttons. Here are the problems I've had:

1. It takes time to navigate around the map just to encounter pirates or find asteroids to dock on
2. We have to mine and/or unload to the station to test upgrades
3. We need to stop and restart the game to regenerate the map
4. We need to restart the game to tweak the player's stats and balance the game

Suggestions for tools

Have a debug mode setting to unlock the debug tools.

1. Navigation and stats

• Have a list of sliders or fields to increase and tweak the player's stats
• Have a button and/or shortcut to enter a debug state for the player, move the ship by clicking around or with the arrow keys. Like we have in Hook!. The state should probably only work from flying/base movement and not when docked or other.

2. Testing upgrades

Have a button to unlock upgrades instantly

3. Testing the map generation

Have a button to regenerate the map?

4. Balancing player base stats

For this one I don't know. Changing values in the Stats resource on the player doesn't seem to reload ingame. It should ideally work with the inspector, but I'm not sure how to make it work. It might be due to the way I implemented the stats.

If there's no way to make hot reload work, at least we can have sliders to play with values in a dev panel.

Refactor world generation

World generation has a bit more coupling than it could have. Also, different spawners have their own rng object with each a different seed.

Tasks

General

• Pass one rng object around all generators so they all share the same seed.

Asteroids

• Add an AsteroidCluster node that keeps track of clusters instead of doing it in the game world.
• The player ship should mine directly from asteroids.

Pirate squads

• Pass a cluster object that encapsulates the info they need to gravitate around it, also that can give them a signal when a cluster is depleted.

Doing so will open the way to more improvements like the ability for pirates to mine the clusters.

Background stars sometimes disappear

Due to the parallax, one of the particle systems that spawns the background stars sometimes disappears, depending on the player's location

Pirate squad system refactor

Currently, the way the pirates coordinate between one another is a little awkward. You have a squad leader, and different behaviors are used in the same state machine state depending on whether a pirate is a squad leader or not.

When a leader dies, this leads to situations where the state has to be 'reset' so that new behaviors are recreated, and the correct signals connected to.

Alternative ideas

• Double up states: You have leader states and squaddie states. When a new leader is selected, he transitions to the leader-version of his currently assigned state. The squaddies don't need to change - they are just waiting for a signal to switch to rest/patrol/attack.
• Overseer: Squads are built inside of a squad controller parent object. It is the squad leader, in effect, as a nebulous overseer entity over the squad. All squaddies are followers, but follow-the-leader style behaviors are configured by the overseer.

The former would be simple in implementation, while the second one could help with extension down the line or more complex behaviors if the game expands that far.

Since, ultimately, it'd be nice to have pirates that do different jobs - attackers, miners and workers, transports that go to their own station, etc - the latter will probably be more useful in the long run.

Milestone 3: Procedural map

Milestone 3: Procedural map

Procedural generation is more important to set the level up and lay out the asteroids.

Player

• The player can access a map that gives them an overview of the entire level.
• The player can mine when attached to an asteroid, and empty their cargo when attached to the station

Map

• Asteroids are generated and positioned throughout the level in pockets
• Pirates are generated and positioned throughout the level in pockets

Refactor the upgrades code and scenes

The upgrade menu should be procedurally built based on the upgrades that are fed into it/are available. It should be relatively simple to extend. An 'upgradeitem' resource that has an icon, a name/label, and maybe a function it calls on the player, or that it executes itself by being passed a player object. (execute(player: Node))

Redesign the UI to collect and unload resources

Currently we have a small bar under the player's ship to show collected resources. It's not clear what's being collected, and how much. Also, there's no feedback on the cargo's size.

Instead we could have an icon in the top-right with a counter, and when mining, have blobs of minerals flying towards the counter and incrementing it.

QuitMenu doesn't quit the game

Selecting "yes" on the QuitMenu takes the player back to the title screen instead of quitting the game

Redesign the Quit Menu

Currently it looks like that:

We could use a UI theme there. I'd also rather use styleboxes and piggyback on button and similar nodes than use custom textures.

Infinite map generation

The game generates a static map at the moment, around the station. Moving forward, we could generate an infinite map, and have a large chunk of terrain available around the player. This would allow us to add thrusters and, why not eventually, warps?

Animate menus

Right now menus just go 'pop' and appear, and then pop and disappear.

Some quick sliding/appearing animations and VFX would go a long way.

Upgrade to Godot Steering AI 2.0.0

The AI framework got a breaking update, 2.0.0, that renames all GST* classes. We'd better upgrade the framework to it sooner than later.