Captain Stardust

Introduction

I have historically made games in Unity (except for 1 Godot game last year). However, after the shenanigans that Unity went through in 2023, I decided I wanted to branch out and learn a different engine. I’ve heard Unreal is similar to Unity, but also, that learning curve was quite steep. 

If I was going to lead a game in a brand new engine – I needed to dramatically reduce the depth of items I wanted to include. In Unity, I am getting to the point that I can make it do whatever I want. In Unreal, I was Googling everything – “How do you move”… “How do you move with blueprints”… “How to Cast to Third Person”… “How to turn Blueprint on”. 

Everything required a Google search. 

To temper expectations, I focused on the following designs: the objective of Captain Stardust was to create a fun, simple, and semi-chaotic game inside of the Unreal Engine (the chaotic nature allowed me to help hide some bugs that worked their way in as ‘part of the fun’). 

I wanted the following: 

• A main menu to go into the main world
• Character movement
• Open world elements to work on open world design (new concept)
• Collectibles that unlocked a new outfit
• Ability to interact with items by picking them up
• A story that unlocked as the player did things: ‘do this, unlock this’
• Enemies – for combat and to work on UI 
• Have ‘World Events’ things that spawn based on where the player is in the world that the player could interact with

Outside of that, everything was put under the ‘nice to have’ category. 

Production Process

The main character – Captain Stardust – was going to be the initial focus point. She was made in Blender, which I am familiar with. Since the camera would ALWAYS be on her, I wanted to make sure she was at least up to my level of quality and personality.

I watched about 20 hours of Youtube videos on how to sculpt realistic people in Blender including a 4 hour tutorial on hair. Every day for several weeks I was chunking those videos apart, making animations, pre-planning animation trees, and making her at least she was done before I pitched the game. 

I then imported her into the game (and lost most of my textures on the import, including about 3 hours of work on the hair coloring) and got basic movement working.

After the pitch, for the first couple of weeks, I focused on the Sandbox level breaking down everything that would be in missions into simple tasks. 

If player health hits 0 (by pressing a key), reload the level 

-Hit this box, start a timer

-Hit this box, print a message ‘Mission completed’

-Create a box that would destroy on impact: Give that box health, if box reaches 0, destroy it

-Walk into item, increase health

