Write Games, Not Engines

I think the primary point the article was trying to make, and Josh can come along and correct me if he likes, is that its far too easy to get bogged down with creating your perfect, infinitely extensible game engine; so much so that, well, you never get around to actually writing the game. The second point, is that it takes a good deal of experience to write an engine, because until you've written several games, you haven't written enough code to find the common threads, let alone to extrapolate those threads into new technology for a game that's not even properly designed yet. Its like taking a hike with no map or compass, and assuming the path you've chosen will take you to your desired destination.

The article does not expressly say "Don't use an engine", nor does it advise you to "never write an engine". Its really advising you to have the humility to recognize when you are not yet ready to write an engine up-front, and to be sure of the requirements of your game and that you are writing code to fit the game, rather than writing some misshapen code and then trying to shoehorn your game into it.

Go ahead and use an engine if you like, exposure to an established engine will be enlightening -- though be careful to view it realistically. Every engine has things it does well, and things it does not so well. Under no circumstances should you take an engine like, say, OGRE or even a commercial engine like Unreal Engine 3, and assume its construction is doctrine.

Quote:

Original post by m3rk I want to make games also here but I also want to make an engine so I can use it to create my next game.

The idea behind that article is that simply writing a game, produces and engine anyway - you don't need to "write and engine" because if you write a game, you get an engine for free. The first game you write will need a menu, a way to get from that into the game, a way to render 3D models and play sounds for example.

So you have scenes and scene management, resource management and use in there. Thats an engine :) Sure it might be a simple one with 4 classes but if thats all you need then bham your done. Maybe copy it into a /src/Engine/ sub directory so you know never to put game specific code into any file in that directory. Next game just cut+paste /engine/ and your good to go.

Next game you start you'll have so much code already there -> that IS your engine. Engines are NOT something mythical or magical, its just a set of source code that does what you want which you can reuse.

Writing a Game Engine is definitely a large undertaking, and definitely a task more people fail at than succeed at.
But it is also a great learning experience, if a long path to success....

I would hazzard that most of the now very successful and long lived engines have come out of the quagmire of finding and solving problems for an original game concept they were used for. If you take a close look at their history you'll see that the owners / designers of those engines are often the ones leading trends, and the people who license them are often stuck one iteration behind, often having to augment the engines to get what they need.

Personally I have not found a game engine yet that does everything I need.
I have also never been entirely happy with any engine I have produced.

If you have the time then I would always suggest having a go yourself.
But if you are producing something that fits the kind of game produced with a particular engine that is available to you, then why not take advantage of that? YOU can always augment that engine with specific modules you require.

However, with most of the cheap and readily accessible engines out there. Torque, Unity, etc. etc. I have always found that learning to use them, and adapting to their methods takes almost as long as writing those things yourself. And you are then stuck with those methods forever, often not fully understanding what's actually going on deep under the hood.
So if that is the case with you then perhaps you are ready to write your own.

Quote:

Original post by Ravyne I think the primary point the article was trying to make, and Josh can come along and correct me if he likes, is that...stuff

Yea, pretty much. The grand, overarching idea is, of course, the one get shit done. So certainly if the option exists to use an existing engine (either a full-spectrum game engine or something more specific, such as a rendering engine like Ogre), by all means, go ahead.

You can still build your own "engine" of reusable bits frameworks of code around something like Ogre just as well as you can build it around something like Direct3D, too.

So what should I do first? Create a game in OpenGL or use the Ogre3D/Irrlicht?

I think if you are making the first step from 2D to 3D you should just write a couple of simple games in DirectX or OpenGL to get used to the 3D stuff. Then you'll have an idea of what is going on under the hood.
After this if you want to progress onto bigger and better games (not neccasarily the same thing ;)) choose an off the shelf engine like Ogre, Torque or something similar.

On the other hand if you prefer to write an engine and arn't too interested about games go ahead and write one but, remember the chances of you being able to produce something better than a dedicated middleware company are very slim.
Even AAA games companies think twice now before developing in house tech as the cost in man hours to create an engine will likely end up being more than licencing an off the shelf solution.

well, this is how it works for me. I began writing a little demo, in which I fly with camera and look at 3d models. This is few lines of code for the exe, but 1000 of lines for the rendering engine. My 3d models I fly around then got textures, illumination, animating, so I could fly around bones animated meshes, hierarchical transformtions... number of lines in exe stayed, like 20 lines, but engine? 2000 lines. That is becouse I use so called "exact" functions, like I mean LoadMeshFromFile(char* filename), but before you code an "exact function" be sure that the exact function will not contain sharp code, but a bunch of another function calls, like for mentioned function it would be FillIndexBuffer(), FillVertexBuffer, AddTexture(), SetAnimationData(), CreateAnimator().... I simply code in a way that when I come to a need of a functionality, I code an exact function for it. But I have functions to retrieve any data, and function to set any data.I simply put all rendering functionality in rendering engine. Rendering is a very important part of game becouse it needs to communicate with every aspect of game: player actions, AI actions... and so on. So you need to be able to alter your rendered data as well as read render data. A bridge between rendering and other parts of game functionality is Scene. Scene is not only for having rendered data in memory, scene is a mirror for physiscs engine, game engine, simply all engines meets themself in a scene. So if you now how to code a scene, and have an understanding of functionality-data binding to libraries and codinf of exact functions, you will result in a game exe like this :

My father told me once, that if I wanted to become programmer, there will eventually be a time where I will ask myself, with the team I am working on, if we are to use an existing game engine or create our own. Well, he told me that to create a new one was a bad idea: creating a new engine is time consuming and expensive, where this money could be spent to buy licences and the time to design and create the game. Also, he told me that if I wanted to create a 3D engine, I should do it now, when I'm still studying, not working in a professionnal area.

This is what I suggest you to do : make games, when you want to try something new, make the engine. That's what I would do and that's what I will certainly do in a near future.

Quote:

Original post by m3rk Now, my question is. Should I use a game engine to create games? If I'll create a game and use a game engine, I can't reusing it's functionality because that's for the only specific engine that I've use. So in the end, I didn't make an engine at all. (...) Now I moved to 3D. I want to make games also here but I also want to make an engine so I can use it to create my next game.

If you use an existing engine, you don't need to write your own - because you can use that same engine for your next game too. What's the problem here? :)

A "Game Engine" is just a fancy word for a framework of re-usable code that saves you time. It's never "finished", and always evolving. Even AAA studios make many changes to their in-house or licensed engines. They don't just buy, or build an engine, and then make X number of games with it, without changing it, or updating it. Technology and techniques advance, and so should your own framework.

Start it small, keep it modular and extensible, and build it up over time. Eventually you'll have enough re-usable code to make flexible sub-systems that have passed "trial by fire" by being used in multiple games. That's extremely important, and it's why the big engines have so many licensees -- they've been proven to work.

So while you shouldn't set out to "write an engine", you should actively be re-using your code, and building up your framework of helper functions, utilities, tools, algorithms and sub-systems. You'll eventually end up with something you could call a Game Engine.

[Edited by - ThrustGoblin on February 17, 2009 7:17:32 PM]

Well, care must be taken when someone is writting a game in order to get an engine for free, because someone could write a "hardcoded game" by accident, with no reusability in mind.

Well, care must be taken when someone is writting a game in order to get an engine for free, because someone could write a "hardcoded game" by accident, with no reusability in mind.

Refactoring - if you're an agile developer you're probably doing it anyway many times while developing, and it becomes the step that turns the meat of your asteroids clone into the engine for your breakout clone.

Two-year-old thread; closing. Best to just start a new thread if you have something new to say.