So studio 3 is coming to an end and as such our garden project, which we dubbed ‘Project Sapling’, has been completed and handed off to the client. This was a different taste of game development and a very interesting one at that.

For those who are unaware of this project, I was part of a team of 4 game designers who were tasked with making an Augmented Reality game about school gardening. This is a serious game with a focus on education and helping students retain memories they obtain in class time by testing their memory through quizzes and mini games. We had 12 weeks to work on the project and had the help of 4 game programmers and I think it’s safe to say that we are all pretty pleased with the outcome. If you want to read up on the stuff that I have been doing throughout this trimester, go check out my Studio 3 blog category.

Teamwork & Flexibility

One major standout from this trimester was the team dynamics. We gained really good momentum from the beginning and aside from the small bumps that should be expected from any new team, we hit it off right from the start. We were consistently showing up outside of class time to do team work and sometimes even field research. I have some blogs about field research that you can read up on my previously mentioned Studio 3 blog category. This really showed me that our team was committed to the project and was trying to make it the best it could be.

Whenever we found ourselves in a scary situation we were all able to talk to each other and ensure that we didn’t get too distant from the project or each other. There were many unknowns and blockers that we faced throughout the project but we always managed to stay level headed and work it out as a team. As very like minded members we were able to come to compromises by being aware of  and trusting in each others strengths. Especially in some of our earlier client meetings when we kept needing to revise our design due to a lack of direction.

Direction

Going into this project fairly blind and needing to prepare for any direction was difficult. This was due to the lack of information gained for the project before we started brainstorming, researching the potential clients and looking into similar games. After our first client meeting we had to change how we were looking at the project, but getting a form of direction was a massive relief. We thought that this would be the scariest part of the project because of how lost we were. Little did we know that the rest of the project would have very little direction. Due to the ambiguity of the earlier client meetings and some misunderstandings on our part, we were not really hitting the right spot in our initial design.

In the first meeting we were told this would be an AR game, but we later found out that we would not be dealing with any AR elements. When we tried to design the account login, creation and storing of account data, we were told that we would not be implementing that. At this point it was really confusing for us and we weren’t sure what direction we were meant to be taking. It wasn’t until our second meeting that we found out the nature of our project. Our project would be used as a demo by our client to gain customers. This meant that we only needed to make it look like it works rather than implementing the difficult features such as augmented reality and account creation/storing.

Project Planning

This was my first time taking the project management role, I had previously helped out with a similar role due to some issues with the project, so I was confident I could take on the role for an entire trimester. My early understanding of project management was a bit off because in previous projects we would only ever have a project manager role and no leader role. Because of this many of us assume that the project manager role is inclusive of the project lead role. This was definitely the case for this project where I was mainly focused on short term planning rather than setting out an overall plan with milestones and such for the entire trimester. This is something that came to bite us in the back for the rest of the trimester especially because of the lack of direction in the first half.

We managed to make do with the flexible team we had and made sure that we were putting work in where it made an impact. Though I think we were focusing on the wrong aspects of the game in the later half of the trimester. We were expected to look at memory retention games and try to apply it to the games subject matter. I have some previous blogs where I do research memory retention games, but when it came to applying what I learnt we didn’t really think it through. Because of this I think that the end product was a bit too broad and not focused into the area that our client had liked.

Testing

When developing games where you don’t have as much creative freedom, feedback is the most important thing that you can get. We’ve always been encouraged to gain feedback when developing games and you’d think that we know that given our previous experience with working with clients. But in this project we seemed to just assume that it would be a end of trimester kind of thing and so we threw it on the backlog. Even if we weren’t going to be testing until the later weeks, we should have made some plans for future testing so we could have made time for it when it was necessary.

With that said we did manage to get a lot of feedback from our client during our meetings and get some internal testing during class time to find the obvious flaws. One of the main problems was the fact that we were testing on PC builds in the prototyping stage and the alpha stage. Being a mobile game, a lot of the user experience is centered around the device and as such we needed to start testing on mobile builds.

Conclusion

To summarize, this trimester is no where near as bad as this post mortem makes it out to be. In fact it was one of the most productive projects I have ever been a part of. A lot of the improvements I have noticed in myself is in my workflow and habits that I have continued to build on. Also because this trimester has been solely focused on a single project, it has been much easier to get close to the project and maintain momentum. It’s been really helpful to me to also make sure that I am working on things in the game that I actually enjoy. During the last half of the project I was struggling to find things to do that I enjoyed, I ended up being tasked with making the alpha version of a mini game. I had so much fun with it and got carried away with making it feel good that it got me involved with the project even more.

Getting a look into the business side of the industry by working with real world clients was a valuable lesson for me. I have always been hesitant about being a game developer in a studio or working with clients because I would prefer to make my own games where I have full creative freedom. But this was the wrong way to be thinking about my career and I was simply avoiding things I didn’t know, more so because it was all ‘suits and business’ stuff. This has given me the confidence to do contract work as opposed to trying to get by as an indie developer or doing solo projects as a hobby.

In early brainstorm sessions and client meetings of our garden project there were some ethical and moral decisions that became present. When dealing with a target audience such as ours ranging from kindergarten to grade 12, there are some constraints that may call for changes or pivots in the design. As an example, we are making an AR game for children that is location sensitive, this is what we were told when getting our briefing from the client. Obviously this is not the way he told us because this is a massive red flag but this is what we got out of our first client meeting. What they actually meant is that there are AR codes at specific areas within the school that need to be scanned in order to prompt an activity in the game. Contrary to our first impression, our client wasn’t wanting us to track the users location via GPS, it was simply a miscommunication. This made us aware of the implications involved with working with such a target audience when going forward with the project.

Being an educational game, the teachers need to be able to see the students progress in the app so they can use it as reference for grading. So now we are talking about tracking children’s information through a personal device. What information would this be tracking? The times at which they are using the app? Where they are using it (at school or at home)? Users under the age of 13 are protected by the Children’s Online Privacy Protection Act (1998). This enforces many restrictions when it comes to storing children’s information and results in limiting their access to online forums without parental consent and the need for privacy policies. Because of this many websites simply disallow users under the age of 13 to view or make profiles in their domain to avoid the costs and risks associated. This is a U.S. law, but the Online safety (2015) publication mentions that children under the age of 13 in Australia are protected by this act and as such cannot use social media sites such as Facebook, Twitter and YouTube.

This area of the game, later named the Teachers Lounge was simplified to avoid any risks involved with the act. We also found out that the clients main team would be handling the student accounts and the information tracked. Given that this was an important part of working in the industry we still fleshed out the design of the Teachers Lounge to ensure that the teachers would be getting sufficient information to grade their students and get the most out of app. In the end the app will store the students name, the number of plants & weeds present in their virtual garden, their course completion and the time of their last logon. We came to the conclusion that this information was not intrusive of a child’s privacy and still allowed the teacher to get enough information to grade their students.

Bibliography

Children’s Online Privacy Protection Act. (1998). Federal Trade Commission. Retrieved 24 August 2017, from https://www.ftc.gov/enforcement/rules/rulemaking-regulatory-reform-proceedings/childrens-online-privacy-protection-rule

Online safety. (2015). Child Family Community Australia. Retrieved 24 August 2017, from https://aifs.gov.au/cfca/publications/online-safety

Choices in games are extremely important to make the player feel in control and to avoid frustration. The only problem is that choice design is hard, making sure your game works for each  of your players choices is a lot more work. I’m sure that every successful designer has been through the ‘Let’s make the player’s decide for themselves!’ phase and had an important lesson learnt. I may not be successful (yet?) but I’ve had a similar experience in a previous project where our client wanted a game centred around player choice and interpretation.

Making sure that your game design works with multiple choices and furthermore making sure that your choices cater to your entire audience can be daunting. For our garden project we didn’t really account for player choice but there are still choices to be made during play. To test the player’s memory on a certain topic they are prompted with short multiple choice quizzes. This type of choice is really basic, you are provided with a question and you choose the one that you think is correct. It’s based off of facts and if you get the answer wrong you are taken to the corresponding mini game so that it can refresh your memory about the question you got wrong. You can’t really blame anyone but yourself if you get the answer wrong in this case which definitely lightens the load.

On the other hand we have our mini games and how they handle fail states. As an educational game we need to make sure that the player can fail and learn through their mistakes so we need to make sure the choices reflect the logic that we are basing them off. As an example our Debugging mini game is about protecting your plants by removing any insects that are dangerous. Not many people know, but ladybugs are not dangerous to plants, in fact they actually eat the insects that are dangerous to plants because they are carnivores. Our mini game rewards the player for removing all the pests, but it will fail the player if they remove all of the ladybugs and prompt them with a reminder about how ladybugs are not pests.

As mentioned before this sort of choice design is based off of factual information, so as long as we explain the facts and the gameplay reflects the facts, it is not as daunting. But when we start to look at games that give the player choices that can be considered controversial, we can see the difficulties of choice design. Games like Postal 2 and the Grand Theft Auto series which give the player the option to do some questionable acts makes you wonder what message the designers really intended. Every game can be interpreted differently and all designers should be aware of the possible implications that their game can convey.

During studio 3, we are required to show skill in a specific area of game design, I personally chose game “feel” as my specialisation. This area of games is somewhat untalked about and overlooked by developers because of the ambiguity  involved. So what exactly is ‘game feel’ (or otherwise known as ‘juice’ or ‘kinaesthetics’)?

Swink (2008) states that there are 3 main building blocks for defining game feel; Real-Time Control, Simulated Space and Polish. Real-Time Control is the interactivity between the player and the computer and focuses on the processing and expression of information. Expressing information usually prompts the expectation of receiving information, which is received via the senses. It is this focus on the user/players senses that can help give the designer awareness of what the player needs to know in order to feel in control. Simulated Space is the space in which the interactivity exists and how the player perceives the game world. Interactions in the game need to be perceived by the player in some form, and because games are actively perceived due to the need of expressing and processing information, this is key to how the game feels. Polish refers to the additional effects that enhance interaction without affecting the simulation. As an example, an explosion in the game can just be a circular collider that damages any character that touches it, a polish effect could be to add a sprite animation to communicate to the player that an explosion happened. This does not affect how the game functions but it does communicate to the player what is happening in the game world.

This can be hard to grasp at first, and mainly because a lot of this stuff is simply assumed by us. When we make a game we naturally try and add details to make it seem more realistic and unique. You can have multiple games that are functionally identical, but by applying different polish effects you can achieve completely different sensations.

Demonstration

I have made a small game to demonstrate how small details and polish can change how the game feels. This game has the basic functionality of movement with a goal of getting to the end of the level. I have made the additional elements able to be turned on and off during play so that it is easy to see the difference. I will refer to the ‘game feel’ elements as ‘juice’ throughout to avoid any confusion. Here is a gif of the game in it’s functional state, it is very bare bones and is intentionally basic to try and emphasise the effect of the juice.

Movement

First I want to talk about the movement. In this demo I have made it so that the playable object has physics applied to it through the use of a rigidbody, but I wanted to convey the idea that the juice mode has physics and the the basic mode does not. The basic movement feel of the object is really static because it instantly accelerates to maximum speed and decelerates to idle almost instantly also. The basic object can instantly corner making for more jagged turning whereas as the juiced movement has more curvy and smoother lines of travel.

The collision of the object also plays into how the game feels. With the basic collision, there is no feedback both in how the object rotates or moves. The juiced mode has rotation when colliding and slight bouncing around, not to mention the various collision events that I will get to later.

