MURK - a small preview

There isn't much to show. A coupe of screenshots bellow.

This is what I have been working on. It's coming slow because... well, I don't devote to it 100% of my free time. But it is something I always wanted to do. Even from when I didn't know how to do it.

MURK is going to be a console single-player game based on two game concepts; MUDs and Rogues. The emphasis is on MUDs, but you will see your progress in the world map as you explore. The game is turn based, except for combat which is going to be MUD based (aka real-time-sort-of).

I'm making an effort to make it as easy to port as possible. No fancy non-portable libraries. The game is using Boost, SQLite3 and PDCurses (a win32 port of ncurses). Everything I might know as being non-portable, is commented in with "NPORT: " followed by a possible description. I hope it will ease the work of anyone wishing to port it to other systems.

Some Game Features and Screenshots:

• Diablo II-like system of random object creation; prefix, suffix, uniques, sets, specials
• Diablo II-like system of monster spawning
• Areas reset when you leave them
• Weather and Calendar systems
• Intelligent rooms; wet if raining and outdoors, lights if night and habited indoors, ...
• Static mazes, shifting mazes, damaging rooms, dark rooms, magic rooms,...
• Many commands in the best MUD tradition. But easy to learn and easy to access
• Complex character creation and development. Don't ask me more...
• Never-ending world. Areas adapt to player level.
• Never ending experience. Player has unsigned long * char levels to acquire.
• Some areas can be totally randomly generated. Other areas can be completely hand-drawn.
• Why I think I can do all this is because I think I'm insane. But trust me, it's been a long, long, dream of mine. It will be done. And much, much, more.... It will take a long while too.

Two screenshoots:
One showing the part of your screen where the room info is displayed and where you have your prompt. The other showing the yet-to-be-formatted result of the inventory command.

The numbers are the object unique ID. So it is possible to manipulate them by name, part of the name, or UID. "remove 5", "remove leather boots", or "remove boo" will all unequip the boots. Objects only show their IDs when in your inventory. A + sign means a container.

You have a fan.

Thanks. The idea is of course, to have the source code available through Open Source once there is a basic game people can play with.

I understand the features list is anything but comprehensive or incisive. But I prefer be more...honest?... about it and only list what I have already, instead of what I plan to have. Saying "hundreds of monsters" when I currently only have 5 for testing purposes and being built on top of a incomplete class is really not my style.

True mario, but this is a project you are working on, and as you said is still a work in
progress. You do not have a team of proffesional artists, researchers and programmers
helping you. Like many people, you are doing this off your own back. In many ways you learn much more about how much C++ you know and can use to full effect when you create a text game.
I might make my first text game soon, I am nearly at the end of my course and have already started the pen and paper processs ( basic classes I need ).

One more thing. You say you are going to have enemys ( of course ) but are you planning on using class inheritence for this? I mean, will you use a base class and derive all the enemy objects from this base class? I only ask as I am pondering this for own game, trying to find out what the best method would be before i put code to IDE.

I think you will find inventory tracking a...more challenging subject when reach the point you will start considering it ;) Enemies was a no-brainer. But itwas for this particular project. Depending on how you want your enemies to behave, it may mean more complex relations.

My game beings are composed of two classes. CPlayer and CBeing. There's no relations between them. Any possible distinctions are implemented through composition, not inheritance. For instance, I have a CRace and CProfession classes for races and profession handling. An instance of these classes is made a private member of CPlayer and CBeing and exposed through interfaces.

Thanks mario, all the best with the project, I look forward to seeing the finished prduct on the games board

Did you write your code in C or C++?

Well, he has classes and he uses Boost ...

i'm guessing C++?

anyway... if it is, how did you get your writing different colours?

It's a library called pdcurses I assume, pretty neat stuff.

and how would i get this library?

http://pdcurses.sourceforge.net/

What? No graphics? :D

BTW, nice going. Will it have the same gameplay as netHack? Can I hack my way from the save files?

hope your strings are in resource files... for easy translation

> Will it have the same gameplay as netHack? Can I hack my way from the save files?

Nope. The game will allow you to load other savegames files, allowing you to go back if you get in trouble. The purpose is not to make it difficult to finish the game. The game never ends. However, all data in the database and save game files is encrypted. It won't be easy to edit the files.

