Game Engine Design
Author
Hi,
I'm a beginner on game programming.
I've developed a render engine with opengl, but for testing things i gave lots of
control to the render engine.
Well now I want to design game engine, and give it the control, so the render engine job will only be to draw.
So my question is about the design, Can anyone forward me to good resources, UML, anything.
I've read lots of articles, but still I'm not sure about the right design.
Tnx,
I have said this many times on this fourm, one of the best books I have ever read was :
Core Techniques and Algorithms in Game Programming by Daniel Sánchez-Crespo Dalmau
He approaches this topic in a very well structured way. He begins by giving you an example game main loop - it looks quite scary to begin with. He then builds on this and explains how each step works. By the end of the book you should understand how a game works and how all the components of the engine fit together.
Core Techniques and Algorithms in Game Programming by Daniel Sánchez-Crespo Dalmau
He approaches this topic in a very well structured way. He begins by giving you an example game main loop - it looks quite scary to begin with. He then builds on this and explains how each step works. By the end of the book you should understand how a game works and how all the components of the engine fit together.
Personally I wouldn't start designing an engine if I didn't have much experience with building actual playable games. I tried a few times, but it never really worked out. I then started to build a bunch of simple games. I reused some of their code for later games, continually improving upon it. I ended up with a framework that was fairly easy to work with, taking care of a lot of common functionality. It had proven itself throughout a bunch of games/prototypes, and while there's still a couple of things that I'd like to do differently, I'm pretty happy with how it turned out. Not only do I have a solid framework (call it engine if you must) and a couple of tools, but I also gained valuable insight along the way.
I mean, think about it like this: if you've never built a game, how can you tell how a good game engine should work? You don't even know what it's supposed to do yet. Sure, you'll have some theories, but in reality, reality and theory differ quite a bit. Of course, doing research along the way is good, but you'll need a healthy dose of practice just as well. ;)
I mean, think about it like this: if you've never built a game, how can you tell how a good game engine should work? You don't even know what it's supposed to do yet. Sure, you'll have some theories, but in reality, reality and theory differ quite a bit. Of course, doing research along the way is good, but you'll need a healthy dose of practice just as well. ;)
Author
Hi,
I've build games on the past. My intention is not to create new games for now,
I just want to create a basic game engine skeleton, so i can continue developing the rendering engine, and testing its functionalities , with simply demos that will be built on the game engine.
I've build games on the past. My intention is not to create new games for now,
I just want to create a basic game engine skeleton, so i can continue developing the rendering engine, and testing its functionalities , with simply demos that will be built on the game engine.
good, then let's come to a compromise, why don't you create a overdeveloped rendering engine, so rendering, but with file management, model loading, texture loading, animation etc.
Than create a game. So you give meaning to your textures and models. That way, you'll learn what a game engine is all about.
Trust me, creating a game engine without having a 500+ page game design document is not going to work!
Than create a game. So you give meaning to your textures and models. That way, you'll learn what a game engine is all about.
Trust me, creating a game engine without having a 500+ page game design document is not going to work!
Quote:Original post by Captain P
I mean, think about it like this: if you've never built a game, how can you tell how a good game engine should work? You don't even know what it's supposed to do yet. Sure, you'll have some theories, but in reality, reality and theory differ quite a bit. Of course, doing research along the way is good, but you'll need a healthy dose of practice just as well. ;)
Perhaps I'm misunderstanding something, but don't you need a game engine to build a game with? Unless you're suggesting he (or rather, I) start with an existing open-source engine...
You build a game without in mind to create a game engine (which in itself can be very difficult).
When you've finished a game then you go and create another game. Use as much as possible from the previous game so that you get over time classes, functions and data structures that you need to build a game.
Read this article but don't take it as an offense as many did in the past here.
When you've finished a game then you go and create another game. Use as much as possible from the previous game so that you get over time classes, functions and data structures that you need to build a game.
Read this article but don't take it as an offense as many did in the past here.
Quote:Original post by megamoscha
Read this article but don't take it as an offense as many did in the past here.
I seek to learn, and you clearly know more than I do. Why would I take offense? We can disagree without being offended by the disagreement!
Quote:To begin with, the term “engine” (specifically as it related to the game development world) has no strict definition. Therefore, in the interests of keeping everybody on the same page, I’ll define the term as I intend to use it in this article. An “engine” is a collection of robust, reusable software subsystems (possibly including both code libraries and tools) designed to facilitate the development of actual games by addressing specific requirements. The requirements tend to be broadly-defined: rendering, audio, physics, et cetera. Particularly ambitious engines that address multiple broad requirement groups tend be to known as “game engines” rather than just “graphics engines” or “physics engines.”
And here is the reason for our confusion, you were using it in the reusable sense, whereas I was using a more strict and limited sense. The engine I was thinking in terms of would be defined better as "the body of rules, and code implementing those rules, that build a game" -- to me, rendering engines, sound engines, etc etc are distinct from the core 'game engine'. For example, an RTS engine would handle loading a terrain map, the units that can run on it, and the rules those units use to move around. A FPS game of some kind would load the world, the players 'game agent', any NPCs, and the rules about how they move and interact. There would be a certain degree of interactivity between the engine and the data that drives it (for example, the engine would contain most of the rules that allow units to move, but the data would decide which rules would be implemented and to a degree how). Other features might be AI, game load / save, etc etc. Input (and output) would be handled in a different section of the game (for example, I'm working with Ogre3D at the moment). It's just... cleaner that way, even if a lot of engines are going (to me, mistaken) the 'one stop shopping' approach. Divvying it up into different parts just makes sense. (Which is one reason I love what I've seen of Ogre3D so far; they are the ones who presented that very agreeable logic to me).
I'm in the "Build games and extract/improve the engines when done" camp.
A game engine is little more than the generic stuff that most games will do. It is a collection of routines and a bit of common or customizable data. How do you know what that stuff is unless you've actually seen the games? How do you know the library has the needed parts if it hasn't been used in a game?
Write your game with the knowledge that you want to eventually extract the good parts back out. When you are done (whatever that means to you), branch it in your version control and extract all the stuff you believe you don't need. This is your engine. Branch it again and create a second game.
When you find yourself rewriting functionality from your first game, pull the code back down into the engine branch and integrate the change back out. When you are done with this second project, extract the good common bits back down to your engine, then branch to a third game.
After two iterations it should be obvious what works and what doesn't, and at that point you can work as your engine as a separate entity.
A game engine is little more than the generic stuff that most games will do. It is a collection of routines and a bit of common or customizable data. How do you know what that stuff is unless you've actually seen the games? How do you know the library has the needed parts if it hasn't been used in a game?
Write your game with the knowledge that you want to eventually extract the good parts back out. When you are done (whatever that means to you), branch it in your version control and extract all the stuff you believe you don't need. This is your engine. Branch it again and create a second game.
When you find yourself rewriting functionality from your first game, pull the code back down into the engine branch and integrate the change back out. When you are done with this second project, extract the good common bits back down to your engine, then branch to a third game.
After two iterations it should be obvious what works and what doesn't, and at that point you can work as your engine as a separate entity.
Quote:Original post by Rilbur
The engine I was thinking in terms of would be defined better as "the body of rules, and code implementing those rules, that build a game" -- to me, rendering engines, sound engines, etc etc are distinct from the core 'game engine'.
You're talking about the "game logic". A game engine, by consensus, is the aggregate of the game logic, graphics engine, sound engine, networking, and file management.
To answer your original question, there is rarely enough similarity between two games to define guidelines. You can think of a game as somewhat of a simulation of real life - you can see recurring rules like "objects do not go through each other" and "unsupported objects fall", but a game only takes into account a subset of the rules you know. There is no gravity in Chess, for instance.
So for how to make a game, just implement one feature at a time and refactor your existing code to take the new features into account.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
