Engines: Discuss.
Author
I've been making games for a while, and I've wondered... what do people actually mean when they talk about game engines?
I just read a topic about someone trying to pick an engine for a 6DoF game, and I wondered why people always like to use existing engines... simple games, at least, aren't really built around an engine.
My earliest games weren't really engine-oriented. They were just a series of commands and calls that were executed each frame. A lot of people though seem to start their game design 'careers' wondering "what engine should I use?"
I'm just looking for opinions. If you've got something to say about engines, what they are, why making engines has become so popular, or whether or not they are even needed, say it. Also, if this is in the wrong forum, say so and possibly move it.
People usually refer to a game engine as a code library that factors out redundant code from games, though this is a loose and possibly wrong interpretation (I forget where i read this, or I would link the source *edit* lol, thanks rip-off, thats the one, but now that i reread it, I don't really agree with all its points).
For example most games need a renderer, a sound system, user input, some sort of cohesive structure (i.e. scene graph), etc... A game engine can/does provide these subsystems so that game developers can focus on design, game logic, and art instead of these lower level functions of a game.
Games don't absolutely need a game engine, and sometimes you need to build the core subsystems specifically for a game for it to be completely optimized, but this a lot of work of course. Simple games are quite easy to code procedurally, but when scenes/graphics become complex, you usually need something to organize the game world, or else it becomes a mess. Game engines often provide ways to remedy this through their renderer and scene graph, but a renderer and scene graph system is not an engine by itself.
To summarize, game engines takes a huge ammount of the work required to run a game away from the game developer. It hands this work in a nice great big package to crazier people who actually like programming more than creating games. Selecting/Building a game engine is a matter of the target genre, feature set, and compatability.
For example most games need a renderer, a sound system, user input, some sort of cohesive structure (i.e. scene graph), etc... A game engine can/does provide these subsystems so that game developers can focus on design, game logic, and art instead of these lower level functions of a game.
Games don't absolutely need a game engine, and sometimes you need to build the core subsystems specifically for a game for it to be completely optimized, but this a lot of work of course. Simple games are quite easy to code procedurally, but when scenes/graphics become complex, you usually need something to organize the game world, or else it becomes a mess. Game engines often provide ways to remedy this through their renderer and scene graph, but a renderer and scene graph system is not an engine by itself.
To summarize, game engines takes a huge ammount of the work required to run a game away from the game developer. It hands this work in a nice great big package to crazier people who actually like programming more than creating games. Selecting/Building a game engine is a matter of the target genre, feature set, and compatability.
I have a few cents to weigh into this conversation.
I am in the minority on this but i enjoy writing engines more than writing games.
That being said for the more complicated and larger scale a game is the more an engine is required.
Also if you plan on making a lot of similar games it just makes more since to be able to reuse the majority of your code than to start from scratch on the next game.
I wrote my on engine because one i learn a lot but more for the fact i have complete control over the license and structure of the engine code. I don't have to worry about making a FPS engine (for example) work for some type of game it was never designed for.
I am in the minority on this but i enjoy writing engines more than writing games.
That being said for the more complicated and larger scale a game is the more an engine is required.
Also if you plan on making a lot of similar games it just makes more since to be able to reuse the majority of your code than to start from scratch on the next game.
I wrote my on engine because one i learn a lot but more for the fact i have complete control over the license and structure of the engine code. I don't have to worry about making a FPS engine (for example) work for some type of game it was never designed for.
Quote:Original post by blackcloak
I wrote my on engine because one i learn a lot but more for the fact i have complete control over the license and structure of the engine code. I don't have to worry about making a FPS engine (for example) work for some type of game it was never designed for.
This is an oft-overlooked point. Understanding the way someone else was thinking when they wrote their engine is in many ways harder than writing an engine.
When you add up all the problems of supporting multiple platforms, APIs, dev-environments, etc. it becomes such a huge task that very few of the (mostly open-source) projects out there can stay on top of things. As an example, I spent several hours just trying to get a simple 'hello, world!' example to compile with the binary distro of OGRE (quite possibly the best supported free graphics engine) due to some obscure linker incompatibility with a dependant library. I don't see it as a poor reflection on the Ogre team, instead it is just impossible to test every possible configuration.
In your own engine, you usually know from the start the intended feature set, the platforms and compilers you must support, and you know your own coding conventions, all of which makes your life infinitely easier.
The only problem with writing an engine and then trying to bolt a game onto it is that this process can show major problems with the engine which were apprent in inital design/writing phase.
This is why the advice is generally; write game, factor out code you can reuse, write next game using this code and repeat.
Writing an engine without a game can also lead to Ogre; an engine which is HUGE because it has alot of 'might need' functionality in it (never mind the singletonitis which infects it at every turn...) and tries to be a jack of all trades.
While I'm all for code reuse there are times when it just seems daft.. and from my brief encounters with Ogre this is one of those times.
This is why the advice is generally; write game, factor out code you can reuse, write next game using this code and repeat.
Writing an engine without a game can also lead to Ogre; an engine which is HUGE because it has alot of 'might need' functionality in it (never mind the singletonitis which infects it at every turn...) and tries to be a jack of all trades.
While I'm all for code reuse there are times when it just seems daft.. and from my brief encounters with Ogre this is one of those times.
"Write libraries, not engines"?
To me, an engine is simply a stable integration of the diverse libraries precisely as required to implement a game of a particular genre (or with a particular complement of conventions). Yes, the word "simply" in there is misleading.
Making engines has become "popular" because engines have been commoditized as middleware in the professional industry, and a lot of marketing hype has been built around promoting said commodities. "Built on the Quake 2 engine!" "Built on Source!" "Using the next-generation Unreal Engine 3 technology!" Beginners think - and they're influenced by the consumer-oriented game journalism industry, which is filled with people who love games but actually have no idea how they're made (which is normal, really) - that engines are a necessity to make games, which simply isn't true.
Sorry, no. The effort to design, implement, test, debug, refactor and publish an engine of any value far outweighs the effort to download, read documentation for, write test programs on, and then employ an existing engine.
To me, an engine is simply a stable integration of the diverse libraries precisely as required to implement a game of a particular genre (or with a particular complement of conventions). Yes, the word "simply" in there is misleading.
Making engines has become "popular" because engines have been commoditized as middleware in the professional industry, and a lot of marketing hype has been built around promoting said commodities. "Built on the Quake 2 engine!" "Built on Source!" "Using the next-generation Unreal Engine 3 technology!" Beginners think - and they're influenced by the consumer-oriented game journalism industry, which is filled with people who love games but actually have no idea how they're made (which is normal, really) - that engines are a necessity to make games, which simply isn't true.
Quote:Original post by swiftcoder
This is an oft-overlooked point. Understanding the way someone else was thinking when they wrote their engine is in many ways harder than writing an engine.
Sorry, no. The effort to design, implement, test, debug, refactor and publish an engine of any value far outweighs the effort to download, read documentation for, write test programs on, and then employ an existing engine.
The biggest benefit that commercial 'game engines' provide lies really in their tools and pipelines and in the fact that a team can get *something* resembling a game up and running quickly at the start of a project and can then iterate on a working game. If you're a commercial developer looking to start work on a game that you want to ship in 1-2 years then you don't want to have a team of artists and designers sitting around unable to create content that can actually be tested on the target platform while you wait for your programmers to build the basic foundations of a game that will get you to the point of having animated models moving around on screen in response to player input.
Most commercial games that use an engine will modify it fairly extensively by the end of the project but what they have bought when they license the engine is the ability to hit the ground running with everyone on the team - programmers, artists and designers - able to see the results of their work on the target platform from very early in the project and to iterate on those results, rather than having to build everything in a vacuum for several months while the programmers lay the groundwork for a commercial quality game.
Most commercial games that use an engine will modify it fairly extensively by the end of the project but what they have bought when they license the engine is the ability to hit the ground running with everyone on the team - programmers, artists and designers - able to see the results of their work on the target platform from very early in the project and to iterate on those results, rather than having to build everything in a vacuum for several months while the programmers lay the groundwork for a commercial quality game.
Quote:Original post by OluseyiQuote:Original post by swiftcoder
This is an oft-overlooked point. Understanding the way someone else was thinking when they wrote their engine is in many ways harder than writing an engine.
Sorry, no. The effort to design, implement, test, debug, refactor and publish an engine of any value far outweighs the effort to download, read documentation for, write test programs on, and then employ an existing engine.
It really depends on the situation I'd say.
What if it cost $750,000 to license the engine?
What if the game isn't a cookie-cutter design perfectly matching any existing engine, and would require lower level engine modification.
If you'd have to do modifications to the engine in order to achieve your goals, then at some point it is easier from the programmers' point of view to write their own engine. You can get a decent engine going in a year with a small team of experienced programmers...it would probably be cheaper than the $750,000 mentioned above. Or you could do it all yourself and spend $0 on the engine ;-) All of the information necessary is out there on the interwebs or at your local book store.
Again, it all depends on the situation, the skill level of those involved, budget, game type, etc.
I think the definition of an 'Engine' is just a set of functions to perform a certain task [graphics,sound,input]...or in the case of a game engine, towards a specified genre [ Flight simulator, RTS, FPS, Racing, MMORPGRTSOMFGZ, etc. ].
Quote:Original post by Oluseyi
"Write libraries, not engines"?
To me, an engine is simply a stable integration of the diverse libraries precisely as required to implement a game of a particular genre (or with a particular complement of conventions). Yes, the word "simply" in there is misleading.
Making engines has become "popular" because engines have been commoditized as middleware in the professional industry, and a lot of marketing hype has been built around promoting said commodities. "Built on the Quake 2 engine!" "Built on Source!" "Using the next-generation Unreal Engine 3 technology!" Beginners think - and they're influenced by the consumer-oriented game journalism industry, which is filled with people who love games but actually have no idea how they're made (which is normal, really) - that engines are a necessity to make games, which simply isn't true.
However, writing a game with no engine is also a pain in the arse - you never realise quite how dependant you are on an engine, until you try to write all the 3d math from scratch ('cause guess what... there are very few game-oriented stand-alone 3d math libraries out there).
Quote:Quote:Original post by swiftcoder
This is an oft-overlooked point. Understanding the way someone else was thinking when they wrote their engine is in many ways harder than writing an engine.
Sorry, no. The effort to design, implement, test, debug, refactor and publish an engine of any value far outweighs the effort to download, read documentation for, write test programs on, and then employ an existing engine.
I wasn't necessarily talking about a publishable engine there, more the sort one writes for personal use - more along the lines of your "write libraries" angle above.
But in all seriousness, by the time you get umpteen-million obscure dependencies installed, work around broken build systems, discover lots of bugs in the hastily slapped-together mac or linux port, re-implement the platform specific part so it works as advertised, discover feature 'X' is unimplemented in the engine, implement 'X'... you might as well have spent your time writing the game from scratch (or around your earlier code-base - aka. 'homebrew engine').
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
