10.6.1.Analysis of current development state
With the original project over and further funding acquired from the CX board, a list of changes was drawn up via basecamp that would need to be made for the game to be in a viable state for it to be released. These changes were:
• Quick Time Events – Reflex games that required users to press buttons within a certain time.
• Puzzle Events – Screens where the users would have to solve some form of a puzzle to proceed.
• Delayed Events – Events that took real time to complete, with the duration of the events linked to the real world weather.
• In game Inventory – A place where collected items could be stored for later use
• More interesting Planet Designs – The designs were all similar and the planets all had the same flat layout, this would be changed so that they had more undulating surfaces.
• Weather History Book – This would be a place where the user could view the past weather that they had experienced when they had been playing the game.
• Tutorials – A tutorial for the dream mode so players could understand what to do.
In order to create these additional features, the team evaluated the state of the current game and if it could be adapted so that these ideas would fit within the current framework. While the existence mode would not be changing a great deal on the face of things, behind the scenes in order to allow these new features and
puzzles to be included the entire section would need to be recoded, likewise with the dream world the overall system of jumping from planet to planet wouldn’t change but the creation of the planets and therefore most of the mechanics would also need to be rewritten. This led to the decision that while it will be possible to repurpose some of the code it will be better for the project to start again, using all
the knowledge gained from the previous iteration to inform the project in the next development stage.
10.6.2.Existence Mode Redevelopment
Following the analysis of the current state of the game and the decision to start again from the beginning it was important to decide on the best practice for redeveloping the project
Figure 47: Screenshot of Reflex Event
Using the requirements for the game was the key to correctly achieving this, the ability to add in different interaction methods and styles would be crucial to the speedy development of the game. To this end a modular approach was proposed that would enclose the game screen and divide it into areas that could be
individually changed and edited, rather than having to recreate the entire screen each time. Therefore, several different modules would have to be created, common components across all screens such as the background or the buttons to access the
inventory/weather history would be created as individual classes then combined into one major navigation component which would ease the screen creation.
Figure 48: Screenshot of Puzzle Mode
The story text would still be displayed in the same place however the buttons that normally accompany it would be changed so that they could be replaced with the Reflex Event as seen in Figure 47 or Puzzle controls as seen in Figure 48.
By creating these components separately, it allowed the team to work
individually upon them, then only bring them back together when they were needed for the next stage of development. The story progress system written by Adrian for the original game version was reused as it performed its job well and could be altered such that the new components could be placed within its layout. The
Inventory and weather history screens were created as overlay screens so that they would appear above the rest of the game UI and contain within themselves the elements of the inventory and the previous weather types that have been
encountered respectively. Finally, with new skills that had been developed from the creation of the Quick Time Events, the health indicator was redeveloped so that it
could be controlled more finely and had better fidelity than just resizing the underlying graphics.
10.6.3.Dream Mode Redevelopment
The changes proposed for the dream mode were not as drastic as they were for the existence mode however, the current state would not allow for the changes in the planetscape that the project team had requested and so the codebase was archived and work began anew on creating the mode. The Mudlark team produced a schematic of the planet generation to help with the new development as shown in Figure 49.
Figure 49: Schematic of Planet Design
From this schematic an algorithm was written that would produce a planet given specific values for how undulating the surface should be and the size of the planet. The planets much like in the previous version would be programmatically created at run time and their properties would vary based on the weather once again, examples of these planets can be seen in Figure 50.
Figure 50: Screenshot of Planet Generation
These planets added much needed variation to the dream mode game and add the challenge of using the terrain of a planet to the advantage of a player so that when they are on higher ground it is easier to traverse to the adjacent planet. Using the new algorithm, a demo level was created where players could be taken through the game in a step by step process to help them understand the aim of the dream level. To aid in this a collection of tutorial overlays were created to give the players further information than could be gleamed from the information on the game screen itself. These overlays would appear at specific timings throughout the first attempt at a dream mode level.
The rest of the mechanics remained unchanged, with the same system of gravity working across the planets, however a double jump mechanism was introduced to help direct planet traversal.
Figure 51: Screenshots of Tutorial Screens