[crossfire] Crossfire 2.0+ features/priorities

[Brendan Lally]

On 1/29/06, Mark Wedel <mwedel at sonic.net> wrote:
>   but relatively to players and developers, what do people see as the top
> feature(s) that should be added (or things fixed) to make crossfire a better game.

I'll split this into two parts, usability issues/improvements, and
game issues/improvements (many of these things I have hinted at on IRC
in the past, but I'll describe them more fully here)

Usability:

currently most useful features of the game are hidden behind obscure
text commands, without any nice way for the clients to show them in a
systematic way. . - the rest are really minor niggles.

I would suggest then, in no particular order:

* client side display of parties (so that they can present an
interface more like gcfclient2 has for the metaserver, removing the
need for using the rather complex party commands directly).

* adding more stats, including a number that could be considered as
settings, so that clients can have a configure menu for them (imagine
having a 'server' tab next to the general, map, and keybindings tabs
in gcfclient)

In order to do that, I think you would need to send....

output-sync		short (byte?)
output-count		byte
bowmode			byte mapped to associated requestinfo
applymode		byte mapped to associated requestinfo
listen level		byte
petmode			byte mapped to associated requestinfo
usekeys			byte mapped to associated requestinfo

all of which would have better names displayed client side
(eg, group up to [spinbox] identical messages before sending, recieve
messages with priority [spinbox] or lower)

* I'd also want to consider removing brace altogether, or at least
making it a flag in the stats so that it can be displayed client side
(hitting brace by accident and not being able to move can be
confusing).

* providing an [instruction]  ext new draw info so that clients can
print the instructions that apply to them in order to do things. (I
would imagine that this would be something like "drawextinfo 0 8 0 to
worship a new god, stand on their alter and $(use_skill praying)" 
then a client could look up their own 'instructions' array, or check
their keybindings, and if use_skill praying is found, print that
instead (otherwise, strip out the $() characters). - so for example,
my gcfclient setup has use_skill praying mapped to 'p', so when I
receive that message, it should check an 'instructions' array, find it
empty, and then look in the keybindings, find one that matches, and
say "to worship a new god, stand on their alter and press p"

* a new login system, which would allow single packet character login,
or creation.
something like a login name\0password packet, and also a createchar
name\0\password packet (with the double typing the responsibility of
the client).
then some way to request die rolls, and send back the final results,
and a race choice

For this there would be something like requestinfo races, returning
replyinfo [list of races with their corresponding face numbers], then
requestinfo race foo return replyinfo race foo "the foo are a
mysterious race from the land of the metasyntactic variable...." -
clients then would be able to present a list of races to choose from,
and a nicer interface to handling swapping stats.

* sending all the information given from describing items in the items
command (I think this is only the message, chosen name & values, then
having the description generated client side, and shown as a tooltip
to each item - freeing the left mouse button to do something else to
items (moving apply away from middle click, maybe?).

* having a concept of actions applying to a square (an extension of
what I mentioned the other day about having a goto system, have
something like left-click to walk to a square/pull a lever/talk to an
NPC/fight a monster on a square (probably whichever is appropriate to
the topmost item on the square, decided server side) and right click
to cast a spell/fire an arrow, etc to a square. (diablo-style
controls)

possibly as an extension to this, send an actionid to the client with
the map command (2 bytes per square (maybe a byte if there isn't a
convenient tayste within the rest of the (newly redesigned) map
command), so that clients can tell the player what would happen by
clicking on a given square (this would also need some special flags to
decide whether to show things like secret walls - possibly they should
be marked walkable once you are adjacent to them, but not from a
distance - or maybe the detect traps skill should mark them detected,
after which they show up....)

- an extension to the extension above, send health status along with
monsters (probably as a percentage to not give away total hp), they
can then have clients draw health bars above their heads.

* having a keywords system in NPC dialog, so that when NPCs speak, it
formats their text specially, underlining (or similar) the words they
say that you can ask more about - additionally then, store all recent
(last day or so) keywords that were discovered in speech (probably
using markers), and present an interface to the client to select
keywords from what was last said, or anything said in the last day or
so.

* starting all initial equipment as locked, with a special warning for
god-given items when they hit the drop button, that dropping this will
get rid of it, and in any case they need to unlock it first.

* send mapname (not path) in the stats command, so that player's can
be shown it in the client.

* Likewise send god (probably by id number, with a corresponding
request-info to get the full list

* send perm exp for each skill, also have a levelbreaks requestinfo,
so that clients can display bars or similar to show how close a skill
is to leveling. (seeing that you are about a half an inch from a level
up is more intuitive than seeing your current exp is n, and the next
level up is at x, and your last level up was at m, so you are about
n-m/x-m of the way there).

* default new players to listen mode 10, and usekeys keyring

* send help in a special form (similar to the instruction drawext I
mentioned above) so that clients can screen out the commands they
handle internally, (north, south, cast, etc)


Ingame:

* states in conversation (so that going up to someone and saying 'yes'
will have them say 'what are you talking about' whereas saying 'yes'
after they ask a question will give a different response (this really
would require the point about conversation keywords to be in as a
pre-requisite)).

* auction house for in-game items: cf-bay?

* a town and god based reputation system, linked to the quests system,
and other actions that are taken - eg you kill an NPC, your reputation
in the region goes down, you kill a monster, your reputation with the
god that monster worships goes down, and your reputation with the god
who is the enemy of that monster goes up (but not by as much).

reputation then would affect prices in shops, damage done by
banishment (if a god likes you, he won't hurt you even if you are of a
race he initially hates), rewards from gods (instead of praying for
hours, each reward could 'cost' a certain amount of reputation, which
is then deducted from the current total), ability to convert, and
available quests (a check in the magicmouth/NPC for reputation > or <
a certain value).

also there should be interconnectedness between reputation values, as
local regions hear rumours, so for instance if you go on a killing
spree in scorn and kill enough NPCs to lose 1 million reputation
points (I haven't quite figured out the scaling yet), then santo
dominion and stoneville might lose 100000-odd points towards you as
well.


Note: a few of these are quite straightforward, and I may try doing
them almost immediatly if there are no objections.