> hope your strings are in resource files... for easy translation

Unfortunately no. I thought briefly about it. But decided to make my life easier on that matter. The game is all in English. To be able to translate it, one has to edit the source files and the data file.

Quote:

---

Originally Posted by Mario F.

Some Game Features and Screenshots:
...

• Never-ending world. Areas adapt to player level.
• Never ending experience. Player has unsigned long * char levels to acquire.

---

You slice through the Ultra Giant Super Mega godlike alligator, dealing 12,093,317 damage.
Congratulations, you have killed the Ultra Giant Super Mega godlike alligator! You gain 4,546,921,958 experience!
Congratulations, you have gained a level! You are now level 9,952,124.
You now need 8,416,749,218,019 for next level.

<6,594,432/12,195,207hp 1,293/1,293mag 110/250mv>

I SOOOOO want to play this game! heehee

What MUDs have you played? Not so much the particular incarnations, but which codebases have you played? I tend to be a Diku fan, but that's mostly because I've researched more about Diku than LP in my own effort to do this. (I am maybe 0.02% complete thus far! And in a mere 4 years, I'm sure I'll be done with it in no time!)

Seriously, how will you deal with this kind of silliness? I like the idea of the game never ending, but what happens when you get your character up to level 9 million? With a little luck, I'm sure someone, somewhere could do it, just to do it if for no other reason.

Quote:

---

Originally Posted by jEssYcAt

What MUDs have you played? Not so much the particular incarnations, but which codebases have you played?

---

DikuMuds mostly, mainly the smaug codebase and other merc and merc derivatives. However I did start in the late 80s with an AberMud. I moved shortly after to the LP codebase, but couldn't resist the Diku's, especially when the Merc codebase first showed up. Had play them ever since.

I don't play for 3 years now. I stopped playing them. I feel that by the late 90's they lost much flavour. I don't know exactly why. I have a few guesses. But I don't play muds anymore.

Quote:

---

Originally Posted by jEssYcAt

Seriously, how will you deal with this kind of silliness? I like the idea of the game never ending, but what happens when you get your character up to level 9 million? With a little luck, I'm sure someone, somewhere could do it, just to do it if for no other reason.

---

I don't think I will be able to provide a serious balance at high levels without a couple of years into the development of the game. No matter what I can come up with, only after revisions due to player feedback and a lot of testing will I be able to achieve this. And even then maybe not in a way that covers all aspects of the game. So, it is quiet possible that the first releases won't be playing well into advanced levels.

Level advancement in the game is slow. Not slow enough to discourage people, but slow enough to not make MURK (the name will probably have to change, btw) a less level dependent game.

Anyways, here are some of the pointers:

- Level advancement happens in function of the current level. As you advance in levels, you will see it harder to gain new ones. Internally the XP gained is calculated normally and then a percentage of it is removed based on your current level. I haven't devised the function yet. But it will have some result towards 0 while never reaching it. So this will effectively restrain new levels at higher ranges, or make them extremely hard to get. The trick will be determining the frontier at which gaining new levels becomes extremely hard.

- Player attributes (strength, constitution, etc...) are fixed on a range of [1,20]. Player skills (axes, hand-to-hand combat, double-damage, etc...) are fixed on a range of [1,100]. Player advancement is such that in order to have all skills at 100 you would need an inordinate number of levels. Players will want to specialize instead.

- Damage in combat is never affected by player level. It is affected by weapon damage, player skills, player attributes and weapon modifiers (see bellow). As such damage is capped since all these elements are.

- Areas will be loaded according to the player level within a certain range. Particularly the monsters that are a part of those areas will be of three types; trainers, free, and ntrainers. Trainers will advance as the player does, these monsters will always be at a level difference from the player as when they started playing the game. Free are random. They have a chance of becoming trainers when loaded. Ntrainers are never trainers. They will always have a fixed level, skills, attributes and equipment. Areas themselves will also be tagged Training, Free, and NTraining. So, a trainer in a NTraining area will never become a trainer.

Of course, many other things can eventually be added to this still simplistic approach. One of the obvious problems I will be facing is how to get a player long interested on a never-ending game? Especially a single-player one!

I have no answers for that. Either I will be lucky enough and hit the jackpot, or I fail and players loose interest in it quickly enough. The second more probable choice will nevertheless help provide insight into what I can change. However, some things have already been devised..

- Complex (ala Diablo II) object generation system with prefixes, sufixes, specials, sets and uniques. This system will be one of the things that will probably give more work and will need to be constantly refined and added to. I have to design it right the first time or it will be an headache to maintain.

- Area Design needs to be scripted and some form of Area Design mechanism needs to be implemented outside the game, so that players can contribute with their own areas. For now I have no idea how I will achieve this. I've been taking a look at Lua and CINT. But regardless the system needs to be somewhat similar to LPC and others, where areas can be designed with only a marginal learning-curve.

- Random and Non Random areas. Some areas will be randomly "drawned" and monsters loaded from a pool of allowed beings when the player enters them.

- Character development needs to be complex in order to be appealing. I have a few novel ideas around this based on my long pen-and-paper RPG experience, from D&D to universal systems like GURPS, or highly exotic systems like Vampire the Masquerade or Call of Cthulu.

EDIT: Ermm... sorry for this becoming so long. I felt like talking about it. I never actually talked about the game with anyone and maybe I will draw criticism and new ideas this way

Quote:

---

Originally Posted by Mario F.

DikuMuds mostly...I moved shortly after to the LP codebase, but couldn't resist the Diku's, especially when the Merc codebase first showed up. Had play them ever since.

I don't play for 3 years now. I stopped playing them. I feel that by the late 90's they lost much flavour. I don't know exactly why. I have a few guesses. But I don't play muds anymore.

---

Perhaps I didn't play enough different MUDs, but it always seemed easier to get into a DIKU, probably since they are all pretty much based on the same foundation. When my favorite MUD went away I started looking for others, but the most common thing I found was "yet another mud started up just so the admin could run his own mud." Between that and not having a lot of free time the last 4 years (hmm, my son is 4, I wonder if there's a connection?) I haven't mudded for a while either. But I have been working on my own here and there.

Quote:

---

Originally Posted by Mario F.

- Level advancement happens in function of the current level. As you advance in levels, you will see it harder to gain new ones. Internally the XP gained is calculated normally and then a percentage of it is removed based on your current level. I haven't devised the function yet. But it will have some result towards 0 while never reaching it. So this will effectively restrain new levels at higher ranges, or make them extremely hard to get. The trick will be determining the frontier at which gaining new levels becomes extremely hard.

---

This is an interesting idea. Sort of a logarithmic progression, like award = xpvalue * (log(level)*.625) or something.

I see the possiblity of requiring a HUGE INT class or something for keeping track of xp earned for those stubborn players who somehow, after 12 years of playing, manage to get their characters up to 500,000th level. heehee

Quote:

---

Originally Posted by Mario F.

- Player attributes (strength, constitution, etc...) are fixed on a range of [1,20]. Player skills (axes, hand-to-hand combat, double-damage, etc...) are fixed on a range of [1,100]. Player advancement is such that in order to have all skills at 100 you would need an inordinate number of levels. Players will want to specialize instead.

- Damage in combat is never affected by player level. It is affected by weapon damage, player skills, player attributes and weapon modifiers (see bellow). As such damage is capped since all these elements are.

---

I like this. Paying special attention to the attributes of the equipment in the game is important. It would be disheartening (even if I never actually realized it since the machinations are hidden in the code) if I maxxed my strength, maxxed the relevant skills for the claymore and fighting with it, found the most powerful magically enhanced claymore, managed to get enhancement spells or potions, and make that once in a lifetime stroke against the dragon only to have the damage I deal reduced simply because there is an arbitrary cap on how much damage can be done in one hit. Making sure that only the greatest combination of those things together will deal more damage than you have in mind for one hit will keep things sane, but also reward me when I, after 400 hours of playing and figuring things out, manage to acquire that magical collection of circumstances and equipment. :)

And keeping the character attributes limited is good too. Afterall, if a character could achieve a strength of 1,000, but started out with a strength of 16, either he started out like an infant (and so how the heck did he survive any of his fights??), or he now has muscles on the muscles on the muscles on the muscles...on his toes!

Quote:

---

Originally Posted by Mario F.

- Areas will be loaded according to the player level within a certain range. Particularly the monsters that are a part of those areas will be of three types; trainers, free, and ntrainers. Trainers will advance as the player does, these monsters will always be at a level difference from the player as when they started playing the game. Free are random. They have a chance of becoming trainers when loaded. Ntrainers are never trainers. They will always have a fixed level, skills, attributes and equipment. Areas themselves will also be tagged Training, Free, and NTraining. So, a trainer in a NTraining area will never become a trainer.

- Area Design needs to be scripted and some form of Area Design mechanism needs to be implemented outside the game, so that players can contribute with their own areas. For now I have no idea how I will achieve this. I've been taking a look at Lua and CINT. But regardless the system needs to be somewhat similar to LPC and others, where areas can be designed with only a marginal learning-curve.

---

So this won't be a dynamically generated "dungeon". One of my favorite things in MUDding was to explore and map. What about having some dynamically generated terrain if the builder of an area wants it? This could be something like the king's hedgemaze, which he has re-arranged on an almost daily basis and then challenges people to solve the maze.

I have wanted to create a Roguelike since I found my first rogue.exe on a BBS while I was in high school. I spent many, many hours trying to get to the bottom of the dungeon. heehee You are making me want to jump back into designing it. :)

Quote:

---

Originally Posted by Mario F.

- Level advancement happens in function of the current level. As you advance in levels, you will see it harder to gain new ones. Internally the XP gained is calculated normally and then a percentage of it is removed based on your current level. I haven't devised the function yet. But it will have some result towards 0 while never reaching it. So this will effectively restrain new levels at higher ranges, or make them extremely hard to get. The trick will be determining the frontier at which gaining new levels becomes extremely hard.

---

You also need a threshold to prevent the gained experience from every becoming 0. Also, getting less and less experience, intuitively, sounds to me like it would be discouraging the player. On the other hand, going the Diablo way and requiring more and more experience points to gain levels, while keeping the actual gain from monsters rising less quickly. (But still rising - hard monsters must be worth more than easy monsters, or the players will go XP hunting against monsters that could slash at them for minutes without doing serious damage.)
I think the required experience for level-up in Diablo2 was an exponential function, while the gained XP from monsters might have been a polynomial one.

The first character on Battle.net to reach level 100 was a barbarian played by a team of players, who kept him up pretty much 24/7 - and always going for the final big boss, as Diablo was worth the most experience.

Definitely something to ponder. I don't want the game to fall back in either playability and interest once a player reach high levels (still to be determined what an high level is). The advantage of a simple exponential function is that it's quick to run and simple to implement. However, truth be said, performance issues is something that will not be bothering much on an ascii game ;)

On the other hand it is probably too simple to be a good solution. And certainly I have to consider other possibilities. The "diablo way" seems a good option.

Another one, of course is to get rid of levels entirely. Something that I always wanted to do, but could never figure out a good way to go about this. The prospect of having a character evolve more naturally always attracted me. Skills can develop themselves over time as the player uses them repeatedly, and get lower as they don't. Attributes can evolve more or less the same way, but here things get much, much, trickier.

The few games I learned about that used this system always failed to make it interesting enough at some point. Either it was too slow, too fast, too difficult, good for a while but then unrealistic...

I have the whole time in the world so I'm not entirely discarding this possibility. Especially since I have one idea that I will provide on a separate post on this thread for anyone wishing to discuss.

This got a bit longer than I expected, and I am used to AD&D which is probably obvious. :)

Quote:

---

Originally Posted by Mario F.

Another one, of course is to get rid of levels entirely.

---

How about assigning a skill level to everything instead of one single, abstract, character level. All skills would start out at 0 and increase with use or training up to a maximum of 100, and all skills decay over time. 20 pts is considered proficient with a skill, and anything less than 20 would have a penalty to the attempt to use the skill (and some skills perhaps cannot be used at all under 20 pts).

There would be groups of skills that are related and affect each other, for example a combat group could be something like:
fighting - abstract skill encompassing general fighting, adapting to foes, intuition, etc.
fighting styles:
- unarmed (brawling/boxing/wrestling/martial arts/etc)
- fighting with natural weapons (claws, tusks, bite, tail attacks, etc)
- 1 weapon fighting
- 2 weapon fighting
- weapon and shield
- 1h weapon fighting
- 2h weapon fighting
- fighting in armor
weapon groups
- axes
- swords
- etc.
specific weapons
- claymore
- main gauche
- morning star
- etc.

