mirror of
https://github.com/evennia/evennia.git
synced 2026-03-16 21:06:30 +01:00
Working on docs
This commit is contained in:
parent
a974a2843c
commit
0095f70835
4 changed files with 264 additions and 17 deletions
|
|
@ -268,7 +268,7 @@ after
|
|||
start node as if it was entered on a fictional previous node. This can be very useful in order to
|
||||
start a menu differently depending on the Command's arguments in which it was initialized.
|
||||
- `session` (Session): Useful when calling the menu from an [Account](./Accounts.md) in
|
||||
`MULTISESSION_MODDE` higher than 2, to make sure only the right Session sees the menu output.
|
||||
`MULTISESSION_MODE` higher than 2, to make sure only the right Session sees the menu output.
|
||||
- `debug` (bool): If set, the `menudebug` command will be made available in the menu. Use it to
|
||||
list the current state of the menu and use `menudebug <variable>` to inspect a specific state
|
||||
variable from the list.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,71 @@
|
|||
# Character Generation
|
||||
|
||||
In previous lessons we have established how a character looks. Now we need to give the player a
|
||||
chance to create one.
|
||||
|
||||
In _Knave_, most of the character-generation is random. This means this tutorial can be pretty
|
||||
compact while still showing the basic idea. What we will create is a menu looking like this:
|
||||
|
||||
## How it will work
|
||||
|
||||
We want to have chargen appear when we log in.
|
||||
|
||||
```
|
||||
Silas
|
||||
|
||||
STR +1
|
||||
DEX +2
|
||||
CON +1
|
||||
INT +3
|
||||
WIS +1
|
||||
CHA +2
|
||||
|
||||
You are lanky with a sunken face and filthy hair, breathy speech, and foreign clothing.
|
||||
You were a herbalist, but you were pursued and ended up a knave. You are honest but also
|
||||
suspicious. You are of the neutral alignment.
|
||||
|
||||
Your belongings:
|
||||
Brigandine armor, ration, ration, sword, torch, torch, torch, torch, torch,
|
||||
tinderbox, chisel, whistle
|
||||
|
||||
----------------------------------------------------------------------------------------
|
||||
1. Change your name
|
||||
2. Swap two of your ability scores (once)
|
||||
3. Accept and create character
|
||||
```
|
||||
|
||||
If you select 1, you get a new menu node:
|
||||
|
||||
```
|
||||
Your current name is Silas. Enter a new name or leave empty to abort.
|
||||
-----------------------------------------------------------------------------------------
|
||||
```
|
||||
You can now enter a new name. When pressing return you'll get back to the first menu node
|
||||
showing your character, now with the new name.
|
||||
|
||||
If you select 2, you go to another menu node:
|
||||
|
||||
```
|
||||
Your current abilities:
|
||||
|
||||
STR +1
|
||||
DEX +2
|
||||
CON +1
|
||||
INT +3
|
||||
WIS +1
|
||||
CHA +2
|
||||
|
||||
You can swap the values of two abilities around.
|
||||
You can only do this once, so choose carefully!
|
||||
|
||||
To swap the values of e.g. STR and INT, write 'STR INT'. Empty to abort.
|
||||
------------------------------------------------------------------------------------------
|
||||
```
|
||||
If you enter `WIS CHA` here, WIS will become `+2` and `CHA` `+1`. You will then again go back
|
||||
to the main node to see your new character, but this time the option to swap will no longer be
|
||||
available (you can only do it once).
|
||||
|
||||
If you finally select the `Accept and create character` option, you will leave character
|
||||
generation and start the game as this character.
|
||||
|
||||
|
||||
|
|
@ -1,8 +1,12 @@
|
|||
# Making a Persistent object Handler
|
||||
|
||||
A _handler_ is a convenient way to group functionality on an object. This allows you to logically group all actions related to that thing in one place. This tutorial expemplifies how to make your own handlers and make sure data you store in them survives a reload.
|
||||
A _handler_ is a convenient way to group functionality on an object. This allows you to logically
|
||||
group all actions related to that thing in one place. This tutorial expemplifies how to make your
|
||||
own handlers and make sure data you store in them survives a reload.
|
||||
|
||||
For example, when you do `obj.attributes.get("key")` or `obj.tags.add('tagname')` you are evoking handlers stored as `.attributes` and `tags` on the `obj`. On these handlers are methods (`get()` and `add()` in this example).
|
||||
For example, when you do `obj.attributes.get("key")` or `obj.tags.add('tagname')` you are evoking
|
||||
handlers stored as `.attributes` and `tags` on the `obj`. On these handlers are methods (`get()`
|
||||
and `add()` in this example).
|
||||
|
||||
## Base Handler example
|
||||
|
||||
|
|
@ -81,8 +85,10 @@ class Quest:
|
|||
|
||||
```
|
||||
|
||||
|
||||
We expect the dev to make subclasses of this to implement different quests. Exactly how this works doesn't matter, the key is that we want to track `self.current_step` - a property that _should survive a server reload_. But so far there is no way for `Quest` to accomplish this, it's just a normal Python class with no connection to the database.
|
||||
We expect the dev to make subclasses of this to implement different quests. Exactly how this works
|
||||
doesn't matter, the key is that we want to track `self.current_step` - a property that _should
|
||||
survive a server reload_. But so far there is no way for `Quest` to accomplish this, it's just a
|
||||
normal Python class with no connection to the database.
|
||||
|
||||
### Handler with save/load capability
|
||||
|
||||
|
|
@ -120,17 +126,24 @@ class QuestHandler:
|
|||
|
||||
```
|
||||
|
||||
The handler is just a normal Python class and has no database-storage on its own. But it has a link to `.obj`, which is assumed to be a full typeclased entity, on which we can create persistent [Attributes](../Components/Attributes.md) to store things however we like!
|
||||
The handler is just a normal Python class and has no database-storage on its own. But it has a link
|
||||
to `.obj`, which is assumed to be a full typeclased entity, on which we can create
|
||||
persistent [Attributes](../Components/Attributes.md) to store things however we like!
|
||||
|
||||
We make two helper methods `_load` and
|
||||
`_save` that handles local fetches and saves `storage` to an Attribute on the object. To avoid saving more than necessary, we have a property `do_save`. This we will set in `Quest` below.
|
||||
`_save` that handles local fetches and saves `storage` to an Attribute on the object. To avoid
|
||||
saving more than necessary, we have a property `do_save`. This we will set in `Quest` below.
|
||||
|
||||
> Note that once we `_save` the data, we need to call `_load` again. This is to make sure the version we store on the handler is properly de-serialized. If you get an error about data being `bytes`, you probably missed this step.
|
||||
|
||||
|
||||
### Make quests storable
|
||||
|
||||
The handler will save all `Quest` objects as a `dict` in an Attribute on `obj`. We are not done yet though, the `Quest` object needs access to the `obj` too - not only will this is important to figure out if the quest is complete (the `Quest` must be able to check the quester's inventory to see if they have the red key, for example), it also allows the `Quest` to tell the handler when its state changed and it should be saved.
|
||||
The handler will save all `Quest` objects as a `dict` in an Attribute on `obj`. We are not done yet
|
||||
though, the `Quest` object needs access to the `obj` too - not only will this is important to figure
|
||||
out if the quest is complete (the `Quest` must be able to check the quester's inventory to see if
|
||||
they have the red key, for example), it also allows the `Quest` to tell the handler when its state
|
||||
changed and it should be saved.
|
||||
|
||||
We change the `Quest` such:
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue