I've been working on the next stage of the newbie quests for the island of Kordan, and one of my major stumbling blocks has been explaining exactly why another stage exists. The general theme with this sort of thing is that there's a continuous storyline as you progress from one quest to another; you work your way deeper into the conspiracy to take over the world (or whatever), and ultimately emerge the hero.
The problem was, I didn't have any such story or conspiracy constructed, and wasn't feeling particularly inspired. So, I decided to try something new. I sat down and wrote some crap.
It turns out that my crap looks like a pretty decent, if dry, story. I accidentally created my first piece of fanfic!
I've posted it on the Alter Aeon Fan Fiction page and added a section for myself. The direct url is:
Plans and Portents - the Story of Qoorik
Showing posts with label building. Show all posts
Showing posts with label building. Show all posts
Wednesday, August 4, 2010
Wednesday, April 28, 2010
Objects - followup
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.
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, November 25, 2009
An Example of Mob IACT Programming
[Reposted from the Alter Aeon Forums.]
An 'iact' is a type of interactive procedure that is used to make mobs perform actions. You can do some pretty complicated stuff with them, including interactive (hence the name) discussions, intelligent quest triggering, and the like. As examples, Thantos responds to Dentin's name, and the fire giants in the fire plane will give up quite a bit of history of the area if you just sit down and talk to them about it.
As common as these are, there's a lot of confusion about how iacts work. Most of this seems to stem from the fact that iacts are a form of finite state machine, and most people aren't used to thinking in state machine terms.
As an example, let's consider a mob that would unpack and wield weapons when fighting, then stop using and put them away when not fighting. This seems like an ideal example to demonstrate a simple state machine iact, as well as give an introduction to how iacts work.
The general idea is that the mob in question, let's call him Bob, has a weapon and a backpack. When Bob is in combat, the weapon should be out of the backpack and wielded, so Bob can defend himself. When Bob is not fighting, the weapon should be stored in the backpack, which Bob should be wearing.
The easiest way to do this is via four states in a state machine:
1) Not fighting. In this state, you wait for fighting to begin.
2) Start fighting. In this state, Bob is fighting, and should unpack his weapon and wield it.
3) Fighting. Bob is fighting for his life, and may need to retrieve his weapon if disarmed.
4) Stop fighting. Bob is no longer fighting, and should disarm and repack his weapon.
Here's a diagram of the four states, with the arrows being transitions between the states. Each block contains the name of an iact procedure, and in smaller text the iact code for that procedure:
Click on the image for a larger version.
As various things happen to Bob, he moves from one state to another. Most of his time will be spent waiting for fighting to start. When fighting does start, he'll quickly get out and wield his weapon in the 'start_fighting' procedure, then he'll transition to the 'fighting' procedure. While 'fighting', he'll continuously try to rewield his weapon if he's disarmed. When fighting stops, he'll transition to 'stop_fighting', which will unwield the weapon and put it away. Then he'll go back to 'not_fighting' and wait for another battle to begin.
An 'iact' is a type of interactive procedure that is used to make mobs perform actions. You can do some pretty complicated stuff with them, including interactive (hence the name) discussions, intelligent quest triggering, and the like. As examples, Thantos responds to Dentin's name, and the fire giants in the fire plane will give up quite a bit of history of the area if you just sit down and talk to them about it.
As common as these are, there's a lot of confusion about how iacts work. Most of this seems to stem from the fact that iacts are a form of finite state machine, and most people aren't used to thinking in state machine terms.
As an example, let's consider a mob that would unpack and wield weapons when fighting, then stop using and put them away when not fighting. This seems like an ideal example to demonstrate a simple state machine iact, as well as give an introduction to how iacts work.
The general idea is that the mob in question, let's call him Bob, has a weapon and a backpack. When Bob is in combat, the weapon should be out of the backpack and wielded, so Bob can defend himself. When Bob is not fighting, the weapon should be stored in the backpack, which Bob should be wearing.
The easiest way to do this is via four states in a state machine:
1) Not fighting. In this state, you wait for fighting to begin.
2) Start fighting. In this state, Bob is fighting, and should unpack his weapon and wield it.
3) Fighting. Bob is fighting for his life, and may need to retrieve his weapon if disarmed.
4) Stop fighting. Bob is no longer fighting, and should disarm and repack his weapon.
Here's a diagram of the four states, with the arrows being transitions between the states. Each block contains the name of an iact procedure, and in smaller text the iact code for that procedure:
Click on the image for a larger version.
As various things happen to Bob, he moves from one state to another. Most of his time will be spent waiting for fighting to start. When fighting does start, he'll quickly get out and wield his weapon in the 'start_fighting' procedure, then he'll transition to the 'fighting' procedure. While 'fighting', he'll continuously try to rewield his weapon if he's disarmed. When fighting stops, he'll transition to 'stop_fighting', which will unwield the weapon and put it away. Then he'll go back to 'not_fighting' and wait for another battle to begin.
Subscribe to:
Posts (Atom)