refactor: Epistemic shift from MUD to Spatial Research Environment

spatial_engine/world/README.md

@@ -0,0 +1,10 @@
+# world/
+
+This folder is meant as a miscellaneous folder for all that other stuff
+related to the game. Code which are not commands or typeclasses go
+here, like custom economy systems, combat code, batch-files etc. 
+
+You can restructure and even rename this folder as best fits your
+sense of organisation. Just remember that if you add new sub
+directories, you must add (optionally empty) `__init__.py` files in
+them for Python to be able to find the modules within. 

spatial_engine/world/batch_cmds.ev

@@ -0,0 +1,26 @@
+#
+# A batch-command file is a way to build a game world
+# in a programmatic way, by placing a sequence of
+# build commands after one another. This allows for
+# using a real text editor to edit e.g. descriptions
+# rather than entering text on the command line.
+#
+# A batch-command file is loaded with @batchprocess in-game:
+#
+#   @batchprocess[/interactive] tutorial_examples.batch_cmds
+#
+# A # as the first symbol on a line begins a comment and
+# marks the end of a previous command definition. This is important,
+# - every command must be separated by at least one line of comment.
+#
+# All supplied commands are given as normal, on their own line
+# and accept arguments in any format up until the first next
+# comment line begins. Extra whitespace is removed; an empty
+# line in a command definition translates into a newline.
+#
+# See `evennia/contrib/tutorial_examples/batch_cmds.ev` for
+# an example of a batch-command code. See also the batch-code
+# system for loading python-code this way.
+#
+
+

spatial_engine/world/help_entries.py

@@ -0,0 +1,58 @@
+"""
+File-based help entries. These complements command-based help and help entries
+added in the database using the `sethelp` command in-game.
+
+Control where Evennia reads these entries with `settings.FILE_HELP_ENTRY_MODULES`,
+which is a list of python-paths to modules to read.
+
+A module like this should hold a global `HELP_ENTRY_DICTS` list, containing
+dicts that each represent a help entry. If no `HELP_ENTRY_DICTS` variable is
+given, all top-level variables that are dicts in the module are read as help
+entries.
+
+Each dict is on the form
+::
+
+    {'key': <str>,
+     'text': <str>}``     # the actual help text. Can contain # subtopic sections
+     'category': <str>,   # optional, otherwise settings.DEFAULT_HELP_CATEGORY
+     'aliases': <list>,   # optional
+     'locks': <str>       # optional, 'view' controls seeing in help index, 'read'
+                          #           if the entry can be read. If 'view' is unset,
+                          #           'read' is used for the index. If unset, everyone
+                          #           can read/view the entry.
+
+"""
+
+HELP_ENTRY_DICTS = [
+    {
+        "key": "evennia",
+        "aliases": ["ev"],
+        "category": "General",
+        "locks": "read:perm(Developer)",
+        "text": """
+            Evennia is a MU-game server and framework written in Python. You can read more
+            on https://www.evennia.com.
+
+            # subtopics
+
+            ## Installation
+
+            You'll find installation instructions on https://www.evennia.com.
+
+            ## Community
+
+            There are many ways to get help and communicate with other devs!
+
+            ### Discussions
+
+            The Discussions forum is found at https://github.com/evennia/evennia/discussions.
+
+            ### Discord
+
+            There is also a discord channel for chatting - connect using the
+            following link: https://discord.gg/AJJpcRUhtF
+
+        """,
+    },
+]

spatial_engine/world/prototypes.py

@@ -0,0 +1,90 @@
+"""
+Prototypes
+
+A prototype is a simple way to create individualized instances of a
+given typeclass. It is dictionary with specific key names.
+
+For example, you might have a Sword typeclass that implements everything a
+Sword would need to do. The only difference between different individual Swords
+would be their key, description and some Attributes. The Prototype system
+allows to create a range of such Swords with only minor variations. Prototypes
+can also inherit and combine together to form entire hierarchies (such as
+giving all Sabres and all Broadswords some common properties). Note that bigger
+variations, such as custom commands or functionality belong in a hierarchy of
+typeclasses instead.
+
+A prototype can either be a dictionary placed into a global variable in a
+python module (a 'module-prototype') or stored in the database as a dict on a
+special Script (a db-prototype). The former can be created just by adding dicts
+to modules Evennia looks at for prototypes, the latter is easiest created
+in-game via the `olc` command/menu.
+
+Prototypes are read and used to create new objects with the `spawn` command
+or directly via `evennia.spawn` or the full path `evennia.prototypes.spawner.spawn`.
+
+A prototype dictionary have the following keywords:
+
+Possible keywords are:
+- `prototype_key` - the name of the prototype. This is required for db-prototypes,
+  for module-prototypes, the global variable name of the dict is used instead
+- `prototype_parent` - string pointing to parent prototype if any. Prototype inherits
+  in a similar way as classes, with children overriding values in their parents.
+- `key` - string, the main object identifier.
+- `typeclass` - string, if not set, will use `settings.BASE_OBJECT_TYPECLASS`.
+- `location` - this should be a valid object or #dbref.
+- `home` - valid object or #dbref.
+- `destination` - only valid for exits (object or #dbref).
+- `permissions` - string or list of permission strings.
+- `locks` - a lock-string to use for the spawned object.
+- `aliases` - string or list of strings.
+- `attrs` - Attributes, expressed as a list of tuples on the form `(attrname, value)`,
+  `(attrname, value, category)`, or `(attrname, value, category, locks)`. If using one
+   of the shorter forms, defaults are used for the rest.
+- `tags` - Tags, as a list of tuples `(tag,)`, `(tag, category)` or `(tag, category, data)`.
+-  Any other keywords are interpreted as Attributes with no category or lock.
+   These will internally be added to `attrs` (equivalent to `(attrname, value)`.
+
+See the `spawn` command and `evennia.prototypes.spawner.spawn` for more info.
+
+"""
+
+## example of module-based prototypes using
+## the variable name as `prototype_key` and
+## simple Attributes
+
+# from random import randint
+#
+# GOBLIN = {
+# "key": "goblin grunt",
+# "health": lambda: randint(20,30),
+# "resists": ["cold", "poison"],
+# "attacks": ["fists"],
+# "weaknesses": ["fire", "light"],
+# "tags": = [("greenskin", "monster"), ("humanoid", "monster")]
+# }
+#
+# GOBLIN_WIZARD = {
+# "prototype_parent": "GOBLIN",
+# "key": "goblin wizard",
+# "spells": ["fire ball", "lighting bolt"]
+# }
+#
+# GOBLIN_ARCHER = {
+# "prototype_parent": "GOBLIN",
+# "key": "goblin archer",
+# "attacks": ["short bow"]
+# }
+#
+# This is an example of a prototype without a prototype
+# (nor key) of its own, so it should normally only be
+# used as a mix-in, as in the example of the goblin
+# archwizard below.
+# ARCHWIZARD_MIXIN = {
+# "attacks": ["archwizard staff"],
+# "spells": ["greater fire ball", "greater lighting"]
+# }
+#
+# GOBLIN_ARCHWIZARD = {
+# "key": "goblin archwizard",
+# "prototype_parent" : ("GOBLIN_WIZARD", "ARCHWIZARD_MIXIN")
+# }