Sign in to follow this  

Object Management

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

As many of you know, I'm working on a 2D RTS engine in C++. I'm not using any specific API yet, as I'm coding it to be API independant via interface classes. Anyways, I come with a question that most likely has been asked before. My question is simple. What's the best way to manage dynamic objects? A little background first: My Object system is completely internalized and modular. The method by which dynamic objects move, is by way of an event system which handles itself. The F_Event functions are friends of the classes that they are meant to handle(such as an F_Event_Movement has an isPossible() that is a friend of F_Actor which can move). This allows for restrictions of the types of events that can be fed to specific classes. For instance, I cannot place an F_Event_Movement into a non-moving F_Object. Doing so would cause an error during compiling. What I need to know, is how do I organize the static and dynamic objects in my world? I can store all of them in a list, iterate through them and process all of their event queues. However, this is very inefficient for finding out where a specific unit is on the world map. On the other hand, I could store all the units in a world-sized matrix and iterate through the matrix tile-by-tile executing the events when I find a unit in the world. This is ineffiecent on two reasons a) I'm going through more loops than units and b) I might call a unit's EventQueue request several times(if a unit is larger than a tile). The method that I'm currently leaning towards, is a hybrid of the two: Have a matrix of lists(for multiple units on one tile) that hold pointers to objects in a list of all the objects in the world. That way, I get the best of both worlds: speed in iterating through them and speed in finding their locations. Additionally, if I use a list to store all of the units, I can easily add and remove units from the list with very little overhead. What do you guys think?

Share this post


Link to post
Share on other sites
I'm still messing around with map objects myself right now, but let me tell you what I've done so far.


First, I have an abstract class called MapObject. All the different objects inherit from this class. At this point, I have PlayerSprite, NPCSprite, StaticObject, and DynamicObject as my inheriting classes. (the difference between static and dynamic is that dynamic is composed of more than one frame).


I have a list of MapObject pointers that I have in my map class, allowing a map to have as many or as few objects as I'd like. When I update the state of the game, the first thing I do is call a sort function on that list, and I sort it by the y-coordinate that the objects are located at. The reason for this is that I want to draw my objects from top to bottom, so that objects can partially or fully be drawn over one another.


So when I'm drawing my objects, I start with the head of the list and I look at the y-coordinate, x-coordinate, object height, and object width to determine if any part of the object should be visible on the screen. I iterate through the entire list each time I draw a frame to find the objects that need to be drawn.



And that's as far as I've gotten. I have the infrastructure for the code there and I'm getting ready to implement this system in a few days. It's probably not the best object management system ever, but I've given it some thought and I think it will work out ok. I'm up for discussing a better methology or alternatives to this system if anyone has one. [smile]

Share this post


Link to post
Share on other sites
I haven't used this on a wide scale yet but my game objects belong to multiple lists at the same time. For example:

struct object
{
// for the big list that ALL items belong to
object *next_obj;
object *prev_obj;

// a list of objects this object contains
object *contents;
// a reference to the object that may contain it is usually helpful
object *container;

// the list parts we use for objects that are contained
object *obj_next_content;
object *obj_prev_content;
};

// a global instance of a list of objects
object *object_list = NULL;

// create a new object
object *new_object( ... some initializers if you want )
{
object *new_obj = new object;

// do the initialization etc.
// ...

// add it to the big list of objects
// should probably sort it right away by its location
// but this is a quick example
if ( object_list )
object_list->prev_obj = new_obj;

new_obj->next_obj = object_list;
object_list = new_object;

return new_obj;
}

// insert an object into another object
void object_to_object( object *container, object *item )
{
// sorting doesn't really matter for item contents
// unless you really need it

if ( container->contents )
container->contents->obj_prev_content = item;

item->obj_next_content = container->contents;
container->contents = item;

item->container = container;
}

// remove an object from a container
void object_from_object( object *container, object *item )
{
if ( container->contents == item )
{
container->contents = item->obj_next_content;
}

if ( item->obj_prev_content )
item->obj_prev_content->obj_next_content = item->obj_next_content;

if ( item->obj_next_content )
item->obj_next_content->obj_prev_content = item->obj_prev_content;

item->obj_next_content = NULL;
item->obj_prev_content = NULL;
}

// free an item from the world
void free_object( object *obj_free )
{
// does it belong to a container?
// if so remove it
if ( obj_free->container )
object_from_object( obj_free->container, obj_free );

// now remove it from he big list
if ( obj_free == object_list )
{
object_list = obj_free->next_obj;
}

if ( obj_free->prev_obj )
obj_free->prev_obj->next_obj = obj_free->obj_next;

if ( obj_free->next_obj )
obj_free->next_obj->prev_obj = obj_free->obj_prev;

delete obj_free;
obj_free = NULL;
}


obviously the STL comes in handy and wrapping this up into an object class is preferable but as this is more of a concept than actual useable code I think this shows what I am doing a little better.

Characters and items alike stem from a common base class whos objects belong to a large sorted render list. This is helpful because it is quite easy to pop things out of the list and push them back into it without caring what it actually is. Upon further reflection though, I have been pondernig having things contain render objects instead of being one although I am not sure of any useful performance gain.

Oh well, hopefully that helps out.

Share this post


Link to post
Share on other sites
Quote:
Original post by Tarviathun
I wouldn't suggest sorting every frame. That's very VERY costly performance-wise. Try a presorted method, such as the matrix or a BTree.



Hmm. I don't really agree with you. I'm not sure what the O notation for list.sort() is but for the sake of argument let's assume it's n*log(n). Also remember I'm using a list of pointers to objects, not the objects themselves. Let's say I have an average of 64 objects on a map. Then that would be O(64 * log64)) = 384, which isn't too gigantic. Besides, the time to draw the frame would be the real bottleneck I imagine. :p


Using a pre-sorted method would not work, because my objects (sprites for example) change their position and thus need to be re-sorted.


Like I said I'm sure my method is not the optimum one, but it's what I've come up with and it will work. If there are any better solutions out there I am eager to hear them. [smile]

Share this post


Link to post
Share on other sites
Quote:
Quote:
Original post by Tarviathun
I wouldn't suggest sorting every frame. That's very VERY costly performance-wise. Try a presorted method, such as the matrix or a BTree.

Hmm. I don't really agree with you. I'm not sure what the O notation for list.sort() is but for the sake of argument let's assume it's n*log(n). Also remember I'm using a list of pointers to objects, not the objects themselves. Let's say I have an average of 64 objects on a map. Then that would be O(64 * log64)) = 384, which isn't too gigantic. Besides, the time to draw the frame would be the real bottleneck I imagine. :p

Maybe I am arguing over wording here but sorting every FRAME is a waste of time especially if not all of the objects move every frame. Instead have the objects pop themselves from the list when they move and reinsert themselves based on their new position. This is really easy if you have a doubly linked list and perform a binary search from it's last location.

Share this post


Link to post
Share on other sites
This I would agree would be a better method. Having your list sorted on initialization, and then re-inserting objects as needed in the proper places. Maybe every x frames re-sorting the list to remove any errors.

That aside, the way I render my objects is have the object that needs to be rendered add an event to it's stack(changed from queue so that render call is always last) adding itself to the vector of lists(oriented towards depth. eg tiles are at index 0, ground objects at 1, aerial at 2, etc). So far, that's the method I've got on paper, nothing coded yet.

I'm still tackling how I'm going to organize my objects. Should I have a global list of F_Objects? Should I subdivide them into something else? The reason why I hestitate to implement your method evillive, is that this is going to be an RTS with(theoretically) hundreds of units on the screen. I need something that's good for managing large numbers of objects. Same thing for your method, Roots. I have to be very performance aware.

A thought that occured to me, would be implementing a list of all the world objects, and then have a list of pointers for active and non-active objects(which ones need to be updated on a frame-by-frame basis). Finally, have the object manager hold the tile matrix which defines movement, where objects can place themselves on tiles easily. This allows for a simple location lookup(the tile matrix) and priority in processing. Does this sound like a good method?

Share this post


Link to post
Share on other sites
Hmm, yeah I think that would probably work better actually. I could even set a flag between frames to indicate that a sprite or whatever has moved to a new tile/location and then make sure I only pop/insert those objects which have changed position. Thanks for the idea! [grin]


Quote:
Original post by Tarviathun
That aside, the way I render my objects is have the object that needs to be rendered add an event to it's stack(changed from queue so that render call is always last) adding itself to the vector of lists(oriented towards depth. eg tiles are at index 0, ground objects at 1, aerial at 2, etc). So far, that's the method I've got on paper, nothing coded yet.


I'm a little confused what you mean here. I understand the data structures, but you are you saying you're only adding events to the object's stack if that object is going to be rendered in the next frame drawn? You need to update all your objects whether they are drawn on the next frame or not, otherwise sprites and the like won't move around unless they are in the current frame, which would look weird. Maybe I'm misunderstanding you though.


Quote:
Original post by Tarviathun
I'm still tackling how I'm going to organize my objects. Should I have a global list of F_Objects? Should I subdivide them into something else? The reason why I hestitate to implement your method evillive, is that this is going to be an RTS with(theoretically) hundreds of units on the screen. I need something that's good for managing large numbers of objects. Same thing for your method, Roots. I have to be very performance aware.


Hmmm, well I'm not really sure of a better way to organize your objects. If I did, I would probably be doing that instead of the method I'm working on right now. Personally though, I stay away from global anything. The global namespace is a sacred entity, not to be adulterated with a bunch of global variables. =D


Quote:
Original post by Tarviathun
A thought that occured to me, would be implementing a list of all the world objects, and then have a list of pointers for active and non-active objects(which ones need to be updated on a frame-by-frame basis). Finally, have the object manager hold the tile matrix which defines movement, where objects can place themselves on tiles easily. This allows for a simple location lookup(the tile matrix) and priority in processing. Does this sound like a good method?


Again the whole "don't update an object if it's not on the screen" has to be taken with a grain of salt. I don't know the details of your game, but the only way I can think of implementing this type of "don't update what you don't see" is to keep a timer associated with each object, indicating the last time it was updated. Then when you are updating your on-screen objects, you look at that variable and compare it to the time of the current update, and based on that you update the object a certain number of times so it gives the "illusion" that it has been updating itself off-screen.

However, this has a critical fault in that an object that is off-screen can *NEVER* walk onto your screen by itself, you have to walk onto the object. And if you update the object X times, maybe the object has moved and now is in a different location, so you end up not drawing it after all, even though technically you should have seen it. Yeah, I really think it's a BAD idea to try and get by with only messing around with objects that are on-screen only.



Since your main problem seems to be having a large number of objects, I suggest you spend some time trying to think of ways in which you can reduce that number. For example, let's say you have a turrent which shoots a barrage of 5 missles out to a target. Instead of labeling each individual missle as an individual object, group them together into a "meta-object" so you only have to update a single object rather than 5.

Share this post


Link to post
Share on other sites
Since I'm in a long-winded mood ;-)

I thought I might briefly go over the "object-system" used in Morning's Wrath.

-Objects
worlds and such are broken down into a hiearchy

->Map :the map structure
-->Tile :the tile structure
--->Base :pointer to a ground structure (optionally null)
--->Overlays :pointers to ground structures (optionally empty)
--->Item :pointer to a sprite object (optionally null)
--->Character :pointer to a sprite object(optionally null)
--->UnderSprites :pointers to sprite objects(optionally empty)
--->OverSprites :pointers to sprite objects(optionally empty)
--->Structure :pointers to structure object(optionally null)

the three classifications of objects that can exist on a tile are,

Sprite - heavy,named,managed,animating,moving,(optionally subclassed)
Ground - lightweight,TileSet Pointer and Localized TileSet Cell
Structure - lightweight,TileSet Pointer, Localized TileSet Cell, Area (walls)
Displacement


-The Setup

