Lesson Learnt Whilst Developing TTRPG-dungeon-planner

I am pleased to be making a side project that I have been working on for the past few years public free and open-source. It is a tool to help game masters create dungeons for table-top role-playing games (TTRPGs). The tool is called “TTRPG-dungeon-planner”; coming up with catchy names is not my forte.

The tool was made for myself to make a part of the TTRPG hobby easier from myself, so it has been built with me in mind. It felt right to open-source it as others may find it useful.

Having some understanding of TTRPGs or RPG video-games may help you understand this project and the post a bit more. For the post, the understanding is not essential.

Version 1.0.0 of TTRPG-dungeon-planner is fairly simple. It consists of web forms where one can input monsters, traps, rooms and then put those all together to create dungeons. The calculations to determine experience points and difficulty of encounters within a dungeon are automated. It has been built using React, TypeScript, Python, Django, Postgresql and Docker. I recommend checking out the repository.

To mark the occasion of releasing this side-project, I wanted to write down some of the lessons I have learnt throughout the two years I have developed this. I doubt these will be particularly profound, but having a blog post to mark the release of the project feels like it gives me some “closure” or a mark of completeness for version 1.0.0.

Firstly, you may be thinking “two years is a long time for such a simple project” and it is true. During the past two years life has got in the way – as it tends to – and there have been some frankly major life-events which have meant that I have not been able to dedicate as much time as I would have liked to this project. Whilst I felt guilty, I came to realise that is fine. I was not building this to be a product to sell on or anything like that. I was building it as a tool to help me in another hobby of mine: playing and running TTRPGs. If I flagellated myself over not continuously working on this project, then I would have just resented the project and ultimately put it to the side allowing it to collect dust in the great side-project graveyard that we all have. Life gets in the way of developing software as a hobby, that is OK.

The above ties-in two other lessons I learnt: tying a side-project into a hobby you already enjoy and building tools you will use both act as hooks to pull you back. The reason for this, I found, is that when doing the other hobby – in this case playing TTRPGs – I’d often think of the tool I was building too and how it would help. It would serve as a little cue to remind me about the side-project that I should get back to; the fact that I was building a useful tool for the hobby would double the pull as I would realise that if I finished creating the tool then I would be able to spend a higher proportion of my hobby time doing the part I love rather, than the drudge calculations that would be automated by TTRPG-dungeon-planner.

What also served as a hook was that I would use the development of TTRPG-dungeon-planner as not just a place to build a tool but also as a place to learn. I frequently dedicate a period of my free time to play with tech and invest in new technical skills. Whilst developing TTRPG-dungeon-planner, I would use some of that playtime to try new tech in the project. This allowed me to pick up Django and Docker from scratch and incorporate them into the project. I did get further experience of both in the workplace whilst developing that project and that is partially because I got to play around with those pieces of tech whilst building this side-project.

A riposte to the above, I suppose, is that by playing with tech it meant that the technical direction changed a few times. A large portion of time was spent moving from Flask to Django and Dockerising the application, for example. Whilst that might be a negative if I were to be working on an industrial project it is not really a negative here, as I was learning during the migration process. I did not get particular joy from migrating technologies, but by dedicating learning time to the project it allowed me to use new technology in anger and ultimately make correct technical decisions. If I were to be rushing around and not developing at a leisurely pace then I perhaps would not have done the switch. That said, I do wish I had thought about using Django at the start. The migration from Flask to Django was not fun; I do wish I had done more technical planning up front. A big take-away from this side-project is developing a love for Django.

Finally, I am glad that I had a clear minimum viable product (MVP) / v1.0.0 in mind. By having a strict MVP it allowed the scale of the creation of TTRPG-dungeon-planner to not feel completely overwhelming. I know what I am like and if I did not keep a strict MVP then it would have felt some over-whelming and there would have been scope creep, meaning that I would not have got the project done. Those are it for the main lessons I learnt. To try and combine it all into a pithy few sentences, my lessons can be summed up as: “Have a clear MVP for a tool that will enhance a hobby you already love. Try and incorporate learning and try and plan ahead on a technical level; you may get this wrong, and that is OK. Sometimes life will get in the way and that too is OK. Remember that this side-project is a hobby, it should be fun, and it will enhance your other hobbies.”.

To whoever is reading this, do check out the repository and do feel free to contribute in any way. I hope it helps!