Camera

The camera is another large aspect to how the controls feel and is relatively simple for the type of demo I’ve made here. Because the focus is only on movement and avoiding collision, all I would need to do is move the camera towards where the player is moving so they can see what’s ahead. Even though the camera view size is large enough to see any threatening obstacles, giving the player a leading view will help make them feel in control and give feedback on what direction they are moving in. To further emphasise the smoothness of the objects movement we can also apply a linear interpolation to the camera.

Now we can talk about the hot topic of game feel, camera/screen shake. So there’s no denying that camera shake can help to emphasise the impact of certain actions and is a very simple but effective way of giving feedback to the player. Seeing as my demo here is all about collisions, it’s a no-brainer to add it in. To make the camera shake feel more realistic, I have opted to change the intensity and duration depending on the collision speed of the player. It’s a very minor detail but it can definitely sell the effect more so when the collisions feel like they have variance.

Visual Effects

There isn’t much happening when actually colliding with the environment, a lot of the feel here is relying on physics and the camera. We need to add more visual feedback that the player is actually interacting with the game. One of the most effective ways to do this is to add particle effects and other small visual details. I have 3 details I added into this demo to show off visual effects, they are very basic but they do emphasise the impact of the interactions. First off I’ll take about the environment visual effect. I made it so that when you hit the walls, all of the walls in the level will flash red. This is similar to how some games make enemies flash a colour when taking damage.

I have 2 different particle effects in the game, one on collision and another as a trail for the player. The collision effect serves as feedback for collision and also is intended to communicate the intensity of the collision much like the screen shake. As you can see with the below image, the velocity of the collision determines the size of the particles. It goes hand in hand with the screen shake and helps keep the feedback consistent. Another good point here is that the particles spawn at the collision point and not at the center of the player object.

With the trail effect, it helps to communicate to the player the speed at which they are travelling because it emits more particles the faster you travel. It also helps to communicate the players line of travel which goes hand in hand with the smooth physics based movements. With this particular demo, it’s difficult to get a point of reference of the players position because the players distance from the walls. This trail effect is simulated in world space so it serves as a good reference point for the player relative to world space.

 

Audio

I got my audio from the reliable and always trusty BFXR site which procedurally generates sound effects which can also be fine tuned. I just have 2 sounds, one for the character movement and one for the collision. The movement sound oscillates and will change in pitch and volume depending on the speed of movement. It serves as another reference point for the player’s speed. The collision effect is a crunching sound that is fitting for a crash and communicates that what they did is bad. It is intentionally jarring to go hand in hand with the screen shake, particle effect and the environment flashing.

Here’s is a video showing off the audio. Since all of the changes have been added, this video will also serve as the final demonstration and will compare the initial version versus the complete demo.

Bibliography

Swink, S. (2008). Game Feel: A Game Designer’s Guide to Virtual Sensation (pp. 2-6). Hoboken: CRC Press.

During class we touched on the business side of things by having a look back at the business model canvas that was introduced to us last year. This trimester is focused on the commercial side of game development and it is important for us to understand how a business model works and how we can go about creating one ourselves.

This lesson was mostly focused towards prompting awareness in those of us that aren’t really familiar with this side of the industry. I for one did not really know anything about the requirements for running a successful business in the industry because I did not plan to be an entrepreneur or take a management role in a studio. After getting a taste of this type of work this trimester and seeing how much more viable it is to do contract work, it’s clear to me that this is really necessary for any game dev to know.

Business Model Canvas

So what is a business model canvas? It is a more simplified business model that was invented by the business theorist Alexander Osterwalder. The business model canvas fits on a single page and is structured in such a way that it can help visualise the important areas of a business for both large scale business and entrepreneurs alike.

The main goal of a business model canvas is to link together the different areas of a business model. This includes;

• The customer(s)
• The products value propositions
• The channels in which you reach the customer(s)
• The relationship with the customer(s)
• The revenue stream
• The key resources for the value propositions
• The key activities for the value propositions
• The key partners which the project relies on
• The cost structure

The points here follow the order in which the canvas should be filled in because of how they depend on each other. Each section ties into their previous sections in some way which helps simplify the concept of business models. Being aware of the costs, risks and parties involved is important when dealing with customers because you want to make sure your team is reliable and can gain the funding required to produce your product.

The canvas is most helpful for us as game developers by allowing us to create a business plan that can be pitched to investors and potential customers so that they have a clear idea of what they will be getting into. This gives a higher chance of getting contract work which is definitely the most viable way to make money as a game developer.

Here is a crash course for how a business model canvas works from the company co-founded by Alexander Osterwalder:

 

Early on in the project we did not have a plan for testing, nor did we have mobile builds prepared for testing. Fortunately for us designers, when the programmers came on board they ripped our prototype to shreds in terms of questioning the ambiguity and decisions behind our design. It sounds harsh but I don’t think our project could have gotten this far without it. This helped us get a footing for future testing and gave us an idea of the type of feedback we would need to look for in the future.

Testing Plan

The testing plan we had in place for this project early on was mainly targeted towards our client. During the initial meetings with the client, the goal was to get an external tester to be able to access every area of the game without confusion. Of course early on this was not very easily achieved but that was to be expected. We decided to branch out and test outside of uni because we needed some unbiased feedback from non-game devs who will focus on the user experience rather than the technical aspects. I do not have accessible testers in the games target audience age group which is between kindergarten and grade 12, but that was fine because feedback from adults and elderly was just as constructive. I also did not have access to an android device that I could put a build on to test outside of uni, because of this most of my external testing was done through a PC build.

As mentioned above, the earlier tests were focused on getting the user through all of the menus and scenes included in the game. From there we tried to make sure that each area was sufficiently accessible so that navigation was more fluid. We wanted users to be able to navigate the menus without necessarily thinking about it too much. After getting our mini game framework and creating some test levels, the focus in testing turned more towards these mini games because they were the core of the game play. With both the navigation and the level testing, one of the standouts was the mobile platform. We found that positioning of UI elements and the interaction in the mini games wasn’t quite what we were going for. Since we were not testing enough internally on mobile platform we decided to make a change to our approach to testing.

Moving forward we made sure that we always had mobile builds ready earlier than usual and made sure to thoroughly test them internally before getting the client to test them. It’s always a good practice make sure that problems we can find through internal testing are not present in external testing so we can get the most out of our testers time. This work flow of having earlier goals set so we could get builds ready a few hours before our client meeting and then continuously testing them and iterating on them until the meeting came around is what we ended up sticking with. Of course our testing processes were continuously evolving over the trimester and it could have gotten even better, but the workflow we were able to achieve in the 2 last client meetings were ideal given the type of game we were making.

Iteration

Based on the feedback we received throughout testing our various builds, we managed to learn a lot about not only our game, but also our processes when it came to designing. We found that a lot of testing feedback could have easily been gathered through more research into similar types of games on a broader scale rather than nailing doing to 1 or 2 specific games. The lack of direction in the project early on definitely showed in the latter half of the project and made it difficult to iterate on our design. This had a negative impact on the testing process because a lot of our issues could have been resolved without the need for external testers and we could have gotten a lot more out of it.

Based on our testing on the mobile devices we found that a large issue was with the sizing and position of UI elements. Because we were neglecting to test on mobile early in the project, we did not foresee the issue that the UI was way too small on mobile devices. We had a lot of real estate on the device screens but were only using a fraction of it. Expanding on the UI sizes allowed us to get a bit more creative with the UI positioning as well, since there was a lot of layering involved with the main menu.

Some user experience issues we found, is that we needed to make sure the menus have context since the target audience was school children. We made sure that we have some hints setup for each of the main screens and that we tutorialised the mini games.

All in all I think the feedback we got from testing both external and internal was really helpful. After looking back at our processes it makes me realise how important it really is to get people to test the game. The whole concept of justifying your design through research and validating it through testing is much more clear to me. We made an effort to ensure we applied this because we were very aware of the concept, we just weren’t aware of the importance at the time.

Throughout this project we have been using certain tools and processes to make the project easier for us. This includes the programs we used to make the game, manage source control and the frameworks created by our programmers to make designing the game less tedious.

Game Engine

First off I wanna talk about Unity. So Unity has been our go-to game engine throughout the course, so naturally we would use it since it’s what we all know. But there is so much about Unity that we still don’t know and that was really evident with this project. I personally had never worked with 2D or mobile development and that made this project a learning curve at the beginning. This lead to the project being mostly made through UI and menu navigation rather than 3D space which is what I am accustomed to.

A lot of the earlier Unity work was in the prototype made by just us designers in the team and I gotta say it was a lot of fun. Messing around with a build that would never see the light of day after it was finished is a massive relief and allowed us to get creative with our designer code. I was really proud of what we managed to pull off in the end, you can check out my other blog post about this prototype. The later Unity work was more so based around the alpha and beta builds the programmers made for us. Once the functionality was there, it was up to us designers to setup the mini game levels and polish the menu UI to fit with the visual style. The mini games themselves were really enjoyable to make, after learning the mini game framework the programmers made for us (more on that later) I felt at home with creating the quirky features of the mini game I was tasked with. The menu UI on the other hand was the biggest challenge for me but it served as an opportunity to learn about Unity’s UI features. Features such as UI panels, vertical layout groups and synchronized scene loading which I had only slight experience in, and other features such as buttons and sliders which I had used a lot but was able to get even more creative with.

Source Control

For source control we all use Source Tree (or GitKraken in some cases) which is what we have been using since the beginning of this course. Source control was kind of the elephant in the room in earlier trimesters, where people who didn’t fully understand it didn’t really speak up because of the difficulty involved in learning it. But because of its importance everyone naturally is required to learn it at some point. Because we are already in our third studio class, it’s nice to have a team that can successfully use source tree and also make full use of its features. Using source tree has become a habit for me in all of the projects I am involved in, especially solo projects! I think that the general workflow of allocating tasks and communicating our commits with source control in mind has minimized the risk of merge conflicts and issues with the repository. Because of this I am much more confident working with GitHub and Source Tree when working on group projects.

Custom Editor Tool

Given the structure of our project and how it utilizes mini games that have similar functionalities, we decided to get the programmers to make a mini game framework. This framework script would be applied to each interactable object in the mini game which allowed to it do various things. This allowed us to script each level ourselves but not have to worry about making separate interaction scripts for all of the interactable objects. Interactions such as tapping, dragging and holding which were present in some form in each of the mini games were made to be easy to implement with the given framework.

Introduction

As project manager for this AR project I have had the responsibility of setting out a project plan and determining milestones over the course of 12 weeks. This is my first time taking on the role since I was never really focused on the management side of projects in previous projects.

Methodology

Ever since starting studio work, most teams usually gravitate towards the scrum methodology due to its agile nature and ease of undertaking pivot and iteration. This was definitely the case for this project because we were going in mostly blind without much experience in working in both mobile development and educational games. This meant that we were more flexible in terms of how we could adapt to changes and unforeseen blockers.

For the sake of simplicity we decided to have weekly sprints so they line up with our class times. It would be counter-productive to use any other sprint time frames given our situation. This allowed us to form both our milestones and out of class activities around the general weekly time frames that we were already accustomed to.

Milestones

For our milestones we had a basic overview of what the layout of the trimester would be, but it was up to us to expand on that and form it around our particular projects. As mentioned above, we are using weekly sprints and as such we are having a milestone at each of these sprints. Our milestone list is as follows;

• Milestone 1: Research potential stakeholders and existing similar games
  • Due to our inexperience with the type of game we were making, it was important for us to look to similar games for influence
  • It was also important for us to research the potential stakeholders we had been given to see what types of products they make and their methods
• Milestone 2: Initial meeting with stakeholder and initial design
  • This was our first interaction with our given client where we would get the first idea of what we are making
  • Throughout the rest of the milestone we would be looking at project management, research similar games to what we had learnt about the clients request and also start brainstorming different ideas
• Milestone 3: Follow-up with Stakeholder
  • This was our second interaction with our client where we could show them what we came up with to get some feedback
  • This milestone was almost entirely focused on iterating our design and trying to justify our design through research
• Milestone 4: First-Pass Design & Development
  • By the end of this milestone we needed to have completed design documentation that would act as the first version of our design that we could use for our prototype
• Milestone 5: Unity prototype ready
  • This milestone was entirely focused on getting a prototype using our current design so that we could show our given programmers what we were looking to create
  • This also included some changes towards the documentation to reflect issues find during the development of the prototype
• Milestone 6: Programmers on-board
  • After getting our assigned programmers and showing them our prototype the next step was iterating on our design and documentation to reflect any questions or concerns that our programmers had
• Milestone 7: Alpha Ready
  • This milestone was mainly spent iterating on documentation while the programmers were making our functional alpha build
  • We also started setting up art bible and asset list documentation with the intent to get some asset creators on board
• Milestone 8: Alpha Testing & Iteration
  • We spent this week looking at the alpha and giving feedback on the alpha and making sure that our documentation reflects those requirements
  • We also pitched to the animators so we could get some art assets
• Milestone 9: Beta Ready
  • After the iteration this milestone focused on getting the project feature and content complete for the beta version
  • We also looked further into the asset list due to some unforeseen content during the beta development
• Milestone 10: Beta Testing and Polish
  • After getting the beta version, we got some outside testing and mostly internal testing so we could get feedback and make any additional changes to the documentation
  • This week was mostly spent on prettying up the game with our art assets, positioning UI and making sure the overall user experience was decent
• Milestone 11: Release Version Ready & UX Refinements
  • At this point the game should be mostly complete and the documentation finalised
  • Any changes should be very minor and only to polish the user experience
• Milestone 12: Final Delivery
  • Final product hand over and contract agreements

Momentum

How did we maintain momentum? I have found in previous projects that getting that initial momentum is key to setting a rapport in a team and getting all of the members engaged. But the issue following is that members can easily lose that initial momentum if steps are not taken to maintain consistency. Our approach to this problem was using tools and setting a fixed period during the week that we would have a team meeting. Hack’n’Plan is the most accessible tool that we are all familiar with and serves as an all round project management tool that allowed us to allocate and track tasks as well as our milestones. We agreed on getting to campus 3 hours before class on every Thursday where we could have a discussion about any pressing matters or work in a team environment because we are usually more productive that way.

Week 5 has just passed for Studio 3 where our team got to work setting up a prototype for our game. We are at a point in the project where our documentation is being finalized and we are getting the programmers involved so they can start creating the necessary systems. Next week we will be showing our prototypes to our assigned programmers to get them up to speed with our project. So it’s up to us to make sure our prototype reflects our documentation as best we can.

Our prototype is very basic and we for the most part, used our storyboards as our main point of reference. Because our game is exclusively user interface without any 3D elements, it was really basic for us to create the windows in separate scenes which allowed the team to work in parallel.

Personally I worked on the virtual garden screen where the user can maintain an expand their own little garden. The user can plant a seed on an available plot and water the seed to make sure it doesn’t die. When the seeds growth hits 100% the plant will sprout meaning that it is matured. At the moment this is a really basic functionality and doesn’t reflect the end product. Here is a gif of some of the functions included in this window. The cursor and ‘more info’ pages are sideways because I had to make this garden in landscape whereas the app will be primarily portrait.

