Tutorials and other Amenities

So, I have finally managed to get other projects done or taken care to the point that I can really get back into the grind of coding up Avaloria.  Sadly taking long breaks like these really hinder the creative flow as I have to re-acquaint myself with the codebase all over again.  One of the first things I did after coming back to this was rig up a config system specific to avaloria.  Evennia has its own, but I just wanted a simple dictionary to store float values/booleans used throughout the codebase for lots of different things like: mob's physical loot spawn rate, dungeon room treasure chest spawn rate, boss mob rare drop rate etc etc.  So now in the modules that need it I have the AVCONFIG global that lets me tap into those values as needed, and since they are all stored in once place, that makes for easy maintenance for me.  Eventually I will add more things like random range values for say the number of mobs generated for a particular zone room, and really whatever else I can come up with.  I'd like to end up with very little hard coded numbers in the end.

Implementing the config was actually a lot easier than I thought it would be, so I decided to work on something else I feel i needed, a proper tutorial for players to traverse through (optional of course) to learn the game, quest, get some early good exp etc.  Eventually once the questing manager can truely handle gear rewards, this would also be a good place to stock the new character with decent low level gear.  An example of some of the quests: Use the public chat channel to communicate with the world, train a new skill, learn a spell etc.  Basically anything that can be questified and teach the commands and ways of the game are being created and added to the various npcs of the tutorial area.  Avaloria is quite the magical place, and you as a character are no normal mortal so traveling there is instant, however eventually to progress through the various rooms, you will need to complete the necessary quests.

While writing these quests, I ended up having to modify the quest objective parser quite a bit to allow for the operations I wanted to work properly.  How do you know and check for someone using a chat channel?  How do you know that have trained a new skill.  For me I went the easy route and basically added a new quest type of 'use_<insert whatever it is you want the person to use>' and also simultaneous properly setting last_cmd on the Characters whenever they ran a command.  Once I did those two things, I just had to write some quick parsing to sanity check the command used and the command looked for and it was off to the races.  So far I have only written two of the handful of quests that will be included in the tutorial, as they did turn out to be a bit more work than I previously thought they would be.

I think this will (hopefully) allow for folks to learn the game while at the same time get rewards (skills, spells, exp, gold, and all that jazz).  Not too long now until I am ready to have some folks play on it.  Quite exciting indeed.

Henchmen Part Deux

As I am fast closing in on the time that I would like to start an alpha testing period, I have been trying to put the finishing basic touches on the different game systems on the backend. I just recently finished the grouping system and polished up the in game friends list, so now I set my sights back on the Lair and Henchmen setup. I very briefly set up the scaffolding for this behind the scenes about a month ago, but it was most certainly not in a useable state. While lair's supported Henchmen, there was no way for the game to interact with them. So, I set out to fix that.

First thing I needed to decide was how a lair would attract followers. What would it be based on? I decided to base it around what structures a player has built in their lair, along with a percentage attribute on the lair. The more you build up the lair, the more the chance to attract followers will be. So, basically while you may have the proper structure built, it does not mean that anyone will come. That is based on the percentage chance inherent to each lair.

Each particular type of structure will have a type of henchman that it attracts. For example, if you build a Gold Mine in your lair, you will attract imps. Training Grounds attract goblins, etc. The higher the level of their particular structure, the higher chance there is to attract them. The structure level also controls how many particular henchmen will be attracted at one time. These creatures are weak willed and easily controlled by anyone of measurable power, hence why they come to you. This works within the lore of Avaloria nicely, since the player is technically a demi-god. The idea will be to amass quite large armies of minions and then set them out to attack your opponents. The first portion is there now, being the generation and attraction of henchmen to the particular lairs.

The next portion to code in, and the most fun I imagine will be the lair combat code, which will be all the logic to control henchmen battles with other Lair's. This certainly will not be quick and easy, but it is the last "large" portion of code I have to work on before I am ready to open the gates to a testing group. While an Alpha test is by far no where near the end of the road, it is the start of a new chapter for Avaloria. It has grown from a small hobby code-base into a fairly feature rich mud code base. Since I have never done any thing at this scale, I can't help but be incredibly proud of my creation. Seeing it all work as it should while play testing makes for a very happy creator/developer!

The more the merrier!

grep would like you adventure with you.  Will you join them? [Y]/N: 
y
Adventuring Party formed! Leader: grep Members: [grep, josiah]
@group
Name                          Level                         
grep                          1                             
josiah                        1   

This past week I have had myself neck deep in Character Grouping code to allow for folks to invite/join an adventurer party complete with its own chat channel and of course; bonuses. Thankfully evennia makes this fairly complex problem easy to solve. Comm channels are already there and easy to add/delete. So in the end, my coding wasn't necessarily all the difficult but just time consuming to test and debug.

