starting game engine

When it comes to physics, math, etc., you will have to ask a more specific question. Your current questions are too broad.

Generally people will use existing physics engines such as Bullet. Trying to write your own will be too overwhelming at your current level.
You will also need to specify the rendering API you are using. If DirectX 9, you can use the DirectX math library. This will however tie you closely to DirectX, meaning no chance of porting your engine in the future (though since it is just for learning that may not be a problem).
Otherwise, you can find how to write vector and matrix classes easily via Google.


My site aims to document the creation of a next-generation engine and has tutorials useful to beginners.

Fixed-Time-Step Implementation
General Game/Engine Structure
Passing Data Between Game States


L. Spiro

Write games, not engines: http://scientificnin...mes-not-engines
If you, after reading the article, still want to write a game engine. Continue reading.

What can the game engine you have in mind do? Is it capable of cross-platforming(Windows,Mac,Xbox,Ps3,etc)? Do you want to work with Win32, DirectX, OpenGL, etc?
Is it a 2D or a 3D engine? Will it be commercial, open source, private?

cross-platforming:
To get the cross platforming done you need to check how a window is created on all consoles, how the type id's are called, etc.
Here are some defines that will help you:

#ifdef _WIN32 || _WIN64
#elif __APPLE__
#if TARGET_OS_IPHONE
#elif TARGET_OS_MAC
#endif
#elif __linux
#elif __unix
#elif __posix
#else // unknown platform
#endif


Win32, DIrectX, OpenGL:
Win32 is the standard library of C++. It's only supporting windows.
DirectX is the best choice, even it's not supporting cross-platforming yet. With the possibilities of this library you can create any application you have in mind!
OpenGL and DirectX were racing neck on neck a few years ago but they update of DirectX made OpenGL run behind. But it's an easy language to use.

Commercial, open source, private:
If you want to make a commercial engine like CryEngine, Unity... No chance on your own so forget this.
If you want to make it open source, be sure to really have everything bug-free, error-free. You don't want the clients to complain about your engine, even it's open source.
If you want to make it private, I think you are better of with a simple framework instead of an engine.


~EngineProgrammer


EDIT: I'm regretting this post immediately.

Is this a school project? Or does 'studying' mean learning about it on your own?

If it's a personal project I'll give 2 solid pieces of advice which have been floating around these boards for a long time:
1. Make games, not engines (as the poster above me pointed out already)
2. If you have to ask how to make an engine, you're not ready to make an engine.

Win32, DIrectX, OpenGL:
Win32 is the standard library of C++. It's only supporting windows.
DirectX is the best choice, even it's not supporting cross-platforming yet. With the possibilities of this library you can create any application you have in mind!
OpenGL and DirectX were racing neck on neck a few years ago but they update of DirectX made OpenGL run behind. But it's an easy language to use.

Why do you drag Win32 into a discussion of graphics APIs? Win32 is not the C++ standard library for windows, Win32 is the basic Windows API which exposes Windows core functionality to developers.
The latest OpenGL release also made it basically on par with DirectX again, so there's no issue there. I also wouldn't expect DirectX to ever go cross-platform (at least not in a way condoned by microsoft), but that doesn't mean an engine shouldn't support DirectX even if that engine will be cross-platform.

If you want to make it open source, be sure to really have everything bug-free, error-free. You don't want the clients to complain about your engine, even it's open source.

There's no such thing as bug-free or error-free software

[quote name='EngineProgrammer' timestamp='1349653462' post='4987801']
Win32, DIrectX, OpenGL:
Win32 is the standard library of C++. It's only supporting windows.
DirectX is the best choice, even it's not supporting cross-platforming yet. With the possibilities of this library you can create any application you have in mind!
OpenGL and DirectX were racing neck on neck a few years ago but they update of DirectX made OpenGL run behind. But it's an easy language to use.

