Right, feature requesting time :) I had a brief chat about this on the IRC with zookeeper (leaning against on the grounds of not giving UMC authors to much to worry about but agrees that parser sucks at the moment) Ivanovic (indifferent, with a view that grzywacz does it for gp2x branch, if he succeeds it might get backported) Mordante (highly resistant because thinks it would turn WML debugging into a hell on earth). Because of the IRC constraints I was not able to present the idea fully there and then, I'd like to do it now for general asessment, because if my assumptions are correct it should adress all mentioned doubts and prove them wrong.
Let's start form the logical model of parsing as I see it working now, it will be simplified at places and probably at points inprecise but it shouldn't affect the overall conclusions. In this model any single content (campaign/scenario) is a package. This package has : a general config file a number of scenario files a number of maps a number of external utils (macros, units, terrains, extracted events) At the moment when package is chosen to run it's processed along those lines : 1) the general config file is parsed. This sets initial texdomain and gives user choice of difficulty level. When chosen game proceeds to : 2) all package contents are cached, parser symbols are analysed, validated and expanded where needed. Package enviroment is set and becomes read only. 3) A part of package (first scenario) is executed as a gamestete This approach has some advantages simplicity and ease of use for UMC author come to mind. But it has also flaws, in most cases it's memory inneficient, it creates inflexible game enviroment, it takes much power off the WML as a language. And that's why I'm proposing a revision of parsing model to one that while still retaining most of the old one advantages, adresses the most serious of it's flaws. PROPOSAL : Assumptions *Things parsed while proceesing general game config create initial game enviroment *First scenario and files linked in it are parsed automaticaly after the player chooses difficulty level *Next scenario is parsed after the previous one finished *Parsing of a scenario causes update of game enviroment (cache) -Cache is not deleted before reparsing -Objects existing in cache are replaced by default if declared again (comparision by 'id' key) -Objects exsisting in cache can be removed *Parsing of scenario removes previous one from cache Effects: Running the campaign after main menu creates initial package enviroment that's enough to run first scenario. Note that, this allows whole external utilities of package to be loaded at this stage and thus current approach to writing content (do a general config, link everything to it, fire and forget). After that the enviroment may remain the same (excluding reloading of scenario data), expand or shrink according to authors needs. When the game ends everything is unloaded as usual. This approach with proper implementation will mean slight change for end user in basic funcionality while greatly expanding extra avaible features. It shouldn't have negative impact on perfomance. If package extras are loaded at once initial load time and memory usage won't get worse and midscenario impact will be neliglible (it takes long anyway due to game saving, autosave removing and construction of new gamestate), loading only chosen extras will cause in much shorter initial loadtime and lower memory usage will drop (I expect 20-30% on longer campaigns). Following WML possibilities appear (amongst others): redefining of units according to scenario outcome, choosing between a set of events to load depending on scenario outcome, choosing scenario map depending on scenario outcome, choosing sides involved depending on scenario outcome, changing difficulty level mid campaign, ... Proposed implementation 1) Change the parser to accept filename as an argument (if it's not done already). 2) Change next_scenario key to make it keep scenario filename instead of scenario id 3) After scenario end pass next_scenario key as an argument to parser 4) Parse file given 5) Implement tag to remove object from cache (searching by id) for outside [scenario] usage I think that' it. Now you may clobber my idea to pieces, though I'd prefer having a chance to adress any doubts and questions first. And please do consider that I don't find the current state completely unbearable, I simply think the game might benefit from this change. Piotr Cychowski (aka cycholka) ---------------------------------------------------- Już niedługo pierwsza komunia! Zrób naprawdę niezapomniany prezent: Pięknie wydany i zilustrowany album do uzupełnienia przez dziecko będzie na całe życie kroniką Pierwszej Komunii Świętej - Zobacz: http://klik.wp.pl/?adr=http%3A%2F%2Fksiazka.eu%2F%3Fpg%3Dseria%26idseria%3D19%26ref%3Dwppl&sid=1113 _______________________________________________ Wesnoth-dev mailing list [email protected] https://mail.gna.org/listinfo/wesnoth-dev
