Being the coder doesn't (shouldn't!) mean you know how it ends. All that should mean is that you know what the mob is capable of doing, and how it will react (or not) to what you do. Unless you don't use any random numbers in your combat system, which would be…. unusual.

Do players care? I have a counter-question…. why wouldn't players care?

I propose that most players neither care nor notice ANY effort we put into details of ANY kind.. be it elaborate room descriptions, or clever mobs that know how to call friends in to flank you, or work in packs to support each other just like players do. Why? Because they don't expect it to be there, they don't look for it, and frankly… when something does act interesting, they assume it's a bug or something "weird" and scamper back to StockMUD 12.0 where they can happily crunch the same rats they've crunched for the last 10 years.

Now, there are players who do like such things, and if you actually built a system and advertised it as such, many of them would probably wander your way to see if it really did feel more alive, and was more of a challenge.

Back in 1993, I played WileyMUD, and it was considered very hard, but a bit above the average game of the day. It wasn't as clever as some of the LpMUDs out there, but our mobs were smarter than they typical Diku. By 1995 when I ressurected and ran the game, the player base had already started to shift towards candyland. Players who logged in were confused by the lack of a "mud school", and though it was "too hard". Some stayed anyways, because it was original and once you learned that the game rewarded you for paying attention, it wasn't so hard. Many fled.

I still have it running today. Every few months someone wanders in. Most of them run away when they see no ANSI graphics, no mud school, mobs in the starting area aren't free handouts. Some surely leave because it's a ghost town and without anyone there to be welcoming, it IS pretty desolate. A couple actually return and play a bit. Considering that I don't actively run the game, don't advertise, and make no real attempt to convince anyone to play… I suspect there is indeed a small audience for it out there.

So, what I'm saying is… if you design a game to be better (in whatever way you want to quantify that), you will lose your lazy players who just play to top the numbers chart, and you'll lose the players who just don't like the way you're taking things. You will gain players who want something different. It's mostly up to you to sell folks on it.

I smell a false dilemma. Just because your under the hood implementation isn't an array it doesn't mean you wouldn't have an interface other than A pointer to do a hookup. Indeed, perhaps a simple idnumber.

Remind me to not let you make any pointers hook up with any id numbers. :wink:

(Gotta love phone auto-correction.)

(What were you referring to?)


I think you're exaggerating just a tiny bit here.

I was referring to what scandum said was a benefit to arrays over other implementations. Specifically that the choice was a pointer or an array index.

An array is much faster than a hash table in practice, especially when a MUD has 1024 hash buckets for 10.000 rooms. Index lookups are most frequent during boot time in the typical Merc mud, and while loading characters, so that's where significant gains would be seen.

So you get one-time gains during startup; that's not a frequent case. Sure, you might be speeding up startup. (Except that you also have to grow that array, like I was talking about – that can be quite costly!) Regardless, you are not "gaining" O(1) performance; you already have it.