Author Topic: Angry Troll versus Magic Bridge - Review by Jo  (Read 7297 times)

guest509

  • Guest
Angry Troll versus Magic Bridge - Review by Jo
« on: March 18, 2013, 10:51:08 AM »
http://dinre.wordpress.com/

  Another 7DRL 2013 entry. And it's a strange one.

GAMEPLAY:
  This is a card game using the standard 52 card pack, some dice and a marker for your troll. It seems to be a take off of solitaire, flipping up cards, moving your troll around, collecting cards for special moves, etc...

  I found it very hard to fathom the gameplay while reading the .PDF, but the game rules are only a small part of the document. Much of the document is an academic style recount of the building of the game. It has poems and stories and copies of emails. Like it's a school project. I don't know anyone who actually designs games in this way. Documenting every little thing. It reminds me of the nearly nonsensical stepwise process I was forced to complete in high school when writing something. But that's just a guess. Maybe that's this guy's process, I dunno.

  It's definitely an odd entry, but that's not a bad thing. Far from it.

RECOMMENDS:
  If you are interested in reading about a convoluted and contrived pseudo academic process this can be very interesting. If you are looking for a more structured way of making a game this is also for you. As for the game itself, it's a solitaire card game using common components. You probably already know if you dig solitaire, if you do then you'll dig this game.

Dinre

  • Newcomer
  • Posts: 3
  • Karma: +0/-0
    • View Profile
Re: Angry Troll versus Magic Bridge - Review by Jo
« Reply #1 on: March 21, 2013, 06:55:21 PM »
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.pdf

Any 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.

guest509

  • Guest
Re: Angry Troll versus Magic Bridge - Review by Jo
« Reply #2 on: March 22, 2013, 12:28:13 AM »
  Well I'm glad it works for you. Recognize that the creative process is highly individualized. I write a design document before I start, sure, almost everyone does, but nothing like this. I discard all ideas that do not fit until I have a list of features and a goal I want to implement. Then I start coding my features in the order prescribed by my plan.

  I'd get nowhere with your method, as likely you'd get nowhere with mine.

Dinre

  • Newcomer
  • Posts: 3
  • Karma: +0/-0
    • View Profile
Re: Angry Troll versus Magic Bridge - Review by Jo
« Reply #3 on: March 22, 2013, 11:56:54 AM »
Jo, I think you would find a great amount of utility in treating your design document as a "living" document, instead of a one-shot creation.  This was one of the great design re-discoveries of the 90's: documenting your process along the way greatly improves everyone's work.  It's not my method, and I don't take credit for it.  It's a method that designers (including myself) have found to improve the quality of a product's design in a quantifiable way (translation: we make more $$).

It's like always commenting your code or applying polymorphism in your object-oriented projects.  The question is not whether or not it works for people; the question is whether or not you are willing to make it part of your process.

I know a lot of people won't be willing to really document their work (and that's perfectly fine), so I put these explanations up for those who are looking for new tools to improve their process.  This tool is one of the most effective in my toolbox, so I want to make sure that anyone who is interested gets the details.