On 1/29/06, Mark Wedel <[EMAIL PROTECTED]> 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. _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire