Post Mortem - Hook is the Hook (Development)

Note: This project is only half way through development. There are two phases: development and production. Development is the design and prototyping phase, while production is producing the game to launch. This post mortem is for the development half of the project.

This trimester we designed and built a prototype for Hook is the Hook. Overall, the process went well. We achieved most of our objectives and the multiple playtests helped form the game into what it is now. Yet there were aspects of the development that we lacked in, or which gave us problems. The following post mortem will go over these issues, as well as what I think we done right.

Code Structure

Going into a large project like this, structuring the code so that it is efficient, expansive and integratable is very important. Many of my projects in the past have had no pre-defined code structure, which ends up causing the code base to get confusing, un-efficient and not that expandable. This is what we were doing with the prototype. We went in, writing code on the spot for what we needed at the time. There was no predefined structure or plan for what we were going to do. Even with only around a dozen scripts and two months of development, the code started to feel a bit overwhelming. It was evident that if we continued with the process of just writing what we need as we go, then many problems will come our way. If not now, then definitely in the future.

This of course happened due to our approach. In terms of code, we had a rough idea of what we needed to complete for the prototype, yet never had it planned out. Since the game is very sandbox focused, we’re giving the player a bunch of toys that all need to interact with one another - so using events is necessary. At the time of making the prototype, I only ever added in events when the code required it. Most notably, the grappling hook script. At the moment there are seven events running the code. These were added in over the course of the trimester rather than at the beginning, causing the script to be inefficient and confusing to look at. Also with no overall codebase structure, we didn’t implement any inheritance based classes. Which in a game like this with various types of enemies, traps and other objects, is something we need.

I’m already working on part of a solution for this problem. A tech spec. Laying out all the events we will need and data classes for those events. Along with this; the classes we will be creating, how they interact with others and what they will be inheriting, etc. This is and will be in future weeks, done by writing documentation, utilising mind maps and even perhaps drawing diagrams to illustrate the overall structure and visualise it easier. In doing it this way, we will have a solid understanding of what needs to be made and can even produce estimates of time and weighted importance for different parts. It won't be us just going into an empty project, making a player controller, grapple script, etc as we need it and ignoring all future problems.

Iteration

One thing I believe we done quite well, was iterating upon our design to make it much better than it originally was. At first, we had the idea for a metroidvania-collectathon game, similar to that of Banjo-Kazooie and the like. Upon pitching it though, we found that the scope was too large and most importantly - the game had no hook. What made it different from the inspiration? Not much really, apart from some mechanical changes and the level design. This prompted us to find a new game, with a hook this time. We landed on the keywords of “grappling hook” and “action”. Bouncing ideas between the two of us, we finally came to an action based, sandbox grapple hook brawler. From what we could find, there wasn’t anything similar to it and most importantly, it had a hook - literally.

Prompting us to find this new game was of course, the search for a core mechanic. Our original idea of a metroidvania-collectathon grew from us wanting to recreate an existing game, mixed in with some other elements. This caused the game to not really have an identity of its own, and just be labelled as “Banjo-Kazooie but shit”, as evident from the first pitch. We weren’t designing a core mechanic, we were designing around a core mechanic. From there, we scrapped the idea and designed a new game. Hook is the Hook, grew from finding a core mechanic and building outwards from there. We had a mind map filled with different game mechanics and genres, connecting to bubbles detailing how they could be used. These then helped us pin down the idea of “grappling hook”. From there, we thought of how this could be implemented. Through Discord, we iterated upon it, how it can interact with the environment, enemies, other objects, etc. The core design of the game was what we worked on first, not what we wanted it to look like, or what we wanted it to be similar to. Really the only thing we compared it to in those early days, was Spiderman - and that was just the concept of swinging and moving smoothly through the air. We only started to think of a theme and structure once the idea of a grappling hook was an agreeable core mechanic between the two of us.

This way of finding a hook and building off from it is something that I will definitely be using in the future. First, creating a mind map and filling it with all different game mechanics and genres that come to mind. Different systems from other games like: gravity manipulation, deck building or reverse tower defense. These can then be combined, torn apart and compared to one another to create a mechanic that is both expandable and unique. Normally with a grappling hook mechanic in games, it’s used only for traversal. In Hook is the Hook, it’s used for both movement and combat. Really, it’s the player’s only form of interaction with the world.

Marketing

Marketing is an aspect of this trimester which we pretty much done none of. We do have a Twitter account, yet the handle is of our initial name for the game (Grapple Gladiator), not Hook is the Hook. Originally, we planned to use the Twitter account to post updates on what’s been added, changed and just interesting GIFs that we believe could build up an audience. As after all, we’re building the game around the idea of these “cool moments” to share with friends and the internet. Yet none of that happened. We also had ideas for a potential YouTube channel, to showcase video updates and trailers for the game. This too fell flat.

The primary reason why I believe the marketing failed, was due to the lack of a marketing plan. We knew what we wanted to do, yet never had the push or foundation for doing so. We created a Twitter account, yet what do we post? And when? We were working on the project and it never came to our minds to share what we were doing on there. Really, it just became a thing we ticked off as having without putting much effort to maintain. Also the fact that we were just prototyping the game and not really having a direct goal of releasing anytime soon. I remember myself always thinking “oh, we’ll start marketing next trimester when we’re doing this for real”. Yet the main purpose of the Twitter account was to in-fact show the process from nothing to release.

In both next trimester and for future projects, a marketing plan will need to be made. A layout for what accounts will be made and the purpose for them. What sort of information are we going to share? In what format? Every week? Twice a week? It will outline a specific schedule for releasing content which like a work calendar, will hopefully encourage us to do it more. We can anticipate when we’re going to be releasing a GIF of gameplay, so we have it ready for the day and can share it on all the platforms we need to. For next trimester, I intend to have the following social media platforms: a Twitter account, to share GIFs of new features and interesting things that happen in the game. A YouTube channel to post weekly or monthly dev logs which will go over changes and additions to the game. Finally, a Reddit account, which can share posts from the Twitter and YouTube accounts to various different game dev related subreddits. This is an optimistic goal, which hopefully a marketing plan will help encourage us to achieve.

Post Mortem - Alien Burger Maker

Overall, I believe Alien Burger Maker is a successful project. Although we didn’t entirely meet the criteria of an energetic experience, the final product is a finished – and with what time we had, a polished game. Yet that doesn’t mean the game is perfect. Both it and the process of creating it brought up a few problems that will be addressed in the post mortem.

Creating an Energetic Experience

This is not so much of an issue with the game, but an issue with the fact that we focused on this aspect far too late and far too in-frequently over the course of the project. The overall goal of the VR game was to create a short energetic experience to get people ready for their day. I believe that we accomplished this with the late changes we made, yet overall it could have been improved. Our bi-weekly interviews with Damian (CEO of Liminal, the clients for this project) gradually focused more on making it build up. Having it get more hectic, make the music tempo faster, have a big finale ending that can give the player that energetic boost. By the end of the project, we had quite a few elements that increased over the course of the game. The ingredients fell faster and more frequently, along with more customers coming to the window at a time and having more background activity. Yet it fell quite flat in other areas. The end scene was functional, yet very much not complete. There was no sound accompanying it and it felt quite sickening to watch in VR. Also we did not get around to making the music increase in tempo or change to more energetic tracks as the game went along, as we intended.

This happened because we were focusing on other aspects of the development. At the time, focusing on the energising elements felt more like polish to us. We had a large amount of bugs and refining of features to do, causing our focus to be more on the technical side than the design side. Although we did get around to adding in more “energetic” features and changes, this was later on in the project once the existing problems were fixed or at least held together. There were two main times in the project that we focused on the experience. A chunk at the start, before we had many technical problems, and a chunk at the end, when the problems were mostly fixed. The rising tempo in music is something that I believe would have been a great help in creating an energetic experience. Yet the process of doing something like that was foreign to us, and without an audio student, this feature was just left alone. We did have the idea of changing the track to something even more energetic every 1/3 of the game, yet that was just days before the release and we were still focusing on (what we thought were) more important matters.

So how could this problem be reduced? Well basically, just working on the experience as you go. We focused on it in chunks and put the technical problems ahead of the experience always. A much better solution would be to try and incorporate both at the same time. If there is a technical problem blocking you from working on a certain part of the experience, find another one that’s open. For example, if the ingredient tube is playing up, you can’t really test out the increasing speed and that. Yet the music would be open to work on. As a team of three, this could have even been less of a problem. Having one or two people work on the technical issues and another work solely on the experience. We all dipped our toes in working on the experience, yet really one person should have had the focus. They could have then attended most of their time in fine tuning and testing the game to make it even more energetic than it already was.

Good Work Ethic

Quite a contrary to what I talked about above, but let’s continue. I believe that the work ethic both my team and I had during the project was quite good. During class, we always knew what we had to do and never really slacked or procrastinated against working. Even when we had game breaking bugs and roadblocks, they were adamantly worked on until they were solved. The overall process of prototype, to placeholder to final build was a smooth and rewarding process.

This was probably due to the fact that we had a direct goal. The game as it is, is quite simple. Customer comes to the window, they give you order, you make the burger and give it to them. This game loop, although simple, can provide variety and interest for a player as there are many different approaches they can take. There was never really anything more complex apart from that. We had to create the systems, add a bit of progression to make the game end up somewhere and it was pretty much complete. This small, yet expansive goal, allowed us to work quickly to a fully functional game, then just move upwards from there. In many other previous projects, where we needed to add in levels, different characters, and other branches of design, the functional product is normally only finished much later on into the project. Here, we had a short goal, achieved it, then just refined it and added in polish. The inclusion of also having a set date for beta, made this process much more structured and streamlined. We knew we had to have all of our features done by a certain date, allowing us to just improve the game from there on. As working on a functional game is much more enjoyable and rewarding than working on one that barely works or is destined to fail.

In the future when attempting a game, the following things should be applied: A direct goal. Now not every game is going to be as basic in mechanics as Alien Burger Maker, yet working towards an achievable goal is. A game is not necessarily only functional (or ready to play) if all the systems are added in to some extent. As long as the core experience is achievable then i’d say it’s good for now. Removing or temporarily putting on hold aspects of a game that don’t directly affect the experience or core game loop would help to reveal the goal. Also having a set date for a beta would be good. This being the first project we’ve had with such a thing, it really helped us to scope the project and allow us to work smoothly towards the end goal. Then having those few weeks of just polish and bug fixing further made the process of working easier. We have a functional game – we can play it. Now, we’re just making it better than it already is. Really, it can only get better from there.

Frame Rate

By far the largest issue with the game both during development and now, is the frame rate. For a VR experience the frame rate should never really dip below 60 fps. Ours on the other never really reaches or goes above 60 fps. Early on in the project, the fps was fine. It only started to dip around half way through development, and we didn’t and still don’t really know why.

We tried many things to fix the problem. The code was optimised to remove any unnecessary loops or GetComponents that would slow down the game. We changed out the original voxel placeholder models (which were quite high in polys) to newer and smaller final ones. We tried disabling various different objects, then running the game to see if the fps went up. Overall, it didn’t really work. The best we got was a few fps increase, yet as a whole the problem still persisted. When I said we tried a whole bunch of different solutions, it wasn’t enough. We never went back to a previous build where there was no lag to see what was different. We just tried to use what we had at that current time to fix the issue.

If ever we were to make a VR game again, we’d approach it differently. Going into it, we were using the same approach as if we were making a desktop game. Optimisation was not a focus at all at the start and even quite a way through development, it was ignored. From the beginning we should have planned for something like this. Pooling objects that frequently spawn is one of them. The ingredient tube creates an object every 0.3 seconds, each with their own model, physics and script. If we pooled these objects when the game started, I believe that the fps problem would have been reduced, as that was a hunch we had, yet we never done anything about it. Also focusing on optimising the 3D models. Removing any unnecessary polys and scaling the models so that if they’re small or far way, they’re not as complex. Similar to the point of creating the energetic experience at the start of the post mortem; working on it throughout the project, rather than when it’s all of a sudden necessary is what should be done.

Post Mortem - Orbit Orb

Focusing on the aspects of monetisation and ethical use of monetisation, I believe that Orbit Orb succeeded in what it tried to achieve. The road to it though, was not all smooth, as will be explained about in the following post mortem.

Nailing Down the Idea

When assigned the task of making a mobile game that can utilise monetisation methods, it took us quite some time to finalise our idea. There were two games we pitched and designed before landing on Orbit Orb. The first was a tower defence game, which through pitching and further thought was deemed to large of a game to make. The amount of assets we would have needed to created, along with all the various interactions and levels, made us scrap that idea. After that, we pitched a gravity puzzle game. It had a simple layout, core mechanic and was ease to expand upon with new elements and levels. Yet it never really stuck. It had been done before and the idea just seemed – meh. Finally, we pitched Orbit Orb. A game with a unique mechanic of jumping between orbs, that we came up with on the day of pitching.

So why did we jump between all these different ideas? Because the hook was either uninteresting or there was really none at all. The tower defence game had no hook. We tried to come up with one after the initial pitch, yet it fell flat as we were trying to implement it into an already existing game, rather than building the game around the hook. With the gravity puzzle game, it lacked in originality. We thought the idea wasn’t used that much, yet upon researching, we found that it was indeed quite common. With that knowledge, we tried to make it more original, by adding in different elements that the player can interact with, yet none of that helped. The core mechanic stayed the same and we didn’t know how to change it. Only Orbit Orb had a unique hook. Jumping between orbs in an endless runner seemed original and making it reflex based allowed us to appeal to to a more specific market than the other games would.

So next time we make a game, the hook needs to be the core focus at the beginning. Orbit Orb, was only successful because we built of the idea that we talked about in class. We didn’t start with the theme, genre, or other mechanics – just the hook. What will the player be doing the most? What will you say to get people to play your game? This way of building up a game from the hook can be seen in one of my other projects. Our initial game was one we didn’t build up from a core mechanic, but from an existing genre with our ideas spliced into it. It didn’t work, and only when we created a hook and bounced off from it, a new, unique and fun game came into existence. So how can you come up with a hook? Well making a mind map is a great start. Listing out different genres, game elements and player interactions. These can be mixed together to create a unique game mechanic. Also doing research on games similar to the ones you’re making is good. We found even with the unique mechanic of Orbit Orb, there were similar games such as Sling Kong. So we tweaked the design to be different, in the end further defining the game as its own.

Scoping

One thing i’m glad we kept consistent, was the scoping. When we went though all the different designs and pitches of games, we landed on Orbit Orb around a month into the trimester. At that point, I just wanted to have a basic game that we can apply monetisation to, as we were quite behind. With this relatively small scope, it allowed us to finish the game right on time, with most of the monetisation features implemented. From there, it was just bug fixing and small tweaks both mechanically and visually, to further enhance the game.

This was done by having a relatively simple design goal: to make an infinite runner with a fun, yet simple mechanic. If we decided to go with one of the two previous game ideas, we would most certainly not have made the release date, or have made it with a butchered version of the game, vastly different or inferior to the original design. With Orbit Orb, we just needed to focus mainly on the core player mechanic and procedural generation to have the game fully functional. If we were making a tower defence game, we would need to make the towers, enemies, progression, levels, etc. We finished the core game quite early on, with a fairly playable version ready for the first playtest. All it included, was the ability for the player to jump between orbs and a very basic procedural generation. It was able to portray the game’s intended experience and feel very early on, with this most likely not being the case for our previous ideas.

Scoping is a very important part of game development and I will very much utilise the methods we used on this project for future ones. For a simple game like this, finding a core mechanic and sticking to it is the best option. With that, you’ll be able to prototype very early on and be able to playtest even with a primitive version of the game. Doing so with a more complex game, such as a tower defence, is much harder. With something like that, the game loop is held together by a lot of different mechanics and systems. Yet that doesn’t mean you can’t simplify it early on. Finding what makes your game interesting and what the core experience is can help with scoping your game and being able to prototype early and finish early. What mechanics do you need? What ones don’t you need? For an early playtest, just focusing on the mechanics that are necessary to be able to play the game at a very basic level should be your focus. If this can’t be done, then maybe scoping down your game is the best option. On one hand, scoping down can decrease the complexity of a game, on the other it can enhance the experience and potentially reveal a core mechanic that was otherwise unknown of not yet in existence.

Progression

In an infinite runner type game like Orbit Orb, progression is very important. It can increase interest for players and add more of a challenge so they come back for more to see how far they can get. In our game, this was something that was not a large focus, and only became one much later into development. We had ideas on how we wanted the game to progress, yet the end product was a much less subtle and basic version of that. About 2/3 of the way through development, we came up with the idea of splitting the game into chunks. About 300m each in length. These chunks would each change different aspects of generating orbs. How far they can be apart from each other, their layouts, frequency, etc. This would be a sudden change that the player could easily identify. Yet the final product was not this. It was much more simplified and not apparent to the player when they entered a new chunk.

This was due to the way we approached development. With the progression system early on, it was very lightly documented. Just the basics of how far orbs should spawn from each other and the technical side of things. With that, we could easily implement the basic progression system. Yet when we came up with the new one, it didn’t get documented at all. At that point, the game was mostly complete, so referring to the documentation felt unnecessary to us. Also on top of that, I don’t think we had a solid understanding on what the progression was. We talked about it, yet I think we each had our own idea of how it would be set up. This is a by product of not documenting it. No one had a 100% understanding of what was gong to be made, so it ended up being scrambled together as a sort of blob that kind of resembles the initial idea.

Solving this problem, would be done through documenting the system. Someone came up with it, yet someone else had to implement it. The lack of diagrams and detailed explanation caused the confusion and lack of enthusiasm to work on the system. Adding on to the fact that this is quite a complex system, that cannot easily be explained to someone through conversation. So to fix this, when the idea comes into mind, write it down. This can be done on paper by drawing pictures, labelling them, or starting to write down dot points. Then transferring it into the game design document, properly explaining all the aspects of the system and how to implement it. This would remove the confusion behind what does what and what’s involved.

Studio 1, Project 3 - Post Mortem

This is a post mortem for a project I worked on in a team, called The Gold Standard. Overall, the project went well. Our initial idea of the game and how it played out is fairly representative of the final product. Although, there were a few problems that occurred during the production.

Laying out the Levels

One of the problems I believe we had which occurred late in the production, was sitting down and documenting the layout of the levels. Us 3 games students each made many levels to reach the goal of 50. Our game was divided up into 5 stages, with each stage having 10 levels. I was given the first stage which introduced the mechanics of the game, while the other 2 team members had the other stages. This process of creating the levels happened during the last week of the project, due to systems of the game needing to be fixed beforehand. This rush of making levels caused them to be different in overall design and not really that well tested. We wanted to go for that strategic, edge of your seat experience for the player. Providing multiple possible routes, each having their own risk vs reward situation. In the end, the levels seemed bland. Each member of the team had their own way of which they laid out the levels and communication between each of us during this process was limited. We never had a document that we could refer to how the levels should play out. How many possible routes should there be? How linear or continuous should the levels be? We went out on a whim, producing levels that just looked kind of different from the previous one.

