Exteriors Development Blog- Tristan Atkinson
Week 1
We began the first week discussing ideas for games. The two prevalent ideas were…
-
A raunchy ‘Conker’s Bad Fur Day’-esque side scroller beat up up starring a detective bear
-
A story-based game metaphorically depicting the female experience
After some time to think, we took a vote on which idea we wanted to pursue in greater depth. A majority of us agreed that the first idea would give us difficulties due to our lack of clear and united vision for the idea, and the raunchy humour would likely come off as more childish than anything else- so by majority vote we decided to pursue the second idea.
‘Exteriors’ (our current name for the project) is about a Woman who is constantly cleaning the outside of her house. Periodically, vaguely-made-out figures will walk past and make demeaning comments about the state of her house’s exterior, and how “the inside must be just as filthy” (which is not the case- at the start of the game the inside is pristine). As time goes on and more of these comments are made the inside of the house will gradually become messier and messier, which the player can do nothing to mitigate.
The game ends when a figure instead asks about what’s inside the house and the otherwise greyscale colouring of the Game is filled with colour, and the inside of the house made pristine again.
The exterior is a metaphor initially conceptualised by our Female Project Lead about how Women are often judged purely based on their outward appearance.
After this, the Design Team began work creating the GDD and Audio and Art asset lists. Additionally, we decided to create a group ‘Miro’ board as we feel it helps us organise information in a visually pleasing and easy-to-navigate manner.
The Miro board involves information such as core mechanics with control schemes, schedules and tasks for each in-game day, and a listing of the mechanics needed for each of these tasks.
In hindsight, more effort should have been put into establishing Agile Frameworks into our development at this stage. As an Agile, iterative development process would have allowed us to test earlier and more frequently as well as being a safer and more practical software development structure. And while Agile techniques were used in development, an iterative process wasn’t taken until later on. This meant that we were rushing a lot nearer the end of development.
Furthermore, in retrospect I think we should have spent the first week coming up with ideas rather than settling on one straight away. Not only would this have given Designers a chance to have their first lecture and learn about MDA Theory going into the project, but it would have avoided many issues later down the line, such as the lack of meaningful gameplay Mechanics and Dynamics in the context of MDA theory.
Week 2
During week 2 I began to have some concerns about how the structure of development was shaping up- the work each team was doing, especially the design team, felt unorganised.
The Design Team had a Miro board that was shared with the whole development Team; but this board I feel like was taking up far too much time with people making it look nice and adding new notes / features to each mechanic. We needed a Kanban Board to help us properly organise and delegate tasks within an Agile framework. This would have streamlined the overall workflow of the Team and allowed anyone to see what was in progress / completed at any time to get a better idea of how development is shaping up.
Our goal for the first day of week 2 was to create a project backlog, but I feel like at least the one the design team made was far too vague and took us far too long.
I was worried that this project might go in a similar way to a Game Jam I had done the previous Summer where I was the Design Lead in a group of over 20 developers on a game called ‘The Rot’. The Rot was the first project I worked on in a large team over several weeks and the final result was disappointing to say the least.
This was in part due to a majority of the Development Team including myself’s lack of knowledge about Agile development frameworks. I wanted to do all I could to prevent Exteriors from going this way. I wanted to implement more Agile techniques such as a Trello Kanban board immediately, sooner rather than later.
To remedy these concerns, I got the design team to join a group call to discuss our development structure. I suggested that instead of the additive approach currently being taken, that we strip down our ideas into a very basic MVP (Minimum Viable Product) and more diligently adhere to a development cycle more in line with Agile Frameworks (Scrum, specifically) and take an iterative approach from here. I suggested that everyone should have a Sprint Meeting on Mondays and work on a new iteration build of the game each Monday-Friday and over the Friday / Saturday the Design team should get testers to play the game, hold a sprint review meeting with the whole team and discuss what to add in the next iteration, which would start the cycle anew on Monday.
This cycle resembles the Scrum agile framework’s sprints far more than the somewhat aimless additive processes that were being undertaken, which I feared would just lead to a lack of cohesive shared vision of the project and falling far behind schedule.
I am hoping this will make Week 3 far more productive than the previous one. Speaking to a couple of members of the Art and Audio teams, they said the MVP document the Design Team made during the group call gives them a useful and more tangible target within a deadline. Hopefully following this structure will help us have a relatively organised and successful development.
Week 3
Unfortunately, our MVP was not met by the deadline near the end of week 3. Following this, the plan for an iterative process wasn’t brought up by anyone else again which was a little infuriating. I believe that neglecting to firmly implement this iterative process now is what led to a lot of problems down the road. I am absolutely not free of blame- I should’ve voiced my concerts now and tried to sort the issue early. After our Sprint meeting the Project Lead, Design Team and Programmers came together to have a meeting to finally finalise the mechanics / tasks that we wanted to be present in the game to create a final GDD.
I attempted to suggest ways we can make the simple in-game tasks more interesting, suggesting we structure them more as microgames. There are multiple ways you can make a game with a single button. Using goals such as fast pressing, timed pressing / holding and rhythm to make simple but different micro games using only one button. However as we only have two programmers who didn’t feel confident implementing this much, we had to simplify the microgames immensely.
We ultimately decided, however over the Week, specific tasks were not delegated to all members of the Design team, which meant my Week 3 was relatively unproductive for many of us and work was dished out disproportionately, with few members doing lots of work and others doing little to none. This led to a lot of work being done by few people so peer review didn’t occur often enough. These communication issues sadly persisted through development which dampened our ability to collaborate on work.
This issue was addressed by our producer on the following Monday’s scrum meeting beginning week 4, however this unproductive week had put the Team a little behind schedule.
In retrospect I should have stepped up, taken more responsibility and asked directly if there was anything I could do to help, and been more open about my concerns earlier rather than later. This might have helped resolve the issue earlier and stopped us from falling behind schedule.
Week 4
In our Week 4 Sprint Meeting our Project Lead addressed the issue of Tasks not being delegated properly. However, even so, our Team has a disproportionate amount of Designers (5/12 people) so it was difficult for her to give each of us a meaningful amount of tasks individually, meaning many people needed to be paired up. Even so, this was a vast improvement on last week where 1 or 2 people were doing all the design work.
In Hindsight I should have stepped up to help some of the more understaffed teams now rather than later, which would have taken a lot of weight off of the artists back earlier rather than later.
Me and another Member of the Design Team worked together drafting up a potential Design for the GUI and Title Screen UI. We looked over this with the other Designers and made tweaks to the Design based on their feedback. We took into consideration how to make the menu UI convenient and quick to navigate as well as the GUI when making wireframe design iterations on paper. Since the player will be having a large number of tasks to list in the later days, we decided it would be a good idea for there to be an expandable-list in the GUI as well as the short list in the top right.
Week 5
During the sprint I was assigned the Task of implementing the Bedroom assets into the current game build. At this point, we had a build in Unity which had some of the essentials of the level implemented; mainly the house. I got to work on the interior, adding the bedroom assets. However, once again there were too many designers to have a meaningful amount of tasks each. These assets needed to be scaled, as when I imported the .fbx files from the artists’ google drive, the models were tiny in comparison to the rest of the level. Additionally, the Artists had sent me .mb (Maya Binary) files which I had to export as .fbx files from my own Maya application to add to the project. This was brought up at our Sprint review and from here our Artists exported their assets as .fbx files before uploading them.
Throughout development, I found that .fbx files exported from Maya were incredibly small when placed into Unity and ones from Blender were accordingly scaled. This meant that I had to manually scale the objects from the artists which wasn’t a big problem as doing so in Unity is incredibly easy.
Near the end of this week I began revising my knowledge of Blender in preparation for next week where I planned to learn 3D modelling more in depth as I noticed our art team was already becoming over-encumbered by this point. And without much else in terms of tasks I wanted to make myself useful.
Reading Week
This Sprint meeting was done over a voice call, and was far briefer than the others. I was assigned the task of making a couple of assets to help our overencumbered artists, I created a Bush model in Blender, as I was going to be importing the file as a .fbx whether I used Blender or Maya, and Blender is the software I am most familiar with. Since the artstyle of the game is low-poly, I was able to create assets up to standard. In hindsight I think both myself and the art team didn’t lean hard enough into the low poly stylistically. We were meant to be making a game with “PS Style” low-poly graphics but our assets were just low-detail- no other techniques to give it a PS1 Game style was undertaken so I don’t think the game is that visually striking. I enjoyed making models on Blender so from here I began to practise and learn the software in more depth in my free time.
I spent much of my time this week researching Blender, as I find the program far more intuitive than Maya, and my assets when implemented into Unity as .fbx files were scaled appropriately. Furthermore, I already had a basic understanding of the program as I had used it before. As I was already having to help the artists create some assets and we had too many cooks in the Design Team, I thought this would be a good investment of my week to help in future weeks.
Week 6
Similarly to last week, I spent week 6 helping our art team meet the demand for art assets. Our Sprint meeting was brief and mainly involved a few of us expressing that we hadn’t been given much work to do. Thankfully, I was given far more assets to complete than over reading week, so I got far more work done even if it wasn’t design work.
At this point in the project, it really sunk in that the Gameplay of Exteriors is shaping up to be quite shallow.
Looking at the Game under MDA theory, it has little to no dynamics between the mechanics- however, aesthetically the game is relatively pleasing. However, without strong mechanics and dynamics, the game hinges on its story. Upon reading the script written by our Project Lead (admittedly this should have been a task handed by a Designer(s), which is a consequence of the project being a passion project of the project lead) we noticed it had strayed from many of the previous design decisions that had been discussed.
The game’s shallow design is in part due to the project being a passion project of the Project Lead, and the idea gave the designers not a huge amount to work with in terms of mechanics and dynamics. I suggested making each task an interesting and unique microgame ala Warioware / Mario Party minigames to make them more fun- but with only two programmers this wasn’t very plausible for each task, and each one is simple. Luckily, I think if we fix the issues with the script and implement the story well that will be enough to make the game interesting as a sort of “playable art piece” / social commentary.
The script contained extensive dialogue from a Narrator (something the designers had agreed we would have little of if any), and the comments made by NPCs were directed towards the character rather than her house (disregarding the entire metaphor the game was built around). Many such comments were incredibly uncomfortable to read and could potentially be harmful to people with severe Sexual Harassment / Abuse related trauma.
Talking with the other Designers about this, we decided to talk to the Team about it at the following Sprint meeting.
Week 7
Collectively, a large portion of the team also decided on the day of our scrum meeting that we would confront our project lead about the script for the game (that she had written). We agreed that the metaphor of the house and garden had been lost and the message was far too on the nose. Additionally, the Sexual assault and harrassment themes made unanimously everyone who read it incredibly uncomfortable, which means that it could prove incredibly triggering to anyone with related trauma playing the game.
Following this, me and the project lead got on a call together to rework the script in line with the advice we had given. I feel that after this the script and story improved- we tweaked the NPC dialogue to be more relevant to the House and Tasks and trimmed down the Narrator to an inner monologue that would offer essential information infrequently.
The Story of Exteriors has some emergent elements, as the player is put in the shoes of a (mostly) silent protagonist who they know little about, and its strength lies in not showing its hand to the player, getting them to interpret the story for themself. The previous draft of the script stripped away the subtlety of this concept and the core strength of this type of non-conventional story, as the Project Lead seems wary to put trust in the player to figure things out themselves. However, the story absolutely won’t work well and will feel too on-the-nose if the player is directly told the connotations of its metaphors.
I spent the rest of the week helping the art team unwrap some of their models and create UV mappings for them. Our two artists are quite inexperienced with 3D modelling software (less so than some of the Designers) so we spent a lot of time helping them out.
Week 8
We started this week with a premature post-mortem of our development. We did this now as we had recently been experiencing various issues with development that we felt we wanted to get off our chests sooner rather than later to make the final few weeks smoother, as we definitely had some underlying issues with our development. Doing an early post-mortem helped us fix them for the final few sprints. We reflected on how many of us had been too timid to voice concerns about problems with the game (e.g. the script) which I admit I was guilty of. One thing this project has taught me is that I need to voice my concerns more readily and remember that the members of my Team are more than capable of receiving criticism about their work / decisions; and any reluctance to do so would poorly impact the project. This project has taught us just how much of a paramount importance Openness and Honesty is in Scrum-Agile development.
More openness would have helped us with many of our previous hurdles. If I had the openness to voice my frustration at the disregard for an Agile iterative approach our development could have followed it more and gone smoother. If we had voiced our concerns over the script sooner then we would have resolved it quicker and with less agitation from the Producer. If I had voiced my concerns and asked for work to do more when there was nothing I could have helped the other teams run more smoothly (especially art in the early weeks).
I spent the Monday beginning this Week writing up drafts for letters the player would be able to find in game, as well as finding potential free fonts for these letters. These letters consisted of a formal letter placing importance on a Vase that would be important to the game’s narrative; and an informal letter foreshadowing the arrival of a Character on the final day of the Game. The goal of these letters is to add a little more structure in the form of foreshadowing to the story. As without them the two main story elements would likely feel very out of nowhere.
Week 9
This week started without a Sprint meeting and task assignment was relatively sporadic. I feel like this approach which carried into later Weeks made our last few sprints needlessly stressful (they would have been even without this). If we had done Sprint meetings these weeks, we could have laid out specific requirements for everybody in the team in a more calm and organised manner.
This week I took the grass tuft models made by another Designer and added some subtle animation to it to add the illusion of wind. This makes the garden look less static and more alive without the need for simulating wind physics which we didn’t have time for.
The Project Lead tasked me and two other designers with building the in-game days in Unity. However- only one of us could work on the project at once to avoid problems on Github.
However, over the week we received little to no communication from the designer and programmer primarily working on this, so me and another designer were left without much to do which dampened our ability to contribute. I spent this week honing my skills on Blender further as I had been doing whenever I had no work to do previously in the project to expand my skills as a designer.
Looking back at our project with my new art knowledge, both mine and a lot of the other designers’ and artists’ assets had really missed the mark for the ‘low poly PS1/2 esque’ art style. For some of my assets which used cylindrical shapes I should have used beveling on a cuboid so it fit the style better. My mistakes here weren’t as bad as some others’ assets- for example in the house there are some small potted plants which are FAR too detailed to be considered low-poly OR PS1/2-esque, as well as the window cleaner which has a similar issue.
Furthermore, our UV Maps should have used more low-res images to emulate the style of graphics we wanted to. For example; the Blender plugin, Pribambase, could have been utilised to easily create pixel-art UV maps to give it that crunchy look for a more distinct artstyle more in line with what we originally envisioned.
As one of the artists heavily struggled to model and rig the NPC, I decided to turn my focus onto learning character modelling and animating in my free time. I had learned how to rig and animate in Blender in previous weeks so I focussed on low-poly character modelling by researching Devlogs on youtube and practising in Blender with some of my own original characters.
Something I learned doing lots of art on this project is that there is far more than I thought that goes into creating a stylised look for a game. My work was incredibly basic and not much had been done to emulate the desired style- that goes for all of us who did art. We should have done research beforehand into the types of games that use this style and how it is done so we could have more professionally and accurately emulated it.
Week 10
This week started without a Sprint meeting again. Even more so than last week, our development resembled more of a mad scramble to fix bugs and get the game to a working standard rather than an Agile process. Carrying out Sprint meetings and other Agile protocols would have allowed our Project Lead to more easily, calmly and clearly delegate tasks and made this week less stressful than it needed to be.
Unfortunately, in this last week most of what needed doing was bug fixing and implementation in the build. Since I am more experienced with C++ than C# and more experienced in Unreal Engine than Unity; I was not much help and the programmers didn’t have the time to teach me their implementation process in depth, so I was not able to help much this week which was frustrating.
It cemented that I need to build a more solid understanding of the Unity engine in the future, as it is a popular engine used by indie developers that I must familiarise myself with as well as Unreal Engine to be a useful asset in the development process of a wider variety of Indie Games.
In hindsight, I should’ve dedicated more time to learning Unity and C# rather than Blender. Although I was able to help out our overencumbered art team and learn valuable skills I can use and build upon in future projects, spending more time familiarising myself with Unity would have allowed me to help out in this week and Week 9 where it was really needed. I neglected this as I had simultaneously been learning how to develop with Unreal Engine 5 for my solo Design project- however over the following months I now understand I must dedicate time to being at least somewhat proficient in both.
Razer Store Launch Party and Final Retrospective
Overall, I can’t say I'm particularly proud of the Game’s mechanical Design. The few microgames we managed to implement were incredibly simplistic and quite similar. I had suggested in an early week of development, ways we could diversify our microgames by selecting different ways simple one-button games can be made- including timed holding, rapid pressing, rhythmic pressing etc.
In terms of Narrative Design, I think the Game has a strong message behind it, and with revisions to the Project Lead’s script (which had removed the metaphor of the house which the game was built around); as well as added foreshadowing to events in the form of intractable letters around the house, I think the delivery of it is pretty solid- and in the end considering our time constraints and limited experience I am proud of the final product.
Our Project Lead, using both her connections to Razer and BAFTA, managed to organize a Beta Launch party at the London Razer Store with Games BAFTA members present to play and give feedback. It was a great day and I'm very grateful for the work everyone on the team has put in to make this possible.