Skip navigation

Major Ideas/Features

wilderness-based coordinates system
A theoretically infinite world, with locations at coordinates generated on-the-fly using 2d and 3d perlin noise to determine terrain and weather respectively. These locations are stored in the MySQL database for reference (if say, another character travels to the same set of coordinates or drops an item there), and will eventually ‘decay’ and be deleted from the database if they are empty and a certain amount of time has elapsed since their creation.

The idea is to have random mobs seeded at these coordinates, with mob toughness increasing the further away they are from (0,0). The equipment dropped by these mobs would also be better the further away they are from (0,0). Throughout the world there will also be hand-built Diku-style NSEW room-based areas planted at certain coordinates. Most of the hand-written content would take place in these areas.

[Edit:] after some consideration, instead of having these handbuilt areas existing as a separate rooms-system, they will just be overlaid on top of the Cartesian coordinates system. i.e. a room in a handbuilt area will simply be a set of coordinates in the database with a handwritten description, etc, that does not decay.

I will need some kind of sphere-of-influence, line-of-sight computation stuff going on (i think its referred to as spatial intersecting or something) so that players a few coordinates away from a city would be able to see it in the distance. The alternative is to pretend that each coordinate is effectively your sphere of line of sight, so if you’re in the next coordinate, you’re too far away to see whats in your neighbouring coordinates anyway. This “fat-coordinate” approach detracts from the seamlessness of the experience of travelling through the wilderness though, since your line-of-sight changes in huge ‘jumps’, instead of smoothly transitioning as you take little steps forward. So I guess I’ll probably try for the “tiny-coordinate” approach first, and see how successful I am at implementing that.

I’ve already implemented the basic on-the-fly coordinate generation functionality, perlin noise algorithims and MySQL interface. I’ve also implemented line of sight and the room decay function. Whats left to be done is write descriptions that will correlate to the Perlin function (this will probably take quite awhile) and implement all of the mob seeding aspects.

This ties into my second idea/feature, which is:

(mainly) equipment-based levelless character advancement
New players would only be capable of taking down creatures close to (0,0). However, as they accumulate a set of basic equipment from these creatures, they will find themselves capable of taking on mobs located slightly further away, and so on. This would allow them to theoretically improve their characters infinitely, taking on harder and harder mobs located further and further away from (0,0). However I’ll probably tweak the system such as to make the monster’s toughness increase exponentially, to prevent boring linear character progression and to encourage players to form parties to take down tougher monsters together.

Players would also be able to increase their base stats (such as strength or charisma) but at a very slow rate. Perhaps they would only be able to do so after accumulating a certain amount of points from immortal-run quests, and would only be able to participate in 2 of such quests every RL month… making it only possible for them to increase their base stats by one point every 6 RL months, for example. Whilst this would reward long-term players for loyalty and make their characters something else other than a walking bag of equipment that is interchangeable with someone else carrying the exact same set of equipment, it would also (as intended) take much of the emphasis away from these character stats, and place them on equipment instead.

There will have to be variety in equipment types and the way the various pieces of equipment interact with one another (perhaps like sets in Diablo 2 or something) in order to provide players with legitimate and genuine choices between equipment, in order to avoid the Clone Wars syndrome where everyone else walks around with the same set of equipment. Ideally this syndrome would already be ameliorated to some extent because of the limitless advancement possible… thus some of the more powerful players will always be wearing equipment that the midling players would at present be unable to obtain (due to perhaps a lack of exploration or not having the time to form a party to get the equipment for everyone).

Fighting styles and stances are another idea which I’m thinking of integrating into the combat system. They deserve a separate heading of their own, but as a component of character advancement.. I’m thinking of having them only being learned and improved upon when defeating mobs that possess equivalent or better ability in those styles/stances. This would make it very difficult, if not impossible to ‘max’ your ability in any particular style/stance, assuming that I tie mob ability in the stance to, again, distance from (0,0). However it would be possible and probably encouraged to specialise your character in a certain set of styles and stances, and to attain relatively high skill in those styles/stances as compared to every other player on the MUD. More on this later on.

Not much of this has been implemented yet. A lot of it rests on finishing the development of the wilderness system first.

mysql integration
Using MySQLdb, SQLObject (for Python) and the MySQL C API, I’ve managed to migrate most of character data storage to MySQL. The wilderness coordinates system explained above is also entirely implemented in Python and MySQL. The goal is to eventually migrate all forms of MUD data storage to MySQL, for easy data manipulation and sharing between Python and C components of NakedMUD (no more writing getters/setters in C for Python!).

My current problem right now involves handling the character socket. This is currently stored in the C CHAR_DATA struct, and I need to figure out if I can store it as a BLOB in MySQL. Need to understand more of how NakedMUD handles sockets for this to work. Need to understand more about sockets in the first place.

combat system
There are several elements in the combat system that I’ve partially implemented on The Harrowing. The general idea/principle underpinning the system is that it should be possible for players to feasibly play a variety of character builds, instead of all going for the high HP, big damage, big armour category.

A secondary principle is that there should generally be slightly more emphasis on character skill as opposed to player skill. I don’t have the space or time to explain my thoughts on this at the moment, but in short its because I believe that the attraction of MUDding partly consists of the fiction of having a character that, given time and dedication, can kick ass.

Another important element of the combat system, that is linked to the secondary principle, is that the key determinants of outcome in combat should be factors controllable pre-combat, not during combat. Whilst you will have certain mid-round abilities that you can use/spam during combat, and maybe even the opportunity to change stances according to your opponent’s fight style/build, these should not be more important or determinative than the decisions that you have made pre-combat as to the set of equipment you’re wearing, the attributes you have managed to gain points in, the styles/stances you have chosen to specialise in, and the character build that you have chosen.

I know that many of the above principles/elements concerning combat look like assertions with no explanation as to why I believe they should be like this instead of that. I do intend to explain my thoughts on those areas in due course… just not in this macro-bird’s-eye-view-post.

As an illustration of how I have implemented some of the above ideas in parts of the combat system: I currently have a stat called ‘size’ on characters. Size of a character is determined primarily by the character’s max Corpus (i.e. HP). The larger you are, theoretically the more damage you can absorb, and the more damage you can dole out (when your fist happens to connect with someone else’s body). However, the larger you are, the easier it is for someone else to hit you (makes sense, right?) and the harder it is for you to hit someone else significantly smaller than you. Smaller characters would have lower tolerances for damage and would probably dole out less damage per hit, but would be harder to hit, and would perhaps also be faster, being able to deal more attacks per round. They probably wouldn’t be able to use certain large weapons as effectively as their larger counterparts though.

What has been implemented so far? The size modifier/stat, a few basic combat styles, and of course the combat system itself (round-based, assumes you’re attacking each round with whatever you’re using in both hands, much like traditional Diku muds). I haven’t thought of a better combat system yet, so this is the way it’ll be for now.

Summary
Any comments/opinions on any of the above would be appreciated. 🙂

Leave a comment