So how could this have all been avoided? Well the first thing I can think of, is a document. A level construction document was something that we started, but it just laid out which mechanics would be introduced when, not really that big of a help. The document would need to lay out: the flow of the level. How far into each level should the player come across a guard? Is it fair to have a guard see them in their starting position? In what way do rooms connect to each other? All these questions and even values should be discussed. Other things such as level time. How long should a level last? Min, max times? What is the maximum amount of time a player should be "inactive" from tapping on distractions? Most importantly, the document needs to tell the designers how they can make each level meet the desired experience that the game is trying to achieve. Communication is also something that needs to be involved. Talking between team members before, during and after a level's creation. Gaining feedback and making sure that the level meets the requirements for it to be a level. Playing each other's levels is also something that we didn't do, which we should have. In doing this, you can see how your 2 styles differ, and how you can make changes to closely seal the gap.

Source Tree Problems

We used Source Tree for the entirety of the project. It was working fine up until around half way through the project. A push or pull error led to one thing, then another, causing quite a bit of frustration and confusion for the team. The project ended up being accidentally deleted. To fix this, a new branch was made and after a bit, the project was back online, yet Source Tree was butchered in a way. Whenever we wanted to push or pull the project, we had to make sure that the correct branch was selected after making this local branch thing... it was pretty confusing. This took us a a bit of time to adjust to, yet there was something that we forgot totally. At the time the animators were pretty much done with their assets, except for a few small things. It wasn't until close to the end, when we realised that those few animators who were pushing changes, didn't push to the new branch. This was totally on us and we should have told them instantly. Luckily it didn't cause too many problems as the changes were very minor. This happened because as early game developers all we really need to know about Source Tree is pulling and pushing. We don't need to know the ins and outs of the program, so when a critical error occurs or something bad is about to happen, we're kind of in the dark. It also occurred because we never really had a schedule or talk about who will be working on what assets at what time. When multiple people are working on the same thing and they try to push or pull changes, it can cause problems. Many of these minor problems did occur almost on a weekly basis.

Getting around this problem would be done by management. Knowing who is doing what at what time. Having only one person working on one asset at one time allows for a clean push and pull to Source Tree. In the future when working in a team environment on Source Tree, we're going to be more clear about what we're working on. HacknPlan would be useful in this case. Making a task called "Working on ..." or "Implementing/improving ..." makes it clear what you're doing. Telling team members to also constrict what they change while working is great too. Going around messing with different prefabs and scripts when you don't know if you should is not a great thing to do. Making sure everyone just sticks to their task and test scene will hopefully prevent the issues that occurred with our Source Tree project.

Getting the Work Done

One thing that I believe went very well for our team, was getting the work we needed complete. Whenever there was a deadline for a certain amount of work to be done, both documentation and the actual game... most of the time it was good to go. We tested our game at every playtest, getting useful feedback to improve it upon. One of the big reasons I believe this happened, was due to laying out the tasks early on. At the start of every week and/or milestone, we laid out the tasks we needed to do for that week. This gave us an overall goal. Throughout the week then, seeing this large list of tasks encouraged us to work at it, rather than entering the tasks as we went. If that was the case, then I believe most of the work would have been done on Sunday night. Team meeting were also another big help. Every Tuesday and sometime during the rest of the week we tried to have a team meeting on Discord. In them, we would discuss what needed to be done for the week, who was to do it and to what standard we expected the work to be at by the end of the milestone. 

In the future, continuing on with this layout is certainly going to be good. Setting up the tasks day one of the first milestone sets that large objective ahead of the team. Seeing all the work that needs to be done, discourages trying to cram is all in a day before it's due. Team meetings are also obviously a good thing. Even though we had around 2 a week, I believe that we should have had more. In my mind team meetings create that "boost" of work. After one, you're encouraged to continue working on what you're doing , before that slowly drops down. Having a team meeting 3 times a week, one Tuesday, one Friday and one Sunday would evenly spread out that work flow.