[crossfire] player character creation/login redo.

[Mark Wedel]

  Looking at the 2.0 TODO list:
http://wiki.metalforge.net/doku.php/dev_todo:cf2.0
(as an aside, I'd hope to make the 2.0 release by end of year, which might limit 
it to the 'High' and perhaps some 'medium' items on the list)

  One of the high priority items is character creation todo.  That's been on the 
list for a long time, and I think is one of the best things to change for 
initial player experience.

  Below is basically my general outline.  It doesn't go into the technical 
details much, but general flow.

  First, the client would have to negotiate that it uses the new login method - 
probably via setup.

  Client would prompt player for both name and password in a nice pop up box, 
which should display the motd and any other pre login information.  The client 
would then send this information to the server in one packet.

  The server could then return 1 of 3 results:
1) login success, and loads the player up, starts playing with previously saved 
password.
2) invalid password - retry login.
3) no such player - go to new password creation method (ask player if he really 
wants to create a new character, confirm password).

  For new players, I see a pop up window with all the selections (stat 
adjustment, race & class selection).  The client could get the available races 
and classes via requestinfo commands.

  For stats, I personally like the idea of giving the player X number of points 
to distribute between his stats.  This removes the need to keep re-rolling until 
you get a good character, and after all, the client could be hacked to basically 
do that - re-roll until it gets the best character possible.  The number of 
points would just be an option in the settings file, so easy to tune. 
(alternatively, stats could be rolled by the server, but instead of anything 
within a stat total range be valid, should always return characters that match 
the best).

  The player then makes his selections.  When all done, they click done, and the 
client sends the selection back to the server (player is an elf fighter, stats 
...).  Play then begins at what is considered the starting map.

  I think this would provide the best experience, and at least for the gtkv2 
client, wouldn't be hard to do that window in glade.  I think this is much 
better than having an in-game mechanism of moving between maps, etc.

  For compatibility, the existing method can continue to be used for a while 
(until at least it seems to have been long enough that clients that support this 
new interface are widely used).  This new method isn't requiring any information 
that isn't currently asked for - it is just providing a nicer interface (for 
that matter, if using the old logic, maybe you won't have a choice but to roll 
stats).

  This also has to me the following long term benefits:

1) the classes will need to be made fully stand along archetypes (if not 
already).  I'm not sure if the current hall of selection map has customized 
archetypes.

2) All new player information is dynamically generated (stats from settings 
file, race from archetypes (same as right now), class from archetypes (not map). 
  This means that new classes or other customizations can be easily made without 
needing to update maps.

3) This should lead to the eventual removal of the ST_ input states - shouldn't 
ever be a need for the server to have to wait for input of a specific nature for 
the client - the server can know if a player is logged in or not, but otherwise, 
it just gets a bulk of data (there might need to be the addition of some new 
Ns_.. socket states, but I'd rather have state data in only 1 place, not 2).