Break The Sky has had a big of a surge in popularity recently. It was well received when I submitted it to AI and Games Jam 2021, coming #1 of 127 in 'Fun', and #5 overall. But it never really broke above my other jam games in terms of player count. Recently, for whatever reason, it garnered enough attention to be pushed quite high on the Itch.io font-pages (the web, free, and games sections), and thus spiked in popularity briefly twice:

By no means huge, but by far the most attention anything I've made has gotten, outside of professional game-dev work.

It's a personal goal of mine to get something released on Steam. It's a goal I've been attempting with various projects in the last few years, but - as is fairly standard - they tend to balloon in scope and get abandoned before they're in any way releasable. It doesn't help that I like to experiment with more esoteric technical challenges (just look at my Itch projects), and I often find myself trying to figure out what game I can make out of some technical prototype, instead of using technology to solve game design problems. I think most seasoned developers would tell you this isn't the best way to make a game (though there are some exceptions like Teardown or Townscaper).

This and the lack of financial incentive - I have a comfortable job in the industry - means I have little drive to push past the fun 'experimentation' phase and into the 'finish something people would pay money for' phase.

Suffice to say...

I think expanding Break The Sky into something I'd be happy to release on Steam for pocket-change is something I can achieve, and will give valuable experience that will hopefully allow me to get some of my other more ambitious projects off the ground in the future.

Lets get technical

Ok, enough of that.

Godot vs Unity

The first decision I have to make is whether to stick with Godot or abandon for Unity.

I love both Unity and Godot. I tend to use Godot for my personal projects, and Unity professionally. I find Unity easier to maintain a coherent and clean project structure, and it has fantastic features like Burst for optimising performance critical code, and support for more technologies like compute shaders. It also has a very robust editor that can be modified in many ways to create custom tooling, great for improving efficiency in long-term projects.

Godot is very fast for prototyping and game jams. I love the hierarchy architecture with nodes built of scenes. It has most of the features you could want for smaller projects, and a great community and is FOSS. My main issue with Godot was GDScript, because I hate loosely typed languages (and the internal code editor kind of sucks). But I experimented with Godot and Mono C# when participating in LD50 (Stacktics) and found it works incredibly well, and it has full Rider support, so I can code just as I do with Unity. C# is also likely to be faster than GDScript in most cases.

GDScript does have some support for declaring types - but is far from optimal...

My decision is to continue with Godot Engine for this project. The most demanding part of the game, controlling many drones (or 'boids'), I feel I can optimise enough in C# to not have performance concerns, without requiring Unity for Burst or compute. Godot has far fewer fully released games than Unity, so it is easier to stand out in the Godot community than the Unity one. I also don't have to port the game to Unity, and when I'm aiming for a relatively quick turn-around that definitely helps, though I will have to port the GDScript code to C# (I don't expect this to take more than a few days).

2D vs 3D

The second big decision is whether to stick with 2D or move to 3D.

I like the current look of the game, in 2D, but I question whether this is enough to stand out when released on Steam. I am worried about it being too derivative of Vlambeer's style (i.e. Luftrausers), and generally too basic.

If I moved to 3D, I would strive to maintain the same aesthetic feel of the Vlambeer style, but use 3D to bring additional flair, fidelity, and ease-of-development. For example, I do quite a lot of perspective tricks in 2D to give the appearance of 3D (such as destroyed ships falling to the ground by reducing scale, or the parallax effect given by the cloud layers. Instead of making these 2D 'hacks', I could just use a perspective 3D camera and the third dimension.

It would also make it much easier to add subtle 'juiciness' (which I try to strive for in my projects), like ships tilting as they turn or fall. This would be a simple rotation of the mesh instead of 2D frame animations. I could even maintain the pixelated quality by rendering to a lower resolution point-filtered target, ala A Short Hike.

The obvious downside of 3D is that I'd have to create 3D models for everything. I'm not a 3D modeler and have minimal experience with tools like Blender (though I have some), but I think a few things increase my confidence that I could pull it off. 1) if I maintain the flat shaded look, I don't have to worry about texturing or even geometric detail outside of the silhouette. 2) Really the only things to model are the ships/fighters/drones, which seems manageable. Everything else is VFX or shaders (i.e. clouds).

I will need to try out the 3D workflow before making a final decision, but right now I am leaning in that direction.

What about the gameplay?

Obviously the biggest question is how do I expand the core vision of the game from the jam version into the full release? This is really where I don't want to scope creep if I can avoid it, so I need to come up with a solid design and implementation plan and stick to it. I will cover this in another devlog when I've thought about it more, but there are some games I've played recently, in similar genres, that I hope to borrow ideas from, including:

• Vampire Survivors - This is probably the most direct comparison in terms of the core gameplay loop. It bears a lot in common with Break The Sky, in that it's an arena shooter about surviving as long as possible while gathering upgrades to facilitate the wanton destruction of ever more powerful enemies.
• SNKRX - Gained notoriety for integrating the level-up and economy elements from autobattlers (Dota Autochess, Teamfight Tactics) into a more standard shooter. Similarly to Break The Sky, you control a group of units instead of being a single entity.
• Both SNKRX and Vampire Survivors automate the actual shooting mechanics, leaving the player free to worry about movement and upgrades. While I want to maintain the manual weapon control in Break The Sky, as the act of shooting - and the drones falling in rank to reload - is one of the core elements and addictive 'game feels' of BTS, I do want to experiment with more automated elements.

Metagaming

Just as important as moment-to-moment gameplay, is the metagame progression model. Is this a pure rogue-like high-score game with no run-to-run progression? Is it rogue-lite where some upgrades persist across runs? Is it more campaign based where progression happens over multiple increasingly challenging levels with progress saves in-between?

I have no answers for these questions yet.

Wrapping up

That's enough for now. I wrote much more than I expected to, but the process has also helped formulate ideas/plans in my head. Sort of like a coder's rubber ducky. I guess that's what these devlogs are going to be.

Thanks for reading (if you got this far) and please do leave a comment or a like, because it would be great to gauge interest in this. I am also very interested in what direction you'd like to see Break The Sky go in, as a player, with particular focus on the things talked about above.

Ciao!

Sam