In the last few days I've spent a lot of time in the mud_prog.c and mud_comm.c files. There's some stuff that seems a tad undocumented in the AFK Source, and there's also some stuff that I'd like to bring into the light for you builders.
The first thing is... AFKMud lets you handle character creation in the game. That means that you can have them walk through an area, or stand in a room, and choose their race and class. You can also have them reroll stats and all that.
But there are some MP commands that are either undocumented or not clear, and they're IMPORTANT in the creation process!
First of all, you should have the character pick a race *first*, since classes are restricted by the race. This means that a Half-Ogre can't become a Paladin. You can do it the other way around if you'd like, but it might confuse people. Race is what you want to be in the game, the class is the profession.
You should know how to do programs by now, mainly things that will let you find out what race the player wants. Whatever you choose, the commands to set and change the player are the same.
You use MPMSET to set the race and class of a player. The format is: MPMSET $n race RaceName or MPMSET $n class ClassName.
At this time I haven't checked to see if MPMSET cares about the restrictions on classes based on the race. This means you should take care to check that a character is only allowed to pick the classes their race allows. You can use the 'if race($n) == RaceName' ifcheck to decide this.
Once you've had the player select race and class, you can also allow them to reroll their stats. Have them view their stats with SCORE, and if they choose to reroll, then use the MPREROLL command.
What happens after this is tricky. Inside comm.c, if you find the reroll CON_ entry you'll see that the MUD forces a player to do an emote. (I think it's the ACCEPT emote?). Either way, this emote is what will trigger the next program. See, MPREROLL dumps the player into a con state where they can keep hitting Y or N for rerolling. When they keep their stats, the MUD bumps them out and forces them to emote. You then need to make an act trigger for that emote to finish off the creation.
Well there's two more MP commands. MPRACESET makes the 'final' settings on a player. It sets racial language and title, and it also finishes off the stats. In my (not so) infinite wisdom, I'd say put this after the reroll. It will modify the player's stats based on race and class settings. It also sets the title and all that lovely stuff! Then there's MPREDO! This removes all the wonderful settings MPRACESET does. So basically... the final room you have you can make them either accept or restart. Then MPTRLOOK them to the race selection room all over again if they restart - after you MPREDO. Otherwise... DON'T forget to advance them to level 2!. Newbies can't gain experience at level 1. You MUST have them advance to level 1.
There are two more commands actually. MPAPPLY and MPAPPLYB. As near as I can figure... these send those little 'Applying for Authorization...' reminders to the gods online. You might want to place one when they select the race, and the other when they finalize their stats.
You can also look through the stock entry.are for how Alsherok has this setup, but some of us just like knowing that these things do.
You can ALWAYS go through mud_prog.c and mud_comm.c and do a search for 'do_mp' to find MP commands. You should either find comments or code that will let you in on what these commands do. (A side note... most MP commands are in mud_comm.c, as that's the command module. The AFKMud additions are in mud_prog.c towards the end.)
Well to wrap this long-winded post up...
A few added extra features that will make keeping track of creation... Read up on A/QBits. One is saved on the character and one is not. You can make a few of these to keep a firm track on where someone is in the creation process. This would be good if you allow them to wander a Hall or Area for it.
I'm also looking at writing a few ifchecks and functions to make the creation process easier to write. I've already written Keyword_Progs which allow the programs to be triggered from 'commands' a player types. The next ifcheck I'm working on will test a player's race to make sure the specified class is allowed by that race. This will mean that you won't need to have a boat-load of race checks... Just a single check that will return TRUE if that class is allowed by the char's race, or FALSE if not.
I hope this helps you some. I might write something more formal on the topic of writing MudProgs. They're not all that hard, but they can be confusing. Once you master them though... you can have a very very lively MUD. Players love things that are 'alive' in a MUD... things that remain static and unchanging get boring!