A character fighting with a mace and a shield wearing full plate armor for example would gain bonuses to hit from his skills in the mace, maces group, weapon and shield style fighting, armored fighting and general fighting. It would take that character a lot of time, training, practice and experience to become the ultimate maceman, and somewhat realistically his skills in the related areas would spill over if he picked up a sword for the first time. Not being proficient with the sword would mean he would have a penalty to hit when using it, but his skills in the related groups would allow him to improvise and perhaps still be better with a sword than a character who is proficient with the sword but not as skilled in general combat. Much like a veteran warrior who never used a particular weapon will know how to use terrain, deception and many other things to his advantage to offset his disadvantage with that weapon, while the apprentice who trained and specialized with that particular weapon only knows that weapon since he hasn't done any real fighting.

Other groups of skills could be drawn up, like spellcasting related skills, tracking skills, social skills (think bluffing, intimidation, etiquette, etc.), thievery, research, etc..

When the character is made initially, you could have templates for different character "classes", so a warrior template might focus on combat skills, a thief class might dabble in a few combat skills and focus more on thievery and information gathering type skills, a wizard class would focus on the spellcasting skills, etc. Or for more control, the player could be given a set number of points to distribute among the skills as they desire the character to start with.

For a character to gain a new skill, they would either need to find someone to train them, a library to research the skill in, or just start trying to use it (and failing frequently).

As a character uses a particular skill, her mental attributes determine how quickly that skill improves. One system like this I found neat was that whenever a skill was used successfully, she got the benefit of that skill. But when she failed the skill, an intelligence check was made to see if she learned from her mistake. If she did, then that skill improved. This rewards high intelligence with faster improvement of skills, and slows the improvement naturally as the skill increases.

The decay of skills could occur as a function of time vs. wisdom perhaps. Something like for every game day that passes a wisdom check is made for each skill. Each skill that fails this check goes down by 1 point. This would prevent all the skills from just going down uniformly every day (or week, or month, however quickly you decide to make skills decay). This would reward high wisdom with slower decay overall. Or to make skills decay even more realistically, the game could keep track of the last time the character used a skill. If the skill was used in the last 24 game hours, then it would skip the check and it would not decay. But for each game day the skill was not used in a row, a cumulative penalty to the check would apply, so if you stop using your longsword entirely in favor of your mace, your skill with the longsword will start to decline while your skill with the mace will increase. Over the course of a couple game days this wouldn't be very much, but after a game week, the skill with the longsword may fall further, and over the course of a few game months where the character never picked up a longsword, he may eventually wield it again and discover his skill has fallen to only half of what it once was.

This would also have the added benefit of having a TON of skills for the character to learn and increase. 100 different players could create 100 different characters with this, and each of those 100 characters would be quite different from each other depending on which skills the players chose to build upon.

On the other hand, this would make it more difficult to determine what would challenge the character. A clever algorithm to randomly populate monsters could compare a given monster's combat, spellcasting, thieving and other skills against the character to see if they are a close match, and even matching some monsters to the weaknesses a character has. Build your character up with all combat skills and let magical knowledge be lax and the algorithm may match him up against more spellcasters.

Those are all good things Jessycat. It certainly a way of doing it, with a few minor repairs here and there. However, I'm aiming for something new or at least more out of the ordinary. Certainly one of the most important factors is to make each character the most unique possible. Many games explore character development in a weak way. You end up playing copycats of previous characters every time you start over.

Also monsters and NPCs will be "player characters" on their own right. The same rules will apply to them. Having a complex, wide scoped, system will make these also interesting and varied.

One of the advantages of developing an ascii based game is that I don't need to concern myself with graphics. This is a duh statement. However it also means I can, and should, concentrate myself on other aspects of the game. And definitely for anything RPG-like, character development is a major part of the experience and enjoyment. I should waste here a lot of effort, energy, and even game resources, if it comes to that.

Anyways... here it is a preliminary approach to the type of attributes system I plan to implement. Skills are another ball altogether for which I don't have a concrete plan yet.

