Dungeons & Dragons Online Forum News (Feb. 06, 05)

Remove all ads!

Here are today's Dungeons & Dragons Online forum highlights, collected from Dungeons & Dragons Online forums. Please take into account that these are only single parts of various threads and should not be taken out of context. Bear in mind also that the posts presented here are copied as-is, and that any bad spelling and grammar does not get corrected on our end.

Jason Booth, DDO Dev Team

Community Spirit

Personally, I believe that type of community has more to do with factors outside of the core game design than within. The fact that those games were not graphical, for instance, ment the gamers playing them we're more concerned with the possibility of thier imaginations than what could be represented on the screen. That attracts a very different kind of gamer, and more of a niche audience. The populations were also much smaller, which ment a tighter nit community, because you encountered the same people more often. A single person in a few hundred has a greater effect on the community than a single in a few thousand.

Once you push more towards the mainsteam, by adding state of the art graphics and sounds, you attract a wider audience of gamers with a wider view of how a game should be. This inevitably widens the scope of expected/accepted behavior to account for the different views of it's users. This puts scale at odds with output such as roleplaying.

Generally, you'll find the best "roleplaying" in games off the beaten path. That means the latest and greatest hit is generally not going to appease someone's desire to roleplay, because it's gravity of audience is simply too large. Too many different ideas of what the game should be prevent a strong, single vision from emerging.

There are only two things a developer can really do to reduce this factor. The first is to aim for a niche market in and accept that they're not making the "next big thing", but instead are trying to please a specific niche. This will greatly limit the scale of what they can create without going bankrupt (high tech graphics, out. Reams of custom content, out. Small and focused, or your out of business).

The second is to come up with ways to allow the community to splinter into like minded sub-communities. This can be done in many ways, each with thier own cascading effects on the game design and it's production costs. Examples include reducing server size per world, guild systems, faction systems, area based ties (I live here), race or role identity, etc. But many of these techniques have as many negative ramifications as possitive, and are often extremely costly to development and support costs, so they arn't, by themselves, answers to the problem; only techniques to work towards a better environment.

Community Spirit

You know, 92% of all statistics are made up!

Combat System Elaboration

Attacks usually take between 0.4 and 1.2 seconds in DDO, depending on the particular attack, weapon style, character stats, etc.. At 6 seconds an attack, I'd fall asleep at my keyboard.. DDO is not that type of game..

Combat System Elaboration

Uhh... no.. thats not how it works, thats just community conjecture being past around as truth. Some attacks do strike more than once per click, but thats usually in two weapon fighting. Generally speaking, it's one click per attack.

Combat System Elaboration

Good find; Eck's description is wrong though. Basically, we tie attacks to the animations in the game. We do have some leway in terms of how many attacks a given animation performs, but this is mostly to do with animations which could look like multiple blows or not. You won't see the sword pass through someone once and attack six times, for instance. A normal attack only hits the person you have targeted, but in some cases a staff (for instance) might pass around the character before attacking. This is a case where we have some leeway in how things work. We can treat that motion as not being an attack, being something we call a glancing blow, or being a full attack.

A while back I gave eck a chart of how many attack hooks I was using per animation, with both the maximum number of percieved blows/glancing blows we could consider an attack to be, as well as base timings and other information relative to balance. In most cases, there is little room for change, but there is some leeway for him to work with for balance reasons.

Most users think of attack speed as a single number derived by various factors (weapon type, character stats, etc); but in the code, there's actually a lot more parameters to drive. For instance, while the base attack speed has a modifier, so does the delay between attacks; how long is it until I can execute my next attack. Adjusting these times create a different feel, yet have the same net effect expressed as damage over time. With a fast attack modifier, if I increase the delay between attacks (usually between 0 and 0.2 seconds), the moves feel more decisive. If I decrease it, the moves get more flow. This creates a different axis of 'speed feel' than just speeding up or slowing down the raw animations; and we can apply the modifiers how ever we like. For instance, it might make sense for an axe to always have a delay between attacks thats high to give the object more weight; thus we would adjust the overall speed of the animations more. With a sword, however, it might be the opposite; where the users overall speed is not effected as much, but thier sense of flow is increased.

Anyway, I'm delving into a bit of a low level design/animation issue which would probrably not be directly noticed at your level (just felt). Suffice it to say that attack speed can be modified by many factors in the game, including stats, weapons, spells, etc. Howver, you won't ever see a 600% increase in attack rate because it would simply look silly, or cause the lower levels to be frustratingly slow.

Combat System Elaboration

casting is much faster as well; I don't know the exact timings off the top of my head, but about a second for most spells..

Combat System Elaboration

There is some consideration of preserving multiple attacks per round; but it just doesn't make sense to speed up an animation by 6x thier speed - It doesn't look correct visually. And placing 5 second pauses between each attack would completely remove the feel of the game being reactive to user input. For instance, pretend your swinging a sword; go ahead, no one can see you. What did it take, half a second? Now try to swing your sword over 6 seconds. Not very fluent is it? If the translation was litterally 6x the speed, the game would either look pretty stupid, or place large, non-action feeling pauses between everything (turn based).
The other option is to express that increase in attack rate through other means as well as speed. This can include hitting multiple targets at ruduced damage rates (glancing blows) or giving the player more attack animations which can be chained together and get progressively more effective (multiple attacks in the animation, wider attack radius, etc). Eck will probrably take various passes at balancing some of these factors to better fit the DMG's overall curve.
So, if this is your holy grail for D&D, then you might take issues with this; but litteral translation did not make sense in this case, as it won't for many cases. Our goal has allways been to reproduce the spirit of the D&D rules into a real-time environment, not treat them as a holy crusaid.

I think that depends on how much of a rules lawyer one is. If you accept no changes to the core rules, then real-time combat would simply not function, nor would many other systems. The D&D rules are designed around a very different setting than a computer game and a very different setting than an MMP; what works for one doesn't always translate well in other mediums, just as real-time combat wouldn't make much sense for the PnP version of D&D. We take the D&D rules seriously, but we take the intended design consequences of those rules far more seriously than the written word.

There will be a group of people who simply accept no changes to the core rules. For those that fit that catagory, I suggest sticking with the PnP version and avoiding any adaptations.

Again, the scaler is too large at anywhere from 1 to 6 seconds per attack (or 1 to 6 attacks per round if you prefer to look at it that way). Thats a 6x scaler in speed, animations can usually only support a speed adjustment of about 70% from thier base (ie: 35% slower or 35% faster) before they fundimentally break down. Concepts like those listed above allow us to retain a attack over time ratio which is much closer to the DMG, while not actually speeding up animations to the point of visibly breaking.

Combat System Elaboration

A damage modifier is a perfectly valid axis to use; though some others would take issue with a 1d4 damage call doing 2d8 on what appears to be a single strike. They would also have issues with not getting two to-hit rolls for the attack. So either way, we're going to step on someone's sacred cow. At the end of the day, we'll step on whichever sacred cow will lead to a better playing game; because if the game isn't fun, you're not going to care much about how we implimented the rules.

Combat System Elaboration

Link death is something we cannot deal with; you must maintain your connection for the obvious reasons (about to die, pull the plug!).

Internet latency is another thing entirely though, and it's an area we've spend a considerable amount of time on given our real-time focus. In fact, much of the combat model is derived from solutions to latency problems, as is the language we've written the combat system in.

In a traditional MMP latency model, the client initiates an action, which is sent to the server to be resolved. The server sends back the results, and the user see's the action happen on the client. This creates a sizable delay between when you push the button, and when the action happens. This can sometimes be covered by autonomous actions (such as a wind up animation playing until the message gets back), but generally feels sluggish.

In essence, you could think about our approach as moving the latency onto the AI. I'm not going to get too deep into the technical details right now (I'll save that for GDC next year), but basically if your within 500ms of latency, most actions can sync correctly over the network regardless of that latency time.

Working with the latency model requires a different mind set to design and programing. The information sent by the client will not be recieved until sometime after it happens; and the information sent from the server will not be recieved by the client until sometime after it happens. However, the server can pre-emptively decide the monsters action and send it to the client in advance; within the latency buffer, this allows the monser to be accurately represented on the client. If the server maintains a history of what is happening, it can rewind time to verify client actions, reproducing the same results on the server as what the client saw. This is why I sometime say the latency has been moved onto the AI; because the AI has to decide what to do 500ms before you do.

Now lets take a simple example: Blocking. If we want players to be able to block, we can allow it, because we can rewind time on the server and see if they were blocking at the point in time when the monster was scheduled to attack (a full second after the attack was decided on by the AI, btw). The user pressed block just in time and sent that message to the server. The server can rewind time to verify the block, because it knows at what time you blocked, and at what time the monster attacked.

Feedback is an interesting case; on the client, you see the monster flinch when hit. This is a representation that you physically hit the monster, but you won't know if you've damaged it until the server rolls for damage; so your damage numbers appear a few moments after. If the D&D rules were simpler, we could probrably have this sync perfectly as well; so sometimes the complexity of ruleset will work against the model. But for the most part, it's fine that the moster flinches when hit regardless of damage.

Now lets look at the monsters case. Lets say we want him to block. He cannot react to the player, because he makes his decision up to a full second before the player's action is known. But instead of designing the AI to react to the individual attack, we design the AI to make pre-emptive decisions about what it will do. Instead of blocking an individual attack, it goes into a state which effectively says "If attacked right now, I will block". The AI no longer has to react to the individual attack; it simply plays a block animation for any attack done while in this state, and everything sync's nicely again.

So, to make things sync correctly, different moves must be programed differently for monsters and players because we need to think about them in different latency paradigms. Some actions can only be performed monster -> player, or player-> monster, or have to be re-envisioned in latency friendly ways. For instance, I cannot initiate a player->monster knockdown with a melee attack, because while I'm executing that attack, the server is busy telling all the clients where the monster will be a second from now. By the time the server gets the events, the monster has allready moved on peoples clients. In essence, you'd do the move, and a second later the monster would fall down.

I can, however, use a latency friendly means to achieve the same effect. If the player poors greese on the floor, and a half second later the monster slips and falls down, thats perfectly acceptable. So sometimes the metaphor used can make latency acceptable.

Now, in this case, players getting knocked down works just fine so watch out for those minotaur charges.

Point is, latency management can be done much more effectively than in previous MMPs; for us that was vital. The cost is that nearly every design element must be constructed with latency in mind, or you'll risk the illusion of "no latency" being shattered. This is also a big reason we won't have PvP at ship; Player to Player combat requires an entirely different way of approaching syncronization, and is a huge R&D task into itself. The latency cannot simply be hidden with server tricks because there is no AI to push the latency onto. We'll have to re-envision the ways we resolve various actions, like those listed above, to work within the PvP environment. PvP is not as simple as allowing you to hit each other, because, at least in this model, each action must be carefully syncronized.

The game play difference is quite worth the extra work though; thats for sure.


Combat System Elaboration

You could put a monster in a "if you hit me now I will be knocked down state", but that would essentially mean the knockdown would be dependant on the AI state, not on user action. The monster would not be able to do any compelling actions during that state as well (such as motion). This is because as you knock the monster down on your client, it is moving to a new location on everyone elses client. At some point those two realities need to be resolved; either the monster would slide back on everyone else client, or the monster would continue to move on your client; neither desirable solutions..

Instead, the best way to deal with this would be to change the expected behavior to allow for latency. If, instead of a melee swing, you were dropping a bag of marbles on the floor; everything would be fine because you would expect to see a delay with the bag of marbles, and you could also potentially cover up some of the delay by applying a shakey animation to the monster.

We use these kinds of tricks sometimes as well; as an example, if I hit you with a spell which might freeze you into a block of ice, ice can begin to form on you before I know the results of the spell; If it's successful, you break the ice; if not, you freeze into a block of ice after a second or so. I call this post padding; a delay is expected post the attack hitting.

