Class Design Draft

[tZee]

Sorry, I think it's quite confusing. It's the complete picture - of course in draft state. For better understanding (for the wiki) it can be divided into smaller pictures, which only picture the according part.

I tried to explain some thoughts and ideas in the diagram itself. Please ask me any question you have regarding it! I know it's a mess, sorry again.

Here it is: http://wiki.parpg.net/Image:ClassDesign2.jpg

[Zimble]

Just wanted to throw in a component based entity system

I don't know if it's good or bad. Just read about it and tried to implement it some time ago and failed.

[tZee]

That's what I intended to do with the game objects. Nice article, thanks.

[meggie]

I noticed a few things that I thought I should point out, though they're all small, off-the-cuff sort of observations.

NPCs will need openable/container(? - for stealing) as well as some combatstats stuff...at some point, some plain "stealable" functionality might be necessary, just because you could steal from objects as well.

Also, the way Instances are added to a layer, the gfx is needed, so we might want that as part of the MapItem class.

I would also like to propose that we construct a similar sort of plan for GUI stuff, which is sort of haphazard at the moment...though I have no experience designing such things, and very little experience actually dealing with the GUI.

[tZee]

NPCs will need openable/container(? - for stealing) as well as some combatstats stuff...at some point, some plain "stealable" functionality might be necessary, just because you could steal from objects as well.

This is not a complete list, so add more suggestions of object attributes. Robable seems a good idea to me.
NPCs: I didn't put it in there as probably not all need it or we are going to refine the class, subclassing Humans and Animals etc.
What do you mean, steal from objects?

Also, the way Instances are added to a layer, the gfx is needed, so we might want that as part of the MapItem class.

Didn't have a look at it in that detail, yet. But in general: If we can reuse the object graphics we should couple them with the maps, but make them available separately to only hold them in memory once each.

I would also like to propose that we construct a similar sort of plan for GUI stuff, which is sort of haphazard at the moment...though I have no experience designing such things, and very little experience actually dealing with the GUI.

Yeah, I think this is a good idea. If you are interested: The tool I use is called StarUML. It's free and very easy to use. All you then need to think about is: How could this be reused? How can I avoid duplication? How would it be natural? (Like: The PlayerClass should not hold the code that decided whether a door opens or not. He initiates the action and the door decides whether it accepts the key or not. etc.) Just give it a try and then we'll discuss about it. Learning by doing!

[meggie]

What do you mean, steal from objects?

Locked objects...I guess I was thinking of The Elder Scrolls, having never played Fallout. But there are often locked objects lying about. Rules for stealing from NPCs and opening locked objects could be very similar or very different, I guess.

[tZee]

I guess that would be a case of openable, where the concrete object triggers some game mechanic checks to determine if you're able to pick it.
Alternatively an additional attribute "pickable", but it sounds too much like openable to me.

[tie]

Damn! I lost a kilometric post... Never ever try to clean up your Esc key while writing a forum post.

Anyway, just ome quick points:
  - Knife is not really wearable. Pants are wearable. Knife goes into some inventory slot.
  - Some agents may include multiple containers, so directly inheriting from container may not be the best option for Barrel. Instead, we can have a HasInventory class, which would abstract container access
  - Instead of having each Barrel, Chest, etc. inherit from multiple classes, we should have some base MapContainer class. Same goes for weapons, characters, etc
  - We should discuss weapon classes with Zenbitz
  - Carryable should include (through inheritance) the MapItem properties. Whatever can be carried can also be dropped. When it is dropped, MapItem stuff kicks in.
  - Openable should include Pickable
  - We may not need separate PC and NPC classes, if we have a good enough Character class
  - We already have an ActionStack class (developed while we were using the Rio codebase), which can be used as a command queue (per character, or world-wide)

Some (pseudo) code:

Code:

class Blade (AgentBase, Usable, Carryable, Weapon):
...
class SwissArmyKnife (Blade)
...

Code:

class MapContainer (AgentBase, MapItem, Openable, HasInventory, Trappable, Scriptable, Destructable):
...
class Barrel (MapContainer):
...

Code:

class Character (AgentBase, MapItem, HasInventory, Living, CharacterStats, AI, Scriptable):
...

[tZee]

Damn! I lost a kilometric post... Never ever try to clean up your Esc key while writing a forum post.

Ouch, I hate when that happens. Because of that I nowadays write long posts in an external editor. In case my browser crashes.

  - Knife is not really wearable. Pants are wearable. Knife goes into some inventory slot.

I was thinking WoW-Style here. But this is subject to the game mechanics I guess. I wouldn't like to have my weapon in my inventory, but wear it sheated on my belt or sth. like that.
 

  - Some agents may include multiple containers, so directly inheriting from container may not be the best option for Barrel. Instead, we can have a HasInventory class, which would abstract container access

I like HasInventory - and it is there in the diagram, but with a different name and not in the inheritance model. I think we should go for your way. Integrates better with the NPC classes as well.
Another point: What you say implies that every object is an agent. I disagree. Actors are agents, like animals, npcs, the player. Dead items are not agents. You use them, you trigger their functionality, but they rarely trigger them themselves. (Traps might be a crossing of both?!)
 

  - Instead of having each Barrel, Chest, etc. inherit from multiple classes, we should have some base MapContainer class. Same goes for weapons, characters, etc

Agreed.

  - Carryable should include (through inheritance) the MapItem properties. Whatever can be carried can also be dropped. When it is dropped, MapItem stuff kicks in.

That was one of my questions. So every item should be dropable? Then we need to think about the consequences. Do we want them to remain on the floor forever? Should they disappear after a while? Too many objects on the floor will make the game slower and it requires more data to be stored. We should evaluate scalability of suggested solutions here.

  - Openable should include Pickable

