For reasons unrelated to the previous post, I ended up doing a lot of object work in the last couple of days. I discovered that the linkages between rarity, and the bind/artifact/rare flags were not just overly complex, but in some cases really inappropriate. It took several hours and multiple tries to work out all the details, and we now have a much better rating system for flags and rarity.
The general summary is that binding is much weaker, artifact and rare are stronger, you get an extra artifact per rack, and rarity is being deprecated.
Rarity I was the most surprised about; there were literally thousands of objects with rarity on the game. I wrote a function to remove it from everything that didn't strictly need it; this cut the number down to under a thousand. It's still a useful mechanic to have on certain special items, but having it on this many of them really doesn't seem appropriate. Rarity will also be a major issue with a larger player base, and we need to use a new mechanic for a lot of these things.
Weakening the bind flag caused issues with a lot of equipment that was built to take advantage of binding. A good chunk of it was in newbie areas, where I myself used it to get fairly powerful equipment to low levels. On the other hand, a lot of the other binding objects were problem objects that needed to be adjusted anyway. We've had a problem with bind flag overuse for a while now, and this helps address that.
The addition of another artifact flag is a major change, but it comes with a caveat: one artifact flag has to be bound, while the other must be unbound. A similar restriction is in place for rare flagged items.
This seems to be a really interesting idea. The bound objects are slightly more powerful but cannot be sold; the unbound objects can be sold and will serve to keep the equipment market functional. The fact that builders must build both bound and unbound equipment should help with equipment diversity and address some of the concerns that players have about "everything becoming bound".
All in all, I've been getting a lot of positive feedback on it. I know it's inconvenient for builders to update things (I make a point of it to personally take my share of pain from the older areas), but so far the consensus seems to be that it's worth it.
Wednesday, April 28, 2010
Monday, April 19, 2010
Objects - rarity and timers - TL/DR
There are several different types of 'powerful' objects, with various limitations, that can be built on Alter Aeon:
Rarity based: Only a certain number of the item can be on the game at once. The limit is a long term (multiple week) average, so there may be none or there may be a lot of them on at any given time. If the long term average is too high, the item stops loading.
Binding: The object binds to whoever picks it up, preventing trading and selling. There are usually a low number of these per zone, between 0 and 3. The building code warns if there are too many of this in any given zone.
Artifact: One artifact is allowed per zone. Artifacts can be much more powerful than normal equipment.
Rare: Two rare items are allowed per zone. Rare items can be a bit more powerful than normal equipment.
Timered: The item has a timer and will at some point self destruct.
Each of these four classes can be more powerful than normal equipment, and as names like 'artifact' suggest, sometimes they can be very much more powerful. Some of these different classes interact with each other, making the calculations and code messy; for example, Rarity and Binding contribute to make Artifacts more powerful, but only to an extent.
This complexity in itself is problematic, but there are two other major issues to consider as well:
Rarity based: For any 'good' and useful piece of rarity equipment, it is obtained repeatedly until it is well past its loading limit. If the item is also Binding, it can't be traded and eventually it begins loading again as players stop playing the game. If it's not Binding, players trade occasionally (one or two trades per year) for the few pieces that exist, and it never loads again.
Timered: Noone will ever use the item. If it's not permanent, people aren't interested.
Rarity doesn't make any sense if all it does is give a small number of players a monopoly on an item; for them it's not rare, it's just a part of their set that noone else can ever get. For everyone else, it's so rare as to be impossible to obtain.
Timers on the other hand are the opposite end of the spectrum. Regardless of how good it is, people won't use it if it's timered. There seems to be some small exception for this with timered enchanted equipment, but I suspect this is because the timers are really long and the equipment doesn't self destruct when the enchant wears off.
Timers are of course, the obvious natural mechanic for controlling rarity based equipment. If something is limited load, simply make its duration in-game finite. This would guarantee turnover and make the item available to more people.
One final thing to consider is the way that timers currently work: they're not based on real time, but rather some amount of game time. You get an item, and you know it'll time out after you've used it for a while, but you never quite know when without checking it each time. If you log off for a week, you're likely to forget about it and suddenly find an important item vanishing unexpectedly in the middle of a battle.
This leads to one possible improvement: RL timered equipment. You have something, but you know exactly how long you have it for. Having something say "This will expire at Mon Apr 19 11:33:15 2010" is very different than having it say "This item will last for two RL days of game time, which could be two months from now if you don't play very often". It also has a built-in sense of rarity attached to it.
I like it.
Rarity based: Only a certain number of the item can be on the game at once. The limit is a long term (multiple week) average, so there may be none or there may be a lot of them on at any given time. If the long term average is too high, the item stops loading.
Binding: The object binds to whoever picks it up, preventing trading and selling. There are usually a low number of these per zone, between 0 and 3. The building code warns if there are too many of this in any given zone.
Artifact: One artifact is allowed per zone. Artifacts can be much more powerful than normal equipment.
Rare: Two rare items are allowed per zone. Rare items can be a bit more powerful than normal equipment.
Timered: The item has a timer and will at some point self destruct.
Each of these four classes can be more powerful than normal equipment, and as names like 'artifact' suggest, sometimes they can be very much more powerful. Some of these different classes interact with each other, making the calculations and code messy; for example, Rarity and Binding contribute to make Artifacts more powerful, but only to an extent.
This complexity in itself is problematic, but there are two other major issues to consider as well:
Rarity based: For any 'good' and useful piece of rarity equipment, it is obtained repeatedly until it is well past its loading limit. If the item is also Binding, it can't be traded and eventually it begins loading again as players stop playing the game. If it's not Binding, players trade occasionally (one or two trades per year) for the few pieces that exist, and it never loads again.
Timered: Noone will ever use the item. If it's not permanent, people aren't interested.
Rarity doesn't make any sense if all it does is give a small number of players a monopoly on an item; for them it's not rare, it's just a part of their set that noone else can ever get. For everyone else, it's so rare as to be impossible to obtain.
Timers on the other hand are the opposite end of the spectrum. Regardless of how good it is, people won't use it if it's timered. There seems to be some small exception for this with timered enchanted equipment, but I suspect this is because the timers are really long and the equipment doesn't self destruct when the enchant wears off.
Timers are of course, the obvious natural mechanic for controlling rarity based equipment. If something is limited load, simply make its duration in-game finite. This would guarantee turnover and make the item available to more people.
One final thing to consider is the way that timers currently work: they're not based on real time, but rather some amount of game time. You get an item, and you know it'll time out after you've used it for a while, but you never quite know when without checking it each time. If you log off for a week, you're likely to forget about it and suddenly find an important item vanishing unexpectedly in the middle of a battle.
This leads to one possible improvement: RL timered equipment. You have something, but you know exactly how long you have it for. Having something say "This will expire at Mon Apr 19 11:33:15 2010" is very different than having it say "This item will last for two RL days of game time, which could be two months from now if you don't play very often". It also has a built-in sense of rarity attached to it.
I like it.
Friday, April 16, 2010
Myspace
Today, I did the unthinkable: I constructed a myspace page. I suppose technically, I had already done that with my personal page last year; but in reality it was simply the bare minimum login and I had done nothing at all to it since it was created.
I really have to hand it to the myspace developers; they've created one of the single most dysfunctional, hard to use, and unconfigurable interfaces I've ever seen that still happens to mostly work. It reminds me a lot of Gimp.
Actually, Gimp is worse. But not by much.
At any rate, if you still have a MySpace account, feel free to add us! Our myspace URL is:
http://www.myspace.com/alter_aeon
I really have to hand it to the myspace developers; they've created one of the single most dysfunctional, hard to use, and unconfigurable interfaces I've ever seen that still happens to mostly work. It reminds me a lot of Gimp.
Actually, Gimp is worse. But not by much.
At any rate, if you still have a MySpace account, feel free to add us! Our myspace URL is:
http://www.myspace.com/alter_aeon
Tuesday, April 13, 2010
Dprocs
We have a rather interesting interpreted language in-game that can be used to perform actions on a handful of triggers; an example might be to add an arbitrary 'use' function to an object. As an example of this, I once built a vacuum cleaner object which could be used to suck up pretty much anything you pointed it at. Sucked up things ended up inside the vacuum.
One drawback of this language is that it didn't have any concept of global data. I added that feature today, using a surprisingly small amount of code.
A surprisingly small amount of code that took me about three hours to write.
Once again, software complexity rears its ugly head. I actually made two false starts on this problem, each of which I had to back out before finally getting a minimal solution to it. The interpreter isn't really that complicated or large by any real programming standard, but it's still larger and more complicated than I could easily wrap my brain around.
It took about two hours to really figure out the best way to handle it, then about an hour to implement it. Most of that time was just trying to understand what was already there and how it all worked. And this is code I wrote!
On the plus side, my actual implementation, when I finished, had 2 bugs in it, both trivial. It's good to know that thorough understanding up front does in fact result in far fewer mistakes.
One drawback of this language is that it didn't have any concept of global data. I added that feature today, using a surprisingly small amount of code.
A surprisingly small amount of code that took me about three hours to write.
Once again, software complexity rears its ugly head. I actually made two false starts on this problem, each of which I had to back out before finally getting a minimal solution to it. The interpreter isn't really that complicated or large by any real programming standard, but it's still larger and more complicated than I could easily wrap my brain around.
It took about two hours to really figure out the best way to handle it, then about an hour to implement it. Most of that time was just trying to understand what was already there and how it all worked. And this is code I wrote!
On the plus side, my actual implementation, when I finished, had 2 bugs in it, both trivial. It's good to know that thorough understanding up front does in fact result in far fewer mistakes.
Tuesday, April 6, 2010
Leading by Leading
If there's one thing I've learned over the years, it's that public debate about radical new game features is seldom a good thing. It's not the players don't have good ideas; it's that vocal minority groups serve to deadlock and kill otherwise good ideas.
This reminds me of the Knesset in Israel. They have so many fanatic fringe groups that it's virtually impossible to get anything done.
On March 16, I globally removed and disabled permanent player killing. I didn't post about it, I didn't request for comments; I simply did it, and waited for the fallout.
There wasn't any. Or rather, the people who would have made a big deal of it were unable to do so - there was no way to invoke righteous indignation from the population by blowing things out of proportion. Propaganda doesn't work when people can try it for themselves and say, "no, that's not true".
The next day, I changed the way magic resistance works for players. I've been wanting to do this for over a decade, but never felt like it would be appropriate. Fallout level? Again, very little. Again, largely because the bullshit espoused by the vocal minority was quickly killed by players simply trying things for themselves.
I like this idea of leading by leading instead of leading by consensus. Decide what to do, make it happen, just be prepared to clean up the mess afterward. It's not that I'll never mess up, but it's definitely easier to apologize and fix it than to debate it up front.
This reminds me of the Knesset in Israel. They have so many fanatic fringe groups that it's virtually impossible to get anything done.
On March 16, I globally removed and disabled permanent player killing. I didn't post about it, I didn't request for comments; I simply did it, and waited for the fallout.
There wasn't any. Or rather, the people who would have made a big deal of it were unable to do so - there was no way to invoke righteous indignation from the population by blowing things out of proportion. Propaganda doesn't work when people can try it for themselves and say, "no, that's not true".
The next day, I changed the way magic resistance works for players. I've been wanting to do this for over a decade, but never felt like it would be appropriate. Fallout level? Again, very little. Again, largely because the bullshit espoused by the vocal minority was quickly killed by players simply trying things for themselves.
I like this idea of leading by leading instead of leading by consensus. Decide what to do, make it happen, just be prepared to clean up the mess afterward. It's not that I'll never mess up, but it's definitely easier to apologize and fix it than to debate it up front.
Subscribe to:
Posts (Atom)