(pitch video https://youtu.be/fmQhSXuEgJw?si=q7uWypiGLR6HgckO&t=191) 

Slowly, these basic items started to be built upon each other

• Hit this box, start a timer
  • Print the UI for the timer in the top of the page, if it hits 0, have the ability to start it over, restart the level, or close out on its own
• Hit this box, print a message ‘Mission completed’
  • Hit a box, print a message that says ‘Go to Mission 2’ and create a different box. 
  • Hit that box and it says ‘Go to Mission 3’ and create a different box.  
• Box has health, if box reaches 0, destroy it
  • Add a mesh to this box. Have the mesh follow the player. 
  • Have the mesh shoot projectiles at the player that lower health
• Walk into item, increase health
  • Add this item to the enemy mesh that drops if the enemy dies
• If player health hits 0 (by pressing a key), reload the level
  • Add the ability for enemies to hit the player to lower her health
  • Add the ability for fall damage
  • Add the ability to block and prevent damage from occurring

All of these small blocks started to stack on top of each other and the basis of the game was starting to form. 

About 1/3rd of the way through development, I started to move into New Lincoln City – the setting for the game. I wanted to keep this simple. Cubes with textures on them – primarily 2 different textures to give the buildings variety. If they are hit by one of the player’s bullets, they emit a couple pieces of shrapnel (this was originally going to leave holes in the building, but that was going to add a ton of scope). 

I had originally had the idea of making 8 missions, but I realized that after Mission 5, I was re-using the same enemies and same missions structure (either go here and do this, or kill X enemies). So I cut almost half of the story and used that time for further polish. 

Two-thirds of the way through development, we held a playtest. I received a ton of very productive feedback on not only bugs, but also UI placement, player feedback, and mission surfacing from our 3 playtesters. Based on the timing of the project, I probably could have waited on that feedback another week or two.

Due to the time constraints, I had every intention of not having any sounds in the game. Most of the tasks I had around audio were landing in the ‘nice to have’ category as no one in the HomeTeam group was picking them up (and I certainly didn’t have the chops for it). 

That was fine by me. Yes, it did feel like something was missing, but if it was a matter of ‘having a fun mechanic’ versus ‘background music’ I was fine cutting it. 

That was until McFunkyPants dropped in city background noises and a song he wrote. Those two pieces added SO much to the game. I opened Audacity and created a handful of other audio sounds to knock out the remaining audio based tasks and littered them through the game.  

In terms of scheduling, I planned it in a way that didn’t put a ton of pressure on me or the team in the final few weeks. I worked on polish, less words in the dialog system, more bug fixes, and better player experiences.

The day before launch, I tried to package and ship the game, but I ran into an error of: 

“Packaging (Windows): AutomationTool exiting with ExitCode=1 (Error_Unknown)” 

which is – like – the most generic error you can have while building. I spent 9 hours trying to figure out why this error was happening. I eventually solved it by creating a new project and bringing over one folder at a time from the old project into the new project, building the game, then adding another folder.

The only folder that didn’t play nicely was the “Builds” folder. Once I deleted everything in that folder, we had a successful/shippable build! 

Challenges

The learning curve – for this project was quite daunting. That was expected, but it also is frustrating when I know exactly what I want to do and I can do it in about 5 seconds in Unity, but it takes me an hour of trouble shooting in Unreal to get that to work. 

This is semi-compounded by having more experienced people in Unreal helping us in the HomeTeam group. Their help was greatly appreciated, but if I needed to tweak a variable or reconnect how the blueprints worked – the level of complexity was beyond what I understood (like a 1st grader trying to understand 6th grade reading). Their added complexity added incredible depth for the AI of the humans, ragdolling, and animation states, but looking at them felt like the ‘math lady confused’ meme. 

Builds – I routinely was making builds throughout the project to not be blindsided at the end of the timeline. That threw me for a loop during the final build which caused an issue where Google, ChatGPT, Unreal forums, and Reddit weren’t helpful in solving. Having to make a new project on the final day of development was a little nerve wracking. 

I am glad I resolved this before the final day, but having it take 9 hours was not how I expected that last Saturday to go.

What Went Right

For a first Unreal project – this worked out very well! 

Preplanning – I had my list of what I wanted to accomplish with the expectation of ‘if no one picks it up, I will need to do it’ so I tried to keep it fairly simple. We accomplished every major item on that list including the flexibility of a little scope cut on missions. 

Tempering Expectations – setting the bar low is the name of the game when making new things. Once you clear that bar, everything beyond that is a bonus. If you get character movement and that character can make it from the start of the game to the end of the game – from there it is a matter of adding details.

Uploading Weekly Videos – this was good for external feedback, the videos were averaging around 20-30 views. The comments would say ‘you could try this’ or ‘this looks weird, could that be changed’. It was quite a positive experience.  

Low Stress / It was fun! – Typically for games I lead, I have a certain level of quality I am aiming for which usually leads to immense scope increases to cram it all in. If you picture a box – typically I try to shove as much as I can into it and close the lid and ship it. This time around, I opted to cut things from the box and work a little more on the presentation of the things in the box. That made it much easier to dive in to work on it and say ‘let’s tweak this’ or ‘let’s restructure this’. An extended timeline also was helpful (see pre-planning). By the end of the game, I was not burned out and I wanted to keep working on it.

Lessons Learned

Everything? Can I say everything? I started this project not knowing how this engine operated and I ended up with a 13 person team over 375 commits all helping to make a 5-mission superhero game with 3 different enemies, collectibles, world events, ragdolling, and it is fun to play! The sandbox element and giving access to the cheats menu opened the game up to a ton of extra options. 

If I am going to specifically call out some items: 

Blueprints: This was daunting to start off with, but by the end, I was genuinely preferring this to hard coding anything. Being able to visually see what I was coding rather than seeing it in my head not only helped me understand, but was faster to test. 

Having a ‘Sandbox’ and main ‘Level’ helped a ton: this was excellent for early stages of development or making changes mid-development to existing blueprints. The sandbox level was kept mostly clean except for the blueprint you were actively trying to test. It aided with rapid testing and faster loading times. 

Playtesting – Usually playtesting is one of the first things that I cut, but with it being the first game – I wanted to make sure I knew the process of uploading a build, making that build viewable, and giving it out to see if other people were experiencing performance issues. The feedback on the game was also a great help. I think I would have preferred to have a bit cleaner of a build for them, but we learned from it. 

CHEATS! – I finally took Chris’s advice and leveraged cheats for movement, collectibles, minimaps, and mission triggers. This saved so much time on development and bug fixing when I didn’t need to retest the entire game for a late game bug fix. Turning those cheats from key-presses to player-facing also helped add a sandbox element to the open world game.

Summary

Studio:  HomeTeamGameDev – Apollo

Title: Captain Stardust

Staff: 13 (10 contributors, 3 playtesters)

Budget: $0.

Total Play Time: 20 minutes

Development Time:  147 days (March 3, 2024 -July 28, 2024)

Release Date: July 28th, 2024

Platforms: Downloadable Windows

Software Used: Unreal, Blender, Audacity

DevLog: https://www.youtube.com/playlist?list=PLUGaCRKIP_nZ2h6OCRNX2xPqwZFldV2bO

Game Link: https://chaoticplay.itch.io/captain-stardust