I know this will get downvoted. I fully agree that if you want to make a game-engine then make one. It's fun! On the other hand, if you want to make a game, use an existing engine.
Analogies: I want to write a novel so I'll first build a typewriter. I want to film a movie so I'll first build a camera and digital editing software. I want to cook food so I'll first build a stove, pots, pans, and knives.
In all those other examples it hopefully clear, you just buy the tools you need and then make the thing the tools allow you to make. At this point, the same is true in games.
If you like making a game engine than make one. Just like if you like making knives or cameras then make them. But, making a knife is not cooking, making a camera is not making a movie, and making a game-engine is not making a game.
I also want to add, making a game-engine is easy compared to making a game. Why? Because all the things to you need are well known. You need a 2d renderer (UI), a 3d renderer (assuming you need 3d), image loaders, model loaders, sound players, music players, keyboard input, joypad input, entity systems. Etc. You build them and it seems like you're making progress and if your goal is to make a game-engine, then you are making progress. But, if your goal is to make game, you're mostly likely fooling yourself that you're making progress. Again, back to the analogies, if you're making a knife, you aren't making progress on cooking, your making progress on making a knife. If your making a camera, you aren't making progress on making a movie, you're making progress on making a camera.
What makes making a game harder than a game-engine is the list things to do for a game is unknown.
I think making a game engine is less like making your own knives and more like having a herb garden at a restaurant.
There are some games that are just not possible using someone else's engine. Consider Factorio, non-Euclidean geometry, the early MMOs, or anything else which pushes the boundaries of what's possible. On the other hand...are you really making a game like that? Similarly, there are good reasons why you'd want to grow your own herbs, and the deep knowledge of growing conditions really does add to your ability to understand why your parsley is bitter this year, but for most restaurants it wouldn't pay off.
>I also want to add, making a game-engine is easy compared to making a game. Why? Because all the things to you need are well known. You need a 2d renderer (UI), a 3d renderer (assuming you need 3d), image loaders, model loaders, sound players, music players, keyboard input, joypad input, entity systems.
That's also a benfit for if you want to break into the industry. There's a ton of gameplay positions, but a lot less people who want to work with the tooling or the tech art or sound engineering. So that's another thing to keep in mind if you are choosing a direction.
I say no matter what you choose though, you stick with it. chasing two rabbits and all that.
> The term "game engine" arose in the mid-1990s, especially in connection with 3D games such as first-person shooters with a first-person shooter engine.
> Such was the popularity of Id Software's Doom and Quake games that, rather than work from scratch, other developers licensed the core portions of the software
Want to correct any of your comments? Or make any other personal accusations?
Don't know what he wanted to talk about, but here's one I remembered off hand:
https://en.wikipedia.org/wiki/Z-machine
All the old Infocom games were ported to this Engine and its existence is why they're so wonderfully well preserved nowadays and can be played in a really playable form with Frotz
The oriignal MUD was an engine, and there are hundreds of derivatives of MUD that are also engines, I recommend Richard Bartle's book for a really good history of it, I think it's free online.
> MUD was programmed in MACRO-10 assembler on a
DecSystem-10 mainframe at Essex University, England, in the
fall of 1978. Its author was a talented Computer Science
undergraduate, Roy Trubshaw. Version I was a simple test
program to establish the basic principles by which a shared
world could be maintained. When it worked, Roy immediately
started on version II, a text-based virtual world that would be instantly recognizable as such even today. It was also written in MACRO-10, a decision that led to its becoming increasingly unwieldy as more and more features were added. Because of this, in the fall of 1979 Roy made the decision to begin work on version III of the game. He split it in two: The game engine was written in BCPL (the fore-runner of C); the game world was written in a language of his own devising, MUDDL (Multi-User Dungeon Definition Language). The idea was that multiple worlds could be constructed in UDDL but would run on the same, unmodified engine (which was effectively an interpreter).
Not only is it clearly the same content generation process as modern engines, he even called it an engine. (this book is from 2005 IIRC but I think it's mostly a moot point what they're named)
PLATO:
> There had been graphical virtual worlds before.
The seminal PLATO (Programmed Logic for Automatic
Teaching Operations) system went live at the University of
Illinois way back in 1961, and many games were written to take
advantage of both its network connectivity and graphics-
capable plasma display units. Some of these laid down principles
that would greatly influence the development of later computer
games; some came close to being virtual worlds; some actually
were virtual worlds.
Orthanc, by Paul Resch, Larry Kemp, and Eric Hagstrom, was an
overhead-view graphical game that, although not implementing
a shared world, nevertheless allowed communication between
individual players. It was written as early as 1973. Jim
Schwaiger’s 1977 game Oubliette (inspired by Dungeons &
Dragons and Chuck Miller’s earlier multiplayer game, Mines of
Moria) had a first-person point of view and used line graphics to
render the scene ahead. It had persistent characters, but was
not a persistent world. Also, the interaction it allowed between
characters was very limited; it was almost there, but not quite.
In late 1979, the first ever fully-functional graphical virtual
world was released: Avatar. Written by a group of students to
out-do Oubliette, it was to become the most successful PLATO
game ever—it accounted for 6% of all the hours spent on the
system between September 1978 and May 198517. Again using a
Fantasy setting, it introduced the concept of spawning to
repopulate areas automatically after players killed all the
monsters.
Although it is charted territory it’s very difficult. There is an extraordinary amount of concepts (depending on what you’re doing) and some are quite mathy. And software design seems pretty important, although I am not far enough along that it’s an issue.
Analogies: I want to write a novel so I'll first build a typewriter. I want to film a movie so I'll first build a camera and digital editing software. I want to cook food so I'll first build a stove, pots, pans, and knives.
In all those other examples it hopefully clear, you just buy the tools you need and then make the thing the tools allow you to make. At this point, the same is true in games.
If you like making a game engine than make one. Just like if you like making knives or cameras then make them. But, making a knife is not cooking, making a camera is not making a movie, and making a game-engine is not making a game.
I also want to add, making a game-engine is easy compared to making a game. Why? Because all the things to you need are well known. You need a 2d renderer (UI), a 3d renderer (assuming you need 3d), image loaders, model loaders, sound players, music players, keyboard input, joypad input, entity systems. Etc. You build them and it seems like you're making progress and if your goal is to make a game-engine, then you are making progress. But, if your goal is to make game, you're mostly likely fooling yourself that you're making progress. Again, back to the analogies, if you're making a knife, you aren't making progress on cooking, your making progress on making a knife. If your making a camera, you aren't making progress on making a movie, you're making progress on making a camera.
What makes making a game harder than a game-engine is the list things to do for a game is unknown.