Ethical game design

I’ll be speaking a bit about Ethics, what it means to me and then how we can apply them in making games.

I completed some exercises at These exercises give a broad overview and testing of your ethical standings and how consistent you are to them over different situations. According to the site I remained consistent but irregular in my choices.

To me ethics are what you believe to right or wrong. Where you draw the line morally and what lens you see the world through.

Ethics in games

Moral Dilemmas in Bioshock

The international game developers association has a code of ethics to:

To promote the growth of our industry and the growth of creative endeavors;

To ensure a professional standard of workplace environment for all development;

To publicly establish and communicate our standards as media professionals.”


One of the parts of this code that stood out to me was: Section 1, point 8: “Strive to share knowledge even while protecting intellectual property, for the growth of our peers as professional craftspeople and our industry”(“Code of Ethics – International Game Developers Association (IGDA)”, 2017)

Here are some examples of role-playing games that offer ethical dilemmas and feature morality systems:

  • Dragon Age
  • Mass Effect
  • Fable
  • Bioshock
  • Baldur’s Gate
  • Fallout
  • The Walking Dead

The Walking Dead – Dialogue/choice system

This games all offer difficult choices and make the player use their moral code to decide how to play the game. Their choices usually have lasting consequences and make the player think and feel the impact of their choice.

This blog has some good commentaries on games that have moral dilemmas:

“Games, by their very nature, teach ethical principles. The vast majority of games require patience and fair play, which tends to be naturally enforced by your fellow players. You are required to adhere to various rules. You are expected to finish what you have started, unless you can peaceably obtain consent from others to resign. You are expected to be gracious, both in winning and losing. And so on.”(Berlinger, 2017)

In my limited game development experience,I haven’t had a experience where I have been uncomfortable and crossed a line. I can see how this situations could come up and how the choices that have to be made, wouldn’t be easy.



I feel have responsibility in creating VR games and experiences. I try to give my players a great first VR experience and represent my industry and the hardware in a positive light. I know the responsibility and power I have in painting that person’s perception of that technology. I strive to avoid motion sickness and make controls and tutorials in my games to make them as accessible and inviting as possible.


Try to keep these principles in mind when creating games and representing the games industry.
Thanks for reading!


Berlinger, Y. (2017). Ethics in Gaming 5.0. Retrieved 4 May 2017, from

Code of Ethics – International Game Developers Association (IGDA). (2017). Retrieved 4 May 2017, from


Project Management Methodology

My most recent project, New Intelligence, has been using certain project management tools and methodologies that I will discuss here.


For the project we used a Critical Path methodology. This is more resource management focused, then task breakdown.

“As opposed to waterfall and agile project management, that focus more on schedules and tasks, the critical chain project management methodology is geared more towards solving resource problems. Each project has a certain set of core elements, called a critical chain (sometimes referred as critical path), that establish a project’s minimum timeline. The critical chain methodology devotes adequate resources to this critical chain while devoting enough resources to other tasks such that they can run concurrently, but still have enough of a buffer to reassign resources when needed. This setup is ideal for resource-heavy teams, or for those who have enough flexibility in their team members’ respective skill sets.”

This methodology allows us to identify critical tasks and place them in a way we can complete them and reach our goals, with urgency and importance as indicators.


This worked well for us but we found the tasks were too large and not specific enough for such a large team. We looked to a Agile methodology to help with more regular communication with the stakeholder and adaptability in order to get a finished product out.

In the allocation of tasks we kept in mind our teams strengths and weaknesses and assigned tasks to teammates that they wanted to do and felt confident on. This led to more effective workflow and let us focus on design,

projected timeline:


Since the communication with stakeholders has been less than satisfactory, with only 4 meetings total, the agile methodology for gathering internal team based feedback and implementing that.

With regular testing throughout the project’s development, we were able to rapidly iterate and use the agile methodology to succeed.
These project management methodologies have kept us on track and are making sure we are developing the best possible product, in the time frame, for the stakeholder.

Technical Specifications

I wanted to talk a bit about my role in the New Intelligence app development.

For the first few week or two of working with the programmers we let whichever designer had questions, go over and ask and explain. This made for lots of confusion with the programmers and between designers. This was because of different terminology used and also different variants of the vision of the design.

