Raising Game Max Level. What all needs to be done to keep game playable?

So now that I have my mud compiling and running, I am picking up where I left off when i started coding this 20 years ago.

I'm running off a Rom variant RoT, which by default has the game set to go from level 1 - 101 with 102-110 being the immort levels. I increased my game's max level to go from 1-201 with 202-210 being the immort levels.

I realize I have to go through all of the areas and retool them as well as build more for harder mobs to net the xp needed to continue leveling. I also realize I'll need to increase when spells are earned. I'm thinking of doubling the level needed to earn each spell, which should span them all over the 201 levels.

Is there anything else I need to do that I am not thinking about?

thanks in advance!

I guess you'll want to modify any other things that have levels too, like equipment or any level-based events. Are you changing stat ranges too or just doubling the max level?

Wow. What a trip! Let me know how it goes!

I'm essentially just doubling the max level (with the exception that the top level is 201 and not 202). I figure doubling would be the easier way of scaling everything.

Currently the game recognizes 210 as the Implementer level. With the level set in this fashion, does the game automatically adjust things like having an appropriate HP and mana per level, as well as does the game automatically adjust skill/training points (to learn and improve skills)?

I think i can handle the area/OLC side of this change, i'm more wondering about code changes that are needed to keep the game fully playable.

If you link to a download of the codebase, I can help figure that out.

Thank you

When i get home this evening, i will upload it to my public server and shoot you a link. I apologize in advance for all the compiler warnings, between starting with the RoT base, followed with my edits in 2000 and 2001, as well as 2010 and 2013, I have a lot of cleaning up to do.

Long story short on the 20 year thing. Back in 1999-2000 I used to play on this Rom variant mud with an Anime theme. I personally wasn't big in to Anime, but I had friends that were, and played it, and thus I made friends there. The guy that ran it completely revamped the code and areas, and did a good job of it at that. Being the totally awesome 15/16 year old that I was back then, I managed to totally piss off the guy running it, and got myself permabanned. At the same time, I was experimenting with developing my own mud. I had a basic understanding of C++ and used that to figure out how to make changes and apply snipets to the code. I also managed to have 10-15 of the original mud's users follow me over to it. The problem is that i was running windows 98 with Cygwin. I was on dial up, so i could only run it at night time. And I had to attend school every day. I was a broke 17 year old who couldn't afford a monthly bill for a shell account. By the time I graduated school, I completely lost having a platform to continue with it. I found a CD with my code base, areas, and p-files in 2010 and attempted to bring it back, I had a couple players return, but I was not in a place in my life where i could dedicate the time to finishing the work. I tried again in 2013, and fell in to hardware issues. So here I am now, trying again. I have a dedicated Linux box, a direct link to my FiOS gateway, and a decent battery backup. My goal now is to finish it, and then I'll work on getting new (and maybe some of the old) players.

here's the current version of my code (minus my pfiles)
http://www.fyremud.net/snapshot/fyre1.2.0003Alpha--02152019.zip

Here are a couple of things I've seen so far...

The raw number 101 (your previous max level) is used at the end of your do_modskill function in class.c instead of the MAX_LEVEL constant.

It looks like your level gains happen in the advance_level function in update.c. I don't know what the original version looked like, but the gains do not appear to take MAX_LEVEL into account. If you haven't already modified that, then you'll either want to (right before you use the values on line 193) divide all of the add_hp/add_mana/etc gains by 2.0 (and then rounding) or do e.g. `add_hp = number_range(0, add_hp)` which does the same thing on average but allows for bigger variation, and then also replace `ch->train += 1;` with `ch->train += number_range(0, 1);` or only add 1 every other level. This will make each level effectively give half as much stuff so that it stretches out evenly across twice as many levels. Instead of directly dividing by 2, you could also define ORIGINAL_LEVEL_HERO as 101 and then use (1.0*LEVEL_HERO/ORIGINAL_LEVEL_HERO) to make it completely based on whatever your hero level is set to.

There's also a function called advance_level_quiet which appears to do literally exactly the same thing as the above except without the print statements. That's a terrible newbie programmer mistake. Extensive logic should only be done in one place. You should do one of:

option 1: make it so that advance_level_quiet returns its modifications and then make advance_level call advance_level_quiet to do the changes and then print the returned modifications.

option 2: get rid of advance_level_quiet and add a boolean argument to advance_level that governs whether the sprintf and send_to_char happen or not.

I fixed the issue in class.c, but then found that it's not in my Makefile at all. Apparently it is not being used at all. When i tried to include it, I'm getting errors "assignment of read-only location". Looking more in to it, it appears to be some add-on that I must have started, but never finished including.

As for update.c : I made hp/mana/move divide the totals by two.

Option 2 sounds like the cleaner option. Where would the variable be passed from to determine whether we are advancing and notifying, vs just advancing? It sounds like advance_level should be the only function, and it should determine output and then display or not display after doing the advancing work.

After changing the advance_level function to take true/false-type argument, you'd then find every current invocation of advance_level and and every invocation of advance_level_quiet and set one one way and the other the other way.

I found where it calls for advance_level_quiet

apparently the advance command (do_advance) in act_wiz.c will drop a user to level 1, then work them back up to whatever level they are set to (if demoting level)


whereas for advancing up its


then in both cases, the code is followed by


So in theory, i should be able to create a variable that would only be true if the advance command is used, and when that variable is true, it would skip the output to the user for the individual levels (From 1 to whatever, since that would be spammy and the user doesn't need to know it works like that)

I'll report back when i get that coded in and tested!

So i haven't coded the fix yet, however, i had my roommates available and we tried to play the game to see how far we could go and what bugs we could find.

i found this code in do_follow and do_group in act_comm.c



this disallowed players to follow/group each other. I commented both sections out, and follow and group worked. I'm sure i'll find some negative affect down the line by doing this.

i also found that by level 20, i could kill mobs at level 40 (With the group), but we're only getting 100-150 xp a piece. I then (for testing purposes), raised a mob to level 80, and although it was a pain in the ass to beat, we still only got 100-150 a piece. So it seems i need to figure out how to get earned xp proportionate to level of my characters vs level of the mob.

it appears i have a lot of work to do. lol

No, it disallows...

two characters

on the same socket

to follow each other if neither of them is an immortal


"They are unable to join your group." is a horribly uninformative error message, though.

Doh' that makes sense. I had everyone connect to my domain address instead of my local server IP address on my LAN.

I will uncomment the code and fix the error messages.