It should be noted that MW has mutal exclusion for characters and structures on a single tile, this was done so that characters and structures would not have to be sorted, greatly improving performance.

The different storage slots on a tile, are used to define draw order,
e.g. grounds are drawn first, items always under characters, structures over all, etc.

this system, while it removes the need for such things as pixel perfect collision detection, complicates things such as motion, since a character cannot exist anywhere but in the center of a tile, while at rest, so it makes moving from tile to tile an 'atomic' type action, even thought it is done smoothly.

-Rendering


based on the camera position the 'looking-at' tile is determined, and then an
'action area' is computed from that center tile.

all tiles in the action area are then rect-tested against the screen

lights within range are also collected, and light values computed for each tile within the view

ground and tile overlays are drawn

then, all items, characters, structures, etc are rendered using the LORM rendering pattern taking into account object area displacement, then all are rendered.

hope that gives some insight lol, or not =)

Share this post


Link to post
Share on other sites
Roots:

I get what you're saying. I think what I'm getting at, are objects that are information data only, that don't change. For instance, a spawn point for the player is not going to change on a frame by frame basis, so it wouldn't need checked for change. A soldier unit, however, would need to be. His sprite would need to be updated, if he's moving his path needs to be updated, you get the idea. The difference between the two, say, is that the soldier would need to know where a tree is because it affects things such as movement and targetting, but the tree doesn't need to be checked for change. So, I get into the problem of figuring out where I need to put the tree and how I eleminate that overhead of checking that tree for change, because it's still in the object system.

Which is where the active/in-active dichotomy comes in. Basically, the objects that don't need to be updated are needed because their location affects dynamic objects' behavior. The location would be handled by the matrix, it'd be a quick lookup, and the overhead of checking those static objects would be eleminated by seperating it from those that do need to be updated. However, the problem remains of how do I store everything? To which the simplest answer would be in a single list that holds all objects in the world. The memory footprint could be decreased by using pointers and not copying anything, but organization-wise, the more things you add on the closer to hell my life gets.

A clarification on the confusing wording about how I render my objects, is that when they're updated, they put an event that adds themselves the renderer. This is handled last, because I don't want to render an object at (x,y) when in fact it's at (x+50, y+50). This is where the stack comes in. I don't know how many events I'm going to have per object, and I want the rendering event to be last. So, if I used a queue, I'd have to figure out when the object was done with everything, and then add the render event. However, with a stack, I don't need to worry about it because it's first in, last out. The depth of the objects is sorted by where it tells the renderer to add it, in the z-layer. The z-layer I was thinking of having sorted by a vector who indices start with ground and move upwards. Personally, I don't worry about if I render objects from left-to-right or top-to-bottom, because as long as they get rendered, everything's ok. They know their location and that's all the renderer needs to put them on the screen.

EDI:

I pretty much have the same system down on paper for rendering and setup. I just need to find out how they all interact, hehe. My approach to minimize the system hit, would be to organize all the objects in a manner where it's easy to find them. eg, have a matrix that holds their location, active vs non-active lists. I can render them once I know where they are and what they're doing by adding them to the renderer's queue, but I can't think of a decent way to make hundreds of units interact in a way that's not ridiculously inefficient.

BTW, what does rect-tested mean and what's your action area?

Share this post


Link to post
Share on other sites
Maybe I am doing something totally wrong here or missing something so maybe you guys can help me out. I have not had any problems so far but at most I have had 30 "sprites" on screen at a time but for me the big bottle neck is the actual drawing (SDL 2d cus OpenGL is actually slower on my card). The object management is actually pretty lite, here is a brief outline:

large object list consisting of references to every potentially visible item currently in the game world (the map). Each object has a virtual update function that gets called every frame.

a map of tile objects. each tile contains a reference list (sorted by y then x axis) of objects on it as well as base information(base image and details drawn before sprites) and overlay (drawn over sprites) objects.

Every frame loop through the large object list and call the update function for each object.

