mirror of
https://github.com/evennia/evennia.git
synced 2026-03-16 12:56:30 +01:00
Update docs links
This commit is contained in:
parent
343d630245
commit
92834aacd0
17 changed files with 133 additions and 228 deletions
|
|
@ -413,15 +413,12 @@ This means storing objects in a collection of some kind and are examples of *ite
|
|||
entities you can loop over in a for-loop. Attribute-saving supports the following iterables:
|
||||
|
||||
* [Tuples](https://docs.python.org/2/library/functions.html#tuple), like `(1,2,"test", <dbobj>)`.
|
||||
* [Lists](https://docs.python.org/2/tutorial/datastructures.html#more-on-lists), like `[1,2,"test",
|
||||
<dbobj>]`.
|
||||
* [Dicts](https://docs.python.org/2/tutorial/datastructures.html#dictionaries), like `{1:2,
|
||||
"test":<dbobj>]`.
|
||||
* [Lists](https://docs.python.org/2/tutorial/datastructures.html#more-on-lists), like `[1,2,"test", <dbobj>]`.
|
||||
* [Dicts](https://docs.python.org/2/tutorial/datastructures.html#dictionaries), like `{1:2, "test":<dbobj>]`.
|
||||
* [Sets](https://docs.python.org/2/tutorial/datastructures.html#sets), like `{1,2,"test",<dbobj>}`.
|
||||
* [collections.OrderedDict](https://docs.python.org/2/library/collections.html#collections.OrderedDict),
|
||||
like `OrderedDict((1,2), ("test", <dbobj>))`.
|
||||
* [collections.Deque](https://docs.python.org/2/library/collections.html#collections.deque), like
|
||||
`deque((1,2,"test",<dbobj>))`.
|
||||
* [collections.Deque](https://docs.python.org/2/library/collections.html#collections.deque), like `deque((1,2,"test",<dbobj>))`.
|
||||
* *Nestings* of any combinations of the above, like lists in dicts or an OrderedDict of tuples, each
|
||||
containing dicts, etc.
|
||||
* All other iterables (i.e. entities with the `__iter__` method) will be converted to a *list*.
|
||||
|
|
|
|||
|
|
@ -330,11 +330,7 @@ To keep things separate we'll make a new module `mygame/commands/sittables.py`:
|
|||
|
||||
```{sidebar} Separate Commands and Typeclasses?
|
||||
|
||||
You can organize these things as you like. If you wanted you could put the sit-command + cmdset
|
||||
together with the `Sittable` typeclass in `mygame/typeclasses/sittables.py`. That has the advantage of
|
||||
keeping everything related to sitting in one place. But there is also some organizational merit to
|
||||
keeping all Commands in one place as we do here.
|
||||
|
||||
You can organize these things as you like. If you wanted you could put the sit-command + cmdset together with the `Sittable` typeclass in `mygame/typeclasses/sittables.py`. That has the advantage of keeping everything related to sitting in one place. But there is also some organizational merit to keeping all Commands in one place as we do here.
|
||||
```
|
||||
|
||||
```python
|
||||
|
|
@ -550,10 +546,7 @@ The arguments are required and Evennia will pass all relevant objects to them:
|
|||
|
||||
```{sidebar} Lockfuncs
|
||||
|
||||
Evennia provides a large number of default lockfuncs, such as checking permission-levels,
|
||||
if you are carrying or are inside the accessed object etc. There is no concept of 'sitting'
|
||||
in default Evennia however, so this we need to specify ourselves.
|
||||
|
||||
Evennia provides a large number of default lockfuncs, such as checking permission-levels, if you are carrying or are inside the accessed object etc. There is no concept of 'sitting' in default Evennia however, so this we need to specify ourselves.
|
||||
```
|
||||
|
||||
- `accessing_obj` is the one trying to access the lock. So us, in this case.
|
||||
|
|
@ -654,10 +647,7 @@ abort this sequence we need to `raise InterruptCommand`.
|
|||
|
||||
```{sidebar} Raising exceptions
|
||||
|
||||
Raising an exception allows for immediately interrupting the current program flow. Python
|
||||
automatically raises error-exceptions when detecting problems with the code. It will be
|
||||
raised up through the sequence of called code (the 'stack') until it's either `caught` with
|
||||
a `try ... except` or reaches the outermost scope where it'll be logged or displayed.
|
||||
Raising an exception allows for immediately interrupting the current program flow. Python automatically raises error-exceptions when detecting problems with the code. It will be raised up through the sequence of called code (the 'stack') until it's either `caught` with a `try ... except` or reaches the outermost scope where it'll be logged or displayed.
|
||||
|
||||
```
|
||||
|
||||
|
|
@ -707,9 +697,7 @@ While it's useful to learn about `try ... except`, there is also a way to levera
|
|||
|
||||
```{sidebar} Continuing across multiple lines
|
||||
|
||||
Note how the `.search()` method's arguments are spread out over multiple
|
||||
lines. This works for all lists, tuples and other listings and is
|
||||
a good way to avoid very long and hard-to-read lines.
|
||||
Note how the `.search()` method's arguments are spread out over multiple lines. This works for all lists, tuples and other listings and is a good way to avoid very long and hard-to-read lines.
|
||||
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -1,22 +1,20 @@
|
|||
# Beginner Tutorial
|
||||
|
||||
```{eval-rst}
|
||||
.. sidebar:: Tutorial Parts
|
||||
|
||||
**Introduction**
|
||||
Getting set up.
|
||||
Part 1: `What we have <Part1/Beginner-Tutorial-Part1-Intro.html>`_
|
||||
A tour of Evennia and how to use the tools, including an introduction to Python.
|
||||
Part 2: `What we want <Part2/Beginner-Tutorial-Part2-Intro.html>`_
|
||||
Planning our tutorial game and what to think about when planning your own in the future.
|
||||
Part 3: `How we get there <Part3/Beginner-Tutorial-Part3-Intro.html>`_
|
||||
Getting down to the meat of extending Evennia to make our game
|
||||
Part 4: `Using what we created <Part4/Beginner-Tutorial-Part4-Intro.html>`_
|
||||
Building a tech-demo and world content to go with our code
|
||||
Part 5: `Showing the world <Part5/Beginner-Tutorial-Part5-Intro.html>`_
|
||||
Taking our new game online and let players try it out
|
||||
|
||||
```{sidebar} Beginner Tutorial Parts
|
||||
- **[Introduction](./Beginner-Tutorial-Intro.md)**
|
||||
<br>Getting set up.
|
||||
- Part 1: [What we have](Part1/Beginner-Tutorial-Part1-Intro.md)
|
||||
<br>A tour of Evennia and how to use the tools, including an introduction to Python.
|
||||
- Part 2: [What we want](Part2/Beginner-Tutorial-Part2-Intro.md)
|
||||
<br>Planning our tutorial game and what to think about when planning your own in the future.
|
||||
- Part 3: [How we get there](Part3/Beginner-Tutorial-Part3-Intro.md)
|
||||
<br>Getting down to the meat of extending Evennia to make our game
|
||||
- Part 4: [Using what we created](Part4/Beginner-Tutorial-Part4-Intro.md)
|
||||
<br>Building a tech-demo and world content to go with our code
|
||||
- Part 5: [Showing the world](Part5/Beginner-Tutorial-Part5-Intro.md)
|
||||
<br>Taking our new game online and let players try it out
|
||||
```
|
||||
|
||||
Welcome to Evennia! This multi-part Beginner Tutorial will help you get off the ground. It consists
|
||||
of five parts, each with several lessons. You can pick what seems interesting, but if you
|
||||
follow through to the end you will have created a little online game of your own to play
|
||||
|
|
|
|||
|
|
@ -1,7 +1,6 @@
|
|||
# Adding custom commands
|
||||
|
||||
In this lesson we'll learn how to create our own Evennia _Commands_. If you are new to Python you'll
|
||||
also learn some more basics about how to manipulate strings and get information out of Evennia.
|
||||
In this lesson we'll learn how to create our own Evennia _Commands_. If you are new to Python you'll also learn some more basics about how to manipulate strings and get information out of Evennia.
|
||||
|
||||
A Command is something that handles the input from a user and causes a result to happen.
|
||||
An example is `look`, which examines your current location and tells how it looks like and
|
||||
|
|
@ -308,16 +307,17 @@ A lot of things to dissect here:
|
|||
`self.args.strip()` over and over, we store the stripped version
|
||||
in a _local variable_ `args`. Note that we don't modify `self.args` by doing this, `self.args` will still
|
||||
have the whitespace and is not the same as `args` in this example.
|
||||
|
||||
```{sidebar} if-statements
|
||||
|
||||
The full form of the if statement is
|
||||
|
||||
if condition:
|
||||
...
|
||||
elif othercondition:
|
||||
...
|
||||
else:
|
||||
...
|
||||
|
||||
if condition:
|
||||
...
|
||||
elif othercondition:
|
||||
...
|
||||
else:
|
||||
...
|
||||
|
||||
There can be any number of `elifs` to mark when different branches of the code should run. If
|
||||
the `else` condition is given, it will run if none of the other conditions was truthy. In Python
|
||||
|
|
|
|||
|
|
@ -2,8 +2,7 @@
|
|||
|
||||
```{sidebar} API
|
||||
|
||||
API stands for `Application Programming Interface`, a description for how to access
|
||||
the resources of a program or library.
|
||||
API stands for `Application Programming Interface`, a description for how to access the resources of a program or library.
|
||||
```
|
||||
A good place to start exploring Evennia is the [Evenia-API frontpage](../../../Evennia-API.md).
|
||||
This page sums up the main components of Evennia with a short description of each. Try clicking through
|
||||
|
|
@ -73,10 +72,7 @@ from here to `mygame/server/settings.py` file.
|
|||
|
||||
```{sidebar} __init__.py
|
||||
|
||||
The `__init__.py` file is a special Python filename used to represent a Python 'package'.
|
||||
When you import `evennia` on its own, you import this file. When you do `evennia.foo` Python will
|
||||
first look for a property `.foo` in `__init__.py` and then for a module or folder of that name
|
||||
in the same location.
|
||||
The `__init__.py` file is a special Python filename used to represent a Python 'package'. When you import `evennia` on its own, you import this file. When you do `evennia.foo` Python will first look for a property `.foo` in `__init__.py` and then for a module or folder of that name in the same location.
|
||||
|
||||
```
|
||||
|
||||
|
|
@ -101,10 +97,7 @@ are actually importing from `evennia/__init__.py`.
|
|||
|
||||
```{sidebar} Relative and absolute imports
|
||||
|
||||
The first full-stop in `from .objects.objects ...` means that
|
||||
we are importing from the current location. This is called a `relative import`.
|
||||
By comparison, `from evennia.objects.objects` is an `absolute import`. In this particular
|
||||
case, the two would give the same result.
|
||||
The first full-stop in `from .objects.objects ...` means that we are importing from the current location. This is called a `relative import`. By comparison, `from evennia.objects.objects` is an `absolute import`. In this particular case, the two would give the same result.
|
||||
```
|
||||
|
||||
> You can also look at [the right section of the API frontpage](../../../Evennia-API.md#typeclasses) and click through
|
||||
|
|
|
|||
|
|
@ -17,14 +17,7 @@ You may have noticed when we were building things in-game that we would often re
|
|||
|
||||
```{sidebar} Python-paths
|
||||
|
||||
A 'python path' uses '.' instead of '/' or '`\\`' and
|
||||
skips the `.py` ending of files. It can also point to
|
||||
the code contents of python files. Since Evennia is already
|
||||
looking for code in your game dir, your python paths can start
|
||||
from there.
|
||||
|
||||
So a path `/home/foo/devel/mygame/commands/command.py`
|
||||
would translate to a Python-path `commands.command`.
|
||||
A 'python path' uses '.' instead of '/' or '`\\`' and skips the `.py` ending of files. It can also point to the code contents of python files. Since Evennia is already looking for code in your game dir, your python paths can start from there. So a path `/home/foo/devel/mygame/commands/command.py` would translate to a Python-path `commands.command`.
|
||||
```
|
||||
|
||||
create/drop button:tutorial_examples.red_button.RedButton
|
||||
|
|
@ -62,9 +55,7 @@ of Evennia. These manifest in game like the server understanding input like `loo
|
|||
|
||||
```{sidebar} Classes
|
||||
|
||||
A `class` is template for creating object-instances of a particular type
|
||||
in Python. We will explain classes in more detail in the next
|
||||
`python overview <Python-basic-tutorial-part-two>`_.
|
||||
A `class` is template for creating object-instances of a particular type in Python. We will explain classes in more detail in the next lesson.
|
||||
|
||||
```
|
||||
- [command.py](github:evennia/game_template/commands/command.py) (Python-path: `commands.command`) - this contain the
|
||||
|
|
|
|||
|
|
@ -112,10 +112,7 @@ First reload the server as usual. We will need to create the dragon a little dif
|
|||
|
||||
```{sidebar} Keyword arguments
|
||||
|
||||
Keyword arguments (like `db_key="Smaug"`) is a way to
|
||||
name the input arguments to a function or method. They make
|
||||
things easier to read but also allows for conveniently setting
|
||||
defaults for values not given explicitly.
|
||||
Keyword arguments (like `db_key="Smaug"`) is a way to name the input arguments to a function or method. They make things easier to read but also allows for conveniently setting defaults for values not given explicitly.
|
||||
|
||||
```
|
||||
> py
|
||||
|
|
@ -296,10 +293,7 @@ with the name `BASE_OBJECT_TYPECLASS`, which is set to `typeclasses.objects.Obje
|
|||
|
||||
```{sidebar} Changing things
|
||||
|
||||
While it's tempting to change folders around to your liking, this can
|
||||
make it harder to follow tutorials and may confuse if
|
||||
you are asking others for help. So don't overdo it unless you really
|
||||
know what you are doing.
|
||||
While it's tempting to change folders around to your liking, this can make it harder to follow tutorials and may confuse if you are asking others for help. So don't overdo it unless you really know what you are doing.
|
||||
```
|
||||
|
||||
So if you wanted the creation commands and methods to default to some other class you could
|
||||
|
|
@ -393,8 +387,8 @@ class Character(DefaultCharacter):
|
|||
|
||||
```{sidebar} Tuples and lists
|
||||
|
||||
- A `list` is written `[a, b, c, d, ...]`. It can be modified after creation.
|
||||
- A `tuple` is written `(a, b, c, ...)`. It cannot be modified once created.
|
||||
- A `list` is written `[a, b, c, d, ...]`. It can be modified after creation.
|
||||
- A `tuple` is written `(a, b, c, ...)`. It cannot be modified once created.
|
||||
```
|
||||
We made a new method, gave it a docstring and had it `return` the RP-esque values we set. It comes back as a
|
||||
_tuple_ `(10, 12, 15)`. To get a specific value you could specify the _index_ of the value you want,
|
||||
|
|
@ -453,9 +447,7 @@ class Character(DefaultCharacter):
|
|||
|
||||
```{sidebar} Spaces in Attribute name?
|
||||
|
||||
What if you want spaces in your Attribute name? Or you want to assign the
|
||||
name of the Attribute on-the fly? Then you can use `.attributes.add(name, value)` instead,
|
||||
for example `self.attributes.add("str", 10)`.
|
||||
What if you want spaces in your Attribute name? Or you want to assign the name of the Attribute on-the fly? Then you can use `.attributes.add(name, value)` instead, for example `self.attributes.add("str", 10)`.
|
||||
|
||||
```
|
||||
|
||||
|
|
@ -508,10 +500,7 @@ is called `at_object_creation`.
|
|||
|
||||
```{sidebar} __init__ vs at_object_creation
|
||||
|
||||
For the `Monster` class we used `__init__` to set up the class. We can't use this
|
||||
for a typeclass because it will be called more than once, at the very least after
|
||||
every reload and maybe more depending on caching. Even if you are familiar with Python,
|
||||
avoid touching `__init__` for typeclasses, the results will not be what you expect.
|
||||
For the `Monster` class we used `__init__` to set up the class. We can't use this for a typeclass because it will be called more than once, at the very least after every reload and maybe more depending on caching. Even if you are familiar with Python, avoid touching `__init__` for typeclasses, the results will not be what you expect.
|
||||
|
||||
```
|
||||
|
||||
|
|
@ -585,12 +574,7 @@ this is done (still in python multi-line mode):
|
|||
|
||||
```{sidebar} Database queries
|
||||
|
||||
`Character.objects.all()` is an example of a database query expressed in Python. This will be converted
|
||||
into a database query under the hood. This syntax is part of
|
||||
`Django's query language <https://docs.djangoproject.com/en/3.0/topics/db/queries/>`_. You don't need to
|
||||
know Django to use Evennia, but if you ever need more specific database queries, this is always available
|
||||
when you need it.
|
||||
|
||||
`Character.objects.all()` is an example of a database query expressed in Python. This will be converted into a database query under the hood. This syntax is part of [Django's query language](https://docs.djangoproject.com/en/4.1/topics/db/queries/). You don't need to know Django to use Evennia, but if you ever need more specific database queries, this is always available when you need it.
|
||||
```
|
||||
We import the `Character` class and then we use `.objects.all()` to get all `Character` instances. Simplified,
|
||||
`.objects` is a resource from which one can _query_ for all `Characters`. Using `.all()` gets us a listing
|
||||
|
|
|
|||
|
|
@ -77,8 +77,8 @@ from this class and just implement the `func` needed for that command without im
|
|||
|
||||
```{sidebar} Tuples and Lists
|
||||
|
||||
- A `list` is written as `[a, b, c, d, ...]`. You can add and grow/shrink a list after it was first created.
|
||||
- A `tuple` is written as `(a, b, c, d, ...)`. A tuple cannot be modified once it is created.
|
||||
- A `list` is written as `[a, b, c, d, ...]`. You can add and grow/shrink a list after it was first created.
|
||||
- A `tuple` is written as `(a, b, c, d, ...)`. A tuple cannot be modified once it is created.
|
||||
|
||||
```
|
||||
- **Line 14** - We do the stripping of `self.args` once and for all here. We also store the stripped version back
|
||||
|
|
@ -163,12 +163,7 @@ Let's try to swing it!
|
|||
|
||||
```{sidebar} Multi-matches
|
||||
|
||||
Some game engines will just pick the first hit when finding more than one.
|
||||
Evennia will always give you a choice. The reason for this is that Evennia
|
||||
cannot know if `hit` and `hit` are different or the same - maybe it behaves
|
||||
differently depending on the object it sits on? Besides, imagine if you had
|
||||
a red and a blue button both with the command `push` on it. Now you just write
|
||||
`push`. Wouldn't you prefer to be asked `which` button you really wanted to push?
|
||||
Some game engines will just pick the first hit when finding more than one. Evennia will always give you a choice. The reason for this is that Evennia cannot know if `hit` and `hit` are different or the same - maybe it behaves differently depending on the object it sits on? Besides, imagine if you had a red and a blue button both with the command `push` on it. Now you just write `push`. Wouldn't you prefer to be asked `which` button you really wanted to push?
|
||||
```
|
||||
Woah, that didn't go as planned. Evennia actually found _two_ `hit` commands to didn't know which one to use
|
||||
(_we_ know they are the same, but Evennia can't be sure of that). As we can see, `hit-1` is the one found on
|
||||
|
|
@ -208,10 +203,7 @@ for limiting the kind of things you can do with an object, including limiting ju
|
|||
it.
|
||||
```{sidebar} Locks
|
||||
|
||||
Evennia Locks are defined as a mini-language defined in `lockstrings`. The lockstring
|
||||
is on a form `<situation>:<lockfuncs>`, where `situation` determines when this
|
||||
lock applies and the `lockfuncs` (there can be more than one) are run to determine
|
||||
if the lock-check passes or not depending on circumstance.
|
||||
Evennia Locks are defined as a mini-language defined in `lockstrings`. The lockstring is on a form `<situation>:<lockfuncs>`, where `situation` determines when this lock applies and the `lockfuncs` (there can be more than one) are run to determine if the lock-check passes or not depending on circumstance.
|
||||
```
|
||||
|
||||
> py self.search("sword").locks.add("call:holds()")
|
||||
|
|
@ -223,10 +215,7 @@ For locks to work, you cannot be _superuser_, since the superuser passes all loc
|
|||
first:
|
||||
```{sidebar} quell/unquell
|
||||
|
||||
Quelling allows you as a developer to take on the role of players with less
|
||||
priveleges. This is useful for testing and debugging, in particular since a
|
||||
superuser has a little `too` much power sometimes.
|
||||
Use `unquell` to get back to your normal self.
|
||||
Quelling allows you as a developer to take on the role of players with less priveleges. This is useful for testing and debugging, in particular since a superuser has a little `too` much power sometimes. Use `unquell` to get back to your normal self.
|
||||
```
|
||||
|
||||
> quell
|
||||
|
|
@ -322,8 +311,7 @@ class SessionCmdSet(default_cmds.SessionCmdSet):
|
|||
|
||||
```{sidebar} super()
|
||||
|
||||
The `super()` function refers to the parent of the current class and is commonly
|
||||
used to call same-named methods on the parent.
|
||||
The `super()` function refers to the parent of the current class and is commonly used to call same-named methods on the parent.
|
||||
```
|
||||
`evennia.default_cmds` is a container that holds all of Evennia's default commands and cmdsets. In this module
|
||||
we can see that this was imported and then a new child class was made for each cmdset. Each class looks familiar
|
||||
|
|
@ -476,9 +464,7 @@ class CharacterCmdSet(default_cmds.CharacterCmdSet):
|
|||
```
|
||||
```{sidebar} Another way
|
||||
|
||||
Instead of adding `MyCmdGet` explicitly in default_cmdset.py,
|
||||
you could also add it to `mycommands.MyCmdSet` and let it be
|
||||
added automatically for you.
|
||||
Instead of adding `MyCmdGet` explicitly in default_cmdset.py, you could also add it to `mycommands.MyCmdSet` and let it be added automatically here for you.
|
||||
```
|
||||
|
||||
> reload
|
||||
|
|
|
|||
|
|
@ -1,21 +1,18 @@
|
|||
# Part 1: What we have
|
||||
|
||||
```{eval-rst}
|
||||
.. sidebar:: Beginner Tutorial Parts
|
||||
|
||||
`Introduction <../Beginner-Tutorial-Intro.html>`_
|
||||
Getting set up.
|
||||
**Part 1: What we have**
|
||||
A tour of Evennia and how to use the tools, including an introduction to Python.
|
||||
Part 2: `What we want <../Part2/Beginner-Tutorial-Part2-Intro.html>`_
|
||||
Planning our tutorial game and what to think about when planning your own in the future.
|
||||
Part 3: `How we get there <../Part3/Beginner-Tutorial-Part3-Intro.html>`_
|
||||
Getting down to the meat of extending Evennia to make our game
|
||||
Part 4: `Using what we created <../Part4/Beginner-Tutorial-Part4-Intro.html>`_
|
||||
Building a tech-demo and world content to go with our code
|
||||
Part 5: `Showing the world <../Part5/Beginner-Tutorial-Part5-Intro.html>`_
|
||||
Taking our new game online and let players try it out
|
||||
|
||||
```{sidebar} Beginner Tutorial Parts
|
||||
- [Introduction](../Beginner-Tutorial-Intro.md)
|
||||
<br>Getting set up.
|
||||
- Part 1: **[What we have](./Beginner-Tutorial-Part1-Intro.md)**
|
||||
<br>A tour of Evennia and how to use the tools, including an introduction to Python.
|
||||
- Part 2: [What we want](../Part2/Beginner-Tutorial-Part2-Intro.md)
|
||||
<br>Planning our tutorial game and what to think about when planning your own in the future.
|
||||
- Part 3: [How we get there](../Part3/Beginner-Tutorial-Part3-Intro.md)
|
||||
<br>Getting down to the meat of extending Evennia to make our game
|
||||
- Part 4: [Using what we created](../Part4/Beginner-Tutorial-Part4-Intro.md)
|
||||
<br>Building a tech-demo and world content to go with our code
|
||||
- Part 5: [Showing the world](../Part5/Beginner-Tutorial-Part5-Intro.md)
|
||||
<br>Taking our new game online and let players try it out
|
||||
```
|
||||
|
||||
In this first part we'll focus on what we get out of the box in Evennia - we'll get used to the tools,
|
||||
|
|
|
|||
|
|
@ -73,14 +73,10 @@ is to use the `.format` _method_ of the string:
|
|||
> py print("This is a {} idea!".format("good"))
|
||||
This is a good idea!
|
||||
|
||||
```{eval-rst}
|
||||
.. sidebar:: Functions and Methods
|
||||
```{sidebar} Functions and Methods
|
||||
- Function: Something that performs and action when you `call` it with zero or more `arguments`. A function is stand-alone in a python module, like `print()`
|
||||
- Method: A function that sits "on" an object, like `obj.msg()`.
|
||||
|
||||
Function:
|
||||
Something that performs and action when you `call` it with zero or more `arguments`. A function
|
||||
is stand-alone in a python module, like `print()`
|
||||
Method:
|
||||
A function that sits "on" an object, like `<string>.format()`.
|
||||
```
|
||||
|
||||
A method can be thought of as a resource "on" another object. The method knows on which object it
|
||||
|
|
|
|||
|
|
@ -35,15 +35,13 @@ def hello_world(who):
|
|||
who.msg("Hello World!")
|
||||
```
|
||||
|
||||
```{eval-rst}
|
||||
```{sidebar} Whitespace matters in Python!
|
||||
|
||||
.. sidebar:: Remember:
|
||||
|
||||
- Indentation matters in Python
|
||||
- So does capitalization
|
||||
- Use 4 `spaces` to indent, not tabs
|
||||
- Empty lines are fine
|
||||
- Anything on a line after a `#` is a `comment`, ignored by Python
|
||||
- Indentation matters in Python
|
||||
- So does capitalization
|
||||
- Use 4 `spaces` to indent, not tabs
|
||||
- Empty lines are fine
|
||||
- Anything on a line after a `#` is a `comment`, ignored by Python
|
||||
```
|
||||
|
||||
The _python_path_ describes the relation between Python resources, both between and inside
|
||||
|
|
@ -138,9 +136,7 @@ class Object(DefaultObject):
|
|||
|
||||
```{sidebar} Docstrings vs Comments
|
||||
|
||||
A docstring is not the same as a comment (created by `#`). A
|
||||
docstring is not ignored by Python but is an integral part of the thing
|
||||
it is documenting (the module and the class in this case).
|
||||
A docstring is not the same as a comment (created by `#`). A docstring is not ignored by Python but is an integral part of the thing it is documenting (the module and the class in this case).
|
||||
```
|
||||
The real file is much longer but we can ignore the multi-line strings (`""" ... """`). These serve
|
||||
as documentation-strings, or _docstrings_ for the module (at the top) and the `class` below.
|
||||
|
|
@ -158,8 +154,7 @@ little detour to understand what a 'class', an 'object' or 'instance' is. These
|
|||
things to understand before you can use Evennia efficiently.
|
||||
```{sidebar} OOP
|
||||
|
||||
Classes, objects, instances and inheritance are fundamental to Python. This and some
|
||||
other concepts are often clumped together under the term Object-Oriented-Programming (OOP).
|
||||
Classes, objects, instances and inheritance are fundamental to Python. This and some other concepts are often clumped together under the term Object-Oriented-Programming (OOP).
|
||||
```
|
||||
|
||||
### Classes and instances
|
||||
|
|
@ -187,11 +182,10 @@ at least one argument (almost always written as `self` although you could in pri
|
|||
another name), which is a reference back to itself. So when we print `self.key` we are referring
|
||||
back to the `key` on the class.
|
||||
|
||||
```{eval-rst}
|
||||
.. sidebar:: Terms
|
||||
```{sidebar} Terms
|
||||
|
||||
- A `class` is a code template describing a 'type' of something
|
||||
- An `object` is an `instance` of a `class`. Like using a mold to cast tin soldiers, one class can be `instantiated` into any number of object-instances.
|
||||
- A `class` is a code template describing a 'type' of something
|
||||
- An `object` is an `instance` of a `class`. Like using a mold to cast in soldiers, one class can be `instantiated` into any number of object-instances.
|
||||
|
||||
```
|
||||
A class is just a template. Before it can be used, we must create an _instance_ of the class. If
|
||||
|
|
@ -252,10 +246,7 @@ way:
|
|||
Or you can use a separate terminal and restart from outside the game:
|
||||
```{sidebar} On reloading
|
||||
|
||||
Reloading with the python mode gets a little annoying since you need to redo everything
|
||||
after every reload. Just keep in mind that during regular development you will not be
|
||||
working this way. The in-game python mode is practical for quick fixes and experiments like
|
||||
this, but actual code is normally written externally, in python modules.
|
||||
Reloading with the python mode gets a little annoying since you need to redo everything after every reload. Just keep in mind that during regular development you will not be working this way. The in-game python mode is practical for quick fixes and experiments like this, but actual code is normally written externally, in python modules.
|
||||
```
|
||||
|
||||
$ evennia reload (or restart)
|
||||
|
|
@ -347,9 +338,7 @@ the parent in parenthesis. `class Classname(Parent)` is the way to do this.
|
|||
|
||||
```{sidebar} Multi-inheritance
|
||||
|
||||
It's possible to add more comma-separated parents to a class. You should usually avoid
|
||||
this until you `really` know what you are doing. A single parent will be enough for almost
|
||||
every case you'll need.
|
||||
It's possible to add more comma-separated parents to a class. You should usually avoid this until you `really` know what you are doing. A single parent will be enough for almost every case you'll need.
|
||||
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -12,9 +12,7 @@ The base tools are the `evennia.search_*` functions, such as `evennia.search_obj
|
|||
|
||||
```{sidebar} Querysets
|
||||
|
||||
What is returned from the main search functions is actually a `queryset`. They can be
|
||||
treated like lists except that they can't modified in-place. We'll discuss querysets in
|
||||
the `next lesson` <Django-queries>`_.
|
||||
What is returned from the main search functions is actually a `queryset`. They can be treated like lists except that they can't modified in-place. We'll discuss querysets in the `next lesson` <Django-queries>`_.
|
||||
```
|
||||
|
||||
Strings are always case-insensitive, so searching for `"rose"`, `"Rose"` or `"rOsE"` give the same results.
|
||||
|
|
|
|||
|
|
@ -118,10 +118,7 @@ build a little "tech demo" along the way.
|
|||
|
||||
```{sidebar} Tech demo
|
||||
|
||||
With "tech demo" we mean a small example of your code in-action: A room with a mob,
|
||||
a way to jump into and test character-creation etc. The tech demo need not be pretty, it's
|
||||
there to test functionality. It's not the beginning of your game world (unless you find that
|
||||
to be more fun).
|
||||
With "tech demo" we mean a small example of your code in-action: A room with a mob, a way to jump into and test character-creation etc. The tech demo need not be pretty, it's there to test functionality. It's not the beginning of your game world (unless you find that to be more fun).
|
||||
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -1,24 +1,21 @@
|
|||
# Part 2: What we want
|
||||
|
||||
```{eval-rst}
|
||||
.. sidebar:: Beginner Tutorial Parts
|
||||
|
||||
`Introduction <../Beginner-Tutorial-Intro.html>`_
|
||||
Getting set up.
|
||||
Part 1: `What we have <../Part1/Beginner-Tutorial-Part1-Intro.html>`_
|
||||
A tour of Evennia and how to use the tools, including an introduction to Python.
|
||||
**Part 2: What we want**
|
||||
Planning our tutorial game and what to think about when planning your own in the future.
|
||||
Part 3: `How we get there <../Part3/Beginner-Tutorial-Part3-Intro.html>`_
|
||||
Getting down to the meat of extending Evennia to make our game
|
||||
Part 4: `Using what we created <../Part4/Beginner-Tutorial-Part4-Intro.html>`_
|
||||
Building a tech-demo and world content to go with our code
|
||||
Part 5: `Showing the world <../Part5/Beginner-Tutorial-Part5-Intro.html>`_
|
||||
Taking our new game online and let players try it out
|
||||
```{sidebar} Beginner Tutorial Parts
|
||||
- [Introduction](../Beginner-Tutorial-Intro.md)
|
||||
<br>Getting set up.
|
||||
- Part 1: [What we have](../Part1/Beginner-Tutorial-Part1-Intro.md)
|
||||
<br>A tour of Evennia and how to use the tools, including an introduction to Python.
|
||||
- **Part 2: [What we want](./Beginner-Tutorial-Part2-Intro.md)**
|
||||
<br>Planning our tutorial game and what to think about when planning your own in the future.
|
||||
- Part 3: [How we get there](../Part3/Beginner-Tutorial-Part3-Intro.md)
|
||||
<br>Getting down to the meat of extending Evennia to make our game
|
||||
- Part 4: [Using what we created](../Part4/Beginner-Tutorial-Part4-Intro.md)
|
||||
<br>Building a tech-demo and world content to go with our code
|
||||
- Part 5: [Showing the world](../Part5/Beginner-Tutorial-Part5-Intro.md)
|
||||
<br>Taking our new game online and let players try it out
|
||||
```
|
||||
|
||||
In Part two of the Beginner Tutorial we'll take a step back and plan out the kind of tutorial
|
||||
game we want to make. This is a more 'theoretical' part where we won't do any hands-on
|
||||
In Part two of the Evennia Beginner Tutorial we'll take a step back and plan out the kind of tutorial game we want to make. This is a more 'theoretical' part where we won't do any hands-on
|
||||
programming.
|
||||
|
||||
In the process we'll go through the common questions of "where to start"
|
||||
|
|
|
|||
|
|
@ -6,21 +6,19 @@ lessons as inspiration and to help get you going, but don't expect out-of-the-bo
|
|||
from it at this time.
|
||||
```
|
||||
|
||||
```{eval-rst}
|
||||
.. sidebar:: Beginner Tutorial Parts
|
||||
|
||||
`Introduction <../Beginner-Tutorial-Intro.html>`_
|
||||
Getting set up.
|
||||
Part 1: `What we have <../Part1/Beginner-Tutorial-Part1-Intro.html>`_
|
||||
A tour of Evennia and how to use the tools, including an introduction to Python.
|
||||
Part 2: `What we want <../Part2/Beginner-Tutorial-Part2-Intro.html>`_
|
||||
Planning our tutorial game and what to think about when planning your own in the future.
|
||||
**Part 3: How we get there**
|
||||
Getting down to the meat of extending Evennia to make our game
|
||||
Part 4: `Using what we created <../Part4/Beginner-Tutorial-Part4-Intro.html>`_
|
||||
Building a tech-demo and world content to go with our code
|
||||
Part 5: `Showing the world <../Part5/Beginner-Tutorial-Part5-Intro.html>`_
|
||||
Taking our new game online and let players try it out
|
||||
```{sidebar} Beginner Tutorial Parts
|
||||
- [Introduction](../Beginner-Tutorial-Intro.md)
|
||||
<br>Getting set up.
|
||||
- Part 1: [What we have](../Part1/Beginner-Tutorial-Part1-Intro.md)
|
||||
<br>A tour of Evennia and how to use the tools, including an introduction to Python.
|
||||
- Part 2: [What we want](../Part2/Beginner-Tutorial-Part2-Intro.md)
|
||||
<br>Planning our tutorial game and what to think about when planning your own in the future.
|
||||
- **Part 3: [How we get there](./Beginner-Tutorial-Part3-Intro.md)**
|
||||
<br>Getting down to the meat of extending Evennia to make our game
|
||||
- Part 4: [Using what we created](../Part4/Beginner-Tutorial-Part4-Intro.md)
|
||||
<br>Building a tech-demo and world content to go with our code
|
||||
- Part 5: [Showing the world](../Part5/Beginner-Tutorial-Part5-Intro.md)
|
||||
<br>Taking our new game online and let players try it out
|
||||
```
|
||||
|
||||
In part three of the Evennia Beginner tutorial we will go through the actual creation of
|
||||
|
|
|
|||
|
|
@ -1,20 +1,18 @@
|
|||
# Part 4: Using what we created
|
||||
|
||||
```{eval-rst}
|
||||
..sidebar:: Beginner Tutorial Parts
|
||||
|
||||
`Introduction <../Beginner-Tutorial-Intro.html>`_
|
||||
Getting set up.
|
||||
Part 1: `What we have <../Part1/Beginner-Tutorial-Part1-Intro.html>`_
|
||||
A tour of Evennia and how to use the tools, including an introduction to Python.
|
||||
Part 2: `What we want <../Part2/Beginner-Tutorial-Part2-Intro.html>`_
|
||||
Planning our tutorial game and what to think about when planning your own in the future.
|
||||
Part 3: `How we get there <../Part3/Beginner-Tutorial-Part3-Intro.html>`_
|
||||
Getting down to the meat of extending Evennia to make our game to make a tech-demo
|
||||
**Part 4: Using what we created**
|
||||
Using the tech-demo and world content to go with our code
|
||||
Part 5: `Showing the world <../Part5/Beginner-Tutorial-Part5-Intro.html>`_
|
||||
Taking our new game online and let players try it out
|
||||
```{sidebar} Beginner Tutorial Parts
|
||||
- [Introduction](../Beginner-Tutorial-Intro.md)
|
||||
<br>Getting set up.
|
||||
- Part 1: [What we have](../Part1/Beginner-Tutorial-Part1-Intro.md)
|
||||
<br>A tour of Evennia and how to use the tools, including an introduction to Python.
|
||||
- Part 2: [What we want](../Part2/Beginner-Tutorial-Part2-Intro.md)
|
||||
<br>Planning our tutorial game and what to think about when planning your own in the future.
|
||||
- Part 3: [How we get there](../Part3/Beginner-Tutorial-Part3-Intro.md)
|
||||
<br>Getting down to the meat of extending Evennia to make our game
|
||||
- **Part 4: [Using what we created](./Beginner-Tutorial-Part4-Intro.md)**
|
||||
<br>Building a tech-demo and world content to go with our code
|
||||
- Part 5: [Showing the world](../Part5/Beginner-Tutorial-Part5-Intro.md)
|
||||
<br>Taking our new game online and let players try it out
|
||||
```
|
||||
|
||||
We now have the code underpinnings of everything we need. We have also tested the various components
|
||||
|
|
|
|||
|
|
@ -1,22 +1,20 @@
|
|||
# Part 5: Showing the world
|
||||
|
||||
```{eval-rst}
|
||||
.. sidebar:: Beginner Tutorial Parts
|
||||
|
||||
`Introduction <../Beginner-Tutorial-Intro.html>`_
|
||||
Getting set up.
|
||||
Part 1: `What we have <../Part1/Beginner-Tutorial-Part1-Intro.html>`_
|
||||
A tour of Evennia and how to use the tools, including an introduction to Python.
|
||||
Part 2: `What we want <../Part2/Beginner-Tutorial-Part2-Intro.html>`_
|
||||
Planning our tutorial game and what to think about when planning your own in the future.
|
||||
Part 3: `How we get there <../Part3/Beginner-Tutorial-Part3-Intro.html>`_
|
||||
Getting down to the meat of extending Evennia to make our game
|
||||
Part 4: `Using what we created <../Part4/Beginner-Tutorial-Part4-Intro.html>`_
|
||||
Building a tech-demo and world content to go with our code
|
||||
**Part 5: Showing the world**
|
||||
Taking our new game online and let players try it out
|
||||
```{sidebar} Beginner Tutorial Parts
|
||||
- [Introduction](../Beginner-Tutorial-Intro.md)
|
||||
<br>Getting set up.
|
||||
- Part 1: [What we have](../Part1/Beginner-Tutorial-Part1-Intro.md)
|
||||
<br>A tour of Evennia and how to use the tools, including an introduction to Python.
|
||||
- Part 2: [What we want](../Part2/Beginner-Tutorial-Part2-Intro.md)
|
||||
<br>Planning our tutorial game and what to think about when planning your own in the future.
|
||||
- Part 3: [How we get there](../Part3/Beginner-Tutorial-Part3-Intro.md)
|
||||
<br>Getting down to the meat of extending Evennia to make our game
|
||||
- Part 4: [Using what we created](../Part4/Beginner-Tutorial-Part4-Intro.md)
|
||||
<br>Building a tech-demo and world content to go with our code
|
||||
- **Part 5: [Showing the world](./Beginner-Tutorial-Part5-Intro.md)**
|
||||
<br>Taking our new game online and let players try it out
|
||||
```
|
||||
|
||||
You have a working game! In part five we will look at the web-components of Evennia and how to modify them
|
||||
to fit your game. We will also look at hosting your game and if you feel up to it we'll also go through how
|
||||
to bring your game online so you can invite your first players.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue