Hello all,
The design for my game is coming along nicely but I'm currently trying to decide which way to go with my map system. I have a general idea, but I'm trying to figure out which out of two possibilities is the best way to put items of interest on my map.
I currently have 2 approaches, item type based or functionality based.
The first means that I would have a generals class / interface for each type of item (e.g. planet, ship, station, roid, etc.)
The second would mean that I would have a class / interface for each distinct functionality (e.g. stationary, dockable, mineable, etc.)
While I think the first one would be easier to implement, the second one would give me greater freedom later on when I actually start making my maps. As I can then decide what functionality a certain map item would need at the moment I place it on the map. (Besides it being cool to have the game mechanics to make a space station mineableā¦)
In this, which of the tow would you pick, or do you have another more brilliant sollution?
Mark
Personally Id go/and am going with the former, Planet, Asteroid, Station. It just makes more sense to me. But why could you not implement both methods? You specify a point in your map to place a Planet/Asteroid/etc, then attach property classes, ie Mineable/Dockable, which define how one interacts with that object.
This was the idea of the second. Because when you start describing the behaviour of the object via sub classes, the only thing you are basically left with is the 3d model, location and rotation of the object. This means you would have a basic MapObject class which countains a Model, a Location vector, a rotation vector and a list of properties / behaviours.
Another thing though is that I want to be able to place a Map inside a map. (this would enable the creation of instances, galaxy maps, etc.) Not sure where that would fit into all of this though, Map willprolly end up being a sub-class of MapObject or something.
Anyways, I'll try and work something out on paper and start coding, I'll let you know when I have something done that's worth showing.
I'd say both. But I wouldn't make the second interfaces, rather annotations.
The way I'm thinking is to have each of the functionalities used in the second method as a seperate class. That way, I can select which functionalities I want with each map object the moment I place them on the map. This would give the map makers a great degree of flexibility.
Anotation would work also, but this would mean I'd still have to decide what types of map objects I want before hand in stead of giving the choice of functionality over to the people who actually make the maps.
Mind you, I would still setup Map Object templates for common things like station, asteroids etc. But this way, if they want to implement something radical like an asteroid with a rebel base inside, it would be possible without having to recode.
Surely the game logic and rendering should be separate?
I may be misunderstanding your post though.
Yes, at this time I have 3 MapObkect classes defined:
BaseMapObject, VisibleMapObject and InvisibleMapObject, the latter two will extend the first one. Their functionality should be pretty obvious.
These Objects have all the functionality needed to render the object on the map bu tthe game logic can be plugged in later. So for instance you want to put a space station on the map, you take a VisibleMapObject, assign it the correct 3d model allong with location and rotation vectors and you have a space station on the map. However, you haven't linked it to any game logic, so all it does is look pretty. Next step woul be to actually setup what game logic should be linked to the MapObject. In this case, one would think along the lines of DockingProperty, LockingProperty and perhaps something like OrbitProperty.
So the render part of the MapObjects is done in the map system itself, but the pluging in of the various Properties just works as a relay to the game engine. But you have the option of deciding what Properties you want to plug into your MapObject through the Map editor along with some default settings.
Given what you've described above, Id say you're heading in the right direction.
Only thing I have to figure out now is, some Object Properties (like docking and locking) will need to be presented in a menu when the target is selected. Since it's the Propertie that knows what items it needs in that menu, I can only put the texts etc. of those items in the Property object. However, the property object is a game enige object, and technically, the text for the menu is a rendering thingā¦
Ah well, I think that such a minor violation wouldn't be too bad given the flexibility it will give me.