Welcome, Guest. Please login or register.

Pages: [1] 2 3
Print
Author Topic: Class Design Draft  (Read 17004 times)
tZee
Community member

Posts: 190


View Profile Email
« on: June 22, 2009, 01:57:25 PM »

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. Cheesy

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

Zimble
Community member

Posts: 57

GMT+1


View Profile
« Reply #1 on: June 22, 2009, 06:30:17 PM »

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.
Logged

tZee
Community member

Posts: 190


View Profile Email
« Reply #2 on: June 22, 2009, 07:04:40 PM »

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

meggie
Community member

Posts: 30

Python programming looking for some C++ experience

un1meg
View Profile
« Reply #3 on: June 22, 2009, 07:37:01 PM »

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.
Logged

-Meggie
tZee
Community member

Posts: 190


View Profile Email
« Reply #4 on: June 22, 2009, 07:47:04 PM »

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. Smiley 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. Smiley Learning by doing!
Logged

meggie
Community member

Posts: 30

Python programming looking for some C++ experience

un1meg
View Profile
« Reply #5 on: June 22, 2009, 07:56:05 PM »

Quote
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.
Logged

-Meggie
tZee
Community member

Posts: 190


View Profile Email
« Reply #6 on: June 22, 2009, 08:08:02 PM »

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.
Logged

tie
Community member

Posts: 77


View Profile Email
« Reply #7 on: June 23, 2009, 12:29:39 PM »

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):
...
Logged
tZee
Community member

Posts: 190


View Profile Email
« Reply #8 on: June 23, 2009, 12:48:07 PM »

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. Cheesy 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 Cheesy)

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)
Logged

tZee
Community member

Posts: 190


View Profile Email
« Reply #9 on: June 23, 2009, 12:53:33 PM »

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. Smiley Sometimes it's easier if you visualize your ideas.
Logged

Gaspard
Community member

Posts: 479


The Blackest Heart


View Profile
« Reply #10 on: June 23, 2009, 01:01:53 PM »

Quote from: tie
  - 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)
Logged
tZee
Community member

Posts: 190


View Profile Email
« Reply #11 on: June 23, 2009, 01:10:26 PM »

Quote from: tie
  - 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.
Logged

Gaspard
Community member

Posts: 479


The Blackest Heart


View Profile
« Reply #12 on: June 23, 2009, 01:43:20 PM »

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
« Last Edit: June 23, 2009, 01:45:31 PM by Gaspard » Logged
zenbitz
Community member

Posts: 1164



View Profile
« Reply #13 on: June 23, 2009, 04:50:55 PM »


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
Logged

We are not denying them an ending...
We are denying them a DISNEY ending - Icelus
tie
Community member

Posts: 77


View Profile Email
« Reply #14 on: June 23, 2009, 05:15:04 PM »

Quote
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".

Quote
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.

Quote
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.

Quote
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.

Quote
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 Smiley The *able names (e.g. Openable) are great, but I can't think of a suitable *able adjective for every case (CharacterStatsable  Huh).
Logged
Pages: [1] 2 3
Print
Jump to: