Steps and process for creating a game engine
Author
Ok I have been working on a game, and so far my code has been getting all messy and crammed, im getting stuck on a lot of parts to the game engine, but I think my main problem is I dont know the steps to creating one!
Can some one please tell me the steps to create a game engine. Meaning physics, sound, networking, graphics, etc.
Im not asking for code, just theory.
Author
I have read that before, it didnt help very much.
I mean like... example
First create the actual game it self. Do the menus and stuff later.
Start off with the 3D engine. Get stuff to load on the screen, and go where you want it to go. This would be the time to make your level editor, and your own level loading algorithm if you are making one.
Then move on to the camera movement.
etc etc
I dont know how commercial game engines function.
Do they load all of the games sounds when the game is 1st loaded, or between each level change.
What does an engines loop cycle look like!
Are all aspects of the game dealt with in one, or by subject. Example would be a player firing a gun.
Now do I detect for the input, and right away play the sound in the same function, or does an input handler set a variable to true, and when the sound engine sees that the variable is true, it plays the sound.
Right now I am able to walk around and stuff in my game, but I dont know how on earth i would now be able to tell which level to load, how to exit the game back to the menu, add other key aspects like networking etc, because I just randomly went out of ordr and threw stuff in.
Also I think my coding could use some help.... this is all of my code for my game so far...
Source Code
I mean like... example
First create the actual game it self. Do the menus and stuff later.
Start off with the 3D engine. Get stuff to load on the screen, and go where you want it to go. This would be the time to make your level editor, and your own level loading algorithm if you are making one.
Then move on to the camera movement.
etc etc
I dont know how commercial game engines function.
Do they load all of the games sounds when the game is 1st loaded, or between each level change.
What does an engines loop cycle look like!
Are all aspects of the game dealt with in one, or by subject. Example would be a player firing a gun.
Now do I detect for the input, and right away play the sound in the same function, or does an input handler set a variable to true, and when the sound engine sees that the variable is true, it plays the sound.
Right now I am able to walk around and stuff in my game, but I dont know how on earth i would now be able to tell which level to load, how to exit the game back to the menu, add other key aspects like networking etc, because I just randomly went out of ordr and threw stuff in.
Also I think my coding could use some help.... this is all of my code for my game so far...
Source Code
There are probably no fixed formulae here, it depends on what you want to do.
Point of interest: You want to avoid hardcoding data into the game like you have it now, so you want to create a resource manager and a level loader. The resource manager takes care of loading resources, passing a reference to a loaded resource if the requested resource is already loaded, unload a resource to make room for another, and similar task. The level itself could be a resource also, specifying the entities it contains and the resources needed to represent them. If your levels are reasonably small, you can probably get away with loading most of the level's resources once (when entering the level). Otherwise you will need a continuous loading scheme that streams content as it is needed and unloads it when it is no longer needed.
The design issues are all up to you. Here's a very basic structure that could help you get started: separate the various "components" such as AI, physics, sound, rendering, scene graph into their own classes. You could then call an update function on each component. A typical game loop could then look something like this:
Point of interest: You want to avoid hardcoding data into the game like you have it now, so you want to create a resource manager and a level loader. The resource manager takes care of loading resources, passing a reference to a loaded resource if the requested resource is already loaded, unload a resource to make room for another, and similar task. The level itself could be a resource also, specifying the entities it contains and the resources needed to represent them. If your levels are reasonably small, you can probably get away with loading most of the level's resources once (when entering the level). Otherwise you will need a continuous loading scheme that streams content as it is needed and unloads it when it is no longer needed.
The design issues are all up to you. Here's a very basic structure that could help you get started: separate the various "components" such as AI, physics, sound, rendering, scene graph into their own classes. You could then call an update function on each component. A typical game loop could then look something like this:
while(1) { time.updateTime(); // advance the clock input.update(); // process keyboard and mouse events if(PLAYER_REQUESTS_EXIT == 1) { doCleanup(); exit(); } ai.updateAI(); // do game logic gfx.update(); // culling, sorting gfx.render(); // render the graphics audio.update(); // play the music and sounds}
Author
Okay, so say when a player moves.
They press W, and I move the player object x amount forward, and I play the footstep sound.
Do I do the thing where one function checks for input at the top of the loop, and then later down in the loop, the graphics function updates the graphics and then after that a sound function checks for the variable and plays the sound, or can I do something like this...
CheckPlayerMoveUp()
{
if up key is pressed
move player object
play footstep sound
update player location variables
end if
}
if it doesnt matter id rather do it the 2nd way, since it would be more organized, and when there is a problem, I can say "Hey, my footsteps arnt playing, why!" and I look in the player move section, instead of going through 3 or 4 different functions to mae sure that all the variables are being passed and getting there. Would probably be faster that way too.
Also:
For the main app loop, what do I do?
while apploop == true
{
if mode = 1
MainMenu
else if mode = 2
GameEngine
else if quitmessage = 1
quit app
}
Also:
What data is hardcoded and what data shouldnt be?
Should I have stuff like weapon settings (ammo, rof, mags), level settings 9game time, max players per team) in settings files, or hard coded?
They press W, and I move the player object x amount forward, and I play the footstep sound.
Do I do the thing where one function checks for input at the top of the loop, and then later down in the loop, the graphics function updates the graphics and then after that a sound function checks for the variable and plays the sound, or can I do something like this...
CheckPlayerMoveUp()
{
if up key is pressed
move player object
play footstep sound
update player location variables
end if
}
if it doesnt matter id rather do it the 2nd way, since it would be more organized, and when there is a problem, I can say "Hey, my footsteps arnt playing, why!" and I look in the player move section, instead of going through 3 or 4 different functions to mae sure that all the variables are being passed and getting there. Would probably be faster that way too.
Also:
For the main app loop, what do I do?
while apploop == true
{
if mode = 1
MainMenu
else if mode = 2
GameEngine
else if quitmessage = 1
quit app
}
Also:
What data is hardcoded and what data shouldnt be?
Should I have stuff like weapon settings (ammo, rof, mags), level settings 9game time, max players per team) in settings files, or hard coded?
To answer that question, you probably first wanna think about how you are going to handle messaging between objects. You're going to have a lot of objects interacting eventually, and it probably isn't practical to have each one keep track of each other object. So you need a way to pass information between objects.
You could have your player object register handler callbacks with the input object, which I think then would result in something somewhat similar to number 2. Or you could, say, push a message that said "player movement detected, forward" into a queue and then get that message from the world processing when you update the world, there advancing the player position and creating a one-shot 3d sound object at the appropriate place.
I haven't implemented this yet, so my advice may not be worth the pixels it uses up on screen :)
Edit: for number 2, what is your question?
For number 3: ideally you should not have any data hardcoded. Your data members are hard coded in your object classes but all specific data is pulled from scripts or configuration files or data files. For example, you don't really want to recompile the whole thing just because you've decided to change the max team size from 12 to 14, right?
You could have your player object register handler callbacks with the input object, which I think then would result in something somewhat similar to number 2. Or you could, say, push a message that said "player movement detected, forward" into a queue and then get that message from the world processing when you update the world, there advancing the player position and creating a one-shot 3d sound object at the appropriate place.
I haven't implemented this yet, so my advice may not be worth the pixels it uses up on screen :)
Edit: for number 2, what is your question?
For number 3: ideally you should not have any data hardcoded. Your data members are hard coded in your object classes but all specific data is pulled from scripts or configuration files or data files. For example, you don't really want to recompile the whole thing just because you've decided to change the max team size from 12 to 14, right?
Author
Quote:Original post by lightbringer
To answer that question, you probably first wanna think about how you are going to handle messaging between objects. You're going to have a lot of objects interacting eventually, and it probably isn't practical to have each one keep track of each other object. So you need a way to pass information between objects.
You could have your player object register handler callbacks with the input object, which I think then would result in something somewhat similar to number 2. Or you could, say, push a message that said "player movement detected, forward" into a queue and then get that message from the world processing when you update the world, there advancing the player position and creating a one-shot 3d sound object at the appropriate place.
I haven't implemented this yet, so my advice may not be worth the pixels it uses up on screen :)
Edit: for number 2, what is your question?
For number 3: ideally you should not have any data hardcoded. Your data members are hard coded in your object classes but all specific data is pulled from scripts or configuration files or data files. For example, you don't really want to recompile the whole thing just because you've decided to change the max team size from 12 to 14, right?
Question 2:
for the main application loop.
The game starts with a splash and initialization, before the main app loop, but then the user will want to go to the main menu, to the game, and then maybe back to the main menu. Would that be a good way of deciding which should be running, the main menu, the game, etc.
Also, here I got started on a new idea for my engine.
Tell me if this is a step up from the source I posted before, or going totally the wrong way.
#include "DarkSDK.h"#include "Application.h" //#include "Splash.h"//#include "MainMenu.h"//#include "GameStart.h"//#include "GameEnd.h"//#include "World.h"//#include "Player.h"//#include "Weapon.h"//#include "GameEngine.h"igeApplication Application;void DarkSDK ( void ){ while(Application.LoopStatus() == true) { }}All the header files would include one class (much more organized and easy to find problems etc)
So anything the player does, would be handled with the Player class. Just like a human. Some methods methods (correct term?) might be Walk, PickUpItem, ShootGun, Run, Die, Crouch, etc
Some World methods might be PlaceBulletHole, CreateFire, CreateExplosion, etc.
So when Human.Walk is called, that function moves the player, updates variables, platys proper sound, and detects collision etc all in one.
This is easier, since I can easily do all this with the DSDK.
Playing a sound is as simple as dbPlaySound(iSoundNum);
The weapon class would need to be called from the player class... so I would need to look up on how to create sub classes or something like that? Member classes? I dont know the correct term :P
Honestly I strongly recomend Game Coding Complete, Second Edition by Mike McShaffry published by PARAGLYPH PRESS. It's one of the few books I have read that goes over in detail, the process of creating a game engine using stratagies comertial games use. It goes over a framework for your application, a cooperative multitasking process manager, a resource loader, events and triggers, scripting languages, audio, graphics, and scene graphs.
I can't help you much with C++ because I program in Java, but breaking up the source code into various files is a good start I think.
For game states, you want to implement some kind of game state control. How you do this is totally up to you. It can be as simple as a switch statement or as complicated as a stack where you push GameState objects on top. Depending on the current state you would forego some stuff. For instance, in a single-player game, you could probably stop updating the world, the ai, maybe the time when the player is looking at a program menu.
You don't want to derive weapon from player... they are not related really, except for both being entities. You could derive both from an entity class if you have something you want to make common to all game entities though (since you're working in C++, you may want to implement reference counting in a common base class, for instance). Check out this article to get started on thinking more generically about your game entities.
Good luck.
For game states, you want to implement some kind of game state control. How you do this is totally up to you. It can be as simple as a switch statement or as complicated as a stack where you push GameState objects on top. Depending on the current state you would forego some stuff. For instance, in a single-player game, you could probably stop updating the world, the ai, maybe the time when the player is looking at a program menu.
You don't want to derive weapon from player... they are not related really, except for both being entities. You could derive both from an entity class if you have something you want to make common to all game entities though (since you're working in C++, you may want to implement reference counting in a common base class, for instance). Check out this article to get started on thinking more generically about your game entities.
Good luck.
Author
Thank you so much for the help!
And annonymous Ill check that book out.
I dont think there is, but is there an easy way to store game files in pak, pck, or cab files?
Also:
Here is my reasoning for putting the weapon inside the person.
The person initiates the action of the gun firing, and can hold, and manipulate a gun right.
The gun can't fire by it self! Im trying to give real world aspect to my classes like my book said.
The only thing shooting a gun will be a player object, so it would work right?
And annonymous Ill check that book out.
I dont think there is, but is there an easy way to store game files in pak, pck, or cab files?
Also:
Here is my reasoning for putting the weapon inside the person.
The person initiates the action of the gun firing, and can hold, and manipulate a gun right.
The gun can't fire by it self! Im trying to give real world aspect to my classes like my book said.
The only thing shooting a gun will be a player object, so it would work right?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