Hmm... I'd rather put pickable in lockable. Openable would have open() close(). Lockable inherits from openable and has lock() and pick() additionally.

  - We may not need separate PC and NPC classes, if we have a good enough Character class

Indeed. The classes for PlayerCharacter is more a concrete class already. When I thought about them I (wrongly) assumed that NPCs wouldn't have an inventory. (I was thinking about the GUI inventory here) HasInventory should also introduce a pickPocket() function, imo.

  - We already have an ActionStack class (developed while we were using the Rio codebase), which can be used as a command queue (per character, or world-wide)

Interesting, going to have a look at it. (Shoot! I have yet to read so much )

Some (pseudo) code:

Code:

class Blade (AgentBase, Usable, Carryable, Weapon):
...
class SwissArmyKnife (Blade)
...

Code:

class MapContainer (AgentBase, MapItem, Openable, HasInventory, Trappable, Scriptable, Destructable):
...
class Barrel (MapContainer):
...

Code:

class Character (AgentBase, MapItem, HasInventory, Living, CharacterStats, AI, Scriptable):
...

I love the descriptiveness of Character(AgentBase, IsMapItem, HasInventory, IsLiving, HasCharacterStats, HasAI, IsScriptable)

[tZee]

Btw.: Going to upload the UML file I created. It's done with StarUML, a free UML editor. So anyone can modify it and post suggestions in graphical format. Sometimes it's easier if you visualize your ideas.

[Gaspard]

  - Carryable should include (through inheritance) the MapItem properties. Whatever can be carried can also be dropped. When it is dropped, MapItem stuff kicks in.

That was one of my questions. So every item should be dropable? Then we need to think about the consequences. Do we want them to remain on the floor forever? Should they disappear after a while? Too many objects on the floor will make the game slower and it requires more data to be stored. We should evaluate scalability of suggested solutions here.

I think it was decided that what's not nailed to the ground will be gone when you leave a map - during the PC's 'absence' scavengers and fellow wastelanders will take the stuff. As long as it is not in a fixed container (ie a Lockable Cubboard, Locker, Footlocker etc) it will be gone.

It's still under discussion whether one should be able to hide loot (dig a hole fill it with stuff and then tidy it up, so it would be hidden)

[tZee]

  - Carryable should include (through inheritance) the MapItem properties. Whatever can be carried can also be dropped. When it is dropped, MapItem stuff kicks in.

That was one of my questions. So every item should be dropable? Then we need to think about the consequences. Do we want them to remain on the floor forever? Should they disappear after a while? Too many objects on the floor will make the game slower and it requires more data to be stored. We should evaluate scalability of suggested solutions here.

I think it was decided that what's not nailed to the ground will be gone when you leave a map - during the PC's 'absence' scavengers and fellow wastelanders will take the stuff. As long as it is not in a fixed container (ie a Lockable Cubboard, Locker, Footlocker etc) it will be gone.

It's still under discussion whether one should be able to hide loot (dig a hole fill it with stuff and then tidy it up, so it would be hidden)

Sounds exciting. How do we define fixed though? You can move a cupboard and probably lockers. (Depending on the type.)
I guess programming wise that would imply a IsMovable class and all objects inheriting from it, which are lying on the ground on a mapchange will not be saved.

[Gaspard]

Hopefully we don't have supermen roaming the snowy desolation who could lift a locker filled with food/weapons/armor/car parts.

Prolly there should also be a distinction between rural (less populated) and urban (more populated) areas. If it's out in the wastes then only a guy with some transport could carry it away (guy with dogs and sled or trading caravan..) in a settlement or close to it it is easier to round up a couple of toughies to carry your find for a couple of beers

By fixed I basically mean containers that one person does not lift easily (unless your Strength is maxed out and you get this special bonus or whatnot - even then you could only lift that one cupboard and nothing else).

EDIT: I guess further discussion on the exact mechanics should go to the Mechanics forum

[zenbitz]

EDIT: I guess further discussion on the exact mechanics should go to the Mechanics forum

In fact, there is already a thread for it...
http://forums.parpg.net/index.php?topic=77.0

[tie]

I was thinking WoW-Style here. But this is subject to the game mechanics I guess. I wouldn't like to have my weapon in my inventory, but wear it sheated on my belt or sth. like that.

I thinkt the word "inventory" is causing hte confusion here. Even if the knif is sheated on your elt, it does take a slot (call it storage if you wish). Think about it this way: you cannot wear a knife if you were naked (well I can think of one location, but you *wouldn't* want to use that:)).

For the purpose of carrying things around your shoulder slot in WoW is an inventory (well, if you ignore the soulbound effect). So, by "inventory" I mean "something that holds/contains something else" don't think just "bags".

Another point: What you say implies that every object is an agent. I disagree. Actors are agents, like animals, npcs, the player. Dead items are not agents. You use them, you trigger their functionality, but they rarely trigger them themselves. (Traps might be a crossing of both?!)

I thought all interactable objects had to be agents (in the FIFE Agent sense). Like the crate for example ? Maybe wrong though.

So every item should be dropable?

In general, every carriable item should be droppable. There may be exceptions (like the 'cursed' items in D&D), but this should be the general case.

Hmm... I'd rather put pickable in lockable. Openable would have open() close(). Lockable inherits from openable and has lock() and pick() additionally.

Agree - it is better this way.

I love the descriptiveness of Character(AgentBase, IsMapItem, HasInventory, IsLiving, HasCharacterStats, HasAI, IsScriptable)

I'm slightly agains using IsSomething as a class naming convention, simply because I instinctively expect these to be functions with True/False return values. If everyone thinks this IsBetter, I won't resist it though The *able names (e.g. Openable) are great, but I can't think of a suitable *able adjective for every case (CharacterStatsable  ).