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

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.

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?

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.

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.

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.