Thursday, May 9, 2013

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!


  1. I hope the game will still be playable offline, without some sort of always-on DRM connecting it to the server!

    1. This. If you can't play a single-player game without an internet connection, the game is garbage.

    2. Just to clarify:

      - the usage of the ADOM server is completely optional
      - ADOM will still work without an internet connection
      - ADOM will only contact the ADOM server if there are changes to the highscore/achievements that need to be send

      The latter may change but it will only be used to enhance the ADOM experience (hehe) and not to enforce some kind of user control.

    3. I absolutely have to chime in with Jochen. I'm still a single-player offline ASCII gamer geek at heart so all that definitely will be kept - promise :-) !

      It's just that the crowd funding campaign results in a lot more option...

  2. Regarding the poster, I really hope you'll have something nicer than those boring Hexagoner maps :-/ ADOM isn't even hex-based! I'm sure if you reach out to the community someone could produce a really beautiful hand-drawn style map of the Drakalor Chain.

    1. Voice heard. As the hand drawn version was the original plan I maybe should stay with that... it also saves me a day of fiddling with a cool hex map design...

    2. It really only takes a tiny teeny bit of effort on my part to put hexes over the map if I need them. Meanwhile, I vote pretty painting!

  3. Not a huge fan of hex maps myself, just my two cents.

    1. Mmmh, you are heard. Maybe I'm too much into OSR RPGs...

  4. Is it really important to implement your own higscore/achievement/licensing server?
    imho, most people will accept if you have a free offline version and a steam online version. And that saves you lots of time.

  5. @mawile

    Global highscore and achievements are stretch goals #4 and #5. Since we don't know if ADOM will be accepted on Steam, we kind of need a "backup" . So yes, we need this server to fulfill our promises. :)

    And we can re-use/enhance it for ADOM II.

    1. global highscore and achievements are both in stretch goal #5, but adding it to steam is stretch goal #4.
      I don't really know about Valve policy, but afaik, games using Steamworks have more chances to be accepted on Steam.

  6. Probably there`s something like Apache Thrift but with Lua support?.. Just an idea.

  7. I do love a good hexmap - but honestly, I think I could produce a zoomed out Hexographer based map of the Drakalor Chain right now, if I wanted one.

    Therefore I vote either a lot more detailed map (which also helps address the grid incompatibility of the standard ADOM worldview and hexed based mapping), or a drawn one that's just a prettier version of the current world view.

    Personally I'd rather a combination of the two though, a zoomed in detailed map with hand-drawn elements (made to look like the old explorers maps with little pictures of the things you're likely to encounter there too), with a faint hex grid overlaid onto (and terrain details predominantly sectioned to within these hexes so that they can be IDed at a glance) it so that it can be used for gaming too.
    Although I feel this would be quite a bit of effort (perhaps too much) - even if it'd make an awesome poster when finished!

  8. As for your MVC concerns.. when one starts use MVC more often, it can be observed, that MVC tends to be recursive pattern. You have MVC layers already, but the View layer itself might have another MVC sub-layers inside. This concept might (or might not) clarify some of your concerns about handling blood in view.

    Like, if there is a model layer in MVC, model might be stored to some database. Who cares that the model is actually nested in a View layer of a bigger MVC instance? :)