[crossfire] player character creation/login redo.

[tchize]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

You are still mixing at protocol level the player login and the
player  creation, this is wrong. If a player want to create a
character, he clicks on a new character button. He doesn't have to
enter user/password before. At protocol level, when player wants to
create a new character, the client request from server the list if
class and stats with description and modifiers. The player then
selects what he wants.

Also, player should not be forved to choose a class, he should be
presented with the option to choose 3 skills instead. (not all game
skills should be available like that!)

Mark Wedel a écrit :

> 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).
>
>
>
> _______________________________________________ crossfire mailing
> list crossfire at metalforge.org
> http://mailman.metalforge.org/mailman/listinfo/crossfire
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEp7YXHHGOa1Q2wXwRAqM8AKDCh6ZeVWRxitKAuEFd6R3UaC3YlACfcw8+
DVnUy2ctMX+oLnoL/ZN54j8=
=vUJZ
-----END PGP SIGNATURE-----