Working on docs

This commit is contained in:
Griatch 2022-09-14 18:40:21 +02:00
parent a974a2843c
commit 0095f70835
4 changed files with 264 additions and 17 deletions

View file

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

View file

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

View file

@ -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: