Building FL0 was definitely a journey. There was a lot of ups and downs in both the development and my mental state. The aim was to build a game that let SAE audio students practice their knowledge of audio signal flow. The key word here was practice, we weren’t trying to teach the players a concept, just letting them practice a concept they should already know. Doing this was going to take a lot of work. Especially considering the fact that we did not know what signal flow was. At all. The first step was learning for ourselves, since we couldn’t make a game about a concept we don’t at least try to understand. We spent the first week trying to learn what signal flow was from both the internet but also mostly our stakeholder. We also spent this time trying to see what other people had made to fill this need before us, if they have at all. We didn’t find much in the way of existing games, but we did find a few things that simulated some similar equipment. Some synthesiser simulators that contain very similar signal flow concepts within them. But one thing that these lacked was diversity, they focussed too much on a singular model and not enough on the concept of signal flow, this is what pointed us in the direction of abstracting the game to focus on the concept. To do this, we decided to look more into games that focused on connection puzzles and line based games such as mini metro or lyne.
So, while we were trying to understand what signal flow is, we were also putting together possible game design ideas. We did this using paper plans, starting out very rough with just basic concepts. We had ideas that were very console specific earlier on, this added to our push towards abstracting the console functions to focus on the idea of signal flow. With that very much settled on, we started looking at the ore abstract things, like mini metro, and how we could take inspiration from them. This started us down the path towards our final design vision. With this decided, we started fully fleshing out how this idea would work. With each step and interaction drawn out on paper.
one piece of our paper plan
This process really helped us flesh out the functions of the game before we’d even written anything into our GDD. Speaking of GDD’s, that’s exactly what we wrote after we had made the final paper plan. This was a much easier and quicker process since we had figured out so much about the game before we had gotten to this point. This is definitely something I’d like to repeat in future projects, just to help with the GDD writing process, and to reduce the possibility that a team misses a piece of the design. You can read more of my thoughts about paper plans HERE
Once the GDD was made, we had a week to prototype the design. This process came with it’s own struggles, and there were quite a few. The plan for this was to divide the tasks that would be needed for the construction and the build them piece by piece. This was the plan, but it didn’t quite go according. This was mostly due to the varied coding strength of our team and it was also heavily affected by the interconnectedness of the project. Almost every script in the game needed to be able to closely communicate with the others. This was just the nature of the game because of how varied and open signal flow is. These issues combined into a lot of stress for me and also resulted in one person doing most of the complex scripting. This, combined with pressures from my other class, resulted in my first metal break of the trimester. This is definitely something I want to avoid next time. The prototype ended up alright, it was pretty touchy and had some glitches, but it worked the way it needed to. But still, there is a lot of things about this process that I want to avoid next time. One key thing I can do to achieve this is to ask for help more often and sooner. This would be the biggest help, but it also would help to have more plans about our approach to the building and have some better strength in our collecting scripting ability. I’ve written more about my experience scripting HERE and HERE
Once we had a prototype built, in the most part, we needed to introduce our programmers at last. We did this by showing them our prototype first and then letting them look over our GDD. There was some issue with our prototype still, so showing them this wasn’t the easiest. But we did manage to show them most of our concepts, but I don’t feel like they took so well. They then left us and went to go read over our GDD. This at first appeared to go well, and we asked them how it went afterwards and we were told that they felt confident in their understanding of our game. I feel like we should have spent some more time trying to learn what they understood, because much later in the development we discovered that they didn’t know that some of the document even existed. This significantly delayed the development of the project and just added to the stress that I felt during the entire project. This also lessened our confidence in our GDD, since we weren’t certain if what we had in there was enough to describe to the programmers clearly. We could have avoided this by talking more with them and structuring our questions better, but that could have also ended up offending the programmers if our questions came off to aggressive or condescending. It’s too hard to know what would have been for this project, but what we had wasn’t fun to go through, so I’d like to do it a little more differently next time.
Now that the programmers were in and were building an alpha, it was time to continue design work. This meant it was time to design levels and audio and art specifics. The levels were initially designed by Bailey, while I worked with Kira and Izzy to create the audio and art requirements. Once Bailey had come up with the initial challenges we would have for each level, He and I worked together to test these ideas with possible layouts and trying to find the possible issues with them. We did this using a paper system that I had developed to try and teach the programmers about how our game objects needed to interact with each other. I called them flominos (READ ABOUT THEM HEREREAD ABOUT THEM HERE) They were a great tool to test each level, since they could act as each node that was needed in the level, and we could lay them down on a whiteboard and use a marker to “play” the level. This worked really well and it doubled for testing the flominos as well as the levels and I was able to improve upon the flominos greatly in the process. As we were doing this, we discovered that some elements of our design were not quite right, and we updated our GDD as needed. For example, the patchbay node in our design was much too complicated for what we needed and so we redesigned it to better suit. This process was really valuable in the development of the project, it is definitely something I’d like to recreate this in future projects. This, however, may prove difficult, since not every project requires design tools to be developed and not every design tool presents itself to you. But if I can keep my eyes open for more opporunities to create design tools, I can be closer to recreating this experience in future projects. This would be much easier to do when it comes to larger projects rather than smaller ones, since larger project warrant design tools and validate the time that is spent in them.
It was at this point in the project that I became stressed again. This was mostly because I felt like we were not going to meet the deadline. My fear of failure blew this out for me and I got very caught up in my own head. Clearly this is something I’d like to avoid in the future. I could do that by being less afraid of failure, but that is very much an easier said than done situation. Like telling a person with anxiety to just calm down. It’s not that simple. So instead I could avoid it by talking more and being more open about how I feel in these times of pressure. If I talk more about how I feel I can let myself be more aware of how well it really is going and I can know that I’m not alone in the situations I am in. I also discovered that our project only needed to be a proof of concept and a prototype when we were handing over the project. I didn’t know this before hand and I feel it would have helped me greatly to be less stressed. I feel like this was something that was stated much earlier in the project, like in the initial meetings or something around that time. But I definitely didn’t remember it. So it would have been much more helpful to remember this or find it out much earlier in the project, letting me have a much more level head throughout the entire project.
At this point, we had reached the end of the project. But because of all of these issues that we had encountered, there was something we had missed. Testing, and more specifically testing with metrics. You can read HERE about how we had planned to test as a team when considering stages and advancing our testing groups little by little. But what we hadn’t considered was how we could apply metrics to that, which to be fair was a low priority in our forest of problems. So what should we have put metrics on, had we done testing. Well, one thing that could be helpful for us is to know whether or not our icons make sense or at least can be remembered. So one thing to check is how many failed connections are made in each attempt and how often the game is paused to check the legend. This would let us know if we need to make the icons clearer or if our legend is confusing. It can also point towards possible level layout issues. We can check the number of disconnections that the player makes per level to find out if our set objectives for each level are too confusing. This would also help with knowing whether or not the level layouts or too misleading. Finally, knowing how long the player spends in each level can also tell us multitudes about how well the game conveys a goal and how simple/difficult it is to obtain.
But hey, in the end. We made it. Our stakeholder was satisfied with our result and it didn’t end as bad as I expected it to. They are hoping to take the project further and hope to take it forward with our team. But I’m not certain that that’s what I want. I didn’t enjoy the experience throughout this trimester and at this current point, I don’t want to continue working on the game. I just want to take a break for a bit, make some things that I actually want to make. Maybe I’ll find that I do want to continue it afterwards, maybe I won’t. I’m just thankful that I don’t have to decide now.