I then put my hand up to become a programmer liaison. This made me the primary contact for designers to programmers and vica versa. This solved the problems of differing terminology and misguiding. This job however quickly took up a lot of my time and I had to pull back from design work in order to manage the programmers.

“The purpose of a technical specification in a software development project is to define the customer’s technical requirements that will be addressed by the project.”(“Technical Specification”, 2017)

I believe my analytical thinking and idea of systems helped me to better communicate to the programmers. I mainly helped to give tasks, set priorities, check progress and voice concerns. I ended up doing a similar thing for the designers because I had the most information and knowledge of the project and the inner systems of the app.


How I did it:

  • Regular stop ins – once an hour. Set their expectations. Get them to batch questions. Anything urgent could be sent over.
  • Specific todo lists – who’s doing what, when, with priorities.
  • Detailed design documentation for them to reference. This allowed autonomy in them finding information instead of having to ask.

We had a detailed bug sheet that we regularly used and was the main place to go for programmers looking for tasks.


I helped with the TDD – making some design decisions that hadn’t been accounted for and with content.


I helped structure the xml info




“A technical specification describes the minute detail of either all or specific parts of a design, such as:

  • the signature of an interface, including all data types/structures required (input data types, output data types, exceptions);
  • detailed class models including all methods, attributes, dependencies and associations;
  • the specific algorithms that a component employs and how they work; and
  • physical data models including attributes and types of each entity/data type.

(“What is the difference between technical specifications and design documents?”, 2017)

I learnt that you need to be extremely specific with your instructions and documentation. There was quite a few times activities design’s were misunderstood and made to a different specification to the one that was needed. Giving more specific needs and wants from activities and what function they serve will help cut down in back and forth time with programmers and will increase overall productivity of the team.

Thanks for reading



Technical Specification. (2017). Retrieved 1 May 2017, from

What is the difference between technical specifications and design documents?. (2017). Retrieved 1 May 2017, from

Post Mortem New Intelligence App

I’ll be discussing and looking back on my latest project, a serious game made as a supplement for New Intelligence’s training program.

New Intelligence flew up from Canberra and spent two  days teaching us the workshop. They condensed three days of workshop into two. In doing this they skipped over the test run roleplay and analysis they usually do with clients. This was a big opportunity missed, to learn how they give feedback and how they frame practice for interviews. We asked and received forms that they would normally give for feedback which helped. In the future I would have expressly asked  what was being condensed in order to let them know what activities and parts would be more helpful than others.


While I was taking quite a hands on approach with our programmers, there was a lapse of information with work done outside of class and from class members that had missed class. This was due to disorganised documentation. We had three separate documents and the google drive hierarchy was confusing. The reason we didn’t keep the documentation up to normal standards was because we had to have a GDD, TDD and multiple activity data sheets to keep consistent across. When one was updated, each had to be updated individually and consistently. This was a nightmare for upkeep and got neglected later in the project.

In the future I will use more central documentation which links to other sections with more detail. This will allow a clear division of information.

Programmers were working mostly from GDD, which was a pain to keep up to date along with the marvel app and the activity sheet data. Having a more centralised document would have solved this.

Team mate dependencies

One of the critical problems we had was a teammate having personal problems in the last few weeks of the project. He had the very important role of lead UI, being that it is a primarily UI game. This mean I had to fill in and take the responsibility for UI. At this late point in the project I was basically doing damage control. There wasn’t enough time to get it to the level I wanted and would have had if it was my responsibility from the beginning. The client seemed to like the look and flow, with which I’m pleased .

In the future, it would be prudent to  have more than one person assigned to such important systems and contingency plans around that. It’s impossible to avoid personal problems and the solution will have to be flexible and modified for every project.

Project management:

Adam handled most of the scheduling and projections for the project management. I believe the biggest problem of this project was how little information we had at the beginning. This led to us over scoping the project and giving our clients too high an expectation. Because this project was predetermined by the course, we gave it our best try but ultimately what we created was a prototype of what this application could be. The milestones we set got pushed back constantly. This was partly because of our inexperience making a mobile application and the scope of the project.

In the future having a better idea of what the project is and what the clients expectations were, would help us better scope and manage.

Design Process:

The first half of the trimester was spent doing paper prototypes and mock up programs. I discussed them in more detail here and here. This allowed us to quickly think of ideas, test them and then iterate. There was no dev time cost and no dependencies of needing programmers or equipment. when we start on the actual we knew we had solid questions formed and tested before any development. This agility was extremely useful and is something I will look to use on projects and ideas in the future.


Working on Android

This was the first serious Android game for me and the rest of the team. This came with some unique roadblocks like having to playtest on a separate device. This required constant building of apks and transferring into tablets/mobiles. The uni computers had varying sdk versions and required firebase systems installed in order to build correctly. This meant we primarily built on one computer manned by one person. This created a dependency on that one person and meant it was primarily his job to build and transfer to devices. But when Marv was busy, it was a pain to get a build. In figuring out this problem, this pushed back our beta by a week. This was mainly caused by slack times in communication.

The unity editor extension for Android would have allowed for a faster and a more direct pipeline and would have made testing small tweaks a lot easier for each individual person.


We also ran into the problem of Android’s many different resolutions across devices. There were many times it looked fine in editor and tablet but then slightly clipping text on phone. We just ended up primarily focusing on an  Android phone. This still gave us some grief with us having multiple Android phone devices with differing resolutions and aspect ratios. I had to go through and anchor all of the canvas and UI elements correctly.


In the future knowing exactly what target device/s we are aiming to ship on would save a lot of time and effort trying to make the app dynamic and work on multiple.


With programmers

I’ll be covering this in a separate blog post, here.

With client

This project is my first time offering my service for an external stakeholder.

There is an important distinction between stakeholder and client in our project for new intelligence. The stakeholder’s were New Intelligence and the clients were the people that had completed New Intelligence’s training. When designing we had to keep this separation in mind and design for both what the stakeholder wanted and what we thought would be best for the end client once it was in their hands.

Communication was disparate and difficult with the stakeholders. We had 2 Skype meetings and 2 face to face meetings. This was not enough back and forth to show activities and our progress. We had to take liberties and make design decisions without their direction and because we have no experience in the fields their clients work in, we were really stabbing in the dark for some of the situations in the activities. In the future having more open and consistent communication lines would allow better direction and authoring of content from our clients.

With designers

Having worked with the other core designers made communication easy. We primarily used discord and regularly had voip calls to work and discuss team matters. We saw each other every Tuesday and Thursday in class also. We had clearly defined roles and were available to help in anyone else’s part.


I learnt lots from this project and think it was a great insight into software development. I will take these lessons of working with a client and working with a more separated team into future projects.

Thanks for reading

From paper to fire. Data driven gameplay changes

Paper prototyping

In the process of designing for the NI app, we used paper prototyping to quickly playtest and iterate on designs for activities. One of the activities was a live role playing game based on recognising and mirroring gestures. We got 2 people from inside the team to playtest and 1 outside person.

I took notes on what gestures were made by both people and Nic L took notes on which of these  were duplicated successfully.

Our data looked something like this:

  1. 56s Adrian – Fix hair
  2. 1:18 Adrian – Chin scratch
  3. 1:41 Nic – Leaning back in chair

After a few playtests we recognised some trends and it was obvious changes had to be made. This allowed us to see holes in the activities design and create rules and add some ways to give additional player feedback.

Some of the changes were:

  • The difficulty of the exercise became much harder when the player had to remember multiple gestures within each 20 second window.  
  • A visual indication of their suspicion level would be essential information and helpful player feedback.
  • There should be a large penalty for gestures duplicated too quickly after the actor does them. This looks very suspicious and would make them think you’re mocking them, etc.

I still have some concerns about the logistics of this live role playing game. Getting two people to play and also keep score is a challenge. Further playtests and iterations need to be done on score taking methods.

Analytics in NI

During our project we implemented Google Firebase and Google BigQuery analytics tracking systems, to record some data on how users were playing our app.

Firebase receives events from a device and sends the raw data to BigQuery. You can view basic analytics in Firebase (number of users, location, etc). BigQuery gives access to custom events.

Analytics events typically aren’t real time. If a device is connected to the internet, it may upload batched events after an hour or so. Firebase only updates at the end of each day, so it can take 24 hours to see results. BigQuery has both per day tables and a temporary intraday table for real time results.


The information we chose to collect was:

  • How much time users spent in exercise – This gives us an idea of how difficult the question or the interface is to use.
  • How many answers they got incorrect
  • And the IDs of these wrong answers – This also gives us information on how difficult users are finding activities and what answers they are selecting.
  • What version of the app they are running. 
  • Model number and Android Version.
  • Location – While all perceivable testers are in Australia at the moment, this is setup for further expansion.
  • Language

This information gives us more insight into what devices and people are using to play our game. It also helps with bug testing and deciding what platforms to focus on.
Firebase offers many other useful stats like active users, retention cohorts and specific stats on each event. 

This query shows all unique users and their devices 

This query shows users completing exercises and is tracking what answers they submitted.

Once this app was rolled out to beta and had outside testers it would then be downloaded per day as a .csv 

This would give us the ability to sort info and track down patterns on user’s behaviors and make changes as necessary.

For example if users were spending a long time on a particular exercise, there might be too much text to read or too difficult of a question. Using this information we could revise the activities copy and give less available options.

Some additional data that would be useful to track would be at what point the user is quitting exercises and the app. This could point us towards some frustrating questions or exercises.

Some of the data is from devs trying to test the application, not users actually interacting with it. We could remedy this by making a dev build that doesn’t track analytics.

Thanks for reading

Studio 3, A potential business

Our work for New Intelligence has been a first experience in working for a client. I want to look at taking the hypothetical 4 designers that are currently working on this application and making a business where we would continue to offer our services for these sorts of clients.

We learned of the 9 step Business Model Canvas, which runs you through different things to think about and plan for starting up a business.

  1. Customer Segments

This section is making you think about who are your core clients and what sort of market is your product/service aiming for?

I believe with our small team size and relatively small experience we would be aiming for contractors or middlemen of larger companies and organisations. This would allow us to focus on our expertise and have them come to us for our services.

As well as subcontracting for large companies we could work with smaller local/city councils, advertising firms, training  or education and promotional companies. The scope of the sort of projects these companies would be wanting is more suited to our team size. We are more suited to a niche market with small companies and specific needs. Trying to create large generic software that could be used in mass markets for large companies would be out of scope for us. We need to also consider what sections have money to spend on this sort of thing.

A similar(real) business is Real Serious Games. They are located in brisbane and do contract work for many different clients. They make serious games, different kinds of virtualisation and interactive planning. They offer a wide range of technologies and applications for businesses. An interesting selling point they use is, showing what technologies they can apply to your business and offering ‘’enhanced outcomes’’. Their main clients are construction, architecture and government.

  1. Value Propositions

It’s important to know exactly what value you can offer to businesses and people. I believe we offer games as a better solution than others. It could be argued that games are a superior teaching medium compared to older methods. We offer playful, interactive, experiences.

A huge selling point of our service is it’s customisability and potential scalability. We custom make software to get the company’s desired outcomes and can further change and develop the app to meet these. In doing this we are using our experience as game designers and applying principles of design in the delivery of the information/software. We aren’t looking to be competitive on prices. The customers we are looking for should see this as a relatively small endeavor money wise and offer little risk.

  1. Channels

Now that we know who our customers are, and what we are offering, we need to think about how we are going to find customers and what the best channels for doing so is. We found a process that outlines how we would go about finding clients, listed below.

  1. Explore our existing connections.
  2. Website, meetings, pitches. advertise on social media, kickstarter, exhibitions and the most important, trade shows. Trade shows are the expected highest concentration of where our customers are.
  3. Setting up a meeting to sign contracts and further pitch our service and support. Define handover and future support. Platform updates?
  4. Ongoing consultations as develop the final product.
  5. We then discuss if they want updates and general support after delivery. This could give us ongoing revenue.
  1. Customer relationships

Here I will outline the expected average customer relationship.

  1. Initial contact with our customers will foreseeably be at trade shows. This is the most concentrated place of potential customers. This will require a person to travel around the world, stay in hotels and attend these trade shows.
  2. After the initial meeting a face to face/one on one meeting would be organised where we further pitch our service. This is still a no commitment from either side meetings.
  3. After we get their interest we will put together a Concept to give a preview of what we could offer them. We would get them to pay for this concept development as this is a small cost to see our potential and still low risk. Phrasing it as ‘and then you don’t have to pay anymore if you don’t feel it’s going the right direction’ would be helpful.
  4. After a green light with the concept we would get a contract signed and move forward into development.
  5. After handover we would have an ongoing relationship. This will vary largely depending on the contract signed and the amount of support needed post handover. This would include setting up lines of communication and Figure out who’s going to contact who and on what circumstances.
  1. Revenue stream

From what sources and and how are we going to get revenue?

Concept development – offering this service for free would be too much of a gamble if they didn’t take the . The small amount of money for these companies shouldn’t matter. And if it does then they probably aren’t seriously interested anyway. Pitch it as “well you don’t have to pay anymore if you don’t like it”

In order to managing risk and have a fair model for clients we decided on milestone based payments. This allows them to pull out of the project at any of these milestones and we are still payed for our work.

Keeping the software updated can be risk in how much development time it takes. This will require case by case analysis whether it’s worth it. Some updates can be a trivial fix or a complete redesign. It’s a bit of a gamble, we would need to tightly define what we will support.

  1. Key resources

What are some of the resources that this project and business would need?

  • Software and a place to work. This could be at home instead of a costly studio at the start of our business.
  • Human resources – reliable programmers and some outsourced artwork possibly.
  • Business loans – financial support for employees and start up costs.

Studio/office space – not necessarily, could be started at home to start.

  1. Key activities

These will be the core activities and duties of our development team.

Networking – Going to trade shows, travelling, client meetings.

Design work – Concept development, what we bring to the table.

Delivery – Publish and present the product to the client.

Support – ongoing support.

  1. Key partners

These are the key people/companies we would be working with

  • Programmers
  • Artists
  • Software companies – Platform owners.
  • Banks
  • Lawyers, solicitors
  • Accountant
  • Customers – the people actually using the product
  1. Cost structure

These are some things that will cost us some resource to do.

  • Cost to travel to trade shows – Accommodation, flights, losing development time, food
  • Face to face meetings – venues, wine + dine etc
  • Equipment and software – platform, licensing, work space
  • Marketing – website costs
  • Salaries
  • Legal costs

I believe this plan could become a viable business for a first job out of university. This plan also scales well and, with a larger team, our service could be done for a large company or a small local council.

Cheers for reading

Some Serious Research

In this blog post I’ll be going through some of the games I researched and analysed in preparation for designing our own serious game. I am creating an app to work as a supplementary for a training course on interviewing skills.

Serious games:

There is a lot of bad examples of serious games. The ‘Edutainment’ genre is littered with short, glorified quiz games. Most commercial training games are also quite bland looking and unintuitive to use. Below are some good examples of applications/games that help people ‘practise’ certain things.

Dumb ways to die    

This is an advertising campaign made by McCann Melbourne advertising agency and released by Metro Trains Melbourne. It is the most awarded Ad campaign in history as well as the most Viral Australian Ad Campaign(Cannes Lions | D&AD | Webbys | Spikes Asia | One Show | Effies | L.I.A. | ADMA)

“Dumb Ways to Die The Games quickly became the number one app on iPad in 85 countries, clocking 67 million downloads, 5.7 billion gameplay sessions and over 93 million pledges to be safe around trains. In-app purchases help fund new safety endeavours and it further transformed our local rail safety campaign from Melbourne into a global campaign, promoting rail safety right around the world.”

Here’s an interesting case study on the campaign,with some more background info, from Aaliya Jaffer, Erica Barbosa, Mahbuba Hussen.

You progress through short mini games with very simple interactions that outline ‘dumb ways to die’. Train safety messages are scattered in amongst comical funny mini games to keep interest. This was aimed at and reached a young audience by using “a mix of offbeat humour, a catchy tune and a collection of amiable animated characters”

After you lose your 3 lives, there is a button in the game over screen that makes you pledge to be more mindful and not do dumb stuff around trains.

This Ad made great use of avatars that create a lot of relateable emotion and empathy. I think a personification and that personal feedback of a sad avatar helps put some weight in your choice.

The use of avatars to create more tension on choices and the playful cartoon theme of this game is something I would like to bring to the app we are creating.

Peak – Brain training


Peak – Brain Training is a game about training different areas and skills of cognition. It was released Sept. 1, 2014 for free on the iOS app store.

When you first launch the app, Peak presents users with a selection of areas for improvement for each category: memory, for instance, allows users to focus on remembering more important information, learning complicated concepts faster, being a better navigator, or memorizing lists and detail.

It shuffles it’s exercises to give users an example of their paid version exclusive exercises. When you start a exercise it tells you the game name, genre, language, difficulty, previous best score, the games benefits. Showing the games benefits at the beginning is a great way to encourage practising and reminds the players what they are actively improving. 

They use short run through cutscenes to teach each game on your first time playing. This runs you through the basic mechanics and the core game loops. A interactive tutorial, where users can step through the tutorial by performing the actions like they would during the game, would have been a better way to teach in my opinion. 


Similarly to Dumb ways to die, Peak uses avatars throughout it’s exercises to give a visual and human indication of your performance.

This report screen shows other solutions and what your score was. On other exercises it shows what you got right and wrong.

Peak is very metric based for it’s user’s performance. It uses graphs and analytics to track global high scores, personal trends, etc. It also has ranks for players, I am currently a novice.

Peak auto loads the next exercise in your ‘workout regime’. This keeps you in their game loop and playing more then you intended. Habit forming because of new variation of games + notifications for new games.


The visual aesthetic and flow of Peak is really well done and feels very professional and consistent. Each exercise has a different color, that is used in shades, throughout. The menus have color coded sections and use many different graphs and icons to show results and skills.

I think some things to take away from peak are:

  • The use of some personal questions first. This is to better understand users and direct them to a more personalised practise ‘workout’
  • Color coded exercises and skill areas.
  • Their extensive use of analytics in tracking user performance and the various graphs used to show those improvements.
  • Again a strong use of avatars.


Thanks for reading

Mobile and VR Prototypes

Hello all! I’ve been doing lots of prototyping for a mobile app and a VR game projects and would like to run through my processes and things I’ve been experimenting with.

Prototyping is very valuable and allows you to rapidly see whether ideas and concepts can work before investing a huge amount of time and effort.


New Intelligence mobile app:

For the mobile app we are developing for new intelligence, I was prototyping some screen ui mock ups and also some different ways to practise certain skills. I was using Marvel for this prototype. It served well for collaboration and we were able to add in multiple members on the same project and work simultaneously.



The simple page creation editor of marvel was decent for throwing designs together but didn’t scale well when trying to duplicate pages or create more refined ideas. The lack of ability to rotate, scale or duplicate got rather annoying 😛

Towards the tail end of this prototype development, we were starting to have 40+ pages in our project. Some strange things started happening; with hotspot page links breaking and being inconsistent. The project page also took progressively longer and longer to load as more pages were added.ec1de5577e

I had to use Photoshop for some of the more intricate designs. I realised how much easier this whole process would have been if I had setup templates and used Photoshop exclusively.

Some exercises were also hard to communicate how they were going to function through this prototype. The simplicity of marvels input and page swap, hampered it in it’s functionality sometimes but for our purposes worked overall pretty decently.


Space Crawl Prototyping:

I have been starting to develop and research into a new game for final project, Space Crawl. This game is going to be a zero gravity dungeon crawler game set in space. We think. We have lots of questions that need answers before we can start developing this game and expect anyone to buy it and enjoy it when it’s done!

Because high end VR headset development, for the rift and vive mainly speaking, is only 1 to 2 years old, there aren’t many conventions or answers for these questions. So we are starting to build small prototypes and experiments to test some ideas and hopefully have a fun (and not sick inducing) game.

Here is a list of things we would like to try.

  • Jet gun. Propulsion in the direction you’re aiming
  • Gun pushback after shooting
  • Collision on body
  • Movement max speed
  • Movement drag over a certain speed/after a delay
  • Bigger and different levels – vertical, tight hallways, large spaces
  • Grappling hook
  • Simple enemies ai – flying, walking
  • Helmet UI/ canvas attached to camera
  • Spike gun/railroad gun
  • 2D Monster sprites – always facing you/animations


Some of these will most likely be strange things that aren’t what we are looking for but we might be pleasantly surprised and find something interesting. We are willing to try any idea as long as we can distill it to it’s core and test it.

Useful resources:

Lessons Learned from VR Prototyping – This great talk from Rob Jagnow at Google, saves us some time by sharing 50 things he has learnt from their internal prototyping. He has some tips for the process of making the prototypes and also lessons learnt from the ones created.

A Playful Approach to Prototyping for Virtual Reality

Studio Playful discusses their prototyping process and shares things they learnt based on those prototypes and the making of them, similar to above. The highlights for me were: Unity rules, use the asset store, pro builder + lighting and programmer animation. These simple quick methods can create quality experiences for very little time cost.

So far we have made one prototype with a combination of elements that we plan to split off and test individually.



There is a lot of specifics to do with testing, from figuring out whether or not your prototype is  ‘successful’, to finding people that have varying VR experience to playtest. We don’t have a lot of these specifics yet and will have to make most of them on a case by case basis.

Here’s a test framework sheet I set up:


And a short survey for people to fill out after playtesting.



Thanks for reading. I’ll have another post later outlining things we learnt from all these tests. There will be plenty of gifs I promise!

Neil Druckmann’s creative direction


Neil has worked at naughty dog for many years and on many titles.

2007 Uncharted: Drake’s Fortune – Game designer, co-writer
2009 Uncharted 2: Among Thieves – Co-lead game designer, co-writer
2013 The Last of Us – Creative director, writer
2014 The Last of Us: Left Behind – Creative director, writer
2016 Uncharted 4: A Thief’s End – Creative director, lead co-writer
TBA The Last of Us Part II – Lead co-writer

Neil started on the writing team and eventually got more and more creative control.  He now overlooks creative direction and game director. He explains ” there is a lot of overlap at Naughtydog of roles” people help each other and fill in wherever needed. Strong critiquing of each other and having a common goal is important in pulling a team together to achieve something worthwhile.

Another important component of the way Neil runs things is having people to bounce your ideas off and soundboard.


With the last of us, he really wanted to create a thematically consistent game through it’s gameplay and controls. Neil limited the amount of freedom the players have in controls – like not allowing rolling or bunny hopping to break the games mood and context. These silly gameplay moments remind you you’re in a game and break the players immersion and how much they buy into the story. The characters are still expressive in there movements and actions but theres less room for fumbling.


I implemented this practise of selective subtraction in Enouement with taking away or limiting certain items in the game. There is a toy gun in Enouement that shoots large nerf t8imhylike bullets that stick to walls and surfaces. It’s pretty awesome. When we first blocked the level out we had it front and center and people would immediately  pick up the gun and the game became less about the other interesting story objects and more about – how many things can I shoot? We fixed this by obscuring the gun to the 2nd drawer in a big dresser and limiting the bullets to 25. This gave players enough time to find the gun, have a play and then move on to find other things.

We also did the opposite for story items, making them larger and closer to the initial direction the player would be facing. This helped players clearly find their first goal and set them off in the right way for the game.


Thanks for reading



Storytelling in VR



One of the storytelling challenges for virtual reality is that you can’t lock a player’s view where you would choose. Doing this is extremely disorienting and jarring and breaks the player’s immersion in your game world, instead of helping them buy into your narrative. Because of this creative limitation, it means you have to use more methods of environmental storytelling and audio/voice over to give context and meaning to your vr stories.

Accounting has some interesting things it does with its narrative and how it delivers it mainly through audio.

It has a concurrent phone in each of the game’s ‘levels’ that the player can pick up and place to their ear to get instructions and further dialogue about the game. This gives the players agency about whether or not they want to participate in the story and don’t have it constantly forced upon them.

The guided narration gives the players their next immediate goal and acts as a game master at times changing rules and giving background on characters. I feel this game relies very hard on it’s wonderful voice actors. The extremely talented, Justin Roiland (voice of Rick and Morty) does an amazing job and really gives the game a fantastic sense of humor.

I knew for our game we wouldn’t be able to achieve the same level of voice acting or writing wit so we had to explore other avenues. For help with the tone of the game I added a soft classic piano piece by Paul Pitman, Ballade in A Flat Major and added some soft rainfall on a roof sounds. This helped prime the players into connecting with the important story items and backstory I had placed throughout the game.


Environmental storytelling:

The majority of the story telling and context in Enouement is done through the items and environment around the player. The vive gives the player the control to walk around a small space in a very natural way and interact with things

Bioshock and Gone Home are very influential games to me and highlighted lots of good ways to do environmental storytelling and portray different things about a house/rooms through this.

This video in particular walked through their thinking and decisions on what items to put where and guided me to pick out the most important and least amount of things I could put to tell the most amount of story.



Some of the character development I did to figure out who my character was and what sort of items he would want to pack.

I picked a short list of