Abstracting a game engine
Author
Hello everyone!
I have a question:
I hear from everyone i know is working on gamedev, that after making the lowlevel parts of a game engine, one should make an abstract "class" "Game".
Does anyone know what that class should contain, how it should be used, and how should it behave?
Thank you for your time regarding this message, and have a nice day!
That will be dependent on features, but the Ogre3D engine is a great example of how to use OOP.
Quote:Original post by nuno_silva_pt
Hello everyone!
I have a question:
I hear from everyone i know is working on gamedev, that after making the lowlevel parts of a game engine, one should make an abstract "class" "Game".
Better make it concrete. ;)
Quote:
Does anyone know what that class should contain, how it should be used, and how should it behave?
Thank you for your time regarding this message, and have a nice day!
Well, I would give it three methods Init(), Run(), and Exit(). And it could have another object (of class "GameState") where you save... erm... the game's current state.
In short, when you design your objects, start at the top and work your way down.
And read this.
Quote:Original post by sevensevens
the Ogre3D engine is a great example of how to use OOP.
I have to disagree about Ogre, with singleton's everywhere it's not a very good example of OOP. Though it has been a while since I used Ogre maybe they've moved away from that.
I would put the logic inside you game class and abstract all the engine stuff away from any actual game logic.
Quote:Original post by nuno_silva_pt
I hear from everyone i know is working on gamedev, that after making the lowlevel parts of a game engine, one should make an abstract "class" "Game".
Does anyone know what that class should contain, how it should be used, and how should it behave?
If you can't figure that out yourself, it might just be an indication that you *shouldn't* have such a class. If it isn't clear what it should be responsible for, a good rule of thumb is to not make the class.
To put your question upside down, if you're writing an engine, why on Earth should it need to know about the game? Wouldn't it be the other way around?
Ajnd if the engine shouldn't have to know about the game, then why should it have a "Game" class?
Of course it depends on how you want to interface between game and engine code, but there's no "right" answer. If you think it'd be logical to make a Game class, and force the game to inherit from that, fine, go ahead. If you can't see the point, don't. Then you can just present an API to the game and let it use it any way it likes, without having to inherit from *this* specific class.
And as said above, Ogre is mainly a good example of singletonitis, which is *not* good OOP design.
Author
Sorry for taking so long to reply, i just got home.
Thank you all for your replies, i did think it'd be a bit unnecessary to make a "Game" class, but a friend of mine who is far more advanced than me asked me if i was going to make one, and i said i didnt know what to put in it, which i still dont.
Also, thank you for the Enginuity Link, it's a great resource for game engine development.
Well, i dont think i have further questions on this topic, except for something mod-development-related:
How do Total-Conversion Mods work on games like Half-Life 2 and such? Because i'd like to have mod-support for my game engine, and for that i'd need to know how they work, but not being a mod-maker myself, i havent a clue.
Would anyone mind explaining please?
Thank you all for your replies, i did think it'd be a bit unnecessary to make a "Game" class, but a friend of mine who is far more advanced than me asked me if i was going to make one, and i said i didnt know what to put in it, which i still dont.
Also, thank you for the Enginuity Link, it's a great resource for game engine development.
Well, i dont think i have further questions on this topic, except for something mod-development-related:
How do Total-Conversion Mods work on games like Half-Life 2 and such? Because i'd like to have mod-support for my game engine, and for that i'd need to know how they work, but not being a mod-maker myself, i havent a clue.
Would anyone mind explaining please?
Driving your game with data that can be edited by tools, and providing access to those tools (or using off-the-shelf tools) makes your game moddable, in general. Specifics depend on the game itself. The more highly data-driven you are, and easier you expose that data for manipulation, the more intrinsically moddable you are.
I would advocate against caring too much about moddability. You can always refactor later. But if you don't have any modding experience, you don't really have any business trying too hard to make something moddable. It will consume a lot of your time, and since you don't how its done, you'll have a hard time building a design that caters to it.
I would advocate against caring too much about moddability. You can always refactor later. But if you don't have any modding experience, you don't really have any business trying too hard to make something moddable. It will consume a lot of your time, and since you don't how its done, you'll have a hard time building a design that caters to it.
I can't speak to half life 2 specifically, but mods are usually done through scripting. Generally this means a simpler, easier to use language (that's also generally slower) running alongside the faster, but harder to change, c++ code.
So you could have c++ handle the really cpu intensive things that are also unlikely to be altered by a user, and have a language like python handle the things a user might want to change. There's a ton of resources out there detailing how to get c++ and python working together. There's other scripting languages too.
To give another example, this is even easier with the .net framework. The really nice thing is that the .net framework allows runtime compilation of code. So you can have scripts written in c# or vb.net or any other .net language, and load and compile them at runtime. You can even put security retrains on the scripts to prevent malicious code.
So you could have c++ handle the really cpu intensive things that are also unlikely to be altered by a user, and have a language like python handle the things a user might want to change. There's a ton of resources out there detailing how to get c++ and python working together. There's other scripting languages too.
To give another example, this is even easier with the .net framework. The really nice thing is that the .net framework allows runtime compilation of code. So you can have scripts written in c# or vb.net or any other .net language, and load and compile them at runtime. You can even put security retrains on the scripts to prevent malicious code.
Author
jpetrie : That's what i've been trying to do lately, to make all my tools and stuff, and make it as moddable as possible.
gharen2 : Yeah, but usually scripting languages are only for stuff like AI and Level Event Information (aka, events on maps), and are usually not the best thing to use to create a whole new game (total conversion).
(the two of you) : Half-Life itself is just a game engine running a client and server DLL (the game itself is 2 DLLs, both half-life and half-life 2), that's why i was wondering what should i do to make that possible with my engine too, and make it easy to work with for anyone who uses my engine.
gharen2 : Yeah, but usually scripting languages are only for stuff like AI and Level Event Information (aka, events on maps), and are usually not the best thing to use to create a whole new game (total conversion).
(the two of you) : Half-Life itself is just a game engine running a client and server DLL (the game itself is 2 DLLs, both half-life and half-life 2), that's why i was wondering what should i do to make that possible with my engine too, and make it easy to work with for anyone who uses my engine.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