Why do you drag Win32 into a discussion of graphics APIs? Win32 is not the C++ standard library for windows, Win32 is the basic Windows API which exposes Windows core functionality to developers.
The latest OpenGL release also made it basically on par with DirectX again, so there's no issue there. I also wouldn't expect DirectX to ever go cross-platform (at least not in a way condoned by microsoft), but that doesn't mean an engine shouldn't support DirectX even if that engine will be cross-platform.

If you want to make it open source, be sure to really have everything bug-free, error-free. You don't want the clients to complain about your engine, even it's open source.

There's no such thing as bug-free or error-free software
[/quote]

Sorry for my misunderstanding about Win32. I meant the header file with Win32. And that can also be used to write a game engine with, so I dragged it into this discussion.

About OpenGL, my programming lecturer said 3 weeks ago that OpenGL is running behind DirectX and he is looking updates about programming stuff every day so I assume he is right.
Though I should have checked first on their sites before posting it here. My apologize.
But still, I've programmed with OpenGL last year for a month, I think it was child coding to be honest. But in a year allot can happen of course.


There is no such thing as a bug-free and error-free game engine?
Yes there is... With enough checking code, and a good team of programmers.
But yes, it all depends on the client who uses your engine. If he can't work with it properly failing stuff will happen indeed. But that's not the fault of the engine but of the client. Still, a good engine would be prepared for moments like that and be sure to have enough error checking.

But my experience in programming isn't that much, I just try to help others with the knowledge I have at the moment.
If you can give me an example of an unfix-able piece that you can't keep error-free, please tell because I want to know.


~EngineProgrammer

It's not about single unfixable pieces of code, bugs can always be fixed one way or another (if they can't there's something wrong with your design), but when a project grows and starts to get more and more complex the potential for bugs to creep in grows as well.
Now let it be so that game engines themselves are incredibly complex pieces of software which have to process loads of data coming from different sources and all in different formats made by different authors, all of that preferably at a very high speed as well. Now also let it be so that there's no way of knowing whether you've actually found all bugs in a piece of software like that. Of course, there are approaches in software development which tend to aggressively test and check for bugs (like extreme programming), but these might not be feasible when working with time constraints and still do not guarantee that you'll find all bugs in your code.

You can be sure of the fact that all the major commercial AAA engines have bugs in them, some more critical than others. It's up to the developers and maybe testers (like when it comes to games) to locate and categorize bugs in software. Then it's just a matter of determining what is acceptable for release and what isn't, and eliminating the bugs which are deemed non-acceptable.

EDIT:

Here's a fitting quote:

"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you are as clever as you can be when you write it, how will you ever debug it?"

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 will just laugh, and the company execs will smile at you and drive away in their Aston-Martins and BMWs (after, of course, wishing you luck with your "Super-Pong VIII" project)... Writing a good engine can result in hundreds and hundreds of successful games by "in-house" and 3rd party developers, and mounds upon mounds of cash. Though writing an engine that good is extremely difficult it has been done more than a few times by more than a few people and companies...

But I have to agree that just writing a "generalized" engine without ever developing any games or sample apps to drive development and solve specific problems is a bad idea. You'll end up creating an engine that does a little bit of everything but is relatively useless for practical and commercial purposes. The approach I advocate is to drive your engine development by way of continuously evolving samples/demos which implement the core/structure of various types of games. Over time those should evolve into complete games. As development progresses you will identify common functionality that is needed by games, eliminate junk/bloat, reduce bugs, increase speed, etc... That is essentially what an engine is; common functionality needed by games and/or a hosted environment for the game to run in.

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 will just laugh, and the company execs will smile at you and drive away in their Aston-Martins and BMWs (after, of course, wishing you luck with your "Super-Pong VIII" project)... Writing a good engine can result in hundreds and hundreds of successful games by "in-house" and 3rd party developers, and mounds upon mounds of cash. Though writing an engine that good is extremely difficult it has been done more than a few times by more than a few people and companies...