Attributes

There are six attributes. Mental and physical attributes are paired, being that for every physical attribute there is a similar mental one.

Strength - Physical strength or power
Dexterity - Physical agility
Constitution - Physical endurance or resistance
Intelligence - Mental strength and power
Smartness - Mental agility
Sanity - Mental endurance or resistance

Adding to these 6 attributes, there will be two traits
Balance - How much the physical and the mental attributes are matched. 1 is a perfect balance.
Valor - How high is the average of the attributes. 20 is the highest.

Of them Balance is the most important and will have a considerable (although not entirely determining) influence on your character abilities.

Balance
I attached a bmp file to this post to help the description of this trait.

Attributes are represented on the game as a pentagram. Having high attributes is not what one player will try to achieve. The main concern will be to keep them balanced with equal or almost equal scores.

As you can see from the image, two mirrored triangles define the physical and mental attributes. A circle encompasses them. This circle is drawn between equal scored attributes that are next to each other. Where two attributes have an equal score, and where they are next to each other, an arc of that circle is drawn between them. Your balance increases as the more of the circle is drawn.

As you can also see from the image, for every physical or mental attribute, its two neighbors are two mental or physical attributes of a different kind (i.e. Strength neighbors are smartness and sanity, not intelligence. Sanity neighbors are Strength and Dexterity, not Constitution).

Your balance increases, as I said, with equal scores between neighboring attributes. However, this only means the arc between them is at full strength. It also decreases the more of a difference there is between two neighboring attributes that didn't match. Here the arc between them is weak. The weaker it is, the bigger the penalty. So it is possible to have some matches but still have a bad Balance score due to the the unbalanced attributes outweighing the balanced ones.

A perfect Balance is the one where all attribute scores match.

All in all, Balance is meant to provide players with a new quirk in which raising attributes is not the main objective, sometimes it is not even the desirable objective.

Balance is meant to represent some inner self attribute. It will have a strong effect in everything you do. Strong enough to force you to make decisions based on it as far as equipment and raising attributes is concerned. Raising attributes for the sheer fact of becoming a more powerful character becomes secondary. You are more powerful if you have an higher balance.

Valor
Valor is less important than Balance, however, we can't deny that having higher attributes should be better than having lower ones. So it's also important to express this even if the consequences may be less important.

Valor is a simple average of all your attributes. It will also affect everything you do. The higher the valor, the better. However, this trait will have less of an impact on your character abilities, where the attributes score themselves and Balance will call all the shots.

It will however be one of the most important things when dealing with NPCs. While Balance represents your inner self, Valor is your outer-self. What you irradiate. It's an important trait for first impressions. However mind you, I said one of the most important. Not the most important. Other things will come into play, like certain skills and certain attributes or combination of attributes depending on what the NPC favors most.

So this is basically a rundown on an yet not perfected attributes system.

On a side note, you mention diablo 2 quite a bit and are very interested in how they coded aspects of the game. Is it possible to email the company on any advise? I know they have not released the source code yet ( like id have for doom and quake ) but any helpful advise you can gain from some proffesionals can only make you a stronger coder in the end. Maybe somthing worth considring when you get to the latter stages of your project

I'm especially interested on their object generation system. Nothing else. Much is known about that already. Blizzard has made available much information about how they do it (not the code, but the processes involved). The information is enough to help me with my own ideas.

The actual formulas and code involved will certainly not be released. Much less to some stranger asking them to incorporate their ideas on his own game. Besides, Diablo II is still very much a reality on battle.net and their object generation system the most wanted secret by players.

What gets me is "why" software companys release game code as open source. Isnt it all copyrighted? And if they publicly show their code, surely they leave it open to other skilled people not at all conntected with the company in question to change or alter the code. Saying this, I doubt "all" the source files are released in one hit anyway. This would mean being able to compile and run the applicatoion having the correct software

Software companies may release their code as Open Source for any manner of reasons. All of them are commercial in nature.

I see. I was very keen for Psygnosis to release the code Lemmings. But they never did. The core of the game ( so I read ) was coded in C. But I have seen other peoples verisons of the game programmed using Java. Psygnonis were one of my all time favouite gaming companys. Greats like Lemmings, shadow of the beast and speedball made me interested in game creation in the first place