[quote name='ATC' timestamp='1349713868' post='4988031']
I will have to disagree with the notion that one should NEVER write an engine... Tell that to the developers of Unity, Unreal, etc...

They would probably agree as all of them started off life as a game only to late end up being pulled apart as a reusable engine...

Whic is the point that every 'do not write an engine' point has; you write a game, you learn how to put something together, you pull out the bits you want for your NEXT game and repeat... over time, with refactoring an change, an engine forms.

Having little test demos or complex scenes is not the same thing; we had those, but the in-house engine developed by experianced people wasn't any good when it ran head first into a REAL game.
[/quote]

Ok, we're on the same level here

There are indeed articles going around which are quite harsh against the idea of writing an engine, but I believe those articles are mostly aimed at exactly those people who need to scour the internet for a tutorial or guidebook on how to build one. If you are comfortable with all the required concepts to build advanced games or an engine, and if you have a desire to actually build one then you should by all means build one.

Agreed! XD

And I would suggest to the OP that he/she does not try to "start making an engine"... asking that question in that way sort of suggests the OP hasn't written enough games to know what goes into an engine, how and why...

[quote name='phantom']
They would probably agree as all of them started off life as a game only to late end up being pulled apart as a reusable engine...
Whic is the point that every 'do not write an engine' point has; you write a game, you learn how to put something together, you pull out the bits you want for your NEXT game and repeat... over time, with refactoring an change, an engine forms.
Having little test demos or complex scenes is not the same thing; we had those, but the in-house engine developed by experianced people wasn't any good when it ran head first into a REAL game.
[/quote]

More or less agreed here as well... The way I've come up with around 60-70% of my engine's code is by stripping down games, applications, samples and tech demos of all sorts and varieties and taking out only those things common to virtually all games. About 5-10% comes from inspiration by other engines. The rest is improvised to tie things together and improve things continuously. But I totally revamp all things to be more portable, flexible, robust and faster. On top of that the engine offers a fully-hosted environment in which games, simulations and applications can be run. Developing a game with this engine is a pretty easy and smooth process... at the "boiler-plate" and lower-levels of things a game/app is backed by very good, clean and fast code that has been tested a thousand times over in the past 5 years. Basically, our engine was born from the compounded result of many endeavors; flight simulators, shooters, 2D games, RPGs, tech demos, samples, business applications, etc...

Write games; not engines.

If you are going to write an engine, write it on a per-module basis, not as a whole big chunk. Do a rendering component, an asset management component, the architecture for the game etc etc separately and merge them. This way you have more reusable code as each component/utility is specific to itself. 'Black boxed'

This also makes it easier to throw stuff out or change it. Being able to throw bits away & keep the good stuff is part of a re-iterative process of building a good engine over a series of game projects.

[font=lucida sans unicode,lucida grande,sans-serif]Enough[/font] of the “write games, not engines” mantra.

4 words do not express the idea correctly. It is an over-simplification of a fairly complex subject and is extremely misleading.
I have seen people on here who look at this overly simple mantra and have gotten the impression that writing engines is to be absolutely avoided.
He isn’t the only one, and the first reply by Ravyne supports my current point exactly.

The content of the original article is mostly fine.
But the title was a horrible choice of words and an absolute disservice the actual idea that was trying to be portrayed.
Every time you repeat that horrible choice of words a kitten dies.


That mantra has done nothing but confuse people or in the very least lead them off track.

If I am going to make a 3D game, it’s obvious I will need a 3D file format and 3D graphics rendering pipeline for that format.
I will need an animation system with skinning support.
It is obvious that I will need a sound engine for any game I make.
Most 3D games are indoors, outdoors, or both, so it’s obvious that I will either need a terrain library or building/indoors library, if not on this project then on the next.
All games should be broken into states, and should have some kind of scene manager to manage all the objects in the scene.
And most 3D games have some amount of physics.

That is about an entire engine right there, and yet without having made anything resembling a game all of it is useful. Anything I know my game won’t use (terrain, for example), I don’t add.

This is the normal thought process of a normal human being.


