Updating Gun Rocket through 10 years of Unity Engine

Unity 2022.3 is a great LTS version to park an older game in maintenance mode on. It's where everything kind of congealed into a solid, reliable engine again, after the hot messes that were 2020.x and 2021.x. It's also still receiving updates for Enterprise users through Unity's xLTS program, which admittedly isn't within reach of most people, but it's a good option for already released, successful games that require continued support.

>Valve certainly doesn't seem to give a shit

Valve is nonexistent in the modern gamedev community, Source 2 is used by approximately noone, and overall releasing one game every decade doesn't exactly make Valve a prominent voice in the gamedev community.

However, yes, companies lock their engines at whatever it was when they started their project, and any upgrades comes from internal engineering. Decade long undertakings like the "recent" FF7 remakes are still on UE4 and will stick with that for the third game, because that's what they started with, and at this point the rendering pipeline and workflow is theirs

> There's not a lot of churn in Unity

Deprecating entire languages (probably the right call long term, oddly enough Godot is keeping GDScript around).

Render pipelines (URP and HDRP to be merged, built in likewise being deprecated).

Most of the things around DOTS.

Most of the things around networking.

The whole package management system (I mean, it’s a nice idea, still counts as churn).

Also multiple approaches to UI and input.

I would say that a lot of the new stuff is built on good ideas but I sometimes wish they’d slow down a bit and ship actually thought out and finished features.

And most of the above already had alternatives previously, this isn’t even getting into wholly new things like Sentis, if you are working on an old project thankfully it will mostly keep working, but if you need to keep up to date with the current mechanisms and practices, there’s a lot of churn.

Maybe not as much as in Godot, but to be honest that other engine is going through a lot of evolution so instability and a feature explosion is to be expected (despite terrain still being a plugin, while Unity’s own terrain implementation is oddly dated and abandoned, while their water system felt like a tech demo and more often than not the asset store is expected to do the heavy lifting), while Unity tries to appeal to everyone and capture headlines it seems. Just look at the marketing around DOTS (and how long it took for it to be usable).

Cities Skylines II is such an immense resource hog compared to what it actually does.

I haven't read the patch notes, so I may be wrong, but they probably don't upgrade the engine across any major versions? The developers just load up an old version of Unity to work in.

See Satisfactory for how much of a pain it can be to actually go through major versions, and how long it can take a more complex game.

Although, I will say that newer versions have made it a lot less annoying to keep up to date.

One thing that isn't really mentioned but hugely important is the tooling - even if you can wire up various libraries for the subsystems of a game, you need tools for actually building the game. Stuff like an asset pipeline to ingest the numerous formats for different assets, optimise them for various use cases, a level editor, light mapping tools, etc. Those you can't get off the shelf, and make a huge difference when actually building gameplay and iterating.

In terms of wiring up various libraries, it's more difficult than it might sound initially because they all need to interact together, it's not so simple as just wiring up a few API calls together like you might do to build a web server.

Now of course CS 1.6 is built on the GoldSrc engine, which spawned from the Quake engine. Very different from modern engines, so obviously you can do it without Unity or Unreal or Godot. The question is if you want to, and if the time spent doing so is worth it.

People can and do build on top of Quake, so that could be a reasonable option if that's the feel you want for your game.

You technically can, but you really shouldn't. The general knowledge is that you can make a game or you can make an engine - not both.

There's just so much you don't know until you do, and there's a reason even all those "render engine" libraries have fallen kinda defunct (Ogre, Irlicht, etc). It's hard and distracts from the real goal.

Just grab an engine and get started on the game day 1 with a tool that can guarantee any game can be made with studio-quality tooling and compatibility.

It's the same reason you grab a date time library. It sure seems totally doable to "just handle times" right up until you try.

If making an engine was really that easy, studios wouldn't pay tens of millions to avoid doing it. Godot 3D would be solved by now.

You don't need it, but as someone who has been there: For me making a 3D engine is a lot of fun! But then I never finish the actual game. So if you actually want to ship a game, I recommend using an engine. Personally I prefer Unreal.

For 2D, yeah, making the engine yourself is fast and easy. Can go without a big engine.

Do you want to make a game, or do you want to make a rendering pipeline and level editor and asset manager?

You can definitely do that, and it's really not too bad.

Grab SDL or Qt (underrated; gets you a nice menu and HUD layer) for windowing/input, basic event loop, etc.

Write a renderer, e.g. on top of wgpu or bgfx depending on how much scaffolding you want to have to write yourself.

OpenAL Soft for audio.

Jolt or Bullet for physics.

A good scene/world model as the backbone, and ways to efficiently mutate and propagate state. You can pick up an ECS lib for this, or just go custom and hand-wring your data structures, mutation journals, caches, what have you. Your scene model feeds into (and interacts with) collision/physics, audio (listener/sound sources), your renderer for viz, etc..

For gameplay a nice approach is some fundamentals in native code (e.g. triggers and actions) and then a scripting bridge.

The problem is basically that doing a good job requires a substantial amount of experience on several levels of being a dev: Good architectural knowledge (incl. state of the art, historical examples, trade offs), lots of domain-specific techniques (rendering, stepping, etc.), solid systems engineering (good platform/shell abstraction, OS/platform integration bits, debugging/logging/tracing infra), being handg with algorithmic work, performance/optimization-minded work, and so on and so forth. It takes probably at least a solid decade before you can knock this out without tripping up or needing a lot of endurance.

Oh, and on top of all of that don't forget to design an actually fun game.

You might be interested in Bevy, which is a modular open source game engine. You can choose how much of the engine you use and just not import the parts you don't want.

It is however built in rust, not c++, don't know if that's a deal breaker?

The game is a 2D orbital physics game that's so simple it could opt for hand-rolled physics. I'm curious what about the article makes you wonder this?

I'm going to "partially" side with the author on this one, but with a big caveat: a lot of displays simply don't get dark enough to make light mode palatable, especially in low light conditions.

With high quality displays that have good contrast and backlight controls that go "really far down", I prefer light mode UIs nowadays.

But, only a few of my displays can dim enough to make it work in dark(er) rooms. CRTs were great at this, with the brightness control for the raster. LCDs generally aren't, though the fancy "FALD" backlight in my macbook pro does get dark enough to make light mode work well in dim spaces.

I started using light mode more often once I learned about the automatic brightness feature on my monitor.

I suspect that changes in ambient lighting over time are what drive most people to max out their backlight and use dark mode. It generally works in all conditions.

I’ll fight. Dark theme isn’t just a UI preference. It’s an accessibility tool. I have a degenerative eye condition that has progressed to the point where I literally cannot use a black on white display

So I use dark reader on web and get creative with apps that think dark mode is dumb.

People use dark mode because they think its cool and haxxor like Tactical Knives sell more than regular Knives. The rest is window dressing.

I miss the golden age of blogs.

Hi there! I'm Jack. I wrote this article and created Gun Rocket. I can add more on my particular point.

When Gun Rocket launched, it did ok (maybe $100s). It made me feel great, but nothing life-changing. Most of the money I made was selling the distribution rights to a publisher (low $1000s). Again made me feel good but nothing crazy. They made some changes like a splash screen ad that I did not like. When that contract term was up I focused on removing that garbage. Idk when the explosion bug was introduced, but the point is I was surprised and immensely frustrated when I found it because the history of this game left my care and came back.

I agree that this bug existing for a long time reflects terribly on me. I hope that fixing it late is better than never fixing it.