As it stands now, I have an object class that represents a Character Group. This objects has all the functions needed to interact with the group (invite, disband, kick, promote) and is also what stores the Communications channel created for the the members to be able to talk in their own private communication channel that no one else is privy to. As I said, this part is fairly trivial when using Evennia since all of that 'icky' code has already been done for me. I then store this 'group object' on each character model who is a member, and also set a boolean flag showing their sentinel script that they are in fact grouped. This is used to remove the party chat command when the character is not actively grouped.

Now that I have completely functioning grouping, the only thing left to do is: loot arbitration, corpse tagging and making a decision on what types of bonuses grouping gives players. Should it be a flat exp percentage bonus? Should you find more/rarer loot since technically you have more people looking and inspecting their surroundings? Also I have to decide what I am going to do about combat. At the current implementation, combat is and can only be between two people. Grouping is not taken into account, though the attributes for combat ai exist, the logic is not there to support it. So I still have quite a bit of work cut out for me with this specific piece of the game, but it's a very important aspect that needs to be done fairly and correctly.

The next portion that some what goes hand in hand with this is the player friendlist, which exists at the moment but is very, very primitive. I coded it quickly in about an hour or two and got the basic functionality then left it for more important tasks at the time. Seems a good time to circle back around and finish it up and put some polish on it. All in all, I am still aiming for an open alpha testing period at the end of april/very beginning of May!

Trudging on through the muckety muck.

This past month hasn't allowed me as much time as I would like to dedicate to Avaloria but never the less I have been working on it.  Lately I have been trying to flesh out a lot of the beginning quests and tutorials so that I can hopefully have an open alpha testing period by the end of April.  In doing so I have been expanding the quest objective parser to allow for different types of quests.  Along with this has been the creation of named enemy npcs.  These are merely specialized mob classes on the backend that have some different functions and flags.  These enemy npcs are going to be very interactive, talking to you, talking to themselves, roaming around and interacting with the game world and other mobs around them.  In creating these I needed the ability to reanimate them after death so that I wasn't constantly re-creating the object anytime someone killed it.

These enemy npc objects also have the ability to store dialogue's on them.  These dialogues are merely dictionaries with keyword keys, and dialogue values.  This will facilitate player interaction with said npcs and allow for trigger events to cause the npc to talk.  So perhaps if you walk into a room with a named npc, he or she may taunt you.  They may say mean things if you flee from them.  All of this is based off hooks used in the underlying evennia server.

All the mobs in the game have ratings that dictate their general difficulty: average, strong, hero, demi-god and God.  The general idea is that most mobs in the world will be average rating or strong.   Most of the quest npcs will be of hero rating and only bosses in large dungeons will be of demi-god rating.  The god rating will only be used for the actual deities in game or their aspects.  These will be incredibly tough enemies that will not be able to be soloed. 

This is just a brief behind the scenes look at the enemies and npcs in avaloria.  In the end, the encounters and enemies in avaloria will be varied and quite colorful indeed.

Lair Combat and Henchmen

Avaloria is a world full of bonuses. Bonuses from armor, weapons, structures you build, your lair itself. They come from everywhere. Lately I have begun work on the lair level system and henchmen. These are the last two 'must have' systems before I let people play test. Just about everything else is up, running and working well. This mechanic is going to be one of the many game defining things for Avaloria. Instead of flat out pvp (which may or may not be added, still undecided if I want that or not), the goal of players will be to build up their lair to the point that they attract followers or as they are called in the code: henchmen. Henchmen come in all different shapes and sizes and live inside the lair. You, the player, will have the ability to direct them to do your bidding.

This becomes interesting when you allow said henchmen to go out and wreak havoc upon opposing deity-factions. This mostly goes hand in hand with the Lair leveling system, which in turn ties into the structure building system. Currently as it stands, when you dump gold into building a structure, that gold is also dumped into your lair as currency for leveling. When your lair levels it gains stats, just as the player does when they level which are used when henchmen from opposing lairs come to attack your lair. Depending on the structures you have built, the bonuses given to your lair, and you as a player will differ. Some buildings buff different stats, while others generate gold for you, or attract followers.

On the backend, henchmen are nothing more than a small dictionary with some stats used for battles and the amount currently stationed at your lair. This allows for a pretty flexible system that makes it rather trivial to add new types of henchmen. Eventually you will be able to raise resources (undetermined what that will be, but the mechanism will be used to limit the amount of times you may initiate combat with another lair) to then lead your army to an opposing deity-factions lair and begin a siege. Sieges can last minutes or hours depending on the parties involved. If you are the attacker and you manage to breach the Throne Room of the opposing player you will receive rewards (Experience, loot, some of their gold, and most likely a large amount of fame based on the level of the opposing player.).

