Hacker News new | past | comments | ask | show | jobs | submit login

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.


It is closer in analogy to making your own gear cutters. If you know how, you can make any gear you want.

If you have a gear hobbing machine, you can only make standardized gears and the only thing you can influence is the size of the gear.


>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 concept of an engine separate from the game is the distraction and didn’t exist when most games we love were made.

Just start on your games. What feature does it need next? Ok now write that.

You don’t need an FBX skeleton parser. You need a header with vertices in it.

This give you very high velocity iteration, without the engine imposing creative constraints.

The final product is tight, efficient, and will last forever.


You can find examples of game engines going back into the 80s. It's not a particularly new concept.


Got any examples? I think the term has been applied retroactively to “we copy pasted our work from our last game to start”.

Quake and perhaps doom popularized selling game technology and even quake engine was tailor made for the game, not general purpose.


A quick google for yourself will take you a long way. You may want to consider researching your claims first going forward.


Ok, I tried it:

> 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?

https://en.m.wikipedia.org/wiki/Game_engine


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

Also in the Adventure Game space:

https://en.wikipedia.org/wiki/SCUMM

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.

https://en.wikipedia.org/wiki/Multi-user_dungeon#Wider_acces...

https://mud.co.uk/richard/DesigningVirtualWorlds.pdf

Bartle's own words:

> 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.


Is this your alt account? I am done participating in bad faith discussion. Goodbye.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: