It took a lot of effort, but we managed to release a new class, Druid, right on schedule. The actual core implementation of the mechanics and code only took about two full months; the hard part was the entropy, coming up with ideas. But ideas aren't really the hard part: if you ask your players for ideas, you'll get a steaming pile of hundreds of them. Ideas are easy. Good ideas that fit a model and work well together are not nearly so easy. I've been collecting good ideas that work together well for a few years now, and I needed pretty much all of them to make the class unique and not just a carbon copy of other classes.
Personally, I feel that just copying spells, skills, and classes is a bad idea, and while it might work in the short term to get content and features out the door quickly, I think it detracts from the long-term viability of a game. Part of what makes a long term game successful is how the pieces interact, the way you can get unexpected effects by strange configurations. Consider minecraft, a game with substantial complexity built on an extremely simple model and small set of ideas.
Unfortunately, holding new classes to such high standards means that I can't create many of them quickly. I would like to add a couple more classes if possible, but there might not actually be enough new and unique things left to do it. Over time, new mechanics will be added that might allow it, but it will probably be at least a couple of years before we have another class release.
I suppose my overall point is this: if you value the long term, don't cheese your game mechanics. Do it well, or not at all. Make something that surprises you from time to time, something that fits in with other stuff in the game, something which can't be done (or can't easily be done) in other ways. If you can't find a way to make races unique and interesting, don't add them. If you can't build a new class without photocopying existing effects from other classes, don't do it at all. Better to keep things sparse than pollute the game with uninteresting noise.
With this in mind, I'm proud to say that I'm happy with the new Druid class, as I was with the Necromancer class when it came out in 2010. They're both very well designed, and I'm certain the new Druid skills will make Alter Aeon and even better place to be. That's a pretty high bar.
Here's the official release announcement for the new class.
Druid Class Expansion on Alter Aeon
The long awaited sixth character class, Druid, has been released on Alter Aeon! Players can now add Druid powers to those of the other classes to create new skillset combinations and strengthen their characters.
This new character class adds a number of new abilities:
- control of the weather, to make storms and call lightning
- rune carving and runic enchantments
- magically controlling and growing plants
- animal lore and handling
- summon wind and dust storms to hinder your enemies
- use minions summoned from the earth to assist you in battle
- brew tinctures and salves for new special effects
- new item crafting skills using carving and runes
In addition to all this, it is now December, and the year-end Advent Calendar is now running! Log in for your daily advent calendar gifts, including practices, credits, storage locker time, unique items, and more.
Releases this big only happen every few years, so stop by and check it out!
Alter Aeon MUD
http://www.alteraeon.com
Sunday, December 1, 2013
Thursday, May 23, 2013
Test cases are awesome
One of my major background projects for the past few months has been to extract common libraries from various codebases, and get everything into a global, unified tree. As an example of this, I have a set of string utility routines I've been using for many years, and my normal way of using them was to grab and copy the code into various projects as I needed it. For routines as well-defined as these, it wasn't really a problem, but for anything even remotely more complex, it becomes a huge maintenance nightmare.
As part of this consolidation, I now have around 20 standalone library parts I can pretty easily use. There's a unified notify/error reporting mechanism, but most importantly for the purposes of this post, there are test cases. Lots of test cases.
I have traditionally done very little in the way of formalized testing, but by the same token, I've only recently started switching to a true 'library' structure for my code. It turns out that test cases are way more powerful and useful than I ever gave credit to.
So how do these test cases work? First, the build system compiles all the libraries, then it automatically builds and runs all the test cases for them. Every time. Running all the test cases currently adds about four seconds to the build time, which I can live with. I also make sure to update the test cases as I find bugs in general usage - it's very hard to guess all the bugs that might happen in advance, so putting in new tests as bugs are discovered is pretty important.
Part of the reason this is so powerful is that it's changed my debugging method for most of the library code. I get a questionable result in the mainline, so instead of trying to debug the mainline, I go add a test case and fix the library before I even try the mainline code again. Usually after doing that, the mainline bug goes away.
Another reason the tests are so powerful is because you never have to worry about regressions, or if something you changed accidentally breaks something else. You've also got simple, clear, and obvious code that demonstrates how to use the module in question, including ways to abuse it which produce well understood errors.
The downside to doing this is time and effort. A lot of time and effort. If I had to hazard a guess, I'd say that building proper libraries and the associated test cases takes 3-4 times as much work as just hacking something together that functions. The key to making libraries pay off is to make up for the difference one of two areas: long term maintenance, and use in multiple projects.
If you expect to maintain a project for many years, you -might- make up the difference in maintenance costs.
If you expect to use the library in at least 3 projects, you will make up the difference in implementation time.
Another downside is that building libraries and test cases is decidedly unglamorous. There's nothing cool about it, nothing you can really show anybody, and if you do try to show someone, you'll get a response like "it took you 12 hours to code up a way to do dns lookup from inside the game server?" The thing that will be missing is that along the way, you added a platform independent threading and mutex model as well as an async DNS caching system. Users will see those words and think 'blah blah', and wonder why your time wasn't spent doing something productive.
Anyway, I'm sold. I'll be adding a lot more test cases in the future.
As part of this consolidation, I now have around 20 standalone library parts I can pretty easily use. There's a unified notify/error reporting mechanism, but most importantly for the purposes of this post, there are test cases. Lots of test cases.
I have traditionally done very little in the way of formalized testing, but by the same token, I've only recently started switching to a true 'library' structure for my code. It turns out that test cases are way more powerful and useful than I ever gave credit to.
So how do these test cases work? First, the build system compiles all the libraries, then it automatically builds and runs all the test cases for them. Every time. Running all the test cases currently adds about four seconds to the build time, which I can live with. I also make sure to update the test cases as I find bugs in general usage - it's very hard to guess all the bugs that might happen in advance, so putting in new tests as bugs are discovered is pretty important.
Part of the reason this is so powerful is that it's changed my debugging method for most of the library code. I get a questionable result in the mainline, so instead of trying to debug the mainline, I go add a test case and fix the library before I even try the mainline code again. Usually after doing that, the mainline bug goes away.
Another reason the tests are so powerful is because you never have to worry about regressions, or if something you changed accidentally breaks something else. You've also got simple, clear, and obvious code that demonstrates how to use the module in question, including ways to abuse it which produce well understood errors.
The downside to doing this is time and effort. A lot of time and effort. If I had to hazard a guess, I'd say that building proper libraries and the associated test cases takes 3-4 times as much work as just hacking something together that functions. The key to making libraries pay off is to make up for the difference one of two areas: long term maintenance, and use in multiple projects.
If you expect to maintain a project for many years, you -might- make up the difference in maintenance costs.
If you expect to use the library in at least 3 projects, you will make up the difference in implementation time.
Another downside is that building libraries and test cases is decidedly unglamorous. There's nothing cool about it, nothing you can really show anybody, and if you do try to show someone, you'll get a response like "it took you 12 hours to code up a way to do dns lookup from inside the game server?" The thing that will be missing is that along the way, you added a platform independent threading and mutex model as well as an async DNS caching system. Users will see those words and think 'blah blah', and wonder why your time wasn't spent doing something productive.
Anyway, I'm sold. I'll be adding a lot more test cases in the future.
Thursday, February 14, 2013
Valentine's Day Server Updates
I had planned to open a bunch of things for Valentine's day, but I only managed to get about half of them done, largely due to laziness and akrasia. It's still a decent chunk of work though:
- There's a new slot machine based on a 'travelling merchant' theme. The first two slot machine wheels pick a random cargo and destination, the next few wheels pick your path through various terrain (or have you get robbed by thieves), and when you arrive at the destination you sell your cargo. If there's a local event and your cargo is badly needed, you make a premium on your cargo, for example if you're hauling food into a famine zone, or supplying weapons to a kingdom at war.
- There's a new level 14 area on the island of Kordan, the Haunted Hills. This is the first complete, full size area that I've personally built entirely myself in at least a decade, possibly more. I ended up making quite a few code changes for this - silly little things to make the area work the way I wanted it to, but important (at least to me.) This area taught me that I underestimate the creativity of my builders, and I overestimate the ability of the code. Several things that should have been easy to do and that I've seen other builders do were best handled as code updates; even though my awesome builders have managed to get similar effects, they had to use incredibly shitty workarounds to do it.
I'm now convinced that if I were to build full time, building areas would rapidly become easier and more powerful for all the builders. It may be worthwhile for me to simply build a zone every month or two to improve the building system. If only I had multiple copies of myself.
- There's also a new level 24 area on the island of Archais, the tinker gnome colony. This is a massive rebuild and rework of an ancient 15 room mini-area built by Aleph at the dawn of time; the rebuilt version is at least five times the size, and uses a lot of the snazzy new building features that weren't available in 1996.
- The planar research guild has opened their main offices in the city of Gad's Landing on the island of Archais. The guild gives out copies of a bunch of quests which were used in the 17th anniversary event of 2012. The players seemed to really like the anniversary quests, and with the opening of the planar knot observation platform, it makes sense that similar sorts of things would be available.
- I added a new level 31 mage spell, 'group teleport'. The whole point is so that people can teleport with their group, to die en-masse instead of solo. Now that we have obscure spells, I can safely add this and put it somewhere out of the way where new players won't kill themselves using it.
- As mentioned above, the 17th anniversary zone is now an official area. The observation platform is instanced and accessible to players of any level - the dangerous parts are cordoned off with a very powerful ward spell. My intent was that it would be a place to visit and/or sightsee, similar to the Lincoln monument. High level groups can break the wards and let loose the elementals in the rest of the area. It takes a group with a minimum of 5k mana and an obscure high level spell to do this, so I'm hoping that new players who wander into it will be safe.
- We also opened the 18th anniversary zone in the Ash Mountains. Ward breaking is needed to enter the main fortress, but honestly any group able to make it to the main fortress in one piece is probably capable of bringing down the wards. This and the 17th anniversary zones were primarily intended to be high level group experience.
There probably won't be any more area or event updates like this from me for a while. I'm pretty burned out now, having done christmas/new years, the anniversary, and now a gob of stuff for valentines day; I'm also really behind on work I had scheduled that is important, so I'll probably be spending some time on infrastructure for a while.
- There's a new slot machine based on a 'travelling merchant' theme. The first two slot machine wheels pick a random cargo and destination, the next few wheels pick your path through various terrain (or have you get robbed by thieves), and when you arrive at the destination you sell your cargo. If there's a local event and your cargo is badly needed, you make a premium on your cargo, for example if you're hauling food into a famine zone, or supplying weapons to a kingdom at war.
- There's a new level 14 area on the island of Kordan, the Haunted Hills. This is the first complete, full size area that I've personally built entirely myself in at least a decade, possibly more. I ended up making quite a few code changes for this - silly little things to make the area work the way I wanted it to, but important (at least to me.) This area taught me that I underestimate the creativity of my builders, and I overestimate the ability of the code. Several things that should have been easy to do and that I've seen other builders do were best handled as code updates; even though my awesome builders have managed to get similar effects, they had to use incredibly shitty workarounds to do it.
I'm now convinced that if I were to build full time, building areas would rapidly become easier and more powerful for all the builders. It may be worthwhile for me to simply build a zone every month or two to improve the building system. If only I had multiple copies of myself.
- There's also a new level 24 area on the island of Archais, the tinker gnome colony. This is a massive rebuild and rework of an ancient 15 room mini-area built by Aleph at the dawn of time; the rebuilt version is at least five times the size, and uses a lot of the snazzy new building features that weren't available in 1996.
- The planar research guild has opened their main offices in the city of Gad's Landing on the island of Archais. The guild gives out copies of a bunch of quests which were used in the 17th anniversary event of 2012. The players seemed to really like the anniversary quests, and with the opening of the planar knot observation platform, it makes sense that similar sorts of things would be available.
- I added a new level 31 mage spell, 'group teleport'. The whole point is so that people can teleport with their group, to die en-masse instead of solo. Now that we have obscure spells, I can safely add this and put it somewhere out of the way where new players won't kill themselves using it.
- As mentioned above, the 17th anniversary zone is now an official area. The observation platform is instanced and accessible to players of any level - the dangerous parts are cordoned off with a very powerful ward spell. My intent was that it would be a place to visit and/or sightsee, similar to the Lincoln monument. High level groups can break the wards and let loose the elementals in the rest of the area. It takes a group with a minimum of 5k mana and an obscure high level spell to do this, so I'm hoping that new players who wander into it will be safe.
- We also opened the 18th anniversary zone in the Ash Mountains. Ward breaking is needed to enter the main fortress, but honestly any group able to make it to the main fortress in one piece is probably capable of bringing down the wards. This and the 17th anniversary zones were primarily intended to be high level group experience.
There probably won't be any more area or event updates like this from me for a while. I'm pretty burned out now, having done christmas/new years, the anniversary, and now a gob of stuff for valentines day; I'm also really behind on work I had scheduled that is important, so I'll probably be spending some time on infrastructure for a while.
Friday, February 1, 2013
Alter Aeon Wiki
People have been harassing me for literally years to set up an AA wiki, but I always managed to avoid doing it for various reasons. I suspect the real reason I had been avoiding it was fear of the unknown, of not knowing if I could even figure it out (I have PTSD from the 1995 linux "recompile your compiler" era.) There's also the fear of it being a huge time sink, and many other such things.
To see the end result of a lot of hard work, the wiki URL is:
http://wiki.alteraeon.com
These fears were not unfounded, and had it not been for Uicli, I probably would never have done it. He set up an initial wiki on one of his servers, which would have made it the third or fourth player wiki over the years. All the other player-run wikis failed or vanished as the players moved on, so rather than have yet another player waste their time, I decided to set up an official AA wiki. Uicli guided me through most of the process, which was just the right amount of handholding.
Properly setting up a wiki is not simple:
Setting up the databases required me to read documentation again, and relearn things I had distantly touched on in the past. I only ever have to dig into them every year or two, so I'm never fresh on commands or how to do anything. Each time requires a little less startup time though.
Getting a custom theme in place was actually beyond my limited PHP abilities, but Uicli helpfully provided me a basic template to work with. Even he had to beat on it a handful of times to get it working properly.
The really surprising thing for me was how long it took to adjust the theme CSS. The initial/obvious stuff didn't take too long, and I've become fairly proficient in hunting down CSS entries using Firebug. Unfortunately, it's the little, unobvious things that really eat into your time budget: there's isolated, single use undocumented CSS entries all over the place, and I only figured out as many of them as I did by making all their colors bright green so they would stand out when they were finally displayed. There's still 20+ entries in the CSS I could not track down.
To top it all off, the wiki stores an additional CSS style sheet layer internally for use by templates, one which overrides ALL EXTERNAL CSS. Uicli and a couple other guys set this up, and I've been trying to slowly push the colors out to the external CSS while keeping the formatting and box styles in the internal CSS. Because the custom theme uses an inverted color scheme, it's a complete pain in the ass: if you do it wrong, either the default themes will be broken, or the custom theme, or both.
The email relaying I had done only a couple months ago when implementing the main game server email account verify code, so it didn't take too long. I have had very bad experiences with email in the distant past, and setting up mail servers still creeps me out.
Finally, I had to dig into the Wiki's PHP and add account restriction code to limit accounts based on game login id and email address. The game server exports a low-security file containing this information, and I've been using it on the AA forum to limit spam accounts. It's shockingly effective - simply limiting new accounts to being existing character names has dropped the number of spam accounts from 5 per day to less than 5 per year. I don't know how much more effective requiring the email address will be, but I'd be surprised to ever see a spam account on the wiki that doesn't come from an existing player (which I can siteban.)
That's a lot of different skillsets that have to come together in one place. While I could probably have muddled through it in the past, I'm glad I had at least introductions to all these things since then. If I had to set up another wiki, I could probably do it a lot more quickly now, and perhaps with this additional background, a few other modern web technologies will seem a bit less scary.
Don't expect me to jump on the Web 2.0 bandwagon just yet though.
To see the end result of a lot of hard work, the wiki URL is:
http://wiki.alteraeon.com
These fears were not unfounded, and had it not been for Uicli, I probably would never have done it. He set up an initial wiki on one of his servers, which would have made it the third or fourth player wiki over the years. All the other player-run wikis failed or vanished as the players moved on, so rather than have yet another player waste their time, I decided to set up an official AA wiki. Uicli guided me through most of the process, which was just the right amount of handholding.
Properly setting up a wiki is not simple:
- Set up and install the web server and accounts
- Grab the wiki package
- Set up the database and PHP so they work properly with the web server
- Initially configure and get the wiki itself working
- Get database and server backups working
- Set up game server SSH cron scripts to export valid account ids to wiki server
- Use PHP to parse valid account info for registration
- Get server email working and relayed through the external mail host
- Use PHP to create a derived theme
- Use CSS to make the theme not suck
Setting up the databases required me to read documentation again, and relearn things I had distantly touched on in the past. I only ever have to dig into them every year or two, so I'm never fresh on commands or how to do anything. Each time requires a little less startup time though.
Getting a custom theme in place was actually beyond my limited PHP abilities, but Uicli helpfully provided me a basic template to work with. Even he had to beat on it a handful of times to get it working properly.
The really surprising thing for me was how long it took to adjust the theme CSS. The initial/obvious stuff didn't take too long, and I've become fairly proficient in hunting down CSS entries using Firebug. Unfortunately, it's the little, unobvious things that really eat into your time budget: there's isolated, single use undocumented CSS entries all over the place, and I only figured out as many of them as I did by making all their colors bright green so they would stand out when they were finally displayed. There's still 20+ entries in the CSS I could not track down.
To top it all off, the wiki stores an additional CSS style sheet layer internally for use by templates, one which overrides ALL EXTERNAL CSS. Uicli and a couple other guys set this up, and I've been trying to slowly push the colors out to the external CSS while keeping the formatting and box styles in the internal CSS. Because the custom theme uses an inverted color scheme, it's a complete pain in the ass: if you do it wrong, either the default themes will be broken, or the custom theme, or both.
The email relaying I had done only a couple months ago when implementing the main game server email account verify code, so it didn't take too long. I have had very bad experiences with email in the distant past, and setting up mail servers still creeps me out.
Finally, I had to dig into the Wiki's PHP and add account restriction code to limit accounts based on game login id and email address. The game server exports a low-security file containing this information, and I've been using it on the AA forum to limit spam accounts. It's shockingly effective - simply limiting new accounts to being existing character names has dropped the number of spam accounts from 5 per day to less than 5 per year. I don't know how much more effective requiring the email address will be, but I'd be surprised to ever see a spam account on the wiki that doesn't come from an existing player (which I can siteban.)
That's a lot of different skillsets that have to come together in one place. While I could probably have muddled through it in the past, I'm glad I had at least introductions to all these things since then. If I had to set up another wiki, I could probably do it a lot more quickly now, and perhaps with this additional background, a few other modern web technologies will seem a bit less scary.
Don't expect me to jump on the Web 2.0 bandwagon just yet though.
Subscribe to:
Posts (Atom)