• Advertisement
Sign in to follow this  

Object Management

This topic is 4765 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

I read over your game and it seems you've done some things that I'm going to implement into my engine, such as a graphical animation editor. How'd you end up doing that?

Share this post


Link to post
Share on other sites
Advertisement
Right now it's a pretty basic editor, that just lets you add, remove and move frames of animations around. There's no graphical editing involved, you have to do that in Photoshop or wherever the graphics are made. My editor just collects frames, animates them for you so you can see the result in real time, and lets you store all animation data in one logical file, which consists of a header followed by each .tga file appended.

One class called AnimationObject loads the textures from such a file in memory and can copy them from other separate .tga files in one. Pretty basic, but it works.

Here's a screenshot:
http://phantom.narfum.be/ro/AnimationEditor.jpg

It's completely built with GlUI, which is my own GUI API loosely based on Java Swing, and GlUI is based on OpenGL/GLUT. So it's platform-independant.

Share this post


Link to post
Share on other sites
Since this is on the same subject, I was wondering if you guys derive everything from a basic object? Mainly, both map tiles and regular game objects.

I was considering not doing this, and having seperate classes for both. Or well, in my case, a map tile would be nothing more than a single DWORD which contains the values (retrieve and stored via bit operators). ImageID, Collideable, SpawnPoint, ObjectID. That's all it'd contain. This would certainly make map storing and loading quick.

My basic object, for all other game objects, has the following:

State, Animation, Point, IsDead.

All basic objects are responsible for drawing themselves, of course, and have Draw() and Update() functions. They also have an OnMsg() function which sends msgs to their current State. Tile objects are handled by the Map object.

I don't think a tile object needs to be that complex. So am I wrong in having two seperate objects for each?

This brings me to another question. Where would a logical place be for handling collision detection? Obviously collision needs to be checked with both map tiles and collideable objects. I was thinking of handling it in the AI, but that's not really a centralized location and I'd have to handle collision seperately for each movement State. That's a bit undesirable.

Thanks for your time.

Share this post


Link to post
Share on other sites
The way I do it, is that I have Tiles and Objects seperate, because they basically serve two different purposes, I think that's a pretty common conclusion. With collusion, it should be handled in the ObjectManager, because that's what's colliding, tiles(I'm assuming) don't move. However, this all depends upon the way you have everything structured. My objects don't draw themselves, because their only responibility is to hold data of where they currently are. The ObjectManager makes sure that they don't move in areas that they're not supposed to and executes all the Object events. The events handle state changes, damage, movement, everything. The renderer requests all objects within a specific area(onscreen) from the ObjectManager and then draws them.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement