# How to manage diverse resources? (Enemies etc...)

This topic is 3626 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

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

##### Share on other sites
One possible way is to use the Factory Pattern. Using a Factory to produce your game objects allows you to store in an external resource file the necessary information for those specific game objects. In the engine you could then make calls to a Factory and the Factory would produce the objects defined in the external resource.

##### Share on other sites
Step one would be to separate the model and the view. Things are much, much simpler to work with when one class solves one problem.

##### Share on other sites
@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

##### Share on other sites
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.

##### Share on other sites
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

##### Share on other sites
It's sort of difficult to describe how it will help. Since a class solves one problem, it's easier to separate responsibility, it's easier to re-use that class internally or in future projects, it's easier to design since you're less tempted to make a variable mean two different things (coordinates on screen == coordinates on playfield for example).

And in general, coupling game objects with render objects makes AI, networking, and serialization super difficult because they don't care about how/where stuff is rendered.

##### Share on other sites
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).

##### Share on other sites
@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.

##### Share on other sites
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.

##### Share on other sites
Quote:
 Original post by Mekanikles@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...

A game objects' representation has absolutely no basis on what its actual effect in game is.

##### Share on other sites
This has been a struggle for me to figure out. If you separate the data from the presentation, what keeps track of, for example, the current frame of the current animation for a given object?

Do you construct both a data object and an associated presentation object? Should you have some kind of "rendering" object which can render a given object?

What have some of you done?

##### Share on other sites
Quote:
 Original post by MaxamorThis has been a struggle for me to figure out. If you separate the data from the presentation, what keeps track of, for example, the current frame of the current animation for a given object?

That doesn't depend at all on the state of the game. Presentation gets it since that's all that cares.

Quote:
 Do you construct both a data object and an associated presentation object?

If both are needed. My AI and pathfinding and network and dedicated server don't give a rat's about the presentation. My UI renderables don't have any game object representing them. Some of the UI displays an object one way and a different way in a different spot (minimap/info bar) or at different zoom/resolution levels...

Quote:
 Should you have some kind of "rendering" object which can render a given object?What have some of you done?

Usually, a factory that knows about the game and the rendering is passed a game object and it returns a sprite/animation/model for use. That also allows the factory to be the chokepoint for knowing what's been created, and changing the creation based on rendering API used.

##### Share on other sites
Hi Mekanikles,

A few years ago (ok 7 or 8 years ago), I wrote a side-scrolling shooter, and I have a solution you can look at.

http://webpages.charter.net/wwjennings/AlphaSrc.zip

If you look, I have multiple files, and the ones you should look at are: Enemy.cpp, Enemies.txt, and stage1.txt.

Enemy.cpp handles the enemy's functions, movement, firing, etc.
Enemies.txt describes the Enemies (speed, strength, weapons, etc). Stage1 (and 2, 3) describe when and where the enemies come onto the screen.

What I have done is used part scripting to design the enemies, and part source code for each enemy type. I use a list to keep all the enemies that will be on the screen (and a time when they should appear), and a list to describe each enemy on the screen.

You're welcome to look at the code. I hope it helps. Feel free to contact me if you have any questions. You can download the actual game at http://webpages.charter.net/wwjennings/Alpha.zip

This was just a fun project for me, nothing more. Don't expect too much!

##### Share on other sites
First, I'm going to agree with Telastyn. While you might think you're 'drawing your game objects', the correlation is weak at best. For example, UI widgets don't appear as game objects at all but get rendered; things like timers and invisible kill zone or clipping zones are game objetcs but do not render; items may render differently in different areas of the map, lighting conditions or when players are nearby. Your game logic and rendering should be as decoupled as you can make it. For a 2D scroller your renderer can probably query objects for the drawing components (if any) those objects require and their Z-order, or something of that sort.

Now, onto the question you actually asked ;). There are three ways to solve this one.
- What you're doing now: have base classes in the engine, and derive classes from them for your game. You have to compile the whole thing each time which is a bit of a pain.
- Similar, but put the game code in a plugin, which contains the classes for the game (not the base classes though). When you start the game, it simply references the engine as a library and plugs in the game objects it creates into the engine. Now you only have to recompile the game code, not the engine. The engine needs to support all the hooks your game classes need, though.
- Scripts. Scripts allow you to define objects' behaviour in a way which your engine will interpret at runtime, and therefore you have to recompile it rarely. This used to be a hard route (writing good script interpreters is HARD), but the presence of standard scripting tools like LUA make this much better than it used to be.

Quote:
 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.

A lot of people have fallen into this trap. Write your engine and your game alongside each other, so that at least the engine runs one game, instead of trying to write something so general you give up in frustration before you get a real product at all.

##### Share on other sites
@BeerNutts:
Hey, nice of you to share source code, though it doesn't quite sound like what I'm after, I will certainly look into it thank you.

@Bob Janova:
Thanx for a great answer, I have tried to keep rendering code and logics separated but I've actually never considered the case of timers and non-render objects. I guess I've thought of them as "invisible" objects that have an empty render function.

Do you have a suggestion how I should implement it? (sorry if I sound lazy, but I feel I've never gotten a "correct" answer on how to do things) As of now I've done it by letting the objects themselves contain the rendering code (solution 1), calling low-level graphics routines, for example as such:

//These are methods in a game object classpublic void doLogic(){   position += velocity;   if (damaged) color = COlOR_RED; else color = COLOR_WHITE;   framecount++;   if (framecount >= 10) framecount = 0;}public void renderMe(){   Engine.Graphics.drawSprite(sprite[framecount], position, color);}

Then the engine calls renderMe on all objects (sorted by Z) as fast as it can and doLogic at a fixed frequency, maybe 15-20 times/sec.

This obviously has its flaws since there's no separation between objects and rendering so I extended this by letting the GameObject register different Drawables in the constructor and manipulate them via the doLogic, like so:
//Constructor in a game object classGameObject(){   anisprite1 = new AnimatedSprite(resource);   Engine.Render.registerDrawable(anisprite1);}//This is a method in a game object classpublic void doLogic(){   position += velocity;   anisprite1.setPosition(position);   if (damaged) anisprite1.setColor(COLOR_RED); else anisprite1.setColor(COLOR_WHITE);   anisprite1.increaseframe();}

By doing this I don't have to have any rendering connected to an object and all the engine have to do to render is loop through the registered Drawables. Still, this is just an abstraction from the first example and things are still hard-coded. Also I need drawables for every thinkable way I want to draw things. I do not know how to incorporate shaders and such by doing this.

The other thing I'm thinking of is letting a GameObject just be a script that can control a PhysicsObject and a GraphicsObject. The position, mass, collision data and such reside in the PhysicsObject and the GraphicsObject contains drawing information. I still don't know how exactly to render "special stuff" (shaders) but this way an object neither needs to be in the physical world nor be visible (such as an timer or a event script). The relations between these three object are also a bit diffuse for me other than letting the GameObject contain the other two.

As allways, I'm thankful for all the help I can get. Concrete examples are much appreciated.

/Mekanikles

On a side note: I do think that UI components can be world-objects. Just without any physics (not necessarily). I'm planning to build my engine with "Scene layers" so that each scene is a separate world placed upon each other. The visible game-world is one Scene, while the GUI and menus are Scenes in front of it. They can still communicate via events but the GUI is handled by a parallel world, so to speak.

[Edited by - Mekanikles on March 20, 2008 7:34:42 PM]