But I have to agree that just writing a "generalized" engine without ever developing any games or sample apps to drive development and solve specific problems is a bad idea. You'll end up creating an engine that does a little bit of everything but is relatively useless for practical and commercial purposes. The approach I advocate is to drive your engine development by way of continuously evolving samples/demos which implement the core/structure of various types of games. Over time those should evolve into complete games. As development progresses you will identify common functionality that is needed by games, eliminate junk/bloat, reduce bugs, increase speed, etc... That is essentially what an engine is; common functionality needed by games and/or a hosted environment for the game to run in.

I don't think anyone here stated that you should never write an engine, but coming onto a forum asking how to write one generally shows that you lack the fundamental understanding of game development required to actually build a usable engine.

I partially agree with your last statement, but I wouldn't consider it a good practice to drive engine development purely on samples. If you don't have a fully defined goal/game in mind to drive your engine then you'll probably end up with that relatively useless engine you mentioned, and I don't consider tech demos or samples proper goals.

I don't think anyone here stated that you should never write an engine, but coming onto a forum asking how to write one generally shows that you lack the fundamental understanding of game development required to actually build a usable engine.

It has been said in a few threads around here, and there are quite a few articles out there on the internet where people scoff at the concept of an engine entirely. But I wasn't accusing anyone here in this thread of such radical views.

I partially agree with your last statement, but I wouldn't consider it a good practice to drive engine development purely on samples. If you don't have a fully defined goal/game in mind to drive your engine then you'll probably end up with that relatively useless engine you mentioned, and I don't consider tech demos or samples proper goals.

Of course not... if you're trying to drive development purely on tech demos and samples you're making exactly that useless engine... I'm just saying that tech demos and samples are a good starting place for getting your engine working, figuring things out and getting a good foundation for your engine. But then you have to switch gears and start writing some games and practical applications... that is, after all, what the objective of an engine is: to write games and apps. Failing to do so is like training an army shoot guns well but never teaching them how to actually fight and win in combat. You'll have an army of good marksmen, yes... perhaps the best shooters in the world... but they'll be totally scattered and routed by a well-organized and trained army with far less-capable marksmen and equipment.

[quote name='Radikalizm' timestamp='1349715178' post='4988035']
I don't think anyone here stated that you should never write an engine, but coming onto a forum asking how to write one generally shows that you lack the fundamental understanding of game development required to actually build a usable engine.

It has been said in a few threads around here, and there are quite a few articles out there on the internet where people scoff at the concept of an engine entirely. But I wasn't accusing anyone here in this thread of such radical views.

I partially agree with your last statement, but I wouldn't consider it a good practice to drive engine development purely on samples. If you don't have a fully defined goal/game in mind to drive your engine then you'll probably end up with that relatively useless engine you mentioned, and I don't consider tech demos or samples proper goals.

Of course not... if you're trying to drive development purely on tech demos and samples you're making exactly that useless engine... I'm just saying that tech demos and samples are a good starting place for getting your engine working, figuring things out and getting a good foundation for your engine. But then you have to switch gears and start writing some games and practical applications... that is, after all, what the objective of an engine is: to write games and apps. Failing to do so is like training an army shoot guns well but never teaching them how to actually fight and win in combat. You'll have an army of good marksmen, yes... perhaps the best shooters in the world... but they'll be totally scattered and routed by a well-organized and trained army with far less-capable marksmen and equipment.
[/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.

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

Interestingly saying "I want to build a rendering component that has no unncecessary coupling to the rest of the program" sounds better than "I want to build an engine" although the two are not really very different.

I followed a series of c++ video tutorials from http://www.3dbuzz.com/ that It includes the very basics, a simple text based, and 2d game, and culminates with a 3D renderer with openGL. They've got tutorial sets for a bunch of other languages as well. (Thought I haven't personally viewed most of them)

It's worth noting, that some of them, particularly involving openGL are very dated, but at least imo, it makes things much simpler to learn the basics from.

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.