Personal goals:

  • Explore systemic game design
  • Improve my skills with game engines and programming (specifically Unity and C#)

Goals for the semester

  • Create unique play experiences
  • Explore choices with cascading/lingering effects
    • Not morality systems or obvious choices


Some definitions:

  • Systemic game design
    • Games where multiple systems interact to create more complexity/randomness
    • Examples: Legend of Zelda: Breath of the Wild, Far Cry
  • Unique play experiences
    • Where any given playthrough will not be the same as another – can be through open world, randomisation, choices, etc.
  • Morality system
    • Aka “Karma system”, where the player’s actions affect a value that swings between good or evil, which then affects how the other aspects of the game work – npcs may shun an evil player and help a good player. Tends to be very binary.
  • Obvious choices
    • Especially in conjunction with morality systems, when choices are obviously right or wrong, or good or evil. Both choices can be valid, but it will be very obvious which one has which result.
    • Example: Bioshock, saving or harvesting the Little Sisters.

Aotea Project of Things – Weeks 10-12 – Reflection

In this reflective statement I will provide a quick summary of the project, analyse and critique the ideas and methods we used in our project, reflect on my personal feelings and reactions towards them, and discuss the future possibilities I see for the Aotea Project of Things.

Our project started off with several ideas, the favoured one being creating an interactive display that would educate people with the history of Aotea Square, and in particular its Taniwha. We eventually moved away from this theme due to concerns about it controversial nature (for example) and the lack of correspondence from the Iwi that we reached out to, focusing more on the general history, and the Hauora connections – physical, social, spiritual, and mental and emotional – to the area. As our thematic ideas shifted, so did our physical ones. We had been focusing on the idea of having the Hauora pathways (series of interactive installations related to one of the walls of Hauora) lead towards the center of the area (informed by our practical research into the ways Aotea Square is used, which I discussed here), which would hold a central piece – originally the Taniwha. After we made the paths our main focus, we also decided to make the project a collaborative one – instead of making the path artefacts ourselves, we would create a set of guidelines for local artists and interaction designers to follow. We created a website to act as a medium between us and the potential designers and several example artefacts to illustrate our guidelines.

On the whole, I think our ideas have potential, but the methods we used and our execution of them leave much to be desired. Our group followed a rough plan for each week – we would meet and discuss ideas and such in class, work on tasks individually, meet again before the next class and use that class to either present or discuss our ideas to/with an outside source – usually Ben. The main issue we had was that our communication skills were lacking, but each stage of our cycle was problematic for it’s own reasons as well. In our first meeting, discussions were often unbalanced, with quieter members of the group having little opportunity to share ideas without being overruled by the more extroverted ones, or just drowned out entirely. I feel this hurt our project quite a bit – the first and only time I tried to bring up my concerns with the current idea (see here) they were immediately dismissed. Our individual tasks were often ill-defined – during several weeks, half the group would be given a specific goal, while the rest would be told to “just work on whatever” – which left me feeling like I had no real purpose in the group. This was somewhat remedied once we began working on the website and example projects, as our project managers began to make sure every person had a task. Our meetings outside of class were often sparsely attended, with often only two people showing up on time. Aside from causing us to have less face-to-face time to discuss our designs, I believe that our group’s morale began to drop as a result of the lack of motivation displayed. Aside from these, we also had issues with our communication outside of our meetups – we began by using Slack for the first half of our project, but several members experienced issues receiving notifications from the app, partially causing some of the issues described above. When we moved to using Facebook Messenger, we still had a lack of proper communication. With both messaging systems, the main use was coordinating meetings – which often failed – and clarifying requirements for week starters and presentations. Discussions about design decisions were almost exclusive to physical meetups, meaning anyone who did not attend was uninformed. In a study done by Curtis et al. (1988), many of the designers felt that face-to-face communication was vital for a project, and a lack of communication lines between groups that did not directly work with each other “hindered understanding requirements” and “buried the design rationale”. If our group had spent more time working together instead of separately and had proper discussions instead of ones where the most assertive overruled everyone else, we may have iterated our ideas faster and moved on to more successful ones quicker.

Another problem with our method was the lack of early prototyping, and the lack of focus in most of our prototypes. In my research on prototyping I have found that prototypes that fulfil a specific goal or set of goals work best to find problems in a design, that they should be able to generate feedback and insights into the design and they should be iterated early and often (Menold et al., 2017). I have also found that they can cause several problems in the design process, even as they help it along. For example, the sole prototype we made in the first half of the project was a small, physical version of the Taniwha Seesaw idea. It did not have any real purpose other than creating a physical version of what we already had on paper. It was not to scale, and not made of any materials that we wanted to test – we merely wanted to see the water flow from one ‘tank’ (tic tac container) to the other. I believe this is an example of “prototyping [leading] to premature commitment to a design” (Bichelmeyer & Tripp, 1990). Many of our later ‘prototypes’ were more designed as visual aids rather than tools to test an idea or theory, with the exception of our website. Even then, I feel we should have created it earlier and spent more time testing than designing – due to how late in our project we began testing, we only had a small number of testers, and no time to iterate on our designs. I felt that the rushed nature of those designs was quite evident in the feedback we did get, as many people struggled to navigate the site, as well as the fact that the individual pieces created by each member of the group for the site were not fitted together well.

Like I mentioned before, I believe the concept we ended up with has a lot of potential, and I am considering continuing on with the project, with a greater focus on coherency and accessibility for the website. I believe a good method for not only testing the website, but also generating example works would be to ask designers (possibly students from AUT) to access the website and try to create an idea that fits the criteria for one of the paths. Ideas that work well for the project would indicate that the website is successful, while failures would give insight as to what is being miscommunicated.


Bichelmeyer, B., & Tripp, S. (1990). Rapid prototyping: an alternative instructional design strategy. Educational Technology Research and Development, 38(1), 31-44.

Curtis, B., Krasner, H., & Iscoe, N. (1988). A field study of the software design process for large systems. Communications of the ACM, 31(11), 1268-1287.

Durie, M. (2017, May 18). Maori health models – Te Whare Tapa Whā. Retrieved August 16, 2017, from

Field, M. (2011, June 10). John Key: ‘I don’t believe in taniwhas’. Retrieved August 21, 2017 from

Menold, J., Jablokow, K., & Simpson, T. (2017). Prototype for x (PFX): a holistic framework for structuring prototyping methods to support engineering design. Design Studies, 50, 70-112.



Aotea Project of Things – Week 9

[In Progress]


Aotea Project of Things – Week 8

[In Progress]


Aotea Project of Things – Week 7

[In Progress]


Aotea Project of Things – Week 6

[In Progress]


Aotea Project of Things – Week 5

[In Progress]


This week we discussed and evolved our ideas for the pathways and centerpiece further. We have begun leaning away from the focus on the Taniwha, as it could and has been a sensitive and controversial topic (for example).


  • Start should have signage/explanation
  • Paths based on Hauora/wellbeing pillars – Physical, Mental/Emotional, Social, Spiritual
  • Example ideas for the paths:
    • Physical – block puzzle
    • Mental – memory/feeling totem
    • Social – something to do with Tech Deck toys? (related to skaters and Mountain Fountain)
    • Spiritual – hidden pictures
  • Each pathway would have three or four activities, and would lead towards the center and the taniwha seesaw
  • Pathways
  • Seesaw prototype progress
  • Some discussion about safety
  • Swappable art, other images
  • Thematic shift from taniwha to past-vs-present – controversy?

Design Goals

  1. Appreciate the ‘spirit’ of Aotea Square
  2. History/education
  3. Aesthetically pleasing – tourists



Aotea Project of Things – Week 4

Aotea-Taniwha See-Saw

Our current front-runner idea is a physical installation in the middle of Aotea square. Resembling a see saw with large aquarium tanks balanced on either side, it would hold water that would obscure the contents of the tanks, and would be able to flow between the tanks via a pipe along the see saw. One side would have a model or image of Aotea Square, while the other would have a model of a taniwha – representing the Waihorotiu taniwha whose stream was buried under Queen Street. The two sides would be slightly unbalanced, so that when left alone the taniwha side would sink lower and fill with water, becoming hidden. People would be able to move the see saw by pushing or pulling on either side, hiding the Square and revealing the taniwha.

Some potential problems and possible actions or solutions I have identified with this idea are:

  • Weight/Size of tanks
    • If the tanks are too large, heavy or full of water, it would make it difficult to move the mechanism.
      • Depending on if we want smaller children handling it – see safety – we would have to test the size/fullness/weight ratio to make sure the intended users are capable of moving it.
  • Safety of public
    • If the see saw moves too fast – either through a person’s interaction or the resetting motion – it would be dangerous to people moving around it, especially small children.
      • We could put a fence around the installation – close enough that people would be able to interact with it, but wide enough that they would not be able to walk under it.
      • The mechanism itself could have some sort of brake or retarder to prevent it from moving quickly enough to cause damage.
  • Damage to installation
    • There is always a chance of people intentionally or unintentionally damaging a public installation that they are allowed to touch or interact with.
      • Our group has considered having guards, possibly who double as attendants or facilitators?
    • With the motion of the see saw and water, it is possible that the mechanism, the tanks or the models could be damaged, particularly if the motion is unhindered (fast).
      • Similar to above, slowing the movement of the mechanism would help prevent damage.
  • Lack of interaction
    • People may not want to touch the installation or not know how it works – in particular if it is hard or heavy to move it may discourage people.
      • Adding handles may be a way to indicate to people that it is not just a strange piece of art – the installation can and should be moved.


We decided to make a simple prototype of the see saw with the connected tanks of water out of materials we had access to during class.

The prototype mainly gave us a better idea of what we were trying to visualize, while also allowing us to see some of the design concerns that we may have to consider while continuing our project, such as the shape and relative size of the components, the need for air holes to release pressure and the positioning of the parts relative to each other for optimal function.

The rest of the Square

We also discussed some ideas for the rest of the square. We have decided to add interactive elements to the main pathways leading towards the main part of the square – the concrete part where we will have the main installation – that will act as guides and draw people towards the center. These will also have information regarding the history of the area, and give context to the centerpiece. I have begun researching possible puzzles and riddles that we could have in this area. We have considered making the puzzles fit a theme, such as ‘water’. Some of our brainstorms so far include:

  • The traditional water jug puzzle
  • A puzzle where multiple people have to cover holes in a pipe that is being filled with water, so that a desired item (e.g. a key) will float to the top as it fills (the holes will allow the water to leak otherwise)
  • Something like this puzzle
  • Some sort of bridge building puzzle