Jack's BCT Hub

When writing the script, I based it off of story points that we had decided in one of our early concept meetings.

http://bit.ly/anautscript

This is a link to a pdf of the script that I wrote using Celtx.

For narrative testing, I used a Twine interactive story that I was able to host temporarily that people could play through, before answering a questionnaire.

One of the dialogue paths I created in Yarn, taken from my script, that was then used with Yarnspinner to make the dialogue compatible with Unity.

When we planned to use Motion capture for our animations, we went and captured some footage based on the actions our characters would take. I was one of the team members that helped with the motion capture filming.

I also cleaned a significant amount of the motion capture data in Cortex.

I used Adobe Photoshop to iterate and work on a logo for one of the main story points I wrote, the New Beira Trading Company (NBTC). I wanted to create a subtly sinister but corporate looking logo suitable for the early to mid 20th century. With input from peers and teammates, I was able to develop something that I felt was beginning to embody the NBTC quite well.

This started early on, within the first weeks with organising user testing for the story narrative. These are detailed in my narrative playtest blogs.

After the narrative testing, I made sure to regularly informally test with peers for insight and understanding. Notably, this was important for our boat. The boat proved challenging to get it behaving correctly and one of the main problems was our lack of experience with boats. To help with trying to fix this we had people try driving the boat and sought advice from those with experience with small boats. This proved invaluable for insight as to how we could improve the boat to make it behave more accurate to a real boat, which was mostly up to how it behaves when turning. 

The consistency of this playtesting did also expose that there was a relationship between how realistic we managed to make the boat and the water buoyancy, and how people would get motion sickness. This has been something we have kept in mind, and intend to do some extensive testing as we continue the production of Aeronautica.

I was comfortable writing a script thanks to my experience in high school, which is what influenced my choice of software. Celtx is a browser-based pre-production software that makes it easy to create well-formatted scripts. My understanding was that it was primarily for film or television, however, when I opened the website I discovered that there was a newly released mode for game scripts. While mostly this was the same format as film, it had a few extremely useful features for game development. One of which was a window that allowed me to have the story points as separate scenes to work on, and have a flow chart between them. Another was an intuitive option writing screen that allowed for very effective dialogue option writing. Lastly, there was a play mode, that put the script into something of an interactive story format. These were very effective for laying out the script in a way that was appropriate to the medium.

Celtx script and map view.

Celtx interactive dialogue writing UI.

Celtx playthrough mode.

I then tested the script (see narrative testing blogs and testing role blog) and adjusted it based on the feedback. After this, the script served as a reference point for the rest of the project.

This turned out to be much more effective for gathering information, as it not only was much easier to distribute to more testers, it also meant that individual tests did not require nearly as much time for me to run through with people. From these tests we were able to gather that we were on the right track for creating an interest in the plot and to give the audience questions as to where certain narrative points would go, as  is our intention with the narrative-based vertical slice, as well as to start understanding how the setting we are creating is being received. However, there was also obvious limitations thanks to the format. Since it was text-only there was confusion around some elements of how the setting and flow would actually feel. Also, because of the lack of visual aid, the dream sequence at the beginning caused testers to be very confused with the relevance of the events of the dream sequence. This identified to us that it is very important that we create visual identities that are both unique to certain elements, such as a visual component to the dream sequence to make it dreamlike, as well as generally recognizable, such as having a fisherman character wear a fisherman's style of clothes.

In order to do this, I put together a simple version of the narrative to sit down with peers and step them through it, describing their settings and narrative events. From these playtest I was able to gather some of the elements of the narrative that did and did not, namely how some of the flow of the narrative and how it would feel gameplay was slowed down by having the player start inside a home, rather than on the beach, already on the way to the boat. I also learned that it would be important to clarify in the dialogue and actions that the player is supposed to be getting the boat. One tester mentioned that having to give up one thing to get another seemed like a decision that should be made by the player. The whole recordings are here: Oral Narrative Playtest #1 Oral Narrative Playtest #2

First of all, Charles mentioned some of the first games that popped into his head while we were explaining it, first of which was Spore.

Spore has an iteration process to it that involves customising an organism with various structural elements necessary for survival, and then sending it out to interact with ecosystems, before customising it again and again and sending it out again and again in order to progress. This gameplay is similar to what we want to achieve with our vehicle iteration process, and it will be very important to look to Spore so that we can see what did and did not work with this procedural iteration that puts the design of something so pivotal to gameplay in the hands of the players.

Next Charles mentioned Enter the Gungeon. Enter the Gungeon takes bullets and guns and uses it for pretty much every single element of the game. HUD, Characters, Environment, and Gameplay are all stylised after bullets or guns. This creates a complete and consistent aesthetic as everything has a central focus to build from. Charles brought this up to point out to us the importance of having this central theme and style to build around. This is a crucial thing for us to remember especially as we work in our own roles, as this could easily lead to large discrepancies between the style of the art and the writing or sound for example. While intentionally having a schism between the styling of elements of a piece of media can serve to send a message, and this might be something to consider, we have to remember to be thinking about whether or not our components fit together coherently.

The third point that was something for us to think about that would help us with keeping our consistent theme, would be to hark back to the MDA aesthetics for play and choose two to really focus on. We chose Sensation, Discovery, and Narrative when we first looked at these aesthetics and this brought us back to remembering to use these, but also to be quite strict with them to avoid our theme gettings tangled up in a mess of aesthetics. An example Charles told us to look at was Doki Doki literature club, which is instead a Narrative focus aesthetic, as the story is the only focus of the game, with the gameplay being very secondary, consisting almost entirely of a single button press to progress. If we contrast how games like Doki Doki play and what players feel when playing it, with how Aeronautica is supposed to play and players feel, then we can get a sense of how best to apply and articulate our aesthetics.

We ran into some technical trouble with my servo mechanism that held the book at the end of open studio evening, and we were unsure if it was going to be a permanent issue or not. We tried again to run the project through on the following Monday for some of the BCT students that had missed out on giving the installation a go. It turned out the book servo had been pretty much destroyed by supporting the weight of the book and no longer had a proper connection to be able to be controlled. This, along with a range of other technical issues to do with the programming, meant that we could no longer run the game through. This was our intention for the installation to be immortalised on the night and exist in documentation and player response, however, it was a shame that there were so many who wanted to try it that could not give it a go. While we managed to get everything almost entirely functional for open studio, there was almost no future proofing, and this really showed. I think that doing this project again, or another project with this same style of existing solely on the night, I would consider using methods that would allow for quick and easy repairs for a couple of times so that the project could potentially be run a few times for a couple of hours each. This would help to get a much large number of responses than we could get on Open studio night as well since this would allow us to show it to much more people, and potentially be able to demo functional versions if there were industry professionals who were not there on open studio night.

My role during open studio ended up being one of the front-men maintaining “selling” people on the project and managing the queue since we could only have one person or group at a time and this meant that as people wanted to try it we had to have them wait for a while. This was posing a problem since wait times very quickly stacked up and we did not want people to have to be milling about in the reception area we had set up, away from all of the other studio works. After a while of making it work or having people patiently wait, we started using a texting queue system. Ben proposed that we take people’s numbers and have them peruse the other projects and that we would give them a text when it was time to have them run through. This ended up working much better and by the end of the night, we had a very effective system. Despite this working out, I think that there was definitely room for improvement in how we operated this system. It was given a low priority compared to the actual project, which meant that as a casualty of time pressure we did not end up being able to invest the necessary time into figuring out a good queue system. While I don’t think this seriously detracted from anything, it is something that I noted could have done with some better preparation for the sake of having things run smoothly.

That being said I think that having to have a queue really improved the mystery and mythos that surrounded our project to those seeing all the posters. I felt it created this type of exclusivity that further added to immersing people in this idea that they were users testing a company’s product. It was, however, a double-edged sword. This exclusivity and queue system meant that we couldn’t show off our work and the effort we had put in to anywhere near as many people as I would have liked. We had an idea for a screen that could show people who weren’t interested in having to sit through the whole experience what was happening, but due to the allocation of space and running out of time and resources to get together these presentational luxuries we weren’t able to do so, meaning that it was only the 13 people or groups that got to play through that really got to see what was involved.