If an object moves and it's new position is on another tile, it pops itself off of the current tiles container list and inserts onto the new tiles list. When an objects position changes, it also pops itself from a large render list of all objects sorted by y then x axis and reinserts itself via a binary search from it's last location in the render list based on direction of travel.

Figuring out which object to start drawing first depends on how much overdraw I have to allow for (largest sprite size). depending on yours you just grab the object list from the first tile you want to draw and use the first object as the head of your objects to render loop and end at the last object on your last tile (this is precomputed before i begin the loop). Then my rendering loop consists of drawing the base of the map, then the objects, then the overlays which for me are handled just like drawing the tile base.

Like I said, maybe I am doing something totally wrong here or maybe I am missing something, but I don't see this being a problem for me later on.

Share this post


Link to post
Share on other sites
Quote:
Original post by evillive2
Maybe I am doing something totally wrong here or missing something so maybe you guys can help me out. I have not had any problems so far but at most I have had 30 "sprites" on screen at a time but for me the big bottle neck is the actual drawing (SDL 2d cus OpenGL is actually slower on my card). The object management is actually pretty lite, here is a brief outline:



Yes, drawing is almost always the operation that takes the longest to perform. That's why I stated earlier that it wasn't *that* ultra-super-important to try and cut corners when you are updating your objects, because the real bottle-neck is in the drawing.

Share this post


Link to post
Share on other sites
Quote:
Original post by Tarviathun
BTW, what does rect-tested mean and what's your action area?


rect-tested, means that we do rect-in-rect tests for all tiles and other graphics before they are sent to the renderer, they are rejectect if they are entirely outside the screen, (the fastest way to draw is not to draw ;-D)

our action area, is a diamond shaped sub-segment of the map that is ncols and nrows big, this area is determined by doing calculations to decide what tile the view is looking at, and then selectiing a certain displacement negative and positive from that center tile, anything that is inside the action area (which is much larger than the view area) gets proccessing done to it, AI, etc

things outside the action area only get minimal proccessing, which ususaly come from outside events *such as a timer object elapsing, etc*

here is a diagram that might visusalize things better...

Share this post


Link to post
Share on other sites
Wow, that's an interesting idea about doing minimal processing outside the action area. But how exactly do you define "minimal processing"? The only thing I think I need to concern myself with in my game (at least for now) are sprite movements outside the view area. When an object is inside your action area, what additional processing do you to to those objects?

Share this post


Link to post
Share on other sites
what you do is really up to you,

you could have multiple concentric areas,

think of it as Proccessing LOD, the innermost visible layer proccesses most heavility (all AI features, audio, etc,etc) next level, only tracking for the player, third level, only events that are sent to it *that is, it wont be polling anything*

the thing that makes this method great, is you can define a region as a sub-segment of your map, by finding the center of your view, the normal 'costly' method is to check the distances of everything to where you are, which eliminates the value of area-based action (since you have to examine each sprite) with this, you can query outward as much as you want, as long as your map tiles know what is on them.


A good way to think about how this would work, is like...

Zombies =D

at least how they are classified in Night of the Living Dead, that is

if they are far away and with no 'stimulus' they kinda just lumber around (very little action) but when somthing gets close to them, they become more excided (heavy more precise proccessing) =D

Share this post


Link to post
Share on other sites
That's actually a really cool idea, EDI, and thanks for the explanation. I sorta feel stupid about it.

I pretty much believe that everyone's right and I'm wrong about what to worry over. I'll see if I can combine a lot of these ideas and concepts into a single functional RTSUnit manager.

I'll probably utilize a matrix/list idea, where I sort the matrix by location and the object list just sort of sits on its own. For the active area idea, I might not be able to do that, seeing as I'm making an RTS engine and I need to constantly keep all units up-to-date. However, I could easily create a function that generated a list(much like the way I render tiles) based on the camera location, where I could pass the manager's update function that list instead of the whole unit list.

The main reason why I'm so concerned about efficiency here, is pathfinding. It's really really costly and I'm worried that I'm going to do it in a very poor manner, and cause the whole system to lag. I'm also afraid that I don't have enough knowledge to find a more suitable method to find paths other than basic A*. Anyways, that's why I'm worried about it.

Share this post


Link to post
Share on other sites
this may not help you, but it is somthing to 'chew' on.


if i had to guess i would say at least 80% of the time, when moving a unit, you are moving it in a straight line.

with this asumption, you can first do a cheap *breshenhem(sp?)* line algorythm to test start point to end point for no obstructions, if there are no obstructions, simply walk that line that was formed, and dont bother doing A*

if there is however, then fall back on A*, using progressivly complex forms of pathfinding is a good idea i think, much in the way you first test for being inside a rectangle, before testing pixel-perfectness, when hit testing.

if you assume that most of the time your paths wont be complex (which i belive is true, depending) and then implement a 'train' of methods that start very simply, and can 'fail fast' if it is found that it cant make a path, and then fall back on the next, the last being full-map pathfinding, etc.

Follow me?

Share this post


Link to post
Share on other sites
Hi guys,

I was about to make a new topic about a similar problem, so I'll just add it here. I'm currently working on a tile-based game, and I have built a generic tile-based engine for it so I can use it in future projects as well. Now the problem I'm having is actually a software architectural problem, but I think it better fits in this forum. I'll give an overview of the engine.

I have a basic Landscape class, which loads map data from a file and prepares them in memory for fast an efficient rendering. It loads tile textures and object textures into memory and creates all the objects (walls, towers, trees, etc) on the map. Now to keep my engine game-independant, I use a base ObjectInstance class, that only holds rendering information (how to render the object, its x/y size, ...) but nothing else. Objects are managed by placing a pointer to the ObjectInstance located on a particular tile in the main tile array. Using a list would be possible too, but it won't solve my problem.

Of course, in my game, I don't just use ObjectInstance's for all my objects. I derive classes from ObjectInstance like Wall, Unit and Tower, and I add additional functionality to these classes. The problem I'm having now is that, because my engine doesn't know derived classes, it can only return a pointer to an ObjectInstance when I'm for example asking for the object located at (25,3). So if my player damages another unit, there's no way I can call the doDamage() function on Unit. Of course I can do a dynamic_cast, but that would be quite an awkward and ugly solution.

So there's my question: how do you guys manage a generic list of objects made out of different derived classes, without using ugly language structures (dynamic_cast)? Another solution would be to keep different lists for each object type, but that would be pretty unefficient as well. Using an abstract base class is impossible too, as functionality can differ greatly between games.

So how would you solve or have you solved this problem? Thanks a lot!

Share this post


Link to post
Share on other sites
Well, lets see if I have this right.

>>The problem I'm having now is that, because my engine doesn't know derived classes, it can only return a pointer to an ObjectInstance when I'm for example asking for the object located at (25,3). <<

from that line, i gather somthing like this is happening


ObjectInstance* oi=landscape.getObject(x,y);

but in reality, the object there is of type, oh, 'BossCharacter', so you would have to do,

BossCharacter* bc=(BossCharacter*)oi;

which works (note i know that doing it that way is 'unsafe')

so, if you would rather not do that cast, your only solution is to create a subclass of your Landscape class, that is more game-specific, and within that subclass write specialized methods, such as

getBossCharacter(x,y);

which does the cast for you,


I think your problem might be, that while you are allowing for subclassing to happen to your map objects, your not allowing for that same functionality for your map, and other objects, for instance...



game layer - [sprite]
engine layer-[map][object]

without subclassing map, you dont have a place to put, game specific map logic.


am I on the right track?

Share this post


Link to post
Share on other sites
Exactly, you're spot on. A cast would solve all my problems, but I've been taught hundreds of times that having to do a cast is a sign of bad design, and indicates that you should rework your engine. So it's indeed the (BossCharacter*) cast that I refuse to use. I already use a derived Landscape class, but I always end up with real ugly code.


The first approach I tried was the following:
When creating a boss character in the derived Landscape class I'd get the following sequence:
BossCharacter *b = new BossCharacter();
bosslist.push_back(b);
addObject(b);

With addObject(ObjectInstance*) a function from Landscape that adds the character to the engine and the map. If I'd need the specific boss functionality later, I'd pick the boss from the list. The problem with this is of course that it simply doesn't use the efficient object access provided by Landscape, and that I need to manage a whole bunch of lists for all object types. Very cumbersome.


The second approach I tried was that I'd put a virtual issueAction(Action) function in the basic ObjectInstance class, that I overrided for all the derived classes. Action was just a container with some data that indicates what the action might be. The problem with this is flexibility. If, for example, one character was going to give an item to another one, I'd have to somehow pass on a pointer to the other character AND the item in issueAction(). Every action required different data to be passed on, resulting in a lot of void pointers and casts and crap like that.


I couldn't get the second approach to work properly, but the first one did. It was just bloody ugly and became even uglier when the project grew, so that's why I made the post.

Share this post


Link to post
Share on other sites
Well, I can't say much about

'Good Design' Versus 'Bad Design'

however, I think you are being a little over-critical,

when developing game engines it is easy to get consumed with perfection, and thus lose sight of what is important, that is, making an engine that works.

Our engine for instance, is not free of having to cast, in fact we have to cast alot, this is because cetain levels of the engine reference things at certain levels of thier extension.

The only dangerous thing about keeping an array of ObjectInstance objects that are of different subclasses, is accidentially casting them wrong.

While it does result in more storage, in some areas of our engine, we keep secondary 'non-owning' lists.

That is, we have our main objects list, Objects

and then we might have another list of objects such as Sprites, which hold objects of the Sprite type of extension, this further goes on for things like, a Characters list,

this allows us to localize our typed instances, these lists are managed via functions, such as, CreateSprite, etc.

So, you pretty much have two choices, Store everything in a large group, and maybe have groups that share those objects.

Or keep everything in specialized groups, this limits your information accessability, since you might not be able to get access to an object that resides in a specialized list.

Overall though, concentrait more on functionality rather then 'textbook' design.
that is my oppinion anyway =)

Share this post


Link to post
Share on other sites
My solution to that problem, Raveler, would be to do something along these lines:

Implement a simple event system, where events change characters. All you'd need to do is add a damage event to the location on the map that you're hitting. Then, when the events are processed, which you can do by way of polymorphism and such, is have two basic functions of isExecutable() and execute(). When it's time to damage the boss, your event knows that it's a damage event and can only damage certain types of characters(such as bosses), and it will do so accordingly because it's built to handle(specifically) damage. This is an easily extendable system that will allow you to make non-game-specific code.

As a note to everyone, I'm changing the scope of my engine. I'm making it an RPG-style(think oldschool Zelda/FF) 2D engine. This doesn't change any of my code, but it does change my spec, which I'll need to rewrite.

[Edited by - Tarviathun on February 4, 2005 6:58:04 PM]

Share this post


Link to post
Share on other sites
Tarvathun, the problem is that it's quite difficult to foresee every event I could possibly want to have in my engine for my future games. It's quite generic, and my current game doesn't even have any characters at all. I think I'll go with the dynamic_cast's. It's certainly the most efficient and flexible solution, and I can actually guarantee because of how my engine is built that the cast will be succesful. Thanks for the help all! I'll post my game here when it's finished in half a year or so.

Share this post


Link to post
Share on other sites
You can follow the progress at the following page:
http://phantom.narfum.be/index.php?page=home&projectfilter=10

It's not quite as frequently updated as it should be, but I made a comprehensive update recently. This is my year project at university this year, hence all the references etc :).

Basically my game is a remake of Rampart, a classic arcade game. It will bring the original fast-paced gameplay to large multiplayer arena's, allowing you to play team battles and enhancing the original gameplay with some strategic aspects. About a year ago I figured a good remake of this classic was long overdue, so I decided to do one myself. It's my first tile-based game, but except for the 2D engine I already have a pretty large code base to work with.

If you're interested in my other (not tile-based) work, you can check out this page:
http://phantom.narfum.be/index.php?page=projects&type=finished

Share this post


Link to post
Share on other sites

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

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this