An analysis of the making of Anathema RL.


What went right

My framework was ready; usually I pretty much start from scratch and wind up writing a lot of boilerplate code. Having a start point allowed me to just jump in and have something runnable from the very beginning as well as not wasting time on trivial stuff (or putting off resource management until the end like last time).


I kept it rather simple. There’s no line of sight algorithm, no inventory, ... I think it was a good idea to skip these and concentrate on more important things, they would certainly have been nice but LOS would likely have taken a lot of time to write and inventory would be useless without more items than I felt I had time for.


What went wrong

I think I implemented the cavern generation algorithm quite poorly as it is noticeably slow. It also doesn’t guarantee connectedness which was a problem. I didn’t feel like writing a fix for that so I added digging tunnels, which wasn’t planned, instead. I’m not terribly happy with that decision though as it made balancing even harder to gauge.


Lousy menu and ending screen. What more can I say? I can’t draw.


Not enough play testing. I didn’t get anybody else to play before the release and didn’t play that much myself. This is always bad, last time my game was too hard, this time I think it was a bit too easy.


The item handling code was a hack, as was special map cells in fact. These were added one at a time so at the beginning it didn’t look too bad but as special cases multiplied it started getting quite ugly. I should have done some (more) planning beforehand. As it was item handling code ended up in the map cell class.


Combat kind of sucks. I was torn between making the game about running away like the original and having more combat to give it extra depth. On the one hand the foreman were ridiculously easy to kill, on the other hand the guards were deadly. I added leveling up as an afterthought which made foremen a complete non threat (though useful as lights :) ) in the competition version. I ended up adding dogs near the end as well.


Lessons learned

Overall I think it went pretty well. If it could do it again, I would have spend more time planning beforehand. Specifically I wish I’d sketched a quick class diagram to avoid issues like the hacked-on item code.


I’ll also revise my framework to address some scope issues. This didn’t really negatively affect me during the contest but the state object is used so much and by so many parts of the code I should probably make it global instead of having every last bit of code passing references around.


Spending a little more time on the menu screen next time would be nice.


More play testing would really be nice. I realize I also said that in the previous post mortem. Odds are I’ll say the same thing next time as well. ;)



Thanks for reading.