Eventually henchmen will have their own sets of skills and uses for things other than just lair combat. Maybe you will set them loose on a opposing faction's zone/town. Perhaps you will use them to gather materials needed for your next siege? The choices will be close to endless once the system is in place. There is still however quite a bit of code that needs to be written before we get there.

Skill System Refactor (Or The Wild world of Percentages)

I don't even know if I can really call it refactoring, since I am really just changing the way skills advance and the currency used for said advancement. However, it is quite a drastic change on the backend.

Previously I had thought that I would make the players seek out trainers and spend their gold on ranking up their skills, which would be found randomly through questing/as loot etc. This seemed like a good idea until it came time to actually advance the skill. What got modified? If it's a damage skill, it seems silly to change the base damage dice every single level. Not scalable. Then, I briefly entertained not making every rank do something in terms of skill effectiveness. That seemed like a cheat and a waste when I thought about it from the player perspective. All in all the system based around gold spending and trainer finding just seemed far to cumbersome, to me as a developer and a player.

So I implemented something that harkens back to my days of playing the fabulous MMORPG Asheron's Call. In that particular game, you spent your accrued Experience Points on your attributes and skills. This is obviously a VERY open system, and is designed to be as such. However, Avaloria aims to be very open in terms of character development. You CAN wear plate armor and cast spells. You may fail a slight bit more than others, or possibly have some spell backlash due to the metal armor, but that chance will be small if you specialize into a class designed for battle magic use. Classes will never be mandatory, and most skills will be available to all classes/non-classed characters.

To that end, skills now have a backend component that is merely a floating number which starts at .01. Each point added to the skill (using Experience Currency) will relate on the backend to a 1% increase to the skill's rank modifier. This rank modifier is then used to increase/decrease certain things pertaining to the specific skill.

So, for example the Strike skill. This is a medium damage melee strike. The modifier for it increases damage output, and also slightly increases critical hit chance. I also have a 'Toughness' Skill that adds to constitution and therefore gives the character more health. In that skill's case it's modifier relates to how much of a bonus the character receives.

This system is quite extensible and can be limited/used in many different ways. I look forward to implementing more skills and spells. Now that most of the backend i wanted up for an alpha is complete, I will actually be able to work on game content.

Refactor all things!

When I began this project almost a year ago, I had never written anything larger then a couple 100 lines in python. My main experience with django was with a small app I wrote for work to scrape emails for a particular failure case we had. Nothing I had done really quite prepared me for attempting to assemble all the game systems needed for a robust, state of the art, and more importantly; modern mud. This is evident in the code I wrote at that time, and so I have spent the past few days combing through it all and re-factoring the horrible parts, taking note from the clean, well designed parts.

This brings me to the next topic: How to make a huge, giant, game world tick without destroying the computer running it. Thankfully with the help of the Evennia devs, the solution is almost so simple it hurts to think I didnt realize it on my own, but you live and you learn.

The method is what is called a 'global tick' or 'global runner' system, and within Evennia at least, it is very easy. Just take a look at the following code:

class MobRunner(Script):
    """
    Controls when the update functions for mobs are called.  Holds
    a list of dbref's for subscribing objects (Mobs)
    """

    def at_script_creation(self):
        self.key = 'mob_runner'
        self.interval = 30 
        self.persistent = True
        self.desc = 'controls the subscribing mobs'
        self.db.mobs = [] 
         
    def at_start(self):
        self.ndb.mobs = [ search.objects(dbref) for dbref in self.db.mobs ]
        
    def at_repeat(self):
        self.ndb.mobs = search.objects('mob_runner')
        [mob.update() for mob in self.ndb.mobs if mob.db.should_update ]

    def at_stop(self):
        self.db.mobs = [mob.dbref for mob in self.ndb.mobs]

So what is that doing? It's basically keeping a list full of subscribing object id's. On start it reads these into memory (say after a server restart), then when the script rolls around and repeats it does two things: update the memory stored list of mobs subscribing to it, and then running the update function on each subscriber, if it is set to update. This particular script runs every 30 seconds and is what controls a lot of random upkeep for the mobs in Avaloria. This approach can be used with multiple scenarios where EVERYTHING in the world needs to have something done to it. The resource usage is minimal and everything runs fantastically so far, even when jammed full of objects all needing updates.

Thanks to the guys at the Evennia project for setting me straight and not allowing me to run my server to an early grave :)