Kuiper

Devtober Post Mortem

Out in the frigid Kuiper Belt, far from the warmth of our sun, water is the most vital resource there is.

To the few that brave this frontier water serves as sustenance, fuel, and defense.

Kuiper is my idea for a unique spin on the classic Asteroids shooter formula. The above gif is the prototype I started with for this Devtober. As you annihilate asteroids you also build a protective shell out of the water ice that makes them up. Throw in enemy combatants into the mix and that protective ice shell becomes vital to the player's survival.

Objectives

For my first Devtober I set rather lofty goals, and met half of them. The game as I imagine it requires some complex systems that I've never built before, and along the way I encountered both pleasantly surprising results and discouraging setbacks. If you want to skip to the Lessons Learned TLDR that's at the bottom, please feel free to!

Revamping Destructible Asteroids

This was by far the biggest undertaking this month. To get the new and improved asteroids to act and look how they do now took half of my Devtober. I knew this would be a big piece going in, which is why I tackled it first. This was also blocker for revamping the accreting ice shell, since it would be built on top of the same system.

I am the most proud of my work on the asteroid break-up. I think it came out looking far better than I could have hoped, and performs must faster than I expected, even while still being coded in GDScript. The next steps are to get it fully coded into C++, which should prevent the frame stutter seen in the demo gif.

This part of the project also had some pleasant surprises along the way. For instance, while playing around with different ways to color the vertices of asteroid, I learned that by using a cubic color interpolation along the ordering of vertices of the Delaunay tessellation, I was able to very easily give the asteroids a nice frosted edge look. There was no reason for this to work aside from sheer luck, and I had no reason to try it aside from sheer curiosity and boredom. This experience taught me that aimless tinkering in moderation in game dev can yield serendipity.

One more lesson I gleamed from the asteroid revamp. The Fruit Ninja-esque chopping mechanic seen in the above gif was never meant to be in the game. It was just some debugging tool I made to test break-up, but as sometimes happens with debugging tools, I realize it's quite fun! I don't know what the mechanic will look like in it's final form, but I now know I have to find some excuse to give the player a similar power in-game!

Adding Asteroid Hopping and Crawling Mechanics

Since asteroids had to be rebuilt from scratch, asteroid hopping and crawling wound up being the only true feature addition I had this month, and it's one I have yet to discuss the idea behind. When accreting ice shells are fully realized in Kuiper, it is possible for a player's ice shell to be chopped up/blown apart such that the player character is now unshelled and adrift in the cold void of the Kuiper Belt without any shielding, propulsion, or weapons. The player is now in E.S.A. mode (Extra Shellular Activity), a sort of "second chance" phase of gameplay, and must use their momentum and nearby asteroids to navigate to safety before they can start the process of rebuilding their protective ice shell.

I dived into work on this feature immediately after I finished asteroid break-up; when I was reinvigorated by a hard fought victory and eager to start something I anticipated to be much simpler to implement. What I mean to say is I may have gone into tackling this feature with a little too much confidence right at the start. I vastly underestimated the time it would take, and I just assumed that the asteroid-ESA code interface would somehow work out. It didn't, and the feature took some amount of recoding on the asteroid end of things.

I also learned from this experience that player controls are hard, and to get asteroid crawling in particular to feel good on both analog stick and WASD is going to take some more time outside of Devtober. I am still proud of where the mechanic wound up, and during its testing I got around to building something I never even put in my objectives, but badly needed all the same: a PlayerFollowCam script.

What Remains

Following the completion of asteroid hopping in the 3rd week of Devtober, and already knowing implementing AI and HTML5 might need to be held off until next month, I was onto the final feature: ice shell accretion. Up to this point I had been building everything in Godot's GDScript, which allows for very rapid prototyping, but is slow for expensive computation like a Poisson disk sampling algorithm or iterating through a 500 triangle tessellation in a single frame. In addition to being destructible like the asteroids, the ice shell must also be larger (more triangles to iterate over), and must accrete material (add triangles in response to water ice collisions), meaning the slowdown from doing this all in GDScript for the ice shell would be significant. I knew the destructible script would inevitably have to be recoded in C++, but it was a step I hoped I could put off until after Devtober. Now this significant task had to be done in much less than a week if I were to have any hope of then extending it with a material accretion mechanic and finishing the accreting ice shell before the end of the month.

Over the final week of Devtober I worked tirelessly toward this end, and the results so far are very promising! The Poisson disk sampling saw a factor of 35x increase in speed, if I can get similar or better increases out of the remaining C++ recode, then the game should run great on most any modern machine (keep in mind I intentionally do not develop on my gaming rig so that I know I'm developing something even low-end machines can handle).

In this final week of Devtober, my focus shifted from rapidly prototyping flashy features that make nice demo gifs towards making sure the implementation of those features are scalable and adaptable enough for what comes next. It was the work that I wanted to do later, but realized I absolutely needed to do now, and while it did not produce any new pretty demo gifs to post, it is building my confidence to see Kuiper through to the end.

Conclusion

Kuiper is a game about being resourceful with what little you are given. Which is why I could stand to learn from it. At the beginning of the month I made a list of tasks that would get me to a vertical slice of the game, but I never took a moment to allocate time for each one. If I had, I am sure I would have removed some non-essential tasks from the list, and had a better idea of what to expect this month. There still would have been unexpected delays along the way, but with a scheduled list I would have stayed more focused on the task at hand rather than dreading what's to come or wondering what to do next.

You will notice my submission for Devtober is actually just an older version of the prototype that I started with at the beginning of the month. At this time I do not have a cohesive version of the game ready where everything works together quite in the way I would like it, so for the time being I am going to hold off on publishing a new version, but plan to have something playable soon. Hopefully within this month, so stay tuned!

I am extremely proud of the work I accomplished on the project this month. This is undoubtedly the most devleopment I have been able to squeeze into a game project within single month, and it's taught me a lot along the way.

Lessons Learned TLDR

1. Do the hard thing first

I'm glad asteroid break-up was the first thing I worked on, and it invigorated me to tackle what came next. Furthermore, if a problem winds up being too hard to tackle, it's better to learn early on in the project and rescope then.

2. Tinker!

Good things can happen when you toy with the systems of your game, even if you do it without a defined purpose. 

3. "Follow the Fun"

4. Give ample time to controls

This always seems to pop into my head everytime I work on a control system. For any game the feel of the controls can make it or break it. Give ample time to both designing and iterating on controls. If you do not have ample time to commit to controls then write a prototype that at least works, and plan to improve the feel of it later on. Simple and readable code is always important, but realize that control systems that feel good to the player rarely take the form of simple. If your code for controls becomes monstorous, that might honestly be okay. Function > Form.

5. List and schedule objectives

In contrast to #2, when you aren't toying with your project in moderation, it's good to work on a planned schedule. If you aren't the type to plan things the month out, like me, then at the very least try and do this: At the end of a day's work make a note. It could be a sticky note, an uncompileable sentence in your code, or a git commit comment; just write it somewhere you'll notice the next morning. Write what you were doing when you finished work, then write what you plan to do when you resume work. I'm not as consistent about it as I should be, but every time I do it I find the overhead of staritng up the next day to be far smaller.

Thanks!

Thank you so much for reading this far! 😁 I will continue to work on Kuiper at the same pace until it I get the vertical slice I'm after. If you're curious about the project and want to follow along, please follow me on Twitter and check out my blog where I'll occasional post longer form updates, including a duplicate of this Post Mortem.

Twitter: https://twitter.com/StarryNiteGames

Blog: http://astrostucky.com/wp/

Itch.io Project: https://starrynitegames.itch.io/kuiper

See you all next year!