Beyond Space Rocks

Context	Personal project from 0-100 in 10 days
Role	Game programmer – designer
Team size	1
Tools	Unity Engine – Git – Aseprite
Duration	09/2024 – 09/2024

Download and play via Itch.io: [https://samleguijt.itch.io/bsr]

View the sourcecode on GitHub: [https://github.com/SamLeguijt/BeyondSpaceRocks]

Project overview

Beyond Space Rocks is a small arcade-like developed and designed by me within 10 days total. You control a spaceship within three fixed lanes where you destroy incoming obstacles of different tiers by adjusting your ship color.

Vision & scope

The goal of the project was to develop and release a game in a finished state before 10 days. To do so, I went for a simple designed game that can be developed within the timeframe, which leaves room for potential bug fixing and polish.

Design wise, the game should feel engaging and like an arcade game. To accomplish this, I went for simple controls and mechanics, only utilising a few keyboard keys. As player, you control three simple mechanics that, in combination with the space inspired assets and fast paced energetic background track, help to bring the arcade-like feeling to life.

In order to release a game that feels finished and not just like a prototype, I aimed to keep the scope small and focused so there was time for polishing. Implementing three player mechanics (moving left and right, swapping colors, firing bullets) and a spawner for obstacles meant most of the game’s mechanics were implemented. This left room open for polishing the sprites, implementing sound effects and tweaking the controls to feel good and intentional. This allowed me to implement additional features like the movement trail, damaged spaceship based on health, screen flash + time slow down when losing a life, UI elements for colors and different speeds for different rock tiers in comination with a first version of a balance curve.

I’ve always planned a future update after the initial release that would tweak some of the mechanics and add more polishing effects. Things I would focus on are:

• Difficulty scaling (colours, game speed)
• Variety in obstacles (patterns, power-ups)
• Polish (juice, shaders)
• Performance (object pooling)

Systems & Implementation

The following systems form the foundation of the game. Development focused on building functional systems that could be quickly iterated on, allowing more time to refine game feel and keeping the option to refactor at a later time open.

Movement system

The game space consists of three lanes where the player can move between fixed positions. Obstacles fall down from the top of the screen in the same x-positions so the player is not concerned with aiming, and should instead focus on moving around the lanes quickly to catch the incoming obstacles in each lane.
This approach was implemented because it allows for deterministic positions with simple input handling while removing the need for precise aiming, something that I found fitting for this game and how I intended the player to be controllable.

Colour system

Bullets with the same colour as ostacles trigger collisions and cause the obstacle to be destroyed, earning the player points. A different coloured bullet will pass through the obstacle and not trigger any collisions.
The player can switch between colours using pre-defines input keys. Switching colours changes the colour of the ship to that colour and updates the UI panel’s colour queue to convey the swap.
Obstacle colours represent different tiers, where higher tiers obstacles have higher movement speed and spawn less frequently.

Projectile system

Projectiles are instantiated at an assigned fire point when shooting, flying forward every frame until destroyed or out of the game space. When colliding with an obstacle, the colours of both objects are evaluated to determine how to handle the collision.

Obstacle spawn system

An obstacle spawner spawns the available obstacles according to adjustable input values. To do so, a budget for each tier of obstacles is assigned. Every spawn tick, one of the lanes is randomly assigned. In a Y position off screen, an instance of an obstacle prefab is instantiated. After instantiating, the tier of the obstacle is assigned by randomly selecting a tier index based on the assigned budgets. This ensures tiers with a higher budget have a higher chance to spawn relative to lower budget tiers, and is used to gradually increase the difficulty by adjusting the budgets of each tier after all obstacles have been spawned.

Reflection

Looking back, the primary improvements would focus on increasing code architecture and communication between components to increase flexibility and extensibility.

The movement system currently relies on a pre-defined LaneEnum (Left, Middle, Right) to place obstacles and the player. While functional, this scales rather poorly. I intend to refactory this by removing the need of an enum alltogether, and instead design the system to support any number of lanes without making code changes.

The current colour system is highly coupled to gameplay behaviour through the ColourData structure. This structs encapsulates a Color (RGB), ColorType enum, Min/MaxSpeed and score into a single data object. This is super useful to setup the different used colours in a single container, but also tightly couples the representation of objects to their behaviour. Refactoring this system would remove the knowledge of colours in the gameplay code, and instead use tiers or something related in code while keeping colours only for configuration and representation.

The projectile and weapon system can be improved by making them extensible and allowing for different fire modes. Additionally, a firing cooldown should be implemented to prevent players from spamming their keyboard to quickly fire bullets. Other changes would focus on making the current Projectile extensible to other kinds of projectiles so future updates can make use of this without any code changes to the systems.

The obstacle spawner system is functional but makes use of hardcoded difficulty scaling. Future changes could be made to seperate this difficulty scaling with the spawning of obstacles, ensuring this system is only responsible for spawning obstacles. This also opens up the possibility to design spawn patterns, waves and combination of tiers to be implemented.

Accross all systems, the biggest issue is the overall architecture of the systems and the shared responsibilities within them. Due to the limited time for this project, a few ‘Manager’ classes have been made to quickly iterate and work with. Future updates would focus on ensuring the communication between some systems is improved so these managers can be removed, resulting in a better overall architecture.

Retrospective

Working on this project improved my ability to work with and around the scope of a project. By constraining the project to 10 days, I was forced to focus on core gameplay and delivering a complete experience, rather than spending time on unnecessary features or excessive polish.

An improtant lesson for me was understanding the trade off between development speed and maintainablity. To meet the deadline, I prioritised rapidly implementing features instead of writing scalable code in SOLID architecture. Even though this limits future extensibility, it allowed me to release a version of the game where I’m happy and proud of. Moving forward, I aim to take this lesson with me and get better at balancing implementation speed with code scalability.

This project also gave me confidence in my ability to independently design, develop, and release a complete game. From creating and refining assets in Aseprite, to playtesting, implementing UI, and preparing the project for release, I gained hands-on experience across the full development cycle of a solo developer. Not only was this a meaningful experience, it also boosted my confidence in myself and my capabilities when it comes to areas besides pure coding.

Overall, this project was a very meaningful experience for me as developer. While strong architecture and designing clean systmes are important for me to grow as developer, being able to quickly iterate on features and work towards the release of a playable game is just as valuable. In the future, I aim to take this lesson with me and work on more side projects in order to broaden my skills and gain more experience with releasing titles.