So, you want to make a game engine (2023)
lisyarus.github.io
lisyarus.github.io
Windows is not a game engine. Being able to play games on Windows doesn't make it a game engine.
Windows is a game engine because you can write standard games for it, standardly, and its base SDK’s support game development, natively - it also of course supports other game engines, which eventually become capable of hosting applications (and are thus OS’s), because: Windows is an OS and it is a game engine…
This isn't the definition of an OS, it's the definition of literally all software - a "system" upon which "operations" are performed.
But the purpose of Unreal Engine isn't to manage a computer's hardware and software resources, user access, etc. It isn't an operating system. It doesn't operate the system. An operating system hosted by an OS still serves the purpose of an operating system. The actual purpose of the software matters.
>Windows is a game engine because you can write standard games for it, standardly, and its base SDK’s support game development, natively - it also of course supports other game engines, which eventually become capable of hosting applications (and are thus OS’s), because: Windows is an OS and it is a game engine…
Windows is not a game engine because its purpose is not creating games. The fact that it can run applications, some of which may happen to be game engines, does not make it a game engine. The fact that it has graphics and sound APIs that game engines can access doesn't make it a game engine.
Sorry, I don't find this profound or interesting. Windows has not become a game engine, and Unreal has not become an operating system. Your argument basically boils down to semantics and only makes sense if you ignore the actual context and purpose of what we're talking about and why the distinctions matter.
Indeed, that is the point entirely. The distinction is arbitrary.
> But the purpose of Unreal Engine isn't to manage a computer's hardware and software resources, user access, etc.
Oh no, that is absolutely the purpose of Unreal Engine - to manager the computers available hardware, software resources, user permissions in such a way that - across a very wide variety of different hardware configurations - the hosted applications run standardly and consistently.
That it fulfills this purpose as a system of operating hardware resources in order to provide standard game applications their own hosting surface, across a wider variety of host OS’s, demonstrates that in fact, an OS does not become an OS just because it is the first thing to boot the hardware.
By that reasoning, the BIOS is an operating system and Windows is just an application which runs on it, with a very large percentage of users doing so only to play games …
> Windows is not a game engine because its purpose is not creating games.
I think there is a billion dollar department at Microsoft with is at odds with your view entirely. Microsoft has spent a lot of resources making Windows into a game engine which can fulfill the purpose.
> Sorry, I don't find this profound or interesting
Give it time. You will see the fallacy in your arbitrary definitions.
> Semantics
Actually, I’m arguing from a great deal of experience as a systems analyst.
Nowadays I have the urge to combine a physics engine, rendering engine, ecs engine to develop my own game which I guess I'll quit in the middle.
As developers I believe we should limit ourselves from doomcoding.
Once I tried to create my own front-end framework from scratch. I created signal library, mounting/unmouting, context etc but never able to write v-dom diffing or using existing vdom libraries.
Then I decided just implement my API on top of Preact. Preact did vdom-diffing for me and mounting/unmounting which was enough for my need.
The final project looked nothing like Preact, it even had it's own context system, data loading, signals, setup + render and context which just hooks itself into Preact Context but taught me a lot about how a front-end framework work.
That said, it's still a worthwhile exercise that one can learn a lot from.
Do we want money or do we want to get the pleasure of being an engineer and make money as a side quest?
There was a video of tsoding about why he doesn't have a job, he says "when I have enough money for my needs I just go into coding instead of working". I like his vision. He likes coding for the sake of programming and earns money as a side quest.
That's a big reason I like developing games with frameworks. It allows reusibility and access to clever code, while still remaining flexible enough to support weird mechanics.
Starting from a checklist of features for a game engine almost always ends in wasted effort
I have worked briefly in the game industry long ago (not in engine teams though) and ended up writing a few engines for myself after leaving, a couple quite complete.
It’s just a hobby like another. I have zero interest in writing a full game on top of it, or even publishing it.
But do you know who NEVER gives me grief about it? People I know who work at Unity or [previous employer] writing AAA engines.
My last monstrosity is a Rust one with zero dependencies other than the std-lib/OS, Metal/DX12/Vulkan, its own physics engine, spatial audio, vm for scripting and other stuff. I will probably do nothing with it other than having updated my skills in a lot of areas.
I wanted to make a game, and had an idea, but then I thought "why not making a game framework so I make my game". It was fun to build a game framework by mixing PixiJS, Rapier2D, ECS, writing my own loop logic and state management but then I lost the motivation. I just coded a framework for pleasure but at the start my point was making a game.
The desire to build something can cause our idea to be dropped.
IF you want to make a game engine, building one is progress
If you want to make a game, building a game engine is the illusion of progress. When you're done making the engine you'll be no further along on your game than if you'd used an existing engine. Usually you'll be behind because those other engines have so many features and tools that you have yet to implement. Sure, you don't need every feature, but you may be surprised at all of the little things you end up having to write.
That said, despite making a bunch of demos[2][3][4][5] since 2021 when i made the game, i never made any game using it after that as i always lose interest - perhaps i do need to be making an engine from scratch to keep myself interested :-P.
[0] http://runtimeterror.com/tech/petra/ (note the version is very old and i've made a lot of improvements since then - this includes the Codeberg repository which i'll move somewhere else at some point)
[1] https://bad-sector.itch.io/post-apocalyptic-petra
[2] http://runtimeterror.com/pages/iv/images/44d7537fb719e00fdcd...
[3] http://runtimeterror.com/pages/iv/images/d22ff83dd5e5109e02e...
[4] http://runtimeterror.com/pages/iv/images/1da6a4bce430a8d8507...
you're not the only one. jonathan blow has made tons of money selling games and also needs to write a whole programming language for 100h to keep him interested enough to yield 1h of content.
i can't really say much about the people who say don't program game engines (or whatever thing they don't like) in terms of opportunity costs (a generous name for this category of complaining), other than they would be bad at both making art and making money.
What a ridiculous take. Making a game engine is to games like building a camera is to making movies. Once a blue moon some new camera enables some new technique (the Matirx), but mostly people just use the tools that exist.
The same is true in games. Tons of super popular and successful games didn't write their own game engine and made both art and money.
I'm watching a friend, claiming he wants to make a game company, burn through all of this money instead making a game engine. If he succeeds, great! But I suspect he'll just run out of money before he's even started working on a game. If it was fun to make, great too. But I think he'll look back on it as throwing away an oppotunity.
Been there, done that, didn't regret a thing since i'm certain i'd have given up way earlier (assuming i'd ever bother starting) if i had to use an existing engine :-P.
(ok, i never had money to "make a game company", the most money i ever had was to be able to spend ~2 years living frugally while making my own stuff, but it is close enough since i think someone could say i should have used some existing engine instead - which is true, except i'd hate doing that)
There are people who want to make games, people who want to make engines and, perhaps a minority, people who want to make games and engines :-P.
(though FWIW in my case i never felt the tech side was much of a limitation, it is art/content that ends up being the bottleneck and makes everything crawl down and the stuff i like to do aren't the kind of stuff you could do with procgen, minimalistic styles or other similar approaches for saving on the art/content side)
From developers this is how in-house frameworks work, that are mostly reusing other frameworks and libraries and create a sort of pseudo DSL.
To me a game engine includes UI elements that package the entire process of game development into a coherent application. Sprite editors, code editors, asset management, physics, all in a neat package. Bonus points I guess for coming up with a quirky bespoke internal scripting language that only gets used with that engine. You can wind up with a utility library that makes writing games easier but to me that still isn't a "game engine" per se.
And I think that's the really difficult part. Everyone probably just uses DearImGUI anyway but that's still an entire layer of abstraction and difficulty on top of writing the game utility code itself, and it encompasses things most developers won't find fun or interesting or even may not know how to do. How do you support multiple platforms? How do you deal with data files? How do you import and export a project? Handle input? Sound? You got a triangle on screen? Great! Now you have to implement the rest of the universe - textures, lighting, UV mapping, shaders, models, skeletons, rigging, animations. Now do physics. Every single aspect of engine design is an entire discipline unto itself.
Of course it also matters how specifically tailored and non-general you want to make an engine. Engines exist just for making RPGs or visual novels. But even then, to me, it isn't an "engine" unless it's packaged into a GUI with coherent design principles.
[1] Why D Programming Language?
https://www.youtube.com/watch?v=teWQbYvPBTg
[2] Art of Reflection:
https://store.steampowered.com/app/2290770/The_Art_of_Reflec...
It helps you build a full ray tracer / 3D engine only guided with tests, really powerful to learn test driven development.
What s cool is that just being driven with tests still allows you to do it in any language you want.
Plus you ll learn a quintillion of stuff about mathematics. This is really the kind of project that makes you go to a real senior SWE
Unless there is absolutely no abstraction, e.g.: with OpenGL being called from random parts of the game, porting is a matter of mostly gluing two interfaces together.
For example, one of my recent games has 20k lines of engine code and 40k lines of game code.