Things I do intend to do in the future, when I have time/will... ====== Content ====== * towns without (bad) monsters, move dungeons outside towns; if still monsters, explain/give decent reasons * make towns bigger * no more houses without map * add ingame lore - world creation, why different magical powers, and such; take from wiki * more quests * hints about quests with various NPCs / at various places * for towns like Navar, enforce the 'no undead' rules * town illuminations at night ===== Darcap ===== * record how much you spend on bar * release some quests/stuff when you spend enough * NPCs hate/love relation - you kill an NPC, you get a reward from another, but are forbidden [for some time] to get into such and such shops ====== Gameplay ====== * skills like cooking, mining, and such => less 'hack and hack' * more graphism / items, including no combat ones * expand 'use' command; put combinations in a file, with more options partially done, merged with alchemy, but limited * alchemy: add 'on_failure_yield' for failures, add min required level * harvest: add breakage percentage * alchemy: multiple cauldrons for one recipe * [[stats|statistics]] on armors, spells, damage, and such * skills or spells consuming specific items when used/cast - done for spells * quests command, and mechanism around -- would need a way to activate a quest when reading a randomly generated scroll, maybe? done * better random maps; fix key placement with some a* algorithm to split the map in parts * reduce food supply, like divide by 10 the current values?, to give more interest to food - right now it's useless * show available operations on an item? like 'drop, apply, slice with knife'? ===== Quest mechanism ===== First low-level storage mechanism committed. TODO: * write documentation * make more objects quest-aware Goal: the most flexible Consequence: only provide base mechanism - quest state tracking. And let every other aspect be controlled by the quest writer. This doesn't prevent writing higher level quest mechanisms if needed. Should there be an explicit available quest listing for the players? So they know what to do? Most flexible idea: add a plugin function for quest handling, to describe the quest and such, call it periodically to give hints to the players, stuff like that. Only one 'active' quest at the same time, but multiple 'in progress'? Active quest can give hints if needed (show target position on map, stuff like that). Server-side, a quest for a player is: * an internal code - must be unique * a description * current state - positive integer, value quest-specific, or special value -1 meaning completed * current state description - to remind the player about what to do * manipulation functions, with a client-side notification, for quest start / modification / completion * setup command and associated client requests to get quest status Client-side: * nothing at first * quest window in the future, with notification handling ===== Harvesting stuff ===== Changes that could be done to harvesting things: * describe in a file instead of using special key/values * 'resources exhaustion' if harvesting always on the same place * tweak only drop monster special parts if player has a decent 'butchering' skill? ====== Various ====== (maybe one day) * expand CRE to actually edit things; merge mapper into it; add cache to not rebuild all things all the time * quick filters to find stuff in eg archetypes * Python: enable script to register for global events without splitting stuff in a zillion scripts * use XML for various file formats, or some common format * move to Qt/C++, to not reinvent the wheel all the time; and massively clean the code * i18n easier to figure out (goes with previous point) done * threading ideas: * one thread for sockets, queues players commands (and processes talk/chat ones, all non map-linked, immediately) * active objects on a map-basis * pool of map-processing tasks for a group of maps ; move maps between pools based on load * in/out queues to put items on maps in other pools * issue: processing linked maps should be by the same thread to not have conflicts/multiple access; or all potentially linked maps in the same (special) pool? could be an issue with bigworld, but could work * threads for resources (arch, formulae, treasures, ...) reloading, then map processing updates fields (first load, then change based on pointers/names, then free old stuff) * thread for metaserver notification * map-loading through threads / in the background? * maps-swapping thread * implies a new player state, 'awaiting map loading' - shouldn't be too long though * check scripts for multiple map access - how to create maps, how to put objects on them (which becomes an asynchronous operation) ====== old obsolete stuff ====== Todo list: * add hooks for plugin events at many places * Just a note, you might want to wait for the [[dev_todo:refactor|proposed refactoring]] to be started, and integarate with that --- //[[user:rednaxela|Alex Schultz]] 2006/10/23 (not logged in)// * let random maps be (easily) generated by plugins. Currently it's possible (intercept the apply event of a specific exit or globally), but you won't benefit from code in random map part. Ideally, a plugin would just send a map (###D### format) and let the random code handle it * improve monster AI. Steal Daimonin's idea of monsters going back to start position when player leaves map * document Python interface mostly done * expand buildable stuff (whole maps?), see, Rednexela's building plot too * make Win build process painless, like //One Batch to build them all and in the Sourceforge upload them// * fix bugs :)