Object usage
From TheManaWorld
This article is outdated
Parts of this article are outdated and do no longer represent the current state of the project or the intentions of the development team.
Contents |
Approach for a system that covers entities and their usage by creatures
In this approach I will try to create a innovative(?) system that controles the usage of game objects in The Mana World. First I have to assume some things:
- every entity may have an inventory, that means it may contain a list of other entities (this makes it possible to put living thing into your inventory (someone remembers the talking chicken in Baldurs Gate? - there it was a dead thing!))
- every entity has a boolean attribute that indicates if the entity is moveable by the players or not (this is unrealistic, thought, but it prevents chaos - imagine the players could move around everything they are strong enough for)
- every entity has a boolean attribute that indicates if the entity is able to contain other entities - a rope for example can't include other entities
- every entity has a list for the ACTIONs he can perform - the list may be empty
- every entity has a list for the FUNCTIONs - the list may be empty
Actor
An ACTOR is a creature which has the ability to perform a list of ACTIONs, Attention: this is not meant a class, but as position a creature takes in when it uses an object - so in the actual implementation the ACTOR is a part of the creature class, an interface !EXAMPLES:
- rat
- knight
Action
This is something that can be done by an ACTOR to an entity (whether he does it to a creature or a lifeless object is completely nonrelevant - so I take the most basic class as a target: the entity)
Here are my suggestions for the most basic actions most creatures should be able to do:
- ingest_entity(entity) // eat an apple, drink poison :-)
- store_entity(entity, target_storage) // where target_storage is an entity list, or single entity slot; used to start carrying entities, too -> just set "hands" or kind like that as target; also used to drop objects as shown later
- move_entity(entity, move vector) // can be used i.e. for buttons that then execute scripts
- throw_entity_at(entity, target_entity) // uses entity as a thrown weapon -> attack
- talk_to_entity(entity) // talk to something, even it may not be alive
Examples
- rat -> eat, drink, pick up, push, pull, bite
- knight -> eat, drink, pick up, talk, throw, push, pull, carry, etc...
Function
This is like an ACTION - though a FUNCTION is not directly executed by an entity, but has to be used by an extern user.
Examples
- oven -> fire up, fire down
- window -> open, close
Examples
Now I try to break down the most common actions in a rpg to this three basic ideas:
1. A player picks up an apple
player->store_entity(apple, player->inventory)
2. A player eats a fish(still living, therefore a creature)
player->ingest_entity(fish)
3. A player uses an oven to bake a bread from some meal
-3.1. player->store_entity(player->inventory->meal, oven->inventory) // put the meal into the oven
-3.2. player->use_function(oven->functions->fire_up()) // fire up the oven
... bread is baken by the oven ...
-3.3. player->store_entity(oven->inventory->bread, player->inventory) // pick up the finished bread
-3.4. player->use_function(oven->functions->fire_down())
4. A player drops an apple to the ground he is standing on
player->store_entity(player->inventory->apple, world->get_tile_from_coordinates(player->get_position()))
5. A player talks to a NPC
player->talk_to_entity(npc)
6. A player opens a secret room behind a wall which is activated by voice detection player->talk_to_entity(wall)
Connection to the skill system
Most of the ACTIONs are connected to a skill or a list of skills. For example if you try to attack an enemy by hitting him with a stroke of your sword, its much more useful than to thrown it at him. This difference in efficency of ACTIONs executed with an entity is evoked by the socalled MODIFICATORs every entity's ACTION brings along.
Example
ACTOR: player
used ACTION: player->hack(inventory->sword, rat);
Here are the skills the player has:
- attack-skills->hack = 50;
- attack-skills->throw = 80;
- attack-skills->stab = 20;
Here are the MODIFICATORs the sword brings along for this action:
- hack = *2;
- throw = /5;
- stab = *1;
Now the players hack-ACTION looks up the MODIFICATORs the sword contents for this ACTION and calculates the success value on this basis:
success = 50 * 2 + 80 / 5 + 20 * 1 = 136
Note
1. All the ACTIONs, etc. should later be scripted, so it would be easy to create the behaviour of new objects by just putting all the needed ACTION-scripts needed for an creature into its ACTION-list 2. All this "code" up there is naturally just a simplification to show the main actions being done, in reallity i.e the drop-action would look like this:
player->store_entity(player->get_inventory()->get_object(/*ID or name or whatever the apple is identified by*/), world->get_tile_from_coordinates(player->get_position()))
Yet unanswered questions
* how to interprete the success-value?
Todo
* influence of entities' masses * different kinds of damage -> how to manage? who is responsable for the damage?
--Argh
Kyokai: We should probably be more concerned with the functionality of your system than implementation at this point. Try answering some of these questions:
- What does your system allow the player to do that he isn't doing already?
- What main categories of objects would exist, and what are the differences in functionality between them?
- How does your system rely on the other systems already in place?
- Give some examples of the system in action (ie: with this system, a player can go to an oven, put in meal, turn it on, wait, turn it off, and take out bread.)
Try to list these in an easily understandable manner. I'm going to encourage that you not use any code in the explanation of your systems, since implementation isn't an issue here, and some of the devs may not understand exactly what you want to say if you speak in C++.
Take a look at the SkillSystem if you want an example of how this should be laid out.
Bjørn: As you'll have gathered from the forums, I agree with Kyokai's comment above. Also note that we had made existing plans (docs/server.txt), about the beings and the objects, and it would be nice if you could relate your system to that.
I have read the code you have posted but I want to warn you it is useless to me. This is not because of my supposed in-ability to read code, but because the translation of a well formed sentence to code is often a trivial one. It is also a dangerous one to make because you suddenly include lots of details that can be wrong, disagreed about, etc. even when maybe people would have agreed with the original sentence.
I do think I can find myself a bit in an action list for beings (using the original terminology), and a function list for objects, but I think you go overboard with the amount of different actions/functions. While we're planning to use a similar system with inventory slots, I still think this may be overdoing the whole thing a bit.
Suppose we only had "use", together with being able to pickup/drop items, put them into containers and equip them in a slot when the specified slot is available. The oven example would still work. The oven only has to say it can hold other stuff, and can be used. You put your ingedients in the oven, use the oven (the oven use script will check what's inside and transform it into bread when it matches the requirements), and take out the bread. Eating fish would be using the fish. We don't need any lists of actions or functions, and for most operations we don't need any scripts either. This system works fine for the player, and would in my opinion still have plenty of flexibility.
Kyokai: I know there's been some confusion about the systems, so I'm going to put a note here on how everything actually fits together (Bjorn will correct me if I'm wrong, I'm sure).
Class - Item. Items simply take up space in the inventory. They have a flag which makes them equipment or single use (this will probably change soon, and equipment will become a derived class of items).
Class - Being. These are the players, monsters and NPCs in the gameworld.
This is how I see your class:
Class - Interactive Object. It sits on the world map and can be interacted with by players in a way similar to NPCs. Players can store it and move it with proper permissions. It's a utility-type item derived from the item class.
Overworked system - WIP!
Object
In my modified approach of an object those would(among other things mentioned in docs/server.txt):
- have a flag which marks them as being movable(or maybe a list of permissions that indicate who may move it)
- have an own inventory(need by a chest, a package, etc.)
Item
In my modified approach of an item those(among other things mentioned in docs/server.txt):
- can be combined to new items
Being
In my modified approach of a being those can(among other things mentioned in docs/server.txt):
- store objects into being's inventory(picking up), into another object(chest, etc.) or on the map (dropping)
- talk to another being(other players, npcs)
- ingest objects(eating an apple)
- move an object(if he has permission to move this particular object)
- use special(scripted) functions of objects(opening a door, pressing a button)
- every action done to an item would cause a reaction, defined by a script being the property of the item
Examples
- eating an apple:
- action: player ingests apple
- reaction: apple gives its user(player) an hp back
Examples
- baking bread:
- player has a sack of meal(item) and cup of water(item) in his inventory; he standing in front of an oven(object)
- player combines meal and water and gets a handful of dough(item) in is inventory
- player uses one of the special functionalities of the oven(can be fired up and fired down) and fires it up
- player stores the handful of dough from his inventory into the inventory of the oven
- oven substitudes the handful of dough in its inventory with a bread
- player uses one of the special functionalities of the oven and fires it down
- player stores the bread from the inventory of the oven into his own inventory
- apple tree:
- generates an apple every x timeunits and stores it in its inventory
- beings can take apples from the tree's inventory and store them in their own inventories
