Another look behind the scenes of current ADOM developments

Hi folks!

Because recently we have been pretty silent Jochen and I tonight are doing a planning session to resolve certain important issues we right now are working on together with Krys, Zeno and Lucas. This blog entry has been written over the course of the evening and hopefully the recent lull in activity will become more understandable after you read it.

As stated in my post about "the long tail" we have entered a phase in which we are fiddling with a lot of important technical concepts which right now do not yield much gain for you as a player but still are an extremely important foundation for the next actual game features.

In no particular order I'll be going to summarize those things down below. Enjoy!

• Jochen and I are discussing how to handle the basic model-view-controller concept between ADOM and NotEye. This has been caused by a "small feature" we added while working on NotEye: ADOM now is distributing pools of blood all over the dungeon (after killing monsters). We added this just as a test but liked the result so much that we would like to keep it. And there comes our current challenge: ADOM does not manage any information about "pools of blood resulting from killed monsters". And Jochen and I both believe that ADOM never should do so - because it would limit the number of concepts that could be used in an enhanced graphical UI (e.g. if ADOM does not manage the amount of bone dust from smashed skeletal monsters there never would be a way that a nifty UI could display heaps of bone dust). Right now we tend towards an event based model where ADOM tells the UI about things like "monster x has been killed" or "the player was damaged for y points by monster z". And then the UI can decide about what to do with this information. If you want to have damage bubbles floating across the screen you can add that. If you want to color the bubbles based on the amount of damage you can do that. If you don't want any of that you just can ignore the event in the UI. As a result the UI becomes very flexible in regard to special effects. But the challenge of this is to find an API that is flexible enough to provide enough information (for whatever definition of "enough") to the UI without creating hundreds and hundreds of different events. And it should work between C (the programming language of ADOM) and LUA (the main programming language of NotEye) without forcing us to add tens of thousands of lines of API code. So this has been  keeping us discussing for many days.
• Next is the problem of how to store "UI only information". Take e.g. the pools of blood mentioned above. For how long do they persist if ADOM has no data structure describing the amount of blood? Should NotEye generate them rather randomly, should there be some semi-random algorithm or should NotEye go the long and hard way of storing extra save files with "view model information"? Right now Jochen and I tend toward the latter situation but Zeno is not completely wrong in indicating that this adds a lot of complexity and functionality to NotEye. No easy decision here again :-)
• Sometimes we spend a couple of hours with "code archeology". Just researching what some ancient piece of code in ADOM might mean and why some things actually do work. Not trivial. Believe us. But very important to be able to extend ADOM. The latest things we researched was the handling of how items are internally identified in order to be able to handle the mapping of images for identified and unidentified items in NotEye in a sane (and correct) way.
• We have been working on the ADOM server. Yes, there will be a server. More honestly Jochen has been programming a very cool prototype of the ADOM server using QuinScapes OpenSAGA project (we even have been discussing to allow community contributions by permitting OpenSAGA extensions for the server). But back to the server. We need it for several things: achievement handling with ADOM versions that are not integrated with something like Steam, global highscores, player registrations and more fun to come. So we actually had to define a protocol for data exchange, agree on data formats (we are going to use JSON internally), refactor various data structures for better global handling (e.g. the highscore format) and so on. Weeks of work without any visible results so far as the ADOM community server is not yet publicly available. And there are tons of things to be done, e.g. the layout for the community server to make it a thing of beauty, more means of interactions and so on. This also meant a lot of internal refactoring as the ADOM C code now contains a JSON library for serializing and unserializing objects (hey, we are becoming modern :-) ) and so on. While doing all this we also discussed high score compatibility concluding that the old high scores will not be importable into the new version (this already makes sense for balancing reasons - but there also are good technical excuses ;-) ). The new format is built in a way though to be able to keep new high scores compatible with future changes (at least we hope so).
• We have been discussing various ways concerning the future user registrations for the Deluxe version of ADOM. Everyone who invested $40+ in the crowd funding campaign will receive a Deluxe license as explained but once those are processed further licenses will only be available as a pad option. The Deluxe version will provide the community elements and some game extensions (e.g. choosable star signs and similar stuff). So to allow for that we need a player registration, a license management system (which must not be too complicated and definitely must not enforce DRM issues on our target audience ;-) ), etc. Again not impossible to devise but we now have to decide for a way of doing all in a way that will remain stable for the foreseeable future.
• Once we have decided upon a licensing mechanism we actually have to implement it (and we are fiddling with those parts right now). This includes things like the "sales client" to "ADOM server" communication code, license management in ADOM, being able to change accounts and so on. Details, details, details :-)
• Krys is done with 99% of the item images (but we had some fun complications as it makes a huge difference to the graphical world how items are represented while ASCII characters allow for much less variation) and about 95% of the monsters. Next I'm going to bother Krys with some nitpicky details and then we are back to map tiles and fiddly details.
• Lucas continues to work on great compositions. He's also been putting a lot of thought into how to add sound effects to the game (e.g. wolves howling, birds chirping, lightning crashes). Jochen has implemented a nice configurable system to allow very flexible settings. 
• Which brings me to another point we have thought about quite a bit (and tried various implementations): Extensibility. Many of the new features (sound effects, images, the way the graphical UI behaves) are highly customizable (if you have some basic technical skills and can compose, paint or program). This will allow for fun community adjustments and we probably will be happy to include great customizations into the core if the customizer agrees.
• The code for the achievements has been structured and now needs to be integrated with the account based system as well as with the ADOM server. Parts of this stuff already is finished but there still needs to be added a lot of network code to handle error cases, etc.
• I personally am still busy writing the ADOM Lite RPG. The goal still is to be finished with the first version until the end of May - quite a bit of work to do as by now space conservation becomes a prime issue in order to fit all rules and a fun game into 64 pages. I have decided to use Hexographer to create a map of the Drakalor Chain that will be included as the setting map (and probably also as a poster in the boxed version - but regarding the latter thing I need to discuss this with Krys as originally we had planned to have him to the poster map; make your voice be heard in the comments below, too ;-) - my line of thinking right now is that a Hexographer style map probably has a higher play value than a painted map).

Taking all this the next ADOM prerelease probably will not happen before the end of May as there just is not enough visible stuff happening. On the other hand we need to get all this stuff out of the way ASAP in order to be able to focus on the next new game play additions so this seems to be the most reasonable way to go.

Ok, enough for now. The past six hours with Jochen have been fun, it's past midnight over here, I'm going to sleep now ;-) (sorry for typos - it's been a long day)

Read ya soon!