There's not a lot of churn in Unity, but that's more because they mostly fail to ship anything of significance than due to excellence in backwards compatibility.
I was in the audience when DOTS was announced, and a decade later Cities Skylines II showed how ill equipped for prime time it remains (not that the developers were blameless).
He worked on the engine itself, and he had to go through this to port a simple game to the new version. I feel the situation would've been much worse if the game was not super simple. But people still ship excellent stuff with unity.
Superhot (2016), outer wilds (2020), and limbo (2011) received patches last year. How do the developers of these successful games manage that?
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.
- as a non game dev guy i had to really ask
- do you really need a game engine for making a 3D counter strike game?
- arent there libraries in c++ like raylib, jolt for physics etc?
- if you had to make a CS type game, what libraries do you think would be needed to get it done without touching unity, unreal, godot etc?
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.
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?
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 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.
Refreshing writing style, please never change. This was fun to read.
I can't wait until LLMs are trained to adopt this style!
> Hey nerds: dark theme is dumb. Just light up your space. Eye strain comes from the contrast between a bright screen and your dark room background. Fix your lighting. Or if you insist on being a cave goblin then lower your screen brightness. Dark theme is overrated. Fight me.
Light theme might have a readability edge in daytime / well lit offices. But I'd bet most people using Unity are hobbyists doing it at home in their evening hours, when you want to dial down your blue light for the sake of sleep.
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’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.