Game Engine structure question.

[epicasian]

I'm making my own game engine and have a quick question about structure. Currently, I have this planned:
Manager classes and the scripting system as the core. Every class goes through the core to retrieve data from another class. Classes never directly access each other.

Does this sound like an efficient way to structure an engine? Sorry if this sounds noobish, I'm just sort of confused.

Thanks
~Asian

[Ginto8]

I think it restricts the type hierarchy far too much and, if you make a small change, it will have drastic circumstances with the rest of the program. You should try a strategy that has better modularity and allows more flexibility if you want to change something.

Sorry if I'm a little vague, I'm a bit tired but I wanted to put in my $.02 worth

[XianForce]

I wanted to add a bit more to this...

so this is the structure presented in Game Coding Complete, so if you want information, check that book out =p


So basically you have an application layer which will contain all your code that should be rewritten for each platform. So how I do this is make some core classes for video, audio, input, etc. Then the application has a class that contains all your game logic. The logic also holds a number of 'views'. The player view will render your game. So now programming the game works off an event (or messaging) system.

So in your Player View, you'd act on input. Typically you'd think like: "Well if the user presses this button, I will make that happen". But this structure works more like: "When the player presses this button, I will request the Game Logic to make that happen".

This also makes it really easy to implement a Scripting Debug Console. All it needs is the capability to send messages, and you can do virtually anything the rest of your code can.


I would go more in depth, but if you want more information you should check out the source code (it's free), or find the book.

[epicasian]

I wanted to add a bit more to this...

so this is the structure presented in Game Coding Complete, so if you want information, check that book out =p


So basically you have an application layer which will contain all your code that should be rewritten for each platform. So how I do this is make some core classes for video, audio, input, etc. Then the application has a class that contains all your game logic. The logic also holds a number of 'views'. The player view will render your game. So now programming the game works off an event (or messaging) system.

So in your Player View, you'd act on input. Typically you'd think like: "Well if the user presses this button, I will make that happen". But this structure works more like: "When the player presses this button, I will request the Game Logic to make that happen".

This also makes it really easy to implement a Scripting Debug Console. All it needs is the capability to send messages, and you can do virtually anything the rest of your code can.


I would go more in depth, but if you want more information you should check out the source code (it's free), or find the book.

After pondering a few days on this, I've come up with a couple questions I hope you can answer :D.

1.) Would the Logic take care of moving the player's position, for example? Or would the Player class query Logic, asking if the Player is able to move?
2.) Would ALL Core classes and other classes have to query Logic before they can perform their methods?

Thanks in advance
~Asian

[dejai]

Why have a player class when you can have a generic "object" or "entity" class of which the creation of a player is possible through scripting the behavior of that object?

[XianForce]

1.) Would the Logic take care of moving the player's position, for example? Or would the Player class query Logic, asking if the Player is able to move?
2.) Would ALL Core classes and other classes have to query Logic before they can perform their methods?

Thanks in advance
~Asian

1) Yes, that's pretty much how'd it work. So in your Player Game View, you'll receive input. Let's say the user pressed the 'w' key. With a standard WASD movement scheme, that would translate to 'move forward'. So you send a message to logic, requesting to move the player forward. The logic then handles it from there.

2) Now it depends by what you mean by 'Core' classes... When I think of 'Core' I think somewhere along the lines of Rendering and Audio Systems... in which case that'd be no. But if you mean Systems that control objects in the map, then yes. And what do you mean by perform their methods? You don't query the logic to see if you can do it, then do it. You ask the logic to do it, and the logic takes care of it.


Another thing that might be useful for you to sort of bring it all together is a Process. So he also talks about Processes in this book. A process is simply anything that can be updated. So you have a base Process class, and then you can derive more base classes (usually interfaces) from the Process class. So you might have an Actor Interface, a screen Interface, etc. So, the process handler actually acts as a low level state machine in a way. If you actually download the source code from this book you can see it...


-NOT DONE- Sorry have to leave, will edit and finish later though...

[EDIT]

Alright I'm back... Anyways back to processes. So since a process is anything that updates you can essentially store them in a simple list, and loop through and update them. The book also talks about having a SetNext member function so that you could do something such as:

Code: Select all

CProcess* walk = new Walk();
CProcess* openDoor = new OpenDoor();
CProcess* turnOnLight = new TurnOnLight();

walk->SetNext(openDoor)->SetNext(turnOnLight);
ProcessManager->Attach(walk);

This way you can string small processes together to somewhat make a bigger process. What SetNext is supposed to do is set up a sort of dependency. In this example, openDoor won't start until walk ends, just like turnOnLight won't start until openDoor ends.

Well... Hope that helped, if you have any more questions, I'd be happy to answer =D.

[XianForce]

Why have a player class when you can have a generic "object" or "entity" class of which the creation of a player is possible through scripting the behavior of that object?

This ^^... This is definitely an idea that this whole architecture I'm talking about uses. The AI units of your game use the exact same logic code as your player would. Instead of having a player handle the input, the logic is going to take care of it.

So here's some pseudo-code:

Code: Select all

if(newKeypress == 'w')
{
    SendMsgToLogic("MoveForward", actor);
}

Then your AI might have the same thing:

Code: Select all

if(bulletComingFromLeft)
{
    SendMsgToLogic("MoveForward", AI_actor);
}

Handling things in this way will also make it much easier if you ever wanted to make a multiplayer game, since everything has the same behavior according to the logic. Adding a new player would be as simple as adding a new 'view'