The other option, which many MMPs actually use (but we don't) is pre-padding. This involved placing the delay at the begining of the move (a large windup) to cover up the latency of time to the server and back. The final animation (swing) executes once the answer is recieved. This doesn't work well for us because the pacing of the game is too fast, and it generally doesn't address melee combat nearly as well as our time sync model does. For proper varification, it would also take double the latency buffer time because of the time sync model, thus requiring a wind up of nearly two seconds. Un-acceptable for us, but useful in a slower paced MMP.

Combat System Elaboration

I should probrably point out that my explanation is a gross oversimplification of the problem and solution; the coding is far more complex, as are the various sub-components which have to be managed. But the basic principal of how all this works is generally there. Often, D&D rules, real-time combat, latency management, fun, user expectation, as well as factors like newbie friendlyness can all influence the way a particular dynamic is implimented. Sometimes those choices will seem somewhat arbitrary to the users unfamiliar with all the inards of such a complex beast and they'll cry foul; but those choices are rarely arbitrary in nature.

Combat System Elaboration

It all comes down to a case by case basis. As stated above, the details are far more complex and minute than you can imagine. For instance, we have monster attack interuption working; which given the brief description above wouldn't be possible. So there are ways to work around certain issues; but others just don't make sense within the model.

You really need to think about the buffer as worst case, not average, or you'll start introducing errors into every event. We might adjust the threshold at some point, but the only real advantage to adjusting it to a faster time is AI reaction times.

Instancing doesn't make latency any better for anyone; we're not a peer to peer model, so to the server, it's still a bunch of people in a bunch of dungeons; each with thier own latency between them and the server.

As for all the various discussion on attack rolls, preserving balance, etc; thats really what eck is tasked to do. I make the magic happen, he tries to balance it within those confines. There's plenty of possibility within that space for him to work with, so the spirit of the system can be maintained. It's not an easy job, but he did help design 3.5 when he was employed by WOTC, so that should qualify him for the job better than most.

Nik Davidson, Administrator

Will there be Looking Up and Down?

Very yes.

Community Spirit

I'm following this topic with a certain amount of interest, but I have to ask, where are you getting this number from? Which game, which time period, etc?

Does what we say really matter?

Sometimes, I wonder what people really think of us. From a purely cynical standpoint, I'd take from forum posts that people think we are either in one of two categories. Either we're...

1) Sitting around scratching ourselves, waiting for the good people on the forums to tell us how to do our jobs,

or

2) Small gods in an ivory tower, brilliant and unknowable, capable of shaping time and space to our will.

Having worked here for a while, I find both theories kind of funny.

Anyway, there are two types of suggestions and discussions, Farlander. You are correct - the core systems of our game are in place. We're not going to randomly start chucking huge chunks of code out the window, or creating vast new systems rather than polish and improve our existing ones. So, suggestions and discussions that focus on us doing either of those are not going to come to a fruitful end.

Things that we're looking most closely at right now are "polish features" - small things that improve the game experience in conjunction with our other systems. Better methods of targeting party members? That's a polish feature. Cleaner, more informative quest logs, another example. Monks are not a polish feature. PvP is not a polish feature. (And woe unto the game that treats it like one!)

So to answer your question, are discussions here helping shape the game? Absolutely. Are we going to do open PvP in Greyhawk with pegasus mounts because it's a popular forum thread? No.

Community Spirit

Regrettably, I'm going to close this as off topic and having run its course. We've run far, far afield from the original post, to the point where it's not really applicable to DDO.

We will not be putting heavy restrictions on player guild formation. We're not going to tell people that there's a right and wrong way to socalize, so long as they're not violating our code of conduct.

Limited Wish in the Box

I was just saying yesterday, we don't need really need a million people paying X$ a month*, we just need X people paying a MILLION dollars a month!

Yeah, maybe not.

* - X has yet to be determined. It will be comparable to other games of the genre.

Horrible

If they already have exploits about our game, we will report them to Mulder and Scully, as they must have psychic powers.

Anyway, we do keep an eye on sites like these.

Weapons?

How many weapons? A lot. Which ones specifically? Not sayin' yet.

Xundau, Community Relations

Quest Experience Bonuses

Some quests will be repeatable, and some won't. Similarly, some quests will have random elements (monsters, traps, placement of quest objectives, etc.), and some will be mostly fixed. I'd imagine that there's some correlation between these (i.e., repeatable quests would tend to have more random elements), but I'm not sure.

XP will scale based on your level -- if a dungeon is considered easy for your party's average level, you'll get less xp for completing it.

Will there be Looking Up and Down?