The main issue was connecting everything together afterwards, with all of our different methods of scripting and using the Unity editor. It wasn’t a major hassle but it did result in us spending more time than needed on it. Another challenge we came across while setting us the prototype is the lack of ‘systems’ that we do not have access to. Our client has mentioned that our app is only a section of a larger app and there will be a lot of information and connections stemming from the main app.

Due to this we have a lot of empty gaps in our design and prototype that we need to sort out in our next client meeting. For now we have compromised by use static images or placeholder assets until we know for sure what we are meant to use in the final product.

As I mentioned, for next week we will be showing our new prototypes to our assigned programmers to get them up to speed. We will also have to start looking at our technical design documentation so that we can get the programmers working as soon as possible. There are still some things in the design that need to be ironed out before we start getting into the technical sides of things, but the team is very pleased with the current state of the project.

We will also be attending the same working bee from the previous weeks but on a different day due to a change in time table for the team. We hope to further our knowledge of gardening and get as much exposure to the experience as possible so that we can inform our game design.

This is our fourth week of studio 3 and we have had some major changes made to our design. It has been really important for us to get these design issues out of the way so that we can go forward with the prototype next week. Some of the things we did include;

• Made a storyboard for our documentation
• Did some more field research at the community garden
• Had our follow up client meeting

After going through our documentation and rough storyboards as a team, we made a more official storyboard in our documentation so we could get an idea of how each window would link to each other. For this I decided to use Google’s drawing feature so that we all had access to edit the drawings. Because our storyboard was still in its rough stage, it was important that we all had input to these drawings instead of a single person calling the shots.

As I mentioned in my last blog, we made plans to revisit the community gardens to get a more diverse range of tasks. This time we learned even more interesting facts about gardening and just how broad the topic is. As an example I was tasked with hanging up pine cones from the undercover area roof which serves as a habitat for ladybugs which help keep insects away from their crops. Other than just moving scrap and hay bails around, we spent most of the time removing some overgrown vines around a water tank.

Again this was a really productive use of our time and we also got to do some more diverse activities which even furthered our knowledge. Both of our field research times we spent most of the time doing a single in depth task. This is good because we learn a lot about these particular topics, but we don’t have the time to go in this much detail with each activity in our app. So next week we hope to get even more diverse tasks so we can get a taste of each area in gardening.

Last of all we had our follow up meeting with our client where we could show him our storyboard and fill him in on what we had done over the past 2 weeks. We did manage to get our vision across for the most part, but I feel that we didn’t really get across all of the work we had done. Overall it was a really good meeting and we got more info from him that we didn’t know about last meeting. We had assumed that we would be making the app from the ground up, but this time we found out that we were only designing a small section of a larger project which his team was making.

Our app will serve as a recall app that will help with memory retention similar to the apps memrise and duolingo. Even though we knew this before hand, we did not think to look into these similar mobile apps and learn from their educational format. Because of this we have had to make major changes to our overall storyboard and design. Though it hasn’t made our work up until now a waste, most of it is still relevant in this format.

Personally I have only used memrise in the past and have seen how they handle memory retention. Both of these example apps are for learning different languages, the way they teach is by showing the player the connections between the users native language and the new language they are learning. After this they will then quiz you on the same words and see how well you go. After this the app will have reminders of when the user should review the quizzes to make sure the knowledge is solidified. This below image shows that this user is due for review on this particular quiz, he has the choice to review the words or ignore them.

This is what our app will also do but instead of us teaching the students about biology, chemistry, horticulture, etc, we can assume that the students will be learning about these things in class (or on the main game made by the main team) and then our app will serve as recall through mini games and quizzes.

Moving forward we are again looking to do more field research at the community garden to get as much exposure to the practice as we can. We are also going to be updating all of our documentation as per our client meeting and also looking towards an updated storyboard. As per our milestones, we must have a prototype ready by the end of next week so we have a lot to do.