Hello everyone, today I would like to discuss practical game engine design. To kick my discussion off I would like to state that the goal of this thread is to enlight myself and if possible, others on the practicality of certain design aspects... API-Independence: Is it even practical anymore? I feel as if this is sort of split down the middle. Many commercial engines that I see are not api-independent and are either hardcoded in Direct3D or OpenGL. I''ve heard it argued that the reason for this is because now-a-days the graphics cards that are in most systems have good enough driver support for your API of choice and that abstracting at the API is a waste of human resources. I personally feel as if I''d like my engine to be API-independent, simple because it allows for such flexibility with what your engine can be ported to (e.i., consoles). Now I realize that I''m almost certainly never going to port my engine to a console system but I would like the option to be there should I have that opportunity sometime. Another point I''ve heard made is that when companies are designing an engine they want to get it done; and not waste time trying to support multiple APIs when they could be using just one API to its fullest extent. I''ve noticed that with my project, I''m spending so much time working out how to get the abstraction just right that I''m getting nowhere visually. I would like to hear your opinions on the subject. Is it worth it to support multiple APIs? Should your engine be programmed using just Direct3D or OpenGL? If you think that just Direct3D is a good approach (like many commercial game developers), then what is your position on platform independence? Platform Independence: Another good thing to think about is whether you plan to have your game/engine ported to another operating system or platform. For most people, Win32 support is the given. But do you ever plan on porting to Linux? Apple? Perhaps a next-generation console? These are all things to factor into your design. Is it practical to try to code your engine to compile on operating systems such as Linux? If you''re coding your engine with Direct3D only then you''re alienating systems other than Windows and XBox. With my engine I''m trying for platform independence (not trying very hard, but it''s a goal). I guess that''s all I have to talk about for now, anyone have any input? James Simmons MindEngine Development http://medev.sourceforge.net

Thank you for the feedback so far, I feel as if I''m leaning towards making my project utilize only one API. Back before I started this engine I had a DirectX engine and then later an OpenGL engine and they progressed very quickly because when you''re working directly with the API you can get a lot more done in a shorter amount of time. However, I''m then faced with the fact that once it''s all programmed in that API, that''s what it uses. Period. Unless later on I abstracted the API again, but that would be a very huge overhall.

James Simmons
MindEngine Development
http://medev.sourceforge.net

Another point I would like to go over right now is game content. I have always wanted to have scripting a core part of my engine. Scripting not only for in-game sequences but also for scene setup. I got to thinking, would it be practical to make all content delivered by the engine come from script files rather than using internal C++ functions such as loadMesh and renderMesh (just examples)?

For instance, in the application layer there is a mandatory entry-point script that must be executed which loads primary resources such as the main menu graphics, or calls the scripts which setup the main menu and from there the menu scripts load the game scripts. I feel weary about making it to where you can only present content via scripts though. Just a brain dump *shrugs*

While I''m in writing mode, I noticed that the way my engine works and the way that say... the Quake engine works is different. The .exe is the engine, and the dlls contain the game content (if I''m not mistaken) and the way my engine works the .exe is the game content and the dlls contain the engine. Can anyone think of any obvious pros/cons about either of these methods?




James Simmons
MindEngine Development
http://medev.sourceforge.net

In the current iteration of the Caffeine Engine (v3), I''m working to write everything in as abstract a way as possible. I guess the short answer is to create interfaces to your subsystems in the most general way possible, and write implementations as necessary. Of course, it may seem ridiculous to have an overgeneralized interface to a rendering core and a factory that only returns one type of implementation, but it really does allow for future expansion. This applies to platform and API independence alike.

Later,
ZE.

//email me.//zealouselixir software.//msdn.//n00biez.//
miscellaneous links

quote:Original post by Zefrieg
Personally, I would ask yourself what you are creating the engine for. Are you just creating the engine for other people to use? If so, then maybe you should think about just making some sort of game. There are enough good engines out there. If you are doing something for personal use, then just code what you need for your project. If you see that you want something else down the road, then just add it on. It is pretty useless to go about coding in features that nobody is ever going to use.

Damn skippy. Design applies to engines and code just as much as it does to gameplay and content.

API-Independence: As far as pro companies just wanting to ''get it done'' quickly are concerned, I''d guess that actually what they''d go for, in general, would be an API-independent design AND a single implementation; there is, after all, a difference between being *able* to use other APIs, and actually *doing* it. They''d want to keep their options open if possible, while still remaining fairly efficient (no point coding a second renderer when you''ve written no game code to use it).

Platform-Independence: I''m a big advocate of it, partly because I''ve been using Macs as long as (if not longer than) PCs, and thus I''m used to seeing each platform as it really is (i.e. roughly equivalent for most tasks). Macs in particular have untapped potential for the game industry; but I''ve got little in the way of evidence to back that up, I''m afraid.

Part of it is the ''virtual machine'' thing. A platform-independent or API-independent design will always establish a ''common platform'' upon which the game itself is built; from a teamwork point of view, seperation of code like that can be a godsend because two completely seperate teams could work fairly easily on each part, developing the whole in half the time. It also lends to reusability; the basic platform can be upgraded over time to include new functionality, and can be reused across projects fairly easily.

Scripting: As far as providing functionality *only* through scripting, that''s asking for trouble. The best approach would be to establish a load of publicly available methods within your code - LoadTexture/LoadSound, etc - and then ''mirror'' them in the scripting vocabulary. You could even get it set up to work semi-automatically - new methods added to class objects automatically are mirrored in the scripting vocab (though you might need to write some custom compile tools or wikkid macros for it).

DLLs and Exes: One disadvantage of keeping the game in the EXE and the engine in the DLL is that it''s not quite so great for modding; sure, you can still load in other DLLs for mods but then you''re dealing with two DLLs instead of only one.


Superpig
- saving pigs from untimely fates, and when he''s not doing that, runs The Binary Refinery.
Enginuity1 | Enginuity2 | Enginuity3 | Enginuity4
ry. .ibu cy. .abu ry. dy. "sy. .ubu py. .ebu ry. py. .ibu gy." fy. .ibu ny. .ebu