Yes, this is definitely possible:
http://www.ddo.com/index.php?page_id=70&gallery[gallery_id]=7&image[edit_image_id]=125

(Okay, they're not ogres, but close enough.)

Regular Gaming

Good thread. We've discussed implementing something along the lines of a regular playing group, but we're leaning against iit for many of the reasons presented here: groups of friends can form regular playing groups on their own, and we don't like the idea of implementing restrictions that prevent people from playing their characters at certain times. This hasn't been talked about a lot on the forums though, so this thread is pretty valuable for us.

Also, just to clear something up:

I'm not sure who's making those guesses, and in truth we haven't finalized our pricing (and won't for some time), but I'd be *very* surprised if we came out at $25/month.

Disappointed...by another Dev Team

I'm going to close this thread, as this topic has been discussed to death already. We decided very early on that it just wasn't feasible to have randomly-generated statistics in our game.

We're heading into beta with a 28 point buy; we may tweak this number during beta, but we don't plan on doing so.

Server Names

It's a little early to start thinking about server names, and I don't think a lot of work has been done on them (the names!) at this point. That being said, it's good to hear what people think/like. I think a lot of the suggestions here are viable.

Personally, I would love playing on the Gelatinous Cube server -- but maybe that's just me

Eberron Novel by Keith Baker

Thanks for the heads-up Cephas -- I knew this was coming soon, but didn't realize that it was actually out.

I'll probably be picking up a copy today or tomorrow.

Weapon Specialization

Just for the record, yes, only fighters will have access to Weapon Specialization in DDO, just like in D&D 3.5.

We are aware of the unique drawback to Weapon Specialization that Celt alluded to -- namely, that a fighter with Weapon Specialization has a strong incentive to only wield that type of weapon. To this end, our treasure team is ensuring that there will be plenty of powerful versions of all weapon types that appear in our game.

Bear's Endurance, the killer spell

This is a great thread -- thanks Thomas for giving people a glimpse of the issues that you guys are dealing with every day.

To play devil's advocate for a second, can any of you think of another MMORPG where you can die as a result of a buff running out? People familiar with 3.5 D&D might understand what's happening, but how will the player who hasn't played a lot of D&D feel when their character suddenly drops dead because their Bear's Endurance or Rage ran out?

The more user-friendly decision in this case is to treat all hit points gained by buffs as temporary hit points (like those granted by the Aid spell) -- when you take damage, you lose temporary hit points first; when the effect runs out, you lose any remaining temporary hit points, but can't lose any of your "real" hit points. The result would be that the character in Oakstaff's scenario would still have 1 hit point after the spell ran out.

I don't know what our final decision will be, but I think that this is one of those instances where what's fun (and this is admittedly a very subjective term) might conflict with the D&D rules. Obviously, deciding between the two isn't always very easy.

Party voting?

We might have some different party options for loot distribution; we're still working on those systems, and actually we'd be interested to hear people's thoughts on the subject. I don't see any of the other examples being given as something we'd put to a voting system.

As far as a roleplaying party goes, I can't really see how it would be enforced by the game. Everyone has a different idea of roleplaying, so there's not really a measurable standard that we can hold people up to. That being said, you'll be more than welcome to organize a roleplaying party (or even a whole guild) in game.

As far as combat goes, our combat system is entirely real-time, and would simply not work as a turn-based system. If we were using a psuedo real-time system that plays in continuous rounds (like Baldur's Gate or NWN), maybe we could give an option of pausing in between rounds, but we are truly, genuinely, real-time -- there's simply no such thing as a "round" in DDO.

Combat Feats (devs please respond)

This is a question that's come up before, but that we haven't really elaborated on in the past. But I think at this point in development I can share a few details.

As most of you hopefully know by now, we're using a real-time combat system, and some feats simply cannot be translated word-for-word. In these cases, we have to either cut them (which we don't like to do), or figure out how to adapt the feats to our combat system.

A good example of this is Rapid Shot. Since there's no such thing as a combat round in DDO, we can't really implement the feat as written. But what is the point of Rapid Shot in the first place? It's firing faster in exchange for reduced accuracy, right? Well, that's something we can certainly do.

