A simpler introduction to writing a game engine?

First off, I'm going to prefix this by suggesting you read about writing Games, not Engines. This is a very important point to understand. You can't just jump in and write a game engine if you have no experience writing games. I would also recommend studying up on the CS field, as some of the topics you've asked questions about are trivial problems within the field (state machines for instance).

If you have experience writing games (not one, several...) then you'll have a much better understanding of the problems you will encounter, how you can solve them, etc. Many of the questions you've asked are all things that end up being fairly trivial after you've gone and actually written a game or two, along with proper study of the Computer Science field.

When I say engine, I generally mean merely the system that my game uses to go from state to state, and the place where all the elements of my game's design meet and communicate with of affect each other. Is this what is meant by the article? I have read it but I am not sure. It seems to me like this kind of system would be practically a necessity for anything more complex then a pong or tic-tac-toe game or the like.

MeshGearFox: When I first started designing my game, I only had a handful of articles and broad input from users on this board. I think the reason that it is so difficult to find specifics is because something like a state machine could vary significantly depending on various factors of your game.

I ended up spending weeks (literally) just planning out my game; all the states, how the game would enter or exit each state, how each state would handle events, the resources that all the states needed, ect., and after these weeks of just thinking and planning I finally began to design the state system that worked for me, even though I never stopped refining it.

I don't know of any tutorials out there that will give you specific instructions on how to design a state system that will work best for you, but an article that put me in a very good direction was LazyFoo's article here: http://lazyfoo.net/articles/article06/index.php

The system I ended up adopting is very similar to the one outlined there by LazyFoo.

Yeah, I mean what Ruzhyo was talking about. I'm not talking about some sort of broad-level engine that I could, I don't know, use for a million different things. Just something that's more or less a fairly specialized framework to run a single, particular game on top of.

Also, maybe specifics is really the wrong thing to be asking for, at least from a programming standpoint. It's more like I'm not even really sure what I SHOULD be programming once I have the game system planned out in its entirey on paper.

The LazyFoo tutorial looks good, though. I've seen a lot of very broad diagrams of how a game loop and a state machine are supposed to... work, but nothing that actually addesses how to do that. The LazyFoo tutorial DOES SEEM to be what I'm after. So, thanks!

When I started with my third attempt in writing a framework that helps me writing applications that displays anything in 3D, I thought of what went wrong with my previous attempts.

The best idea I ever had was to build an abstraction layer that simplifies interaction with a specific API (DirectX, PhysX, etc...). Previously I never really did that, which mean that my meshes had ID3DTexture (or whatever that interface is called) pointers in my meshes, etc...

I thus created a basic interface for objects I wanted to be managed by my engine, which resulted in those ones:

-ITexture (Represents a texture)
-IMesh, IStaticMesh, IDynamicMesh (the later ones enhance IMesh)
-IEffect
-IVideoDevice

This abstraction layer helped me to simplify things alot. For example the (dynamic) meshes, textures and effects handle a lost device scenario themselves (something I found to be extremely difficult when I was fiddling with Vertex- and Indexbuffers manually). I also don't need to look up the right parameters for those D3DXCreateSomething functions, my device strips the parameters down to what I think I will need in the future.

I don't have any advice on managing game states or assets yet, as I don't plan to put them in my engine (yet) and because I don't have a clue how I'll implement this higher level stuff.

The ITexture/IMesh case is a typical example of what Object Oriented programming cannot do.

The reason is quite simple: you wish to associate a texture to a mesh, which means your IMesh interface will have a method like public void useTexture(ITexture);

And now you write:

The elementary rules of object-oriented programming (and, in particular, the Liskov Substitution Principle) dictate that this code should work. This is because you advertised your mesh as "can be associated with any texture" even though what you actually meant was "can be associated with any texture using the same implementation".

What I meant is that the entire implementation is hidden from the user of the framework.

I create an instance of my engine that has a set of implementations for VideoDevice, PhysicsDevice, SoundDevice attached to it. But this engine offers functions like this:


The ONLY place where the user has to decide which implementation to use is when creating the engine:


The function returns a pointer to an engine that implements the specific devices (like OpenGl/Direct3D) that have been requested, but the interface stays the same, no matter what has been requested. I never have to deal with D3DMesh, OGLMesh when I use my framework.
Should I ever decide to offer OpenGl as well, I only need to implemented the classes and engine is ready to use OpenGl as well.

[Edited by - SiS-Shadowman on April 7, 2009 3:34:29 AM]

For those who say it is better to learn about programming games first rather than engines, read this:

When I started learning about 3D game programming last year, I started off looking at DirectX. I followed the tutorials at http://directxtutorial.com/ which were great for teaching me the basics of how game programming works.

I bought the book "Programming a Multiplayer FPS in DirectX" by Vaughan Young and I thought it was incredible. I spent a long time looking at the code and learning how it all works. I very quickly found that my real interest in 3D programming was in programming the engine rather than the game itself so I started to take a look at that area specifically.