Then someone comes along and says, “Make games, not engines.”
Normal human #1: “Huh? Was my planning all wrong up to this point? I should panic and try to think about how I can have all these features without them being considered an engine!”
Normal human #2: “Huh? Was my planning all wrong up to this point? This all seemed so logical. Then how is a game supposed to get made? I don’t see how to continue from here, since all of this made sense, but is apparently wrong.”


You are not helping anyone by saying, “Make games, not engines.”
Stop using catch-phrases and start explaining the concept, avoiding those 4 words as much as humanly possible. They sound catchy, but they don’t help. They hurt. They only hurt. They do no good for anyone, and kittens die from them.


Do carefully note that I did not say the concept was wrong. I said those words are wrong. And they are. They misrepresent the concept and they mislead people.
Enough already. It was catchy 1 time 5 years ago. Let it die.
If you want to help people, explain the concept, omit the mantra.


L. Spiro

Sorry Spiro, I was trying to get the concept of building utilities for a game rather than building a game or an engine across, but I clearly didn't try hard enough. My failure. I'll remember to explain a bit more in depth in the future:

my mantra is make utilities: figure out what you need, write some specifications, extremely specific ones, as in separating different grain sizes of sand specific, for how you need it to work to best optimise your development process as well as to reduce as much risk as possible, then search for off the shelf solutions that meet your requirements, failing to find such write a solution yourself. Exactly as how spiro described getting a list of what you need and then working on those. My further recommendation is to, if you don't have existing tech to use, then aim to create the tech to support a small and simple game. And with each new game you make you build/find/implement more utilities so you can increase the scope of what you can do.

2D renderer + asset loading + architecture + audio handler = GAME[ 1 ]
2D renderer + asset loading + architecture + audio handler + better tools = GAME[ 2 ]
2D renderer + asset loading + architecture + audio handler + better tools + social connectivity = GAME[ 3 ]
3d renderer + skeletal animation + asset loading + physics + architecture + awesome tools + audio mixer + multiplayer = GAME[ n ]

And so forth.

@L. Spiro:

I admit that the "make games, not engines" rule can be confusing to those not familiar with game development and that it could be phrased a lot better, but you start your reasoning with the sentence "If I'm going to make a 3D game", but in threads like these the OP starts his/her reasoning with "I want to make an engine so I can maybe create a game later".

In this situation the "make games, not engines" quote makes more sense as it encourages one to look at their development process based off the features their game should have, not which features might be cool to have in an engine which a game might use later on (that strategy just has "failure" written all over it)

But again, you are completely right in that it may come over as confusing to those who are actually building an engine-like structure as a base for a game, and we should try to phrase it better to avoid this confusion.

If you are going to write an engine, write it on a per-module basis, not as a whole big chunk.

If one is going to write an engine I second the idea that one should NOT create a huge, monolithic engine... I give Kyall a +1 for that mere sentence because it is an incredibly important point. Monolithic monster designs are nearly impossible to maintain, re-version, port and work with. And they are also bloated/bulky and tend to be slow and buggy to boot. It is simply bad software design...

As Kyall said, an engine should be development from "components"... stand-alone (or nearly stand-alone) modules of functionality (e.g., a rendering component, an audio component, a content component, etc). These components should be completely decoupled or have very loose coupling; at most you should only be coupled with the exposed interfaces of other components (NOT their inner implementations) where dependency is unavoidable. Sometimes dependency IS unavoidable... for example, several engine components may need access to a "core" component which defines essential data types (e.g., Vector2/3/4, Quaternion, Matrix, etc) and functionality (e.g., a "DisposableObject" implementation, smart pointers, whatever). If you do things this way not only will your engine be a breeze to maintain but it will be very easy to extend, mod and edit. Furthermore, developers using your engine can choose what components they need for their game and have no need to deploy huge sets of unnecessary libraries and such... a complex video game, for example, may require all of the components. But a financial charting application may only need the rendering and audio components... those developers will be thanking you when they don't have the hassle of dealing with a huge, monolithic engine full of unneeded components (some of which could be a major liability).

But now you're probably thinking, "What about engines like Unity and Unreal which seem to be one large unit of software with all features present?" A good question. And the answer is even sweeter. To create such an engine all you then need to do is create an "Application Layer" component which hosts games and ties all/some of the engine's critical components together.