Jo, thanks for giving the game a try!
It sounds like you ended up reading the design document, instead of the rules. Here's a direct link to the rules, for anyone who is interested:
http://dinre.files.wordpress.com/2013/03/angry-troll-versus-magic-bridge-rules-public-release.pdfAny feedback on the rules document would be very much appreciated, since that was the last (and thus least tested) product of the development.
The real meat of this 7DRL entry, though, isn't the game as much as it is the testing that went into it. I had playtesters involved in every day of the development to encourage a user-centered design rather than just making something inside my own head.
I would like to respond to your comments about the design document, not to defend it, but to explain what a design document can do for the development process. I have learned over the years that documenting your process is extremely valuable in a quantifiable way, and I want to help others learn this lesson without having to make the same mistakes I have made.
There are three primary reasons a design document is valuable:
- You can be consistent within your own design.
- Team members can understand the work you have done and how to participate.
- Outside parties (read: clients) can see evidence of work.
First, about being consistent within your own design: During the development process of any product, you as a designer make lots of decisions. At the time, each decision makes sense, but as the product development progresses, you end up with complex layers of often conflicting logic. I often find myself looking at a decision I made early on in a project and wondering why I didn't do things differently. Usually, there is a very good reason why I didn't take a more obvious approach, and with a design document, I can refer back to WHY I made that decision. If the reasoning still makes sense, I now know that I shouldn't change the decision. However, if conditions have changed (like the addition of mobile platforms as release targets), I can now reevaluate the decision to get the most appropriate answer. Before I started documenting these decisions, I would end up doing large amounts of rework trying to make sure a design change didn't just break my entire product. This has the additional benefit of allowing you to take a break from the design and come back to it later without losing track of how everything fits together.
Second, about team members being able to participate: The greatest challenge in working with others is communication. To coordinate efforts, everyone on the team must understand the roles and how the various pieces of work will fit into the final product. If a team member has to leave the project, the others must understand how to pick the work up and continue. All of this requires documenting the entire chain of individual and team decisions. Otherwise, you end up with pieces of work that don't fit together (and then people start blaming each other), or a team member disappears and no one understands how to pick up the work (and then the project stalls and usually dies). I understand that a lot of Roguelike developers work alone, but working with others is almost always required if you decide to make a commercial product. I personally work in an environment that mandates team work, due to the complexity of our projects. I have unfortunately watched other projects spend $500,000 USD and then die, due to the lack of documentation.
Third, about outside parties seeing evidence of work: Whenever someone else is looking at your work from the outside, there are usually two states from their perspective: unfinished and complete. They can see your product in its glory as a finished product, or they view it as basically zero work. This is especially true when this outside party is a paying client. By documenting your process, you can create a tangible deliverable before your product design is finalized. Outside parties can look at your documentation and see the decisions and process that you are following. Often times, this can also lead to great suggestions from the outside. Uninformed outside parties will usually give overly simple or broad suggestions that don't really contribute to your progress. With your design document, though, an outside party can see your reasoning and provide relevant input. Some of the best outside ideas for my projects have come through this channel.
General tips about design documents: When creating a design document, the most important thing is to be structured in a way that you understand and to put almost everything in. The exact format is immaterial. Many designers I know use paper and pen and keep cabinets of notebooks that they can refer back to later. Personally, I prefer electronic documentation, because I like having a linked table of contents. It's really just the structure and completeness that matters. It can be a lot of scribbles on a page, but you benefit most from being able to relive that process.
In my professional work, I usually use a highly-structured format, because I file my documents for others to reference later. Being consistent in my documentation between products makes it easier for others to follow my work and adapt it. In the case of my 7DRL entry, I chose a very flexible format that I updated as I worked. You can see the structure adapt over the course of the seven days, but in general it remained the same. I constantly referred back to previous work in order to make sure that the good ideas I had earlier weren't lost and to make sure I was remaining true to my overall design goal. This meant that even when I was tired or had trouble focusing, I always had material I could use to focus my next steps.
For this particular product, I was helped immensely by referring back to my list of design elements. I had started by deconstructing the games Rogue and Klondike solitaire and then choosing design elements from both to suit my design goals. I would have had to repeat this process many times, if I hadn't documented my decisions. There were a few design elements that I kept forgetting about that made the game significantly more interesting. I'm glad I didn't lose them.
As I said before, my point in talking about this is not to defend my work but to point out how wonderfully useful design documents are. It takes a lot of discipline to document your entire process (this short process generated 17k+ words), but the end product is far more polished and later modifications are much easier.
