The great thing about data is that, by itself, it’s simply inert. Unlike with code, you don’t have to think about logic or time. This is why you should work out a first draft of the data required for your project before writing any code. For example, in a Mario game, you’ll need a data type representing Mario’s coordinates in the world, his number of coins, his number of remaining lives, his collision boundary, his current momentum along the x and y axis, etc. We don’t yet concern ourselves with how the Mario type will be used by code, just that the type can represent all possible Mario states.
Because of the wide open nature of Evennia and the flexibility of Python, this gives us the ability to have a much more robust data model of each object in the game. We need to discuss and determine what types of objects we're going to have, as well as how the data should be modeled on them.
With the ability to have a true object-oriented system, we can start thinking of things in a more organized way. For example:
Structure
Weapon
- Ranged
- Aoe
- Targeted
- Thrown
WeaponCategory*
- One hand
- Two hand
- Ammunition
- Grenade
WeaponDamageType
- Bludgeoning
- Piercing
- Slashing
\* weapon_type should probably be an attribute called by WeaponCategory due to the fact that weapon types don't change in PathFinder (config_Opt,)
I would also like to propose to use this format when we are outlining code, as it gives a natural progression from discussion to implementation - that's basically a class/method layout with a reference to an external call to a config option. The (config_option,) syntax is non-negotiable. It will make scraping files for system frameworks much easier. Note the trailing comma - there on purpose
because Python requires a trailing comma for the creation of a single element tuple (data type).
We will need to create issues for every system (These should be automatically) be posted onto the KanBan Project board (which I encourage all team members to join) which will help speed workflow - and nobody will be left wondering 'Are those two working on anything!?' :-)
Processes
As we get deeper into the systems, I would propose that we give a complete written description of each step of the system processes in bulleted format in __docstring__ for a few reasons:
Writing things out first improves understanding of what steps are needed
Near-complete setup that you can copy for the final 'docstring' content (PEP257)
Near-complete setup that you can copy for creating variables and code structure
On Variables or What's in a name?
I have the world's worst time naming things. I will go through four or five iterations of a variable name before I finally land on one. My current mantra is:
"Call it what it is."
If you look at my bucket.pymodule, you will see a stunningly perfect example of bad naming and shoddy code. This is a working prototype at this point.
So, in lieu of self.bladed_non_axe_weapons, just use self.swords. This improves readability for all who contribute downstream; Not only that though, it eases the process of understanding what your code is while you're writing it. So if you're having a hard time understanding what's going on with your code, try renaming some things to be a little more no-nonsense. It's not a self.switch_handler, it's just a self.switch.
Needed Models:
We need to determine the needs of the following models. Do we want to modify the base behavior, and if so, in what manner. What should all these things have in common?
Accounts
Description
The account is the basic controller of Evennia. This allows a player to negotiate a connection to the server and retrieve messages sent to that account to their client.
I suggest that we think very carefully about modifying the default behaviour of the account - not that we shouldn't at all...just that we should proceed with caution if we do.
I also suggest that we get the player's email address to register the acounts to, as this willadd an extra layer of security. I think we should also obscure account holder's Email addresses from the rest of the playerbase, unless someone wants to share that info.
With an email address and smtplib, this will allow us to do a few neat things:
+mail/offline - send mail to a userwho is offline - a good way to let them keep a record of requests, interactions, etc. Offsite backup is never bad.
Automating mailings to players as needed - Newsletter anyone?
Easier system of decomp'ing character data to package up, zip and send to the user's address. No more ugly walls of text file to deal with, we can format the output as part of the processing.
Common Features
Alts
It is my recommendation that instead of using the old mush standard of 1 account == 1 alt, that we take advantage of Evennia's inbuilt puppeting features to handle creation of and management of alts.
This will be a slightly newer process to most players; however, with intelligent UI design, it should be easy to pick up.
Email
If we make this optional, people won't use the features that we can build in, however, if we don't use some sort of optout system for automatic mailings, that could lead to some dirty looks.
need more input on any account level features we want to have
Automation
Description
TBD
This is probably going to be a sensitive topic from a mush traditionalist's point of view, but it's something I would like to toss up there. My goal for the code we develop is to eventually be able to handle automation of NPC's, ambiance, shifting room effects, the ability to construct solveable mazes and puzzles and (possibly) building in some framework for developing mini-game like areas within the context of the server itself, using multiple play systems.
This may be something that's a little beyond the scope of where Tenebrae wants to go, and if that's so, that's completely fine. What I need though is input from what systems you guys want automated first so that I can
track it on the system with issues so we can hopefully get another contrib or two in here if people are interested in helping.
Common Features
tbd
Character
Description
The character is the base functioning object that players log into. These are objects, just like any other created thing, however they can (and should) inherit many different attributes.
We can easily implement things like actual strength checks to move items/objects tied to the character's sheet, systems for shapechangers to be able to assume their chosen shape and have all correct attributes apply.
So, while you're thinking of features, don't just think in terms of PathFinder, also think in terms of what all playable races/classes have in common. This will be broken down into subclasses as we code of course.
Because of the wide open nature of Evennia and the flexibility of Python, this gives us the ability to have a much more robust data model of each object in the game. We need to discuss and determine what types of objects we're going to have, as well as how the data should be modeled on them.
With the ability to have a true object-oriented system, we can start thinking of things in a more organized way. For example:
Structure
I would also like to propose to use this format when we are outlining code, as it gives a natural progression from discussion to implementation - that's basically a class/method layout with a reference to an external call to a config option. The (config_option,) syntax is non-negotiable. It will make scraping files for system frameworks much easier. Note the trailing comma - there on purpose because Python requires a trailing comma for the creation of a single element tuple (data type).
We will need to create issues for every system (These should be automatically) be posted onto the KanBan Project board (which I encourage all team members to join) which will help speed workflow - and nobody will be left wondering 'Are those two working on anything!?' :-)
Processes
As we get deeper into the systems, I would propose that we give a complete written description of each step of the system processes in bulleted format in
__docstring__for a few reasons:On Variables or What's in a name?
I have the world's worst time naming things. I will go through four or five iterations of a variable name before I finally land on one. My current mantra is:
If you look at my
bucket.pymodule, you will see a stunningly perfect example of bad naming and shoddy code. This is a working prototype at this point.So, in lieu of
self.bladed_non_axe_weapons, just useself.swords. This improves readability for all who contribute downstream; Not only that though, it eases the process of understanding what your code is while you're writing it. So if you're having a hard time understanding what's going on with your code, try renaming some things to be a little more no-nonsense. It's not aself.switch_handler, it's just aself.switch.Needed Models:
We need to determine the needs of the following models. Do we want to modify the base behavior, and if so, in what manner. What should all these things have in common?
Accounts
Description
The account is the basic controller of Evennia. This allows a player to negotiate a connection to the server and retrieve messages sent to that account to their client. I suggest that we think very carefully about modifying the default behaviour of the account - not that we shouldn't at all...just that we should proceed with caution if we do. I also suggest that we get the player's email address to register the acounts to, as this willadd an extra layer of security. I think we should also obscure account holder's Email addresses from the rest of the playerbase, unless someone wants to share that info. With an email address and smtplib, this will allow us to do a few neat things:
Common Features
Alts
It is my recommendation that instead of using the old mush standard of 1 account == 1 alt, that we take advantage of Evennia's inbuilt puppeting features to handle creation of and management of alts. This will be a slightly newer process to most players; however, with intelligent UI design, it should be easy to pick up.
Email
If we make this optional, people won't use the features that we can build in, however, if we don't use some sort of optout system for automatic mailings, that could lead to some dirty looks. need more input on any account level features we want to have
Automation
Description
TBD
This is probably going to be a sensitive topic from a mush traditionalist's point of view, but it's something I would like to toss up there. My goal for the code we develop is to eventually be able to handle automation of NPC's, ambiance, shifting room effects, the ability to construct solveable mazes and puzzles and (possibly) building in some framework for developing mini-game like areas within the context of the server itself, using multiple play systems. This may be something that's a little beyond the scope of where Tenebrae wants to go, and if that's so, that's completely fine. What I need though is input from what systems you guys want automated first so that I can track it on the system with issues so we can hopefully get another contrib or two in here if people are interested in helping.
Common Features
tbd
Character
Description
The character is the base functioning object that players log into. These are objects, just like any other created thing, however they can (and should) inherit many different attributes. We can easily implement things like actual strength checks to move items/objects tied to the character's sheet, systems for shapechangers to be able to assume their chosen shape and have all correct attributes apply. So, while you're thinking of features, don't just think in terms of PathFinder, also think in terms of what all playable races/classes have in common. This will be broken down into subclasses as we code of course.
Common Features
PC's
NPC's
Object
Description
Common Features
Room
Description
Common Features
Zone
Description
Common Features