I have an idea!

So over the past few weeks I have been planning to take my Night spirits game and turn it into a game with more progression and direction rather than just experiencing a space. I want to take a lot of it’s mechanics and combine them with some things that I have used before to create a new experience. But I have some concerns about how this may turn out because of the underlining meaning that I want to put into the game. I want to try and portray the experience and fear that is being closeted. But before I get into that, first I’ll talk about what I plan, then I’ll get into why I am concerned.


In the game the player has a camera  (or something that can convey an alternative perspective) and as they explore a space, they find graffiti or some form of images that represent doorways/viewports) these look just like walls from the player perspective, but through the camera the player can see into the window/door. Within these windows and doors are different “scary” entities. Things like eyes or hands, or teeth. The world the player is walking around is very similar to my night spirits game. It isn’t the most pleasant place to be in, but it is mostly just uncomfortable to be in, and doesn’t portray any true danger. The spaces inside these invisible doors, however, are meant to be sources of fear and represent the fear created from hearing bad stories of others coming out and the stories that the mind tells you when thinking about coming out and how the possible repercussions could affect you, running through the hypotheticals and spiraling out of control. The reason that you can only see them through the camera is because these stories, both hypothetical and true, are never what is really experienced by the person in the closet. So the player is never experiencing these entities in person, the only ever see them through another perspective.


I want the game to start in a field with a small piece of building on the edge of the vision. There would be trees around them, but the only interesting thing is the broken piece of building. This would start the player interest, but may not be enough to encourage them to walk towards it. The thing to encourage the player to move would be a combination of the sounds and a pair of eyes that appear in the distance. Similar to the way that the “badman” in night spirits worked, but without a visible body and it would linger for longer. I also want to have more of these eyes be visible if the player is looking through the camera. These things would give the player a feeling of discomfort, and would then encourage them to move forward and to progress throughout the game. This feeling of discomfort would continue throughout the whole game and would be a constant push for the player to move. Another key point that requires some player choice is whether or not to look at the drawings they find on the wall with the camera. I would encourage this by giving the camera more vision and making a few more things visible through the camera only, like the extra eyes in the dark.


I feel like this could be a problem because the horror genre is very easy to use to demonise a people or experience, and I really don’t want to do that. I want this to be a representation of an experience that is shared by many people, I don’t want it to be a game that puts people who have had this experience or the people around them in a bad light. One step that I have taken to avoid this possible end is by abstracting the message extensively. I did this by making it only a symbolic representation of this experience rather than a direct recreation of the experience. I have also positioned the player in the closeted person’s perspective, making the affected person the player helps with sympathising with them and combined with the symbolic abstracting it means the only person represented is the player.


Playing with the genre of horror in general can often lead to demonising something, because once you portray something as an enemy or make it threatening to the player, the idea is seeded. For example, with the game Outlast, it is set in a mental asylum that has been shut down. But because the enemies within it are portrayed as mentally ill and the whole asylum is portrayed like an inescapable trap, it suddenly acts as a deterrent for anyone who might need help or may need to interact with a mental asylum in the future. If I portray lgbt people or their experiences in the wrong light, I can very easily turn this game that is trying to help people sympathise with them into a game that makes them more afraid. By creating this game to show a problem that exist in the world, I can very easily add to it. So I need to tread carefully and be sure that every decision I make isn’t going to turn into problem after release.


There are still things that could cause problems for me, since it is still a horror-esque game with an lgbt+ inspiration. But I hope that I have made enough adjustments to avoid these.


Fl0 postmortem

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.


Image result for mini metro

Mini Metro

Image result for 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.

Testing, or the lack thereof

One thing that is important when working on a project is to insure that it is tested, both regularly and by a wide variety of people. One thing we were not able to do on this past project was just that, which of course was not good. We did however, have plans for our testing, what we lacked was a functioning build to test.


Our initial plan for testing was to take portions of our builds that were functioning at different stages as we went and test with them. For example, we wanted to have a testing session with our initial functions when they would have just been implemented. This version would have had no proper levels and would only be testing the functions to assure that we were heading in the right direction. The issue with getting this was that. At the point where we would have had this, we didn’t have the functions we needed, even in their simplest form. So it wasn’t possible to test. This issue was a recurring theme throughout our entire design process. We also wanted to be able to step up the level of the people we were testing with by taking the different versions to different groups. This would have started with our audio contact and then ended with students either in the target level or just above it. But because we never had a playable version until very close to the end, we weren’t able to do the testing we wanted to do.


However, I guess there is a silver lining to this, we were able to do one bit of testing. With my “signal flominos” we were able to test our levels and hash out some of their issues and win states details. This was so helpful considering our game wasn’t functional enough to test these things as early as we need. This also doubled as a time for me to test my flominos, resulting in many fixes. Bettering both the flominos and the levels. So our levels were mostly functioning when we reached the end. I would have liked to have done more testing on the functions and interactions of the game earlier on, but that would have put a much larger pressure on our team, so it’ll have to be something for next time.

GDD do’s and don’ts

So, now we’re basically at the end of this project, it’s time to look back at what exactly happened (and boy, was it a lot). But for this post, I’ll just be focussing on the game design document and how we did or didn’t mess up.


First up, what did we do right? We made the document as a team effort and it went quite well, it was made quickly and it gave us plenty of time to revise and reread. This was not particularly impressive since we would never have made it any further had we not made it. However, because we continued to update this document when we discovered things were missing, our practices were significantly improved. This happened throughout most of the trimester and it made our document pretty accurate in the end.

But what did we do wrong? Well, while we did make a decent game design document, one major thing we missed was a change log. This resulted in a few problems, but was mainly caused by our reliance on the google change log. One issue this resulted in was some members of our team and most members of the programmer team didn’t know what was changed and what the document did and didn’t have in it. The lack of a change log wasn’t the only thing that caused people’s confusion. We also didn’t directly inform our programmer team about what was updated and when, so they weren’t fully aware of what was happening after the updates. But my understanding of their understanding was vague since it was mostly described through our programmer liaison, which didn’t help.


If we had made a change log we would have been more aware of our updates ourselves and so would all be aware of what was in the document at each point in it’s progression. If we were more aware of our project we would have also been able to know where the programmer’s understanding was better than we did and would have also been able to inform them of the updates as they came, since they would have been more documented. But all we can do now is learn from these mistakes and try and improve the process next time.


What on earth are Signal Flominos?

We needed to explain to the programmers how our connection system worked. Because it’s super specific and also very flexible. So, while wrestling with this and trying to find the best way to efficiently demonstrate it for the programmers, Adrian Forest pointed us towards Kate Compton’s Generominos. The Generonimos are used for designing and teaching the flow of data as it is transformed in a generative system. It uses symbols and small portions of text to describe each point that data can be transformed from one type to another. These are positioned on the cards so that the modules inputs are on the top and the outputs are on the bottom. So many pieces of this systems design can be transferred into our needs and we would be foolish to not be inspired by the Generonimos when trying to explain our system design to our programmers. Suitably naming them, Signal Flominos, a name that stuck super glue. 

Cate Kompton’s Generonimos

Since the Generonimos were describing a flow of data as it is transformed, we could use the idea and method to describe the flow of a signal as it is transformed and altered through the modules. The Generonimos use symbols to represent the specific connections that can be made, so I used different shapes to demonstrate what modules could connect to what. This was a solution to the initial problem of trying to explain the connections to the programmers, but we also realised that these cards could be used for much more than that. We started using them to prototype our levels by using a whiteboard and some markers and it became clear that these could also be used as a teaching tool with some refinement. After realising the new uses, I suddenly had more reason to continue refining the cards, and so I did.


Our Flominos

I spent some of my time after that working on refining the cards. I ran some of the earlier versions by our audio contact, who informed me of some of the big mistakes I had made in the ordering of certain pieces and how the connections worked. I also tried to streamline the sorting process by making certain elements that would need to be found quickly a different shape. This resulted in 4, 6, and 8 sided cards for different purposes. The next step of the improvement is to ask a graphic designer to come in and give some advice and work on some symbols for the cards to better describe the goal, instead of just having google drawings. After this fourth version that I have just finished creating, I will almost definitely need to make even more adjustments. But for now I can only wait until I’ve got them printed and laminated to start testing.

I hate anxiety

So, about a week and a half ago, I made the decision to defer one of my classes. That is not a small decision to make, at least for me. I had been dealing with a large amount of stress for the previous month or so that fluctuated in it’s intensity. It regularly hit it’s peak on a Monday night/ Tuesday morning, which I regularly got little sleep on and was faced with large amounts of work for the next day. When it came time for this, I often was left with little to no contact with team members for help or had found that the things that had been completed needed to be reworked or adjusted. When this happened, I was often overwhelmed with the weight of work that was left for me to do. This then carried over to the next day, where I would often need to do a presentation for my team. This shouldn’t have been left for me alone, but it often was due to poor communication with my team and me deciding to take on the weight instead of ask for help. This happened on loop for about 4 weeks, steadily increasing in weight, peaking on Tuesday morning. After those weeks, I couldn’t do it anymore.


The monday night of week 6 was when I finally reached out for help from someone. I sent an email to my lecturer for the class that was causing my the most panic. This was the best step that I could have made to help me in this situation. I went into uni the next day not knowing how much that email was going to help me. Upon arriving at uni, it didn’t take long before I was taken aside and spoken to by one of my lecturers about how to fix this stress. This was when I realised why those people talk about how important it is to reach out when you’re struggling. I’d heard so many stories from people who talk about how it’s so important to talk to someone and how you should reach out if you’re struggling, but boy did I underestimate how much I’d need that. After talking to the lecturers about how I was doing, I came to the decision to defer my final project preparation class.


This was so relieving for me, I could finally breath again. It took some time to fully understand how much I was stressing over it. There were many points that my mind jumped back to thinking about the workload that I had and I had to take a step back and remind myself that I didn’t have to do it anymore. It’s a strange feeling, a moment of panic so close to a moment of relief. I do not want to go back. So in an attempt to avoid ever experiencing that again, I need to remember to take a step back regularly to examine how I’m doing and to see how well I’m coping. I need to make sure that I’m still connecting with my friends and enjoying my life, because I know that if I don’t, I’ll get caught up quickly in work.


So now that I’m doing less work, there’s only really one thing I’m concerned about. That is that after having taken a step back from work, I’m concerned that I’ve stepped too far back and might be doing too little work now. I hope that this is not the case, and that it is just my brain trying to find something new to worry about. But at the moment, I feel that I should pick up my game a little bit. I need to consider how well I’m communicating with my team and how well they are doing their share of the work. Because while I need to do my parts, I need to know that I’m not doing someone else’s as well.

More programming.

So, due to difficulties outside of our teams control, not all the programming tasks that were assigned were completed. So we needed to take a step back and reassign the programming tasks so that the prototype could be ready for the client meeting, since it was too late for presenting to the programmers. But we also needed to move on with the other tasks that needed to be done now, since we were running behind schedule. To take care of this, I took on the task of finishing the programming tasks allowing the rest of the team to work together to look after the programmers and adjusting the holes in our programming.


So. Programming. The things that Still needed to be done was creating all of the patchbay functionality, and integrating the potentiometer. To start this, i took what had been done with the potentiometer and pulled it appart. The parts that had been made were all focussed on world space, so I needed to take it and then integrate it into the ui, where the rest of the game had been made. After I was able to rotate a UI object like the previously made piece could, I needed to be able to do something with that rotation. So I put a limiter on the flow of the shapes through the lines, so that when the object was receiving, if it had a potentiometer, the potentiometer needed to be turned up for it to flow. There was a few issues with getting the rotational value out of the object because of the way unity handles quaternions. This resulted in only half of the potentiometer working. The other half resulted in a negative rotation number.


The next thing that I needed to create had no work towards it. The patchbay. To start this, I had to first create a method of opening the patchbay. I decided to make it open when you double click the node. This is something that we hadn’t planned, and so after I was done creating the patchbay, I went and wrote it into the documentation, along with a few other adjustments. Within the patchbay, I made three new types of nodes, outputs, inputs, and internal patchbay nodes(which I named inouts). These needed to have special connections made for them to suit the situations they can be used in. Once the patch bay could appear and disappear while keeping its connections, I needed to let the patchbay accept inputs. When it was able to accept inputs, they needed to be assigned to the outputs within the patchbay. I did this with a for loop with the signal number arrays and an array of outputs. Next I needed to create checks on whether or not there was a signal reaching the end, and allow the signals to then be taken out of the patchbay when it is connected. I didn’t create any more functionality of the patchbay, and after making it and presenting it to the client, we did rework our approach to the patchbay, but any more functions would have been unnecessary for the level of detail we needed and the time that we had to produce these results. It wasn’t fun having to do work that other members of my team were meant to do, but at least it was work that I knew I could do. We as a team will need to put some time aside to figure out how we’re going to avoid this happening again.

I did some coding. What a mess.

So, we had to make a prototype for our game, before we gave it to our programmers. This was… fun. To start, we divided the tasks between us. My first main task was to get the connections working. I wasn’t entirely sure where to start this. So i began with being able to draw the lines with my mouse. Starting with a standard unity UI button, I created a system that would spawn a bar shaped button. I then made a system that would position it so that it was pointed towards the mouse cursor and would its width would be scaled to reach it. One issue I found with this was that the scale for the width will always be the same, but the mouse’s distance from the button will depend on the screen resolution. This was something that I didn’t have time to fix and so I left it to only work at one resolution, but created a scaling variable that lets you adjust it to suit the resolution. Once i could draw the lines, I created a thing to let you drag the lines after they were created, and also made systems to allow the lines to connect to new points. When this was done, I created systems to remove the lines if they weren’t connected to anything.


