THE BOOK OF TALES

Summary

Travels into the book of tale, to untangle and correct all the jumpled stories, and to find each of the four Runes of magic. All before you master returns. This point and Click was developed over 8 weeks half-time by a team of 10.

Responsibilities:

Screen Layout and Strukture
Character and Narrative design
Puzzle Design and Paper Prototypes
Composed Music for the Ending Cutscene

Design:

By and large, a Book of Tales is a pretty standard point and click. It stayed true to most established conventions. A center mechanics we toyed with was the "Magic Runes", which when found gave the player a infinitely repeatable item in form of an element, to use for Puzzles. For instance the player would find the rune of Water, which allowed for the summoning of water to help grow or beanstalk or overflow a cup of water.

Since the games plot literally revovled around going into existing fairytales and storied like "Don'Quixote", "David and Goliath", and "Jack and the Beanstalk". Most of our puzzles were build around common plot points from these stories, which helped us a great deal in setting up each task and challenge. Borrowing from so many stories naturally also meant that the game had a quite heavy emphasis on Characters, which led to a large majority of the puzzles being atleast partially resolved by interacting with said characters. This did put abit of strain on the variety the game had to offer, but gave us a pretty organic and non-intrusive hinting mechanism, in form of interacting with these characters.

Thoughts and Reflections

While the Magical Rune ideá definetly had it's merits and helped the game stand out abit more, it did end up causing quite a few obstacles for the puzzle design. The main issue was, in order for the mechanic to actually matter each rune had to be used as part of a solution to more than one puzzle, and ideally more than two. For a simple point and click like this, there are only so many conceivable puzzles that envolved using fire, which also fitted into already established stories, that also felt different and interesting to solve. This issue was profounded by the limitations of the project, where we couldn't really have any real animations and dynamic objects, which meant most "kinetic" puzzles were out of the question.

Another classic issue the game definetly suffered from was obscure and unintuitive puzzles. Due to the game being set in a highly magical world, many of our puzzles ended up with a Kings-Quest vibe, which was accomdated with similar levels of absurdity.

Group Acomplishments

Becuase of the nature and scope of the project, level design tools don't really exist or are as heavily needed as in the other projects. This meant that outside of writing Dialog text, level design werent hands-on developing anything in the engine, instead any puzzle whilst designed by Level Design, had to be implemented by a programmer. This obviosuly puts quite alot of strain and importance on proper communication and documentation, and that is something i felt we did really well. The communcation between programming and level design was stellar and we managed to almost always be on the same page in terms of what needed to be done and how.

Another thing me and my Level Design partner, Carl-Henrik Andersson, did really well was prototyping. Since we couldn't test out most thing in the engine for the first few weeks, we made paper prototype of all the more complicated puzzles and tested it on fellow students at school. This meant that by the time programming was ready to implement the puzzles, the first few design iterations were already done, which meant less time had to be spent asking a programming to re-iterate a already implemented puzzles later down the line.

Group Obstacles

One issue the group realized somewhat late in development was that the games ending felt quite flat and lacked a proper puzzle to end it all off. luckily programing and level design were both ahead of schedule, thus the "Laser Puzzle" was born. The core design itself was fine, the issue of the puzzle was it's high level of obscurity and how complicated it actually was to implement in our simple engine. The puzzle was so complex from a development standpoint that it took a single programmer several weeks to implement, and it all got dangerously close to handin. So while the puzzle actually was completed in the end, it throughly lacked proper playtesting and iteracting, and ended up to complex for most people to actually solve it. Even though it was probably one of the most visually and techincally impressive puzzles of the year.