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 =)
Object Management
Author
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]
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]
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.
Author
Ok. Keep us posted though, with screenies and WIP updates and stuff. I'd love to see your game being made. Best of luck!
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
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
Author
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?
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.
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.
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.
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.
Author
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
