So, engines again...

Started by
0 comments, last by iNsAn1tY 20 years, 4 months ago
So, I was thinking the other day, as usual. I thought of all the ways you could separate game logic from engine code and looked at some examples. Am I right in thinking that to create a mod for Unreal Tournament, you have to use UnrealScript? That's the only way of doing it, and there's no actual C++ to be written? If it is, is that the way a moddable C++ engine works? Please tell me if I'm wrong, but I can't see any other way of doing it, as a C++ engine is just a collection of classes, which happen to be used by a game executable. This would mean that each mod or game would need to be a separate executable, which doesn't work for modding, as a) you couldn't switch between mods, and b) it's stupid to have an executable for every mod. There's a couple of ways of coding an engine I know about. First one is to have the game code in a DLL, and the engine in an executable. Then the executable sends messages to the DLL, and vice versa (Quake 2/3 style). Or you could have the engine as a collection of classes, in a library, and include that into an executable. So it would seem that if I want to make a moddable C++ engine, I'd need to use the Unreal method, and write my own scripting language, which I really don't want to do. On the other hand, if I wanted to write a simple, reusable OOP engine, I could just package it in a library, and include it in different projects. Is this right? It'll be nice to have this figured out, because then I'll know all the basic methods of creating FPS engines, and I'll know which method is the best to use, so I don't end up wasting my time taking the wrong path (again ) EDIT: Also, I assume that the Enginuity engine fits into the "C++ engine in a library which you link to when you're compiling your project" catagory? It's not moddable? That would explain a lot, if it's true. Windows 95/NT - 32 bit extensions and a graphical shell for a 16 bit patch
to an 8 bit operating system originally coded for a 4 bit microprocessor,
written by a 2 bit company that can't stand 1 bit of competition. [edited by - iNsAn1tY on December 12, 2003 8:11:38 PM]
My opinion is a recombination and regurgitation of the opinions of those around me. I bring nothing new to the table, and as such, can be safely ignored.[ Useful things - Firefox | GLee | Boost | DevIL ]
Advertisement
quote:Original post by iNsAn1tY
First one is to have the game code in a DLL, and the engine in an executable. Then the executable sends messages to the DLL, and vice versa (Quake 2/3 style).


Isn''t that the answer to your problem ?
The executable is always the same, no matter what Game/Mod is running. The executable can keep running, while you are changing from one mod to another.

Then you could of course distribute your engine over several DLLs, stuff the game in another DLL and use one executable to do the communication between those. But I fail to see what advantages this gives or where exactly the difference between the engine in exe + various dll plugins, game in dll and this approach is. You''d still need your main entry point in the exe and would kinda just degrade everything, even your usual engine-core to a plugin, which doesnt make sense to me. Anyone who has used this approach here who could enlighten me ?

Oh and the best method should be what suits you best. If your doing an FPS (as you said ), with the need for modding, but you dont want to write a huge scripting language (or just use LUA for example), then using DLLs for your game-code would be the obvious choice.
If doing some kind of RPG, modding via scripts and data-file editing could be the better choice.
For a game without modding abilities the static lib is a good choice, because it''s just very easy to use.

This topic is closed to new replies.

Advertisement