Game Engine Design

This topic is 2848 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

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,

Share on other sites
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.

Share on other sites
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. ;)

Share on other sites
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.

Share on other sites
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!

Share on other sites
Quote:
 Original post by Captain PI 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...

Share on other sites
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.

Share on other sites
Quote:
 Original post by megamoschaRead 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).

Share on other sites
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.

Share on other sites
Quote:
 Original post by RilburThe 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.

Share on other sites
Quote:
 Original post by RilburI 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!

Yeah, thats good. But in the past many people were offended because someone posted this link. That's the reason why I wrote it. Search here for "Write game not engines" then you know why I've wrote it.

Share on other sites
Hi,

So I did homework, and read a lot of articles and few books around.
I have in mind a sketch of the total engine and how the components will communicate with each other. But I need little help to sharp things up:

I'm going to use message queue for the components communication, I'll use the "Command" pattern for the messages. Can anyone give me an example, how to use it
in a game?
(My problem is how can I create a generic mechanism for message sending separated from the game,so if I have different game, with different messages, I can upload the commands, for file and take care of them, or something like that...)

tnx

Share on other sites
Quote:
 Original post by RilburAnd 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.

And that's one of the problems with building an 'engine': it's a very broad and vague term. Some people would consider map-loading and game entity management part of their game engine, other people have different ideas about that. So don't just say: "I want to build a game engine". Only you know what that means - but often people who say this do not know what exactly they're going to build, because they think they need some kind of generic game engine because every game needs one, whatever it may be.

Now, if you would say, I'm going to build a 2D tile-based turn-based strategy game, then that's a lot more specific. Not only does it give you clear goal, it also gives other people an idea of what you're going to build - which allows them to give specific advice. And yeah, you're right about having various modules doing their own specific thing - there's libraries for physics, rendering, pathfinding, and so on.

In other words, 'engine' says as much as 'housing'. Do you live in an appartment, a stand-alone house, an iglo or do you have your own palace? Each will have different requirements and construction methods.

Quote:
 Original post by masterbubuSo I did homework, and read a lot of articles and few books around.I have in mind a sketch of the total engine and how the components will communicate with each other. But I need little help to sharp things up:I'm going to use message queue for the components communication, I'll use the "Command" pattern for the messages. Can anyone give me an example, how to use itin a game?

The command pattern is pretty useful for editors, especially for undo/redo functionality, but for a game... why would you need such a messaging system? I mean, function calls are also a form of messaging, why would that not be sufficient for your game/engine? As for components, what sort of components are we talking about here?

The more specific you are, the more specific help you can get. If you don't know your requirements, you can't be specific, and you can't build a good system - because you have nothing to measure it's effectiveness against. So I'll have to ask, what exactly do you want your engine to do? For what kind of games will it be used?

Share on other sites
Well i'll try to be more specific. I have read that there is a "star" design where each of the subsystems (AI, GRAPHICS, PHYSICS...) sending and receiving messages from it. This way the AI engine does not communicate with physics engine directly. This allows the components be undependable, so you can replace subsystem without effacing the others.

My question was: how can I build such a message queue?

tnx

Share on other sites
Quote:
 Original post by masterbubuThis way the AI engine does not communicate with physics engine directly. This allows the components be undependable, so you can replace subsystem without effacing the others.

The idea behind interfaces is the same: if a subsystem provides a decent interface (classes, functions, expected behavior), then it's underlying implementation can safely be changed without breaking code that uses it, as long as the interface itself is not changed.

If I call renderer.DrawRectangle(x, y, width, height, color), then I don't care what renderer does under the hood. Perhaps it uses OpenGL, perhaps DirectX, perhaps software rendering? As long as it does what it's expected to do you can swap the underlying code without affecting the calling code.

In the end, you're going to have some sort of interface. Whether that's a direct code interface, or a more abstracted form of messaging, if you need to work with a subsystem you will need to know something. You'll just want to limit that to what's necessary.

Quote:
 My question was: how can I build such a message queue?

As an example, every time a collision occurs, the collision system could send a message to the collision message queue. This could be an object that describes what objects collided, their contact points, the forces involved, and so on. Another subsystem could check the queue and notice that a collision message was posted. It can then react to it based on the stored information. So yeah, as the name implies, it's a queue of messages.

Another approach would be to bind callback functions to certain events. Some code that needs to know about key presses from the input subsystem would tell the input subsystem: when this event type occurs, call this function. The calling code no longer has to poll for messages - instead, it will be informed whenever that event occurs.

In both cases, events or messages can be represented with classes. For example, a CollisionEvent could look like this:
class CollisionEvent{   CollisionObject* objectA;   CollisionObject* objectB;   Point collisionPoint;}
With the queue, you'd store them in a queue and you'll let other subsystems read from that queue. With a callback system, you send them directly to all subsystems that registered themselves (of course, they'll need to provide a function that accepts such an event object as an argument). With both approaches, other subsystems still need to know what sorts of events to expect, otherwise they can not meaningfully work with them.

As you can see, there are multiple approaches possible. Which one to choose depends on your requirements - so it really helps to be specific.

Share on other sites
Tnx man you helped a lot.

Share on other sites

This topic is 2848 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Create an account

Register a new account

• Forum Statistics

• Total Topics
628760
• Total Posts
2984544

• 12
• 25
• 12
• 10
• 17