A few weeks ago I decided to take a look at OpenGL and SDL (because I wanted to write a new game engine for myself which would run on Windows, Mac, Linux etc) and within about 5 hours I had built up a simple engine framework. Over the next few weeks I had implemented some base systems like resource management. Just this week I created my own custom 3D model file format and storage class (with a custom exporter for Blender) allowing me to create model resources. And just today I added custom materials with textures.

I managed to learn how to make a simple game engine in OpenGl with only a few weeks experience with the library and a year after first picking up C++. I have yet to make a single complete game. I have ideas but I would rather work on the engine.

My advice is this. If you are interested in making game engines (like me) and have never built one from scratch before, I would recommend looking up "Programming a Multiplayer FPS in DirectX". Even if you want to use OpenGL or make some other game type, most of the concepts are transferable (like state management, resource management, engine framework etc). The book gives you a very gentle introduction (you don't even have to have ever written C++ before, but it helps). I have looked at other books about game engine programming, but I find them to be very deep and hard to understand.

If you would rather make a game than the back end, some websites and books might tell you more but I find that they tend to focus on one technique at a time and don't tell you much about important concepts like memory management.

As for state management and such things, unless you are comfortable with advanced OOP concepts such as inheritance, you may find it hard to understand at first but it's not as hard as it first appears. Again, "Programming a Multiplayer FPS in DirectX" has a great example of state management at work.

Quote:

Original post by SiS-Shadowman What I meant is that the entire implementation is hidden from the user of the framework. I create an instance of my engine that has a set of implementations for VideoDevice, PhysicsDevice, SoundDevice attached to it. But this engine offers functions like this: *** Source Snippet Removed *** The ONLY place where the user has to decide which implementation to use is when creating the engine: *** Source Snippet Removed *** The function returns a pointer to an engine that implements the specific devices (like OpenGl/Direct3D) that have been requested, but the interface stays the same, no matter what has been requested. I never have to deal with D3DMesh, OGLMesh when I use my framework. Should I ever decide to offer OpenGl as well, I only need to implemented the classes and engine is ready to use OpenGl as well.

I think you kind of missed his point. You can't use an OGL texture with a D3D mesh. However using that interface it will allow you without complaint. He didn't really suggest a solution, but it would probably be templates, reflection, exceptions, etc. Without reflection in C++ it could be as simple as defining a static string/int in your class ("D3D" or "OGL") and using that upon good faith to determine compatibility between classes.

It doesn't matter if you're using managers or not. VideoDevice->CreateMesh returns IMesh, and IMesh says it can use any ITexture, including either D3D implementation or OGL implementation, which it cannot.

Quote:

Original post by Dae Quote: Original post by SiS-Shadowman What I meant is that the entire implementation is hidden from the user of the framework. I create an instance of my engine that has a set of implementations for VideoDevice, PhysicsDevice, SoundDevice attached to it. But this engine offers functions like this: *** Source Snippet Removed *** The ONLY place where the user has to decide which implementation to use is when creating the engine: *** Source Snippet Removed *** The function returns a pointer to an engine that implements the specific devices (like OpenGl/Direct3D) that have been requested, but the interface stays the same, no matter what has been requested. I never have to deal with D3DMesh, OGLMesh when I use my framework. Should I ever decide to offer OpenGl as well, I only need to implemented the classes and engine is ready to use OpenGl as well. I think you kind of missed his point. You can't use an OGL texture with a D3D mesh. However using that interface it will allow you without complaint. He didn't really suggest a solution, but it would probably be templates, reflection, exceptions, etc. Without reflection in C++ it could be as simple as defining a static string/int in your class ("D3D" or "OGL") and using that upon good faith to determine compatibility between classes. It doesn't matter if you're using managers or not. VideoDevice->CreateMesh returns IMesh, and IMesh says it can use any ITexture, including either D3D implementation or OGL implementation, which it cannot.

Except the case that ToohrVyk proposed should never occur. ViedoDevice would be reponsible for creating both a Mesh and a Texture (and any other graphic resource); it knows if they'll be for D3D or OpenGL, and it should never switch.

The D3DMesh, GLMesh, D3DTexture and GLTexture classes should be hidden from the user.

Quote:

Original post by bronxbomber92 Except the case that ToohrVyk proposed should never occur. ViedoDevice would be reponsible for creating both a Mesh and a Texture (and any other graphic resource); it knows if they'll be for D3D or OpenGL, and it should never switch. The D3DMesh, GLMesh, D3DTexture and GLTexture classes should be hidden from the user.

Yep, that's exactly the point I was trying to make: The underlying system is irrelevant to the user. All he wants is to create a mesh or a texture. If it's a D3DTexture or OpenGL texture in the end is of no concern. The user only specifies which system he wants to use when the engine is being instantiated.

Okay, so what about content and resource management then? LazyFoo doesn't seem to be covering that in a hugely in-depth manner. Stuff offered in http://www.gamedev.net/community/forums/topic.asp?topic_id=529923 is helpful but I feel like I need a bit more. Mostly from an organizational standpoint.