One of the things that seemed to really add to the mystery for participants before they went in were the waivers. In the interest of making sure that people were okay to be recorded for our documentation and that they were not photosensitive or likely to have problems of anxiety or paranoia due to what we were talking about, we drew up and made waivers that participants had to sign in order to be able to enter. This idea, however, that they had to sign a waiver, a document often associated with danger, really seemed to heighten the feeling of intrigue and add to the mythos that we were creating.

These problems aside we received some excellent feedback and the only things that I would change in future projects of a similar style would be in smoothing out the queue system and in making people that didn’t want to invest so much time able to have some look at the what we had done. I was very much happy with what we ended up with and even more so on the open studio night when people would finish up in the room and come back out to the “reception” desk we had set up and congratulate and compliment our work.

The project had the majority of its functionality implemented without us having to invest too much time outside of what we normally would do week to week, however, it was getting the last pieces of functionality and the cleaning and presenting of the space that put time pressures on us.

We did not manage to get the UE4 build quite to the state that I would have liked, as we still had some quite relevant bugs, but that was the nature of some of the elements, such as the portals which seem to have posed technical challenges for the team doing the construction of the UE4 side of the project. The portals provided a vital and very potent element of the level layout, especially in the non-Euclidean section, although I can’t help but feel as though some of the portals outside of this area could have been replaced with different level layout in order to streamline the process. As this was not my working area I don’t realistically know enough about the workflow to know if this would have made a meaningful difference, but the portals sometimes appeared to be complicating things. My crunch came in making sure that the physical installation elements were made and working. Admittedly I think that my time management was lacking when it came to prioritising elements of the installation, as I noticed a handful of times that I would be focusing on making things passable but not very consistent and moving on. I think that I would have benefited from getting things done as I was working on them, to try and avoid as much of the time wasted by getting back into the head space of the different things I was working on. Moving off of something helped when I was stuck and needed to come back, but some things I started doing almost to procrastinate what was in front of me. I managed to get the physical puzzle elements we wanted in and functional, but I can’t help but feel like I could have been much more efficient and could have spent time making elements such as the book servo able to last longer.

The LED strip lighting setup

Hard drive cage and hard drives that made up the hard drive puzzle

Max headed the charge on the graphic design and marketing, but in some of my moments of procrastination or spare time I took the opportunity to offer my titbits of advice, provide an external look at some of the design, and even tried my hand at some of the graphic design. This was partially out of interest in helping the project but also in helping lay the groundwork for me to start building skills in some of these elements.

One of the best parts about helping where I could within my limited capacity, was seeing the aesthetic and the idea of Aethos coming to life. I was talking to a Graphic Design major and they said that “good graphic design makes a company” and I could not feel that more than when I saw some of the posters come together.

There was a real surge of drive instilled within me to make this work and make it work well once I saw our logo, name, and oh so corporate monochromatic colours come together. At the time it gave a much more coherent feel to what we were building narrative-wise, and continued feedback, especially on Open Studio night, maintained that feeling that what we had formulated as a group, and what Max had sold to the public with flyers and posters was very much the narrative we wanted.

I remember at the beginning of the project feeling as though the graphic design element was going to be very low priority and imagined that when we got to our inevitable crunch point that it might even be scrapped. This was a mindset that only changed as I started to realise how it would come together, and the important role that it would play. I felt that we may have benefitted from some more user testing of the logos and name to get a better sense of what was really showing what we were going for, and in future projects, I intend to put a bit more time into this type of information gathering when creating logos and aesthetics. In order to be able to get a message across, especially in the limited time we have in Open Studio, a lot of groundwork has to be done before you even open your mouth at your installation. The opening conversation is between the viewer and the work itself as they are stepping up. While we were not able to have this be the case with the work itself at Open Studio, we were able to achieve that somewhat with the posters Max had created that were in the foyer, especially since it featured Stuart’s “Ratman” character with black tape over his eyes.

The logo designed by myself and Max in the door to the room

The posters in the foyer designed and edited by Max

I needed to create a mechanism for dropping the key to a puzzle, and a book that would hold one of the hard drives and fall at a point in the installation.

The key mechanism was going to pose a series of problems, as we were brainstorming how to construct a box that it could fit into and look in place with our aesthetic. While we were discussing what the box could be made from, I couldn’t but think that it seemed excessive to create a whole box or to repurpose something professionally made. While it may have worked well within our aesthetic, I felt that it would take up much more time and require all sorts of resources that would be stretching myself and anyone else that was going to assist much further than need be. In an effort to circumvent this I looked around at what we had already accrued for testing. I found an old copy paper box that James had put together as a paper prototype that I suggested, however, it had large holes cut into it and hot glue all around it making it look horrible if it were to go in the installation. However, as chance would have it, James had brought in another copy paper box that we had been using for storage, which ended up being an excellent size and extremely convenient for holding the key mechanism as well as storing the Arduino that would go on the cabinet. It fit in well with being in the office space that we had created and ended up being a much more efficient way of putting the key mechanism in something that we hoped that players would not think to look in. The decision to not burn valuable time on creating something entirely, and instead to use resources readily available, ended up being fortunate for our time management. The testing that was required in order to get the key mechanism working chewed up a lot of time since it had to be precise and work consistently because of the role it played in the participants' experience. While it may have appeared that bit more professional to have a custom made or specially designed box for this part, I decided at the time that it was much more important to have functionality with what we had that could fit in.

The book was straight forward in hollowing it out with a craft knife, and while I was doing wiring and coding for the Arduino Max and Kelvin made the level that would hold the book in place before dropping it. The learning moment out of the book experience was in obtaining the book itself. Max had circulated notes and talked to the group for a few weeks about looking around for expendable books at all the group members’ homes, to no avail. We then decided to check out a book store and see if they had anything suitable for a cheap price. We went to a second-hand bookstore and asked the attendant If there was anything big enough to fit the hard drive, and not but a few minutes later she handed us a book that not only looked perfect, it was the right size, and since it was in a pile to be thrown out she gave it to us for free. While there was nothing ground-breaking or new to reflect on from this situation, I cannot help but mention it out of the sheer amazing convenience that we happened upon. One might think that this was the product of a computer program or simulation the way it occurred.

When deciding to use the hard drive we decided from the get-go to use them as physical keys rather than to actually have users plug them in and have the game read data from them. This was for a couple of main reasons. Technically, it would pose a much larger challenge both in terms of coding and construction. While we were prepared to put large amounts of effort into all aspects of this project, we felt as though this would consume time that could be better spent getting a wider breadth of physical elements for the user to interact with. We also felt as though the difference between the two may not be so apparent for users to warrant the time and effort, and may even distract from the philosophical element to a more technical display element.

So to create this I went about setting up a series of buttons on a plate at the back of the hard drive cage. Since we wanted all hard drives to be able to activate their effect in any slot, so as to avoid players becoming unstuck if they put a hard drive in a random slot, I set up a grid of buttons with rows pertaining to a particular hard drive.

A drawn diagram of the complicated layout of the buttons.

Early prototype button grid, the hard drives did not get as far as the buttons to be able to press them, and the height of the buttons was inconsistent because of using hot glue, which also did not hold very well.

My original plan of buttons fell through, however, when the hard drives would not press the buttons when they were too far away or would cause the plate to fall out, or stop the hard drives clicking in properly when they were too close. Circumventing this would mean spending much more time on building specific pieces, and with the time pressures, I was starting to feel overwhelmed. However, advice from Krishna and Zane Kelbrick helped me to realise a much better alternative. Instead of using tactile Arduino buttons I changed tactics and used tin foil attached to the hard drives to close a circuit, making the hard drive itself behave like a button. This was much more effective and could be much more customisable in easy and convenient ways. My main point of learning from this was listening to the advice of others and seeking external input before giving up or becoming overwhelmed. I often personally run into the issue of wanting to figure out how to do something without needing assistance from others, however, this experience really helped me to learn the importance of being able to reach out, especially when I am working in an area I may not be completely comfortable with yet. Zane was also able to point out that my inclusion of external pull-down resistors was viciously overcomplicating my wiring.