Now things were connected, I needed to make our shapes flow down the lines. To do this, since the lines were straight, I just made shapes spawn at the lines origin and made them move towards the end. However, these needed to only be sent if the origin is receiving shapes. To do this, the shapes needed to send information to the connection points, and the connection points needed to send information to the lines, which were spawning the shapes. So the shapes were flowing. But it was all one colour, we couldn’t use different signals. Now here’s where it gets messy. I started by numbering the signals, this was mostly simple, since it was just a number that could be passed between the points when they were connected, Getting them to reset when they disconnect was a little trickier, but that’s nothing compared to the mess that became the colouring of each line and connection point. This was a nightmare of if statements and multiple different points to do almost the same thing. But, it kind of worked. What I should have done was get the colours to be based off of the signal numbers, but that would have been the smart thing to do.


After this, I created the channel functionality. This could have been done better than it was, and it doesn’t entirely function correctly in it’s current state. I piggybacked off of the standard connection methods, but forgot to stop it from advancing the shape type and did not allow it to connect twice (which may or may not be good). Once I had done that, I needed to create the systems to allow connection points to accept multiple coloured inputs. This is where the train derailed. Because I hadn’t got the colours based off of the signal number, getting a colour to continue from the connection point would not work properly, since the connection point did not have a colour. I still need to fix this before we show our prototype to our programmers this tuesday, but there’s still time.


The rest of my team spent their time focusing on other areas of the game, such as UI or more in detail interactions with the connection points. After each of our parts are complete, the next more complex part is to try and combine them without breaking it. Fingers crossed it will work.

Paper Plans are good.

One thing when I come into a new project, one thing I struggle with the most is getting a full idea of what is being made. So, I end up with a lot of half thought out elements that were designed midway through the project. This isn’t the best with smaller projects, but at least it’s manageable when there isn’t much in the overall game. Now that we are entering into larger projects however, it’s becoming an issue. So, how do I work out more detail? Paper plans. With the use of paper plans, my team was able to realise the elements of the game that we were not aware of and make decisions about how elements would work that we didn’t know would be needed until the paper plan was in production. We used it to properly think through our UI and think about how the mouse would need to interact with the individual elements of the game. For example, the patch bay was an element of our game that we had thought would be very simple. But then, when we came to bringing it into our paper plan, we discovered that a proper representation of a patch bay for an audio console in our abstract multipurpose approach would be a lot harder than expected. So we were forced to make decisions about how it would work with greater detail, being able to draw each step of the process to layout how it would operate. Resulting in a more realised understanding of its function and a clearer understanding of our game overall. Of course this will never be what we have in the end, because game development almost never ends with the exact idea it was started with.


So that is how one example of paper plans work, but one thing paper plans aren’t the best at realising is 3 Dimensional games. This is mostly because they are hard to draw, because we’re game designers. Not artists. (perspective is hard). So one way that this can be taken care of is to draw the paper plans from only one perspective (top down/side on) and then creating an objects, actions, and interactions table to show how each element planned for the game interacts with other objects or actions. This lets you understand more about what needs to be done when it comes to making the game and what specific situations need to be designed, and gives you an advantage on designing these interactions to encompass all of the game’s elements in the most efficient manner. I have used this on another project I am working on and it was helpful to discover that there wasn’t much interaction in the game, and we were then able to find more places for interaction to happen. Both these methods have really helped me and my teams create and obtain a better understanding of the games we are making, now the only thing left (really not the only thing but for the sake of a good closing statement) is to see how they end up.

Learning about sheds

So I have a possible project coming up that would require me to create a shed designing app. But of course I have no idea what it takes to create a shed designing app, or what they need to be able to do. So, I looked at what already existed. Starting off with the Shed Boss android and web app, which through discussions seems to cover most if not all the areas needed for the project. There were some obvious improvements that could be made. For example, having a web app that worked in more than just internet explorer and firefox, and having a UI that doesn’t obstruct so much of the view. But most of the other features could be mostly recreated with minor improvements and adjustments to fit the client’s needs. But for the sake of better improvements, I had a look into what other apps exist for the same purpose, to see what they had on offer. For example, the Fair Dinkum Sheds app has quite a few improvements on the shed boss app. For example, fair dinkum sheds lets you enable and disable each wall of the shed individually unlike the shed boss app. This makes customizing the shed much easier. The fair dinkum sheds app also allows the user to adjust lean to’s with more detail, adding them to any shed type and being able to tweak their height and roof angle individually.  This gives the user so much more freedom with the designs, but, depending on the company, they may not want to offer these features upfront but prefer people ask them directly for the additions.


A lot of what will need to be done for this project is up in the air at the moment. So there can’t be any final decisions made at this point. But this research will be very helpful for how to make the decisions when the time comes. One key thing we will need to do on this project is to make sure that the program can easily be used by the target audience. Most of these apps would be used by older people whose knowledge of games and computers in general can’t be relied upon. So things will need to be clearly labeled with text and icons, and it is paramount that we test with the target audience before we deliver to the clients. So we can know to the best of our abilities that it is suited to the target audience. To make sure this is done right, more research will need to be done into what suits our audience better. But that’s for another day.