A more difficult example is Cleave (and Great Cleave). In PnP D&D, these feats allow you to make extra attacks after dealing a lethal blow. We decided early on that we didn't want to implement these feats as written -- losing control of your character while they make a number of additional attacks, and having to auto-choose which enemy to cleave didn't really appeal to us.

But again, what is Cleave supposed to represent in the first place? In my mind, a character with Cleave has learned to attack multiple enemies with one powerful, sweeping strike. To this end, we've experiemented with a couple of implementations of Cleave: one of them has the attacker swing their weapon in a wide arc, hitting any enemies caught in the arc. We found that this wasn't always very effective though, so we've also tried Cleave as a short dash forward, weapon extended -- any enemies caught in the dash can be hit.

Even though this second version strays a little farther from the PnP feat, I prefer it -- I usually play melee characters in our playdays, and I can't tell you how extremely satisfying it is to Cleave through a pack of kobolds and then turn around and watch them all drop dead.

Other feats are easier. For instance, Whirlwind Attack does exactly what you'd expect it to -- you spin around, swinging your weapon(s) in a giant circle. Very nice when surrounded by a pack of monsters. Something like Two-Weapon Defense will probably just be implemented as a passive feat -- if you have it, you'll see an increase in your armor class when you're wielding two weapons.

As far as your question about unarmed combat goes, I'm not sure if we're going to be putting too much effort into it before Monks come out. We do have unarmed animations in right now, but fighting with your fists isn't so effective. In PnP D&D, I've always been under the impression that a non-Monk fighting unarmed could only be successful as a grappler (see the Reaping Mauler from Complete Warrior), but there's no grappling in DDO.

The Eberron Campaign Setting does have a warforged-only item called a battlefist, which gives them a 1d8 natural weapon attack. I'm not sure if we're going to have this item in our game or not though.


para cuando en español?

We'll announce our plans for international availability and localization/translation at some point in the future -- there's no official word on these things yet.

ThomasOakstaff, DDO Dev Team

Bear's Endurance, the killer spell

Today I found myself working on our rest mechanic. We're attempting to be true to D&D rules as much as possible, and this is no exception. At first, it seemed like one of the more simple systems to implement, but like many things, the devil is in the details...

Let's imagine we're playing Pen and Paper D&D...

I'm a level 10 warrior named Thogg. Thogg is adventuring with a cleric who has graciously cast Bear's Endurance on him.

Bear's Endurance gives +4 Constitution, which gives +2 HP per level. Therefore, Thogg gains 20 HP. Not bad...

Thogg and his friend end up fighting a nasty giant, and Thogg wins the fight with only 1 HP left. Unfortunately, the cleric perished.

With no spells left and no potions, Thogg is left only with the option of rest. So, he does.

Now, Rest heals 1 HP per level by default, for a total of 10, but that takes 8 hours. 7 minutes from now, Thogg's buff is going to wear off, taking away 20 HP. Thogg is going to die, and there's nothing for it.

That's Pen and Paper D&D. Let's imagine you're playing D&D Online...

Same fight, same outcome... except Thogg clicks the "Rest" button and immediately dies.

This is completely true to the D&D rules. But is it acceptable gameplay?

Quite a dilemna.... isn't it?

Thomas

PS There isn't actually a "Rest" button, but I can't give exact details on how it does work yet.

Bear's Endurance, the killer spell

Imagine you're either:

1) A player not familiar with the D&D rules
2) A 3.5 veteran who didn't notice he had Bear's Endurance on him
3) Someone who only played 1st edition and hasn't heard of Bear's Endurance.

All you might know is that someone buffed your hp.

Now imagine that you've got 1 HP, you try to rest, and you immediately die.

Sure, it's logical that it should work that way, to be true to P&P...

If you memorize D&D rules you might even remember that in the heat of the moment.

I think it's much more likely that even experienced D&D players would react to this situation like this:

/shout "What the heck?? I just rested and died. How do I contact a GM?"
/petition I died to a bug

Now, this is just my perspective. But I think it's pretty much how it would play out.

We certainly won't change a rule lightly, but I think this situation highlights the fact that being true to the D&D rules is often at odds with playability.

[ February 06, 2005, 20:59: Message edited by: chevalier ]