General outline of future versions:
1.0: First true public release - fully stable, and very well balanced.
Post 1.0 outline, with the goal for a 2.0 release:
1.1 -> 1.5: Make the big changes that will result in the biggest bunch
of new bugs. Things I think about are map tiling, increased
viewable playing area, and object cleanup. Small changes can also
go in these releases, but the idea is get the big stuff in early
so there is more time to find the bugs and get it working
(some will also require new clients or support within the client)
1.6 -> 1.8: See what is still on the TODO list and other ideas, and decide
if they should get in by 2.0 or wait for 3.0
1.9 -> 2.0: Releases for balancing and finding bugs - no new features,
and bug fixes should be well thought out.
Various bits, in no particular order. This is far from a complete list -
however it keeps growing as various problems are discovered that
don't have an easy fix.
------------------------------------------------------------------------------
Future feature requests
- Make random treasure chests lockable, such that you need a special key
to open them.
- If player tries to login with same name/password as a character currently
active, drop the old connection and associate the player with the new
connection. Useful if connection is dropped but server hasn't detected
it yet.
- Generalize the code better - split between 'rules' and 'engine'. The engine
would be the aspect of loading/saving objects, dealing with maps, and
basic object support (exits, levers, etc - things useful for any working
system). The 'rules' would be the more general genre of the game -
a science fiction game would have a different set of rules than the
fantasy game. And even the same genre may have a different ruleset
(ie, adding new skills). This is sort of like the current server/common
split, but goes a bit more than that - the engine would be able to compile
into an executable with the addition of some basic stub functions,
but playing as such would really just amount to a ghost moving accross
a world which time is pretty much stopped (as monsters would be in the
rules side, and not engine).
- Changing the stat generation system - instead of roll based, give some
number of points. This makes it easier for players to choose what they
want to play - otherwise, I think some clients will be written that will
do this for the players in any case.
- Change draw_info so that server tells client what type of message it is
instead of the color. Client can then decide what color to draw it
or other special handling.
- Better handling of saved characters on potentially better maps. The save
can either have been caused via disconnection or autosave.
- Change code so that objects 'spill over' to other spaces if too many
get piled in one space.
- More/better maps. Add more quest maps or maps to take advantage of
newer features (ie, church maps for each god, maps for alchemy quests
or with rare ingredients, etc)
- Add some identifier for unique objects so that if the player that has
a unique objects quits the game, the object goes back into circulation.
- Add flag to make price of objects not affected by charisma or other
abilities. This should act like gems do right now (pay 1.03, receive
0.97). In this way, gems don't have to be hardcoded, and other items
could be similarly set. Nuggets should be added to this list - its possible
to make small amounts of money alchemy silver and then selling the nuggets.
- Add/change door handling - make them more real life - they stick around,
can be opened, closed, different keys for different doors, etc. This
sort of mimics the gate behaviour, except keys may need to open them, etc.
- Added armor quality, with armor being damaged as it is used. Add repair
shops to go with this.
- Change players draining exp from others. Currently, there are problems
in that it not adjusted based on levels, so there are various abuses
draining from low level characters. Also, generally it is not possibled
to drain exp from monsters. Possible ideas:
- Change draining from other players to be a ratio of levels (ie, a level
10 character draining from level 5 only gets half the exp.
- Ability to drain exp from monsters (might make drain weapons more
useful). Maybe have monster lose some portion of the exp he would
award when drained, and try to adjust level/other stats downward as
it looses exp?
- Fix map loading/saving so it can do it over several ticks for smoother
performance (maybe thread it?)
- Clean up skills table so that the basic skill information is dynamically
generated when the program runs, and not compiled in values.
- Clean up party code with respect to experience/skills. Currently,
other party members can get exp in whatever they want and let another
party member do the killing.
- With above, a general cleanup of skill experience for the player needs to
be redone - there are too many ways where players can shuffle exp into
the skill they want. The problem is really the spells since the player
can change exp category after the spell has been cast. But I could also
see problems with pet monsters and the like. Probably some extra
field for spell effects which mark which spell category they are from
needs to be added.
- Add method so characters that get transported into the middle of oceans
can get back to the city with sysadmin intervention. It would be pretty
easy to check and make sure the player is surrounded by ocean - not sure
if this might be used to cheat somehow (dimension door to the ocean,
then use the command instead of word of recall?)
- When you try to load a map that you already have loaded, have crossedit
raise the window of the original map.
- Delete oldest swapped map in case the TMPDIR disk fills up while
swapping out a map. To do this, detection of error on save would need
to be done (presently, the fputs are done without return value checks.)
- Have map tiling handled automatically by the code - this should make
map designing easier and some spells work better. Ideas for doing
this: Keep present map system pretty much the same. Add some extensions
so crossfire knows what directions, if any, there are other maps to
be tiled in. Replace functions like out_of_map, get_map_ob,
insert_ob_in_map, et. al. to by multimap aware. For example, if map
coordinates of -2 -2 are given to out_of_map, it would check to see
if due to tiling there is a map there. If so, it claims it isn't out of
the map. Likewise, if insert_map_in_ob gets such coordinates, it
inserts the object in that map (and updates the op->map appropriately.)
In some sense, the map becomes a hidden object. In this scenario,
if get_map_object or insert_ob_in_map gives coordinates outside the
map, it would then load the map. A member of last tick this map
was referanced probably needs to be added (a player could be moving
parallell to and edge, but we wouldnt' want that other map swapped out.)
Advantage of this map idea is that for most all objects, this tiling
should be invisbile to most objects - those spells, monsters, etc
would freely move accross this tiling.
Possible problems: How to deal with multi space objects (both in
terms of movement and actual placement). I think movement might be
OK (I am not sure there is any requirement that all of a monsters has
to be on the same map). However, for multi space objects (towns,
forts, etc) placing them accross maps becomes more difficult because
you need to be able to save a map with that setup. A possible solution would
be to break apart non living objects that span maps. For monsters, it may
be possible to just save this head (however, this will not work if the
monster has treasure in other bodyparts.)
- Seperate weapon speed and real speed for players - one is used for attacking
only, and the other for movement only. Right now, a characters real speed
could become the weapon speed when they attack something.
Make speed more variable for some actions (limit how much can be picked up
at once, certain skills should take longer than others.)
- Make monster pick up more intelligent - only pick up items if they may be of
some use (perhaps base this on int - stupid monsters might pick up everything)
- Add different dragon scales, in which different types of armor could be made
from.
- Look at getting better tools to split & merge the images.
- Add random terrain type square. Idea being you might make something a
random tree, and when the map is loaded, it chooses a tree random. This
would allow some variation in maps each time with possibly keeping the bulk
of it the same (Depending how extensively the random trees are used.
- Increase the outdoor scale, so travelling from one town to another is
actually a real adventure.
- Allow transportation objects (ie, horses, carts, dragon, griffins, boats,
etc.) Flying objects should probably ignore line of sight for most
objects (you are above the forest or mountains, but then fog should still
affect things). To do this, a terrain type value probably needs to be added,
and this acts a bitmask. Thus, transports compare bitmasks to see if
travel through that is allowed.
- Make an object type/subtype setup. Thus, the object type might be a
monsters, with a subtype as grimreaper. Or type equipment, with subtypes
of armor, weapon, boots, etc. This probably would clean up things a bit,
and make more logical sense. However, this is a major change and would
require a bit of work.
Related to this: Make access of object attributes through macros/inline
functions instead of direct referance. In this way, the code can actually
request things by what they are used for (ie, instead of requesting hp and
sp in maps for destinatins, you would request dest_x and dest_y, and the
the macros would know those are actually sp & hp). This also makes it
easy to change overloading of some values to actually use differente elements
or add new elements to the structure.
Secondly related: Make better handling for identified & non identified
item properties (ie, face, value, name, etc)
- Allow monsters to be randomly generated on a map without generators (ie,
orcs show up in forests or whatever.) Uses this as an option to use instead
of the existing random encounter code.
- Have monsters potentially attack others if they are damaged by a friend.
It looks like the code should already allow this, but I think the problem is
that monster reevaluate their objectives too often, and which time they
switch back to attacking the player.
- Add a confirmation setting for the dm command so that the password doesn't
appear as plaintext.
- Allow treasure lists to be specified as part of the objects message
- Set up config file that is read when the program is run that control
many of the options presently in config.h - for ones that make
sense (inventory icon, perhaps full ring descriptions), even let
them be things players can set. (even let TMPDIR be set in the file)
- Perhaps print out a message shortly before a spell effect is about to end.
- Rewrite all variables, using own typedefs of type:
[us]int8, [us]int16, [us]int32 : Variables that should be at least that
size (is there actually anything that needs to be precisely some size?)
These typedefs can be set depending on system type.
- Expand the features of parse_message():
Support for state-variables in messages.
Support for services (ie, receive item, give different item, or advice)
Allow for automated movement (ie, guards could do patrols, etc). Both
relative direction and absolute coordinates should be supported.
- Related to above: In communication remains the same (keyword matches),
highlite the keywords or in some way make them more noticable so players
can know to use them. This is no worse than many commercial games which
give you just a few choices to choose from to continue a conversation.
- Statues turning into golems when activated (like doors).
- IDEA: Make spells be objects. One object for each spell you know. Same
system for the monsters. For now let the objects be invisible.
Then later create a spellbook into which the spells can be "put".
Thus knowing a spell consists of having the spell-object in some
spellbook. With this, more properties of the spell (level, cost, etc)
from the current array to the spell object. Alternatively, spellbooks
have the spell objects that are then put in the players inventory when
the spell is learnt. scrolls, wands, potions would just be objects with
some spell object as an inventory.
As a further extension, make general spell casting code, which can look
at the spell object and come up with effects. For example, right now
the cones could be pretty generalized - all that is really different
is the attack form (could be determined by attack type), area of effect
(some other value in the object), damage, spell cast, level, etc. In
other words, the spell objects could pretty much provide all the information
needed for some of the more general functions (cast cone, fire_bolt, etc.)
- Figurine (when a figurine pet dies, it becomes a figurine, and can be reused)
- maybe even make a simple interpreting programming language to be used by
the objects. [object ob;ob=environment();set_speed(ob,3);sleep(30);
set_speed(ob,default_speed(ob));destruct(this_object());]
(sleep(30) is the easy part: speed_left=-1,speed=1/30.0)
- Make some general variable structures, try to get rid of the current
mess where some variables are used for other things than they
were meant to (union won't do either).
- Ability to aim at targets not in the front row. This should apply for
most range attacks (thus, in a group of orcs, the ones not immediately
around the player could still use missile weapons.)
- Look into updating the map look at the end of each time. Presently, when
ever an object is inserted, it recalculates what the maps looks like on
a particular space as well as properties. However, for things like buttons,
this function may be called several times (as well as if a bunch of objects
is being inserted.) Better method would be to add some flag stating if a
space needs to be updated (ie, is stale), and if so, update it. In fact,
a lot of updates would not need to be done until it is needed (ie, who cares
if a space out of the players view is out of date?)
- Ability to rename objects in your inventory. Best way would probably be
to just add another pointer to the object that points to the desired name.
That name is only used when in the inventory, other name is still used
for other purposes. When object is dropped, remove that name tag. This
could be a client issue, but something more would need to be added to
preserve the names accross runs.
- Handle multi space objects more efficiently in saved files. The current
problem is since multi space objects are saved last in the map, they can
'bury' objects below them (ie, drop a sword on a shop, and when the map
resets, the sword will now be below the shop.) Best method might be
to only save a monsters head when the map is saved (head contains all
the needed information), and the rest of the monster can be inferred when
loading the map. For buildings, we probably jsut need to break apart the
building into individual segments - main gain of it being 1 object is
that updates to it affect all pieces.
Secondary features:
These are more features (low priority at that) to be added. Some of these
may be related to items above, or they may be things that just would not
add a lot to the game (IMO).
- Flag so that there is a random chance that an object will or will not appear
on a map (this is perhaps better handled by treasurelists. Unfortunately,
treasurelists can not be set in the maps).
- Ability to have pixmaps set in maps or otherwise be able to load images
without having to rebuild the default images.
