While the two design methods used in my honours project are vastly different and have their own major selling points and downsides. The conclusion I have come to is that both are good for the game designs being presented.
The Visual Document suits the Superman: Man of Steel idea perfectly and allowed me to showcase the design in a larger than life and colourful way. It allowed by its very nature the inclusion of all the image files used in the document that add to the overall look and feel for the game design. The document itself flows from one section to the other and presents things to the point and with the minimum of complication.
The Game Design Wiki suited the Time Travel game perfectly because it allowed me to take the time to explain the more complex ideas and concepts behind the game design. The document itself is presented in a way to easily explore and navigate.
The things is I can not actually come to a conclusion as to which method is better. I think in future, now that I have perfected the Visual Design method I will be able to generate contented for such documents at a much faster rate. As for the Game Design Wiki I am comfortable with editing and organising them now and the merits of presenting the design in an ordered maner make it stand out.
I think in future I would try to use an amalgam of both methods to present a perfect game design document. With the visual aspect covering the spine of the documentation and delivering the key information and the wiki giving you the finer details of the game design.
You can view the Time Travel Game Wiki by heading, HERE.
The set up and process for using a wiki format in game design is fairly quick and simple. The the wiki method and the process of creating it has its many good points and bad points though:
- There is plenty of free wiki software and portals available such as EditThis.info (which I ended up using for this project) and Wikia among others
- There is a full automatically generated log of new posts and changes that is updated every time you access the site so you can easily keep track of changes and edits. You can see the edits log for the Time Travel Game Wiki, HERE.
- The learning curve is not to steep despite some large hurdles
- Simple structure and emphasis on embedded links and material makes the design documentation easy to navigate and understand
- Everyone knows how to read and navigate a wiki
- If you are going for the default online hosting options that many wiki providers offer, you have no control on making it private. For this project it is a sort of bonus because it makes sharing and editing it on the go easy.
- In the industry private offline hosting would be the only option to guarantee privacy. While the option I went for, EditThis.info does allow for private wikis it is not a perfect solution because it requires having a tight control over pages created and edited for the wiki. You can set overall privacy controls for the Wiki but each page can be set to private and public as well. So you can see the hypothetical situation of a disgruntled employee flipping the public switch on pages that they are allowed to edit.
- Not all wiki editors allow for settings to only allow specific users to add and edit the wiki (EditThis.info provides this option hence why it was chosen) most wiki editors and providers require you to make the Wiki you create public and editable by all
- Learning material on editing certain formats of wiki is out of date. The help documentation for EditThis.info is really out of date, thankfully the help documentation for Wikipedia which uses the same system as EditThis.info is fairly up to date!
- MAJOR ISSUE! Problems with Wiki host and site speed. Towards the end of the project the Game Design Wiki for the Time Travel Game slowed and filled with page timeout errors. This issue slowed down production to a very slow and painful grind. It meant that every edit/addition needed to be poured over before hitting submit and the average wait time was 3-8mins for pages and the editor to load. Eventually I managed to get in contact with the owner of EditThis.info and resolve the issue but it showed that wiki’s can be very temperamental. If I was to be unable to resolve the issue I would have been stuck in a very dead end.
One interesting aspect of the process behind putting the wiki together was that I found myself relying on a lot of external programs and software to create a lot of the content for the wiki itself.
Apart from the obvious sourcing of the various images in the wiki things like the tables and layouts had to be created outside of the wiki editor and then added in as image files. The problem with this is that the wiki has limited screen space and while you can technically have images of infinite size in the wiki is you pull them from elsewhere rather than uploading them to the wiki itself. The results can be less than appealing because it can break the overall formatting of the wiki. The work around is to have two versions of an image that needs to be seen in detail. A smaller one to call directly into the wiki and not break the formatting and the full size one as an external link. It is not the best solution but it seems it is the only option in this case.
So while it may seem like there are way more bad points to using a Game Design Wiki I feel that the good points more than make up for it. This is because the majority of the bad points are system and technical problems rather than functional problems. At the end of the day the wiki presents the design for the Time Travel game in a clear and consistant manner that is easy to navigate and get your head around. I think in future if using the wiki method again I would look into having my own private, off-line wiki so that it avoids the technical problems I encountered while creating the Time Travel Game Wiki.
Well yesterday was…interesting… I spent most of the day fighting with the Wiki site for the Time Travel Game, in attempts to both add things to it and make it run smoothly. I got to the end of my tether with it and was about to declare the whole thing a giant failure when I came across a Google Group for EditThis.info. There had been no activity on the group for pretty much a year but I had no other option.
I asked about the issues I was having with the site and my wiki and within two hours it was magically fixed! So I am back in business with the Wiki now and you can head here to check it out.
So due to all this faffing around with it the past couple of days I haven’t added as much as I wanted to the wiki but I managed to get a bit up yesterday.
The wiki is now on version 1.10 as I start adding the content to key sections. The current plan is to sort of do it in the reverse order of what I usually do. I am getting all the other sections finished before tackling the Game Mechanics one. This is because the controls and in particular interface of the game are integral to how players use the majority of the game mechanics.
So yesterday I managed to get the Story Synopsis section done in a very loose and basic form with the plan to add to it as I go. The overall Game Objective and the Controls page which involved the creation of the following image and table:
Personally I think the Controls section of any form of Game Design Documentation is one of the most important sections. Many student GDDs I’ve read on the internet seemingly overlook it or put it in as an afterthought. While the section is relatively small and basic compared to others it has great importance because it is the tool/s for how your players will be interacting with the game. If you don’t think about it you are doing them a disservice. I always sit there with a controller or mess around with my keyboard and mouse when writing these sections. It is surprising how helpful it can be. You can test out the inputs and ergonomics of the controls you are developing.
Anyway that’s it for now, hopefully I can get back on track with it now that it is all working as it should be again.