Blog: Sky Striders Game
- Jack Stevenson
- Sep 12, 2025
- 11 min read
Updated: Jan 10
Fall 2024
Sky Striders: Retrospect
December 14, 2024
As our development cycle come to an end, I wanted to take the time to reflect on the development of my team's game, Sky Striders. It's a fast-paced flight simulator that revolves around the player flying vast distances, getting money from completing objectives, & using that money to purchase upgrades.
While I was at first unsure of how the game would turn out, I now see that such uncertainty was entirely unfounded, since the project has really turned into a solid game. It's even debatable that, with some minor tuning, the game could be sold as a retail product. With that in mind, I'd like to discuss what I did well, what I could have done better, & what I'd do differently in the future.
There are multiple things that I would say went really well during the development of this game. One of those things would be the ramp/flight systems. These systems were the first that I had created for the game, as they serve as the core of this game's gameplay loop. Originally, I had actually programmed all of the physics handling to be custom. This was due to how I wanted explicit control over how the player moved, and I felt as if Unity's built-in physics wouldn't allow for what I wanted. However, I eventually did end up switching over to Unity's physics, as they allowed the physics to be much more consistent (and not framerate dependent). It was thankfully very easy to integrate, as there weren't a huge number of changes that needed to be made.
I also incorporated the glider into the game's upgrade system. This was done by making the glider derive from the 'Equipment' class, which has an overridable function for handling upgrades. Along with this, I added some trail visuals to the sides of the glider, which really helped to make it stand out & emphasize the player's movement.
While many parts of the development process went well, it wasn't all sunshine & rainbows. In fact, there were a few systems that were really frustrating to develop. One of these troublesome systems was the obstacle management system. Originally, this system simply created objects near the player as they moved & deleted all of them when the next day started. While it worked, the number of objects that were spawned would cause lag once the player had flown far enough, as objects that the player had passed wouldn't be removed. To solve this issue, I created my own object pool system. This system worked by simply disabling/storing gameObjects in a queue rather than deleting them once they were far away. These disabled gameObjects could then be reset & placed in front of the player when a new obstacle needs to be placed. This dramatically improved both performance & memory usage, as the game no longer had to handle hundreds of off-screen objects at once.
I faced another roadblock with this system when it came to adding multiple levels, since I needed a way to have unique obstacles for each level. My first solution to this issue was simply adding a container gameObject to each level, but this had a multitude of issues that made it tedious to change elements. I settled with a much more robust scriptableObject system, which allowed me to edit the obstacle data for levels without having to open each of them individually.
Looking back, I'd say I'm really happy with how our game turned out. However, there are a few things that I would do differently if I was to recreate it. The main thing I'd do differently is develop a more thorough plan for how my game's systems would interact with one another. I did a little bit of structuring before I created the systems, but it was very rudimentary & I didn't follow it very strictly.
Going forward, I'll try to put more effort into developing a concrete set of plans that still has room for on-the-fly adjustments as needed. Another thing that I would do differently is try to only focus on visuals later down the road. There were a few days early on that I dedicated to making the shaders look better, and while I am happy with how it turned out, I should have prioritized finishing the game's systems before refining how it all looked.
I am very satisfied with the work that my team and I have done to make this game. We went from a concept to an entire game within only 5 weeks, working hard to ensure deadlines were met & that the game was fully functional. We planned each sprint & logged all of our progress using Trello & GitHub. We had playtesting sessions & presented our progress to an audience with PowerPoint slides at the end of each sprint. We took notes from each playtest & planned the next sprint with them in mind.
I have never worked with a team as efficiently as I had with this group, and seriously commend all of our efforts involved in creating this project.
Sky Striders: Sprit 4
November 23, 2024
For our 4th sprint, we started by layout out the work we would do for the sprint. I had two main goals in mind, but there were also smaller things I wanted to do. However, I had to prioritize my main goals for the time being due to how they would influence the rest of our game.
The first main goal was to create a dynamic object pool for my obstacle management system. I realized that this was something that I needed to do since our game's performance started to suffer when the player started to fly very far. This was due to how the game would simply delete and recreate obstacles as needed, which caused lag spikes from Unity's garbage collection system.
Implementing this object pool was fairly simple, as I had worked with object pooling before in prior projects. Once implemented, I noticed a considerable improvement in performance. There were some issues, however, that would arise later in development.
My next goal was to create a system for changing levels. This was going to be much more challenging due to how I needed multiple subcomponents for this to work. Not only did I need a way to ensure some objects persisted between levels, but I also needed a way to keep track of what unique obstacle sets to use for each level.
Object persistence is already a standard Unity feature. All I needed to do was get a list of the GameObjects that I wanted to persist and feed them into the DontDestroyOnLoad() function. This ensured they wouldn't be deleted when a new scene was loaded. Distinct level stats were also fairly simple, as I made a LevelData script with an automated singleton to handle it. This meant I could place a LevelData script in each level with their own data and they would automatically set themselves up.
As per usual, we had a playtest for this sprint. We took a lot of the feedback that we had gotten from last time and incorporated it into the game. This time around, players seemed to be more accustomed to the game and were much more capable of getting past each level. They were also much more engaged with the game itself, likely due to the level system giving players a sense of progress.
The main feedback we had gotten was about how the controls were still a bit unclear, even with the tutorial screen. This is likely due to how players couldn't pull the controls menu back up once they closed it, and players would forget about individual controls that they might not have used until a certain point. We also had to do a presentation, where we showed off our work over the sprint to the class. As usual, that went really well, and I'm happy with how it all turned out.
Overall, it's really nice to see how our game has come together. It's been a really fun adventure developing this game with people I had just met, and I feel as if we all have improved dramatically in our ability to work together. After this sprint is Thanksgiving break, which I'll use to decompress and chill out with family. However, I'm excited to get back to work with my team and push towards the finish line.
Sky Striders: Sprit 3
November 8, 2024
My team and I started our 3rd sprint with a few goals in mind. One of those goals was to finalize the core gameplay loop of our game. The last main component of our core game missing was the upgrade system. To make this, my team's designer needed to create a list of possible upgrades for the player to purchase. Once posted on our Google Drive folder, our team's producer got to work creating Trello cards in order to split up this upgrade system into smaller chunks. It was my task to implement the code needed for this system to function.
As the programmer, I first started by creating a simple restart screen. This allowed our game to have a much more natural transition between levels, rather than having to awkwardly press a button whenever the player felt like restarting. I also added a bunch of trackers to show how far the player went, how high they soared, and how long they traveled. These would then be turned into currency, which the player would use in the upgrade system that I would implement afterwards.
The creation of the stat tracking system was surprisingly more challenging than I anticipated. This was due to the fact that it needed to keep track of the maximum values achieved, but only for one run. These stats would then need to be converted into currency & reset once the player enters the next day. While it took me some time to figure out a proper solution, it came out to be a fairly solid system that worked as needed.
After this was put in place, I worked on creating two acquirable upgrades: the glider and the rocket. The glider took me a lot more time to implement than I would have expected it to, since I needed to figure out a way to emulate lift & drag in a way that was easy for players to understand. After that was taken care of, I then created the rocket upgrade. This was far simpler, since it just needed to push the player forward when the correct button was pressed.
We also had a playtest session midway through this sprint. My team and I had enjoyed showing people our game and getting their thoughts on. We got a lot of great feedback alongside plenty of praise for our game's polish and general feel. It felt really good to hear how much people enjoyed trying out our demo.
Overall, I'm really happy with how our game is turning out. With each sprint, we come closer and closer to a finished product, and I am gaining plenty of experience in the process. I feel as if I've learned a lot so far about how to properly work as a team, and how I should advocate for my own needs or when I might need help with something. My group mates have been fantastic as well, as we've all been very supportive of one another during this project. I'm excited to continue developing our project over the next few sprints.
Sky Striders: Sprit 2
October 24, 2024
For our 2nd sprint, my team and I continued to develop our game based on the feedback we had received. Based on feedback from our prototype, we knew that we had a few things to work out.
The main system I focused on developing this sprint was the obstacle spawning system. We needed this in order to create obstacles as the player traverses the level. We needed the system to be able to change what obstacles were spawned, as well as be easily configurable to make balancing more intuitive.
At first, I thought this would be a simple task. I thought I could just litter the ground in front of the player with obstacles as they flew, but I quickly realized that, without keeping track of where the player had already traveled, the player could circle back onto the same area and respawn obstacles in that region. This meant that I now had to keep track of each area that the player had visited. To accomplish this, I divided the world into 'chunks' and spawned obstacles in each chunk once the player got within a configurable distance from each chunk. This meant that spawning was much more controlled & already generated chunks wouldn't be recreated.
After this system was put in place, I focused my efforts onto starting a resource system. I tried a few iterations of possible systems, such as having pre-existing resources, but I ended up using a dictionary-style system. By doing it this way, resources that the player doesn't have yet can be added to their 'inventory' dynamically, and resources that are given to the player that they had previously found before are simply added to that entry. This makes it a lot easier to add new resources.
For the next Sprint, I plan on working on the game's upgrade system. I've already coordinated with our team's designer, and he will come up with a system for me to implement. He also plans on developing a few models for the upgrades, so that the player will see them once purchased. This should help to convey a sense of progress for the player, as their character will be more and more 'decked out' as they advance further in the game.
Overall, I really happy with how our game is turning out. While the game isn't functionally complete yet, it's coming very close to getting to that point. Once we have upgrades in place & different levels to advance to, we can narrow our focus on refining the core experience of the game, ensuring that each system is both robust and satisfying to interact with. I'm excited to see what my peers will think of our game once it's finished.
Sky Striders: Sprit 1
October 12, 2024 Our game started out as an idea from our lead designer: a 3D version of the game Learn To Fly 2. The designer had reached out to me about joining the project, and I gladly accepted the invitation. Once our designer found a solid producer to help manage the production of our game, we got to work.
As the programmer, my first goal was to set up the workspace for our game. We're using the Unity game engine, which meant I could use GitHub for file sharing and version control. While I was doing this, the producer and lead designer worked together to create a Trello board and fill it out with the tasks needed to complete our game. They also helped to compile a paper prototype for play testers to try out.
Our first playtesting session really helped us tune the direction that we wanted to take for our game. We used a long strip of cloth taped around a table for a track, which we then pulled to emulate motion. One of our other teammates would then put obstacles and coins on the track for other players to avoid or collect. The main feedback we got was that our rules were a bit convoluted. Someone also mentioned they felt like there should be more to do than just moving left or right.
On the side, I was also working on the digital prototype. The first thing I had to create was a dynamic ramp system. It needed to be scalable vertically and horizontally. This was more complicated than I thought, since I needed to scale multiple separate parts independently from each other to avoid distorting the curved parts of the ramp. After some tinkering, I managed to find a solution I was pretty happy with that worked fairly well. I then set my focus on the player's movement. Thankfully, this was pretty simple, as I only needed to worry about the ground plane for the time being.
For the next Sprint, I will focus on adding more objects to the world to make it feel livelier. I will add dynamic obstacles and collectibles that the player can collect as they go. I will also need to incorporate player controls, but I don't expect this to be too much of a hassle given how the player's movement is handled currently. I will also make sure to update my progress with my team members frequently to ensure it aligns with our collective vision for this project. I want to ensure that my work meets their expectations for this game.
Overall, the main thing that I've learned from this first Sprint is how to more effectively work with a team. Most of my game development experience has been on my own, so working this closely with other members is a new experience for me. While the project was a bit tricky at the start, I am very proud of the work that we have accomplished as a team, and I am excited to see what we continue to do. I will do my best to be open to feedback and reflect on my work and my work ethic as much as I can.
