Please excuse the rather ambiguous subject, but I don't quite know how to formulate my problem so briefly. Also, if this has been asked before, I'm sorry. Anyway, I'm making a 2D-engine (C++/OpenGL) with a main goal for supporting side-scrolling/platform shooters and my problem is this: How should I manage specific game content such as enemies, powerups, doodads etc... In smaller games each and every one can easily be hardcoded with different AI-routines collision details and so on. But since I'm making an engine I would prefer some kind of external format for game objects so that I don't need to recompile every time I want to add a new object(just make it availabe as a resource and refer to it in my level files). As of now, I'm letting my engine provide me with game object superclasses. So when I want to design a new enemy I just code a game object class called ENEMY1 and inherit a suitable superclass. The superclass has a few pure virtuals such as "LogicLoop" and "Render" that I need to implement for each new object. This approach makes designing enemies very easy since I can hardcode each enemy's AI and how it should draw itself. However, obviously, this requires me to recompile every time I add new content or tweak any settings which can be quite cumbersome. I was thinking about providing a kind of library of commands for some make-do scripting language. For example, library commands might be simple ones as "move" and "shoot" in addition to querying statements. Then for each enemy I would just have a textfile describing textures, AI and so on. The problem I see here is that for a large amount of different types of enemies (bosses for example) the library would grow huge and if I needed a new boss to to something special the library needs to be recompiled. Also a huge amount of graphical objects describing every possible way an object might want to be rendered in would also need to be available. Since I'm making a rather generic engine its really hard to know in advance what types of commands or graphical objects I might need for a specific game. So, am I being to unspecific in designing my engine? I'd like to see my engine being able to handle a variety of different games but I'm really stumped at this part. Any help would be appreciated /Mekanikles

@Shakedown: Sorry, but I'm a bit of a newbie. Can you explain in more detail? What would the external resources be, compiled files or scripts?

@Telastyn: How would this help? (not to be ungrateful but I really don't know what you mean)

I'm looking into Lua scripting right now, seems like I could run a separate script for each entity in the world but I'm worried about speed. Good/Bad idea?

thnx

Scripting can work. Speed isn't an issue; if something isn't fast enough in Lua, you can always implement it in a compiled language and expose a Lua interface to it.

If I decide to use Lua for implementing AI how feasible is it to use for many small objects? I can really see the use for it in scripted scenes and enemy-AI but what about, say, bullets?

Imagine a bullet where it, in addition to drawing itself, needs to draw a limited "trail" behind it, constantly updating the position of the trail-effect particles. If say 100 of these bullets occupy the screen at the same time, is it really possible to use an "instance" of a script for each and every one of them in realtime? And since the effect-particles would also have their scripts run it amounts to a hell of alot of scripting for very simple tasks.

Should I opt to hard-code some objects and use scripts for more complex enemies? Is it realistic to be able to add new objects to a game without recompiling and still get reasonable speed?

Sorry if I'm rambling but I feel I could use some directions :)

thnx again

The bullet's motion can be controlled by scripts. Rendering and particle effects should probably be part of the engine (they only need to access the bullet's location to render it and generate particles at its location, and particles and effects don't need to be as flexible in their behaviors).

@Telastyn: Ok, that's generally good advise, but I do think the object is interested in how it is rendered: Whether or not is should be animated, use shaders etc...

@Vorpy: Thnx for clarifying. Then doing as you suggests, rendering needs to be centralized, i.e. a game object should be able to describe it's rendering process entirely from the resource file since it cannot control the rendering directly. Is this a good approach, seems like the rendering could be rather bloated if the engine should cover all possible ways of rendering an object.

So, do you have each of your objects rendering themselves? I have always wondered how this is done in games. I've heard this is how it's done but my hang up:

with directx you have just one beginscene/endscene and all the rendering must be done here. (correct?) If this is true, you would need to pass every single object into that one rendering function. This seems insane when considering the amount of stuff that could potentially go into each frame.