Putting All My Hobbies into A Single Project (Boosted: A Propulsion Game)
How Amazon Q helped me build my dream project in a programming language I didn't know existed.
Published Jan 14, 2025
Last Modified Jan 19, 2025
Boosted is a game where you maneuver a rocket through unique courses to get to the finish line in as little time as possible and climb the leaderboards.
Here's the thing, I love music, art, design, and programming. And one thing that encapsulates all of these is Game Development. I have always dreamed of making a video game where I create everything in the game, meaning music, art, animations, and of course code, but it seemed extremely overwhelming and I had no idea where to start. So over the years it kind of dissipated into the back of my head, but I never really forgot about it.
Fast forward to about 2 months ago, I got an email from Devpost, about the AWS GameBuilder challenge and I immediately knew I wanted to join.
But ... Where do I start?
I started by reading the competition's requirements, and I then proceeded to research what I needed to build a game, the first thing I needed was a game engine, this is where I found out that I had a lot of options to choose from. The most common ones were Unreal, Unity, and Godot.
I didn't want to waste time trying to decide which one would be the best for me, I just chose Godot because it's lightweight and open source, didn't do any more research.
Now the big question is, What was I going to build?
First and foremost, I knew that I didn't want to make the next Stardew Valley, or some crazy RPG that looks nice but no one would play again after trying it out once.
I wanted to make a game that was simple, competitive, and would keep you coming back.
while I was thinking about the idea I remembered a game I had on my phone called asteroids, which was actually a remake of a classic Atari game. Although the game was very simple, I liked the physics a lot. The boost system was extremely satisfying. So I kept that in mind.
One other game I liked was Trackmania, although the graphics aren't the most beautiful and the controls aren't the best, the way they implemented the timekeeping and the leaderboards makes it very competitive.
So I wanted to combine these two concepts and build a game with a satisfying boost system and a well-built leaderboard that would keep the game interesting and competitive.
So I immediately installed the AmazonQ extension for VSCode and started getting comfortable with the Godot Game engine, which uses a scripting language called GDScript which I had never even heard of. I started by asking Amazon Q questions like this:
I then proceeded to prototype with a rocket, trying to get the boost system right. In the early prototypes I made, the movement was bad, everything was just awful. But with the help of Amazon Q, it started improving with subsequent iterations.
I started researching and asking Amazon Q about AWS services and decided to go with the following:
- Lambda
- Cognito
- API Gateway
- DynamoDB (which I ended up not using)
- IAM
- Cloud Watch
- and Amplify
I created 5 lambda functions for authentication, user, and leaderboard handling. I liked how AWS Lambda is well suited for a more modular approach, to keep concerns separate.
I used lambda within the console itself, and I found it to be very convenient.
Here's a snippet of the lambda I used for sign-in:
One thing I get very annoyed with when trying out a new application/game is being asked for my email address, I get that it's required for some apps to function, but especially for most simple games I really don't think it's necessary. But this is where I ran into an issue with AWS Cognito, since an email or phone number is required to confirm the user, I had to use the AdminConfirmSignUp command provided by Cognito to automatically confirm users on sign-up if they provide a valid username, password, and country (which is required for the leaderboard).
I know that this may not be the best approach but I didn't want to deter potential players by asking for information my game doesn't need at all.
To allow my Game to access the functionality provided by the lambdas, I created the following resources in API Gateway and connected them to their corresponding Lambda functions.
- /signup
- /signin
- /leaderboard
- /validateToken
- /refreshToken
Although some of these functionalities can be grouped into a single endpoint/lambda, I am a big fan of using a fragmented approach, so that's exactly what I did.
One issue I faced when using API Gateway was I kept getting a 502 Bad Gateway error and sometimes I just didn't get it, since the issue didn't always happen I just couldn't figure out why, I tried almost everything but nothing worked. After I informed Amazon Q about the issue, it suggested that I used CloudWatch to monitor my API Gateway logs, and I did just that, it turns out that the issue was actually originating from my Lambda function, it was timing out as the default time before timeout was 3 seconds, and as I was also connecting to my MongoDB database within the same lambda function, the 3-second timeout just wasn't enough. So, bumping up the timeout completely fixed my issue.
I first planned on using DynamoDB to store leaderboard data, but since I was doing some not-so-straightforward transformations and sorts, I found it to be less flexible for my use case. I then started looking into DocumentDB since I'm comfortable working with MongoDB and also since I wanted to use an AWS service, but the instance-based pricing model wasn't practical for my game, always running an instance for the small amount of database requests my game was going to receive didn't make much sense. So I ended up using MongoDB Atlas which actually utilizes AWS as a cloud provider.
Below is how I query and transform my MongoDB Collection data during sign-in to fetch the user's best times with the corresponding track names to be stored on the user's device, so that the database doesn't have to be accessed every time the user wants to view his/her best times.
And within the game, I did the following to store the received data on the user's device:
First of all, I had a couple of ideas of some of the things the game had to have, based on my own video game preferences, and I was not willing to compromise on any of these points. It needed to:
- Be simple: for the observer, the gameplay must look interesting and the goal at hand should be obvious, if not, there's a big chance it would deter potential players.
- Have Replayability: the game needed to be replayable, it had to be something you'd want to come back to.
- Be Competitive: players needed to have a way of competing with each other, this will make the game more interesting, we as humans have an innate desire to compete with each other, and most games leverage this idea.
- Last but not least, there needed to be No Dying!, just good times!
Keeping the above points in mind, I got into the visual design, I first started by doing some rough sketches of what I wanted the game to look like, including some of the UI. I really love the tactile experience of using pen and paper to brainstorm and capture my thoughts.
After I had done those awful sketches, I took to Figma to make the actual designs. Below, I have included some of the designs I made, interestingly, almost all of them made it to the actual game.
What's funny is, I didn't have the slightest idea of how to actually implement the designs in my game. Especially when making the track selector design, I thought to myself, "This is probably going to be crazy difficult to get right", but thankfully Godot's layout system had similarities with that of Flutter's and the CSS box model, which I had some experience with.
With the help of a couple of YouTube videos and Amazon Q's assistance, I was able to get most of the job done, but making the track selector was proving to be difficult, as I couldn't get it to feel right with Godot's built-in ScrollContainer, So I wrote my own scroll functionality from scratch.
Below is the code for the track selector:
Creating my own scroll functionality from scratch turned out to be a great idea, I thought it would be a ton of work but it allowed me to make the track selector exactly how I wanted it to be.
To enhance the competitive experience, I wanted to add country flags to the leaderboards. A generic global leaderboard without country designations felt uninspired and would also drive new players away as it'd be significantly more competitive than a local one, so having both global and local leaderboards was not just better, it was necessary.
I began by downloading flag images for every country, but most free online resources only included country codes, not full country names, maybe this is the standard, I don't know, but I had to find a way around it.
Here's where Amazon Q came in handy, I asked it to generate a dictionary with country names as keys and country codes as values.
After that, all I did was map the flag assets to their corresponding flag names as follows:
One very important thing we need to consider when making a competitive game is how we can mitigate cheating. Cheaters ruin games and that's a big problem, so I had to implement some form of anti-cheat.
The simplest anti-cheat I could implement was one that uses hashing. So when the user uploads a time/score, a hash is created with the time, the name of the track the time was recorded in, and a secret key.
The secret key is shared by the server and the game client, so the server will calculate the hash again with the data it received, if the hash doesn't match, then the score is invalid.
Client code:
Lambda:
I included the track name when creating the hash, so that a player can't perform a Replay Attack, where they send a valid score with another track name.
Since the source files are encrypted and exported as compressed binary tokens, it would be extremely difficult for a cheater to decipher and start sending data that has been tampered with.
Although I'm aware that this method isn't foolproof, I believe that it gets the job done for the purpose of this game.
Music has always been a deep-seated passion of mine, but turning that love into creation has always felt like a distant goal. I've dabbled with guitar and piano for a while now, but it was this competition that truly gave me the push that I needed to finally bridge the gap between interest and action.
My goal was to create a sound that not only sounded good but also enhanced the game's atmosphere.
So I got on my keyboard and started noodling around until I got a melody that sounded good, well, at least to my ears :)
After that, I went on Ableton Live (A Digital Audio Workstation) and created the different sounds within the soundtrack section by section, which I finally arranged into the final soundtrack.
I experimented with different instruments until I found the one I liked, I then recorded 3 different notes (I'll explain why later)
I then played around with the attack, frequency, and so on, until I got the right "neon tactile sound" whatever that is.
I finally exported the track to Audacity to easily trim each note to be very short, or else it would make button presses feel delayed and clunky.
After importing the 3 different sounds into my game, I wrote a script to play a randomly selected sound every time a button is pressed. The random selection and the sounds being different is necessary so that the SFX doesn't sound robotic and unnatural.
Finally, I used AWS Amplify to deploy the game. I was baffled by how easy and straightforward the process was.
Moving forward, I plan to continue working on Boosted, as this is a project I'm beyond passionate about. Below are some of the things I'd like to add to the game
- More music; for now I only made one soundtrack which is played across the entire game, but it'd be a nice touch to have multiple unique soundtracks, one for each map/track.
- More tracks; Right now, the game has three short tracks (which I intentionally made short to keep players engaged), but I plan on incorporating more.
- Publish on Mobile; The game is currently only available on the web, but I plan to also publish on the AppStore and Playstore, as mobile was my original intended target.
- Player-Designed Tracks; Giving players the ability to create their own tracks and share them opens the door for unlimited content.
Making this game has been an extremely challenging but rewarding journey that I'll never be able to forget, it was especially difficult since I was doing this solo, wasn't using any pre-made assets or sounds, and had zero experience working with AWS tools, as well as Game Development. But that's also what made this project exceptionally rewarding.
I'm also extremely glad that I got introduced to the amazing tools AWS has to offer, I will definitely be using them in my future projects.
Before I conclude this post, I want to say that as someone living in an East African country (Ethiopia) where such kind of opportunities are almost non-existent, I would like to thank the AWS team for organizing this competition from the bottom of my heart. I'm genuinely grateful to have been given the opportunity to be a part of this!!
