Project Sapling Postmortem

This trimester, my team and I have been working with a client to product an Augmented Reality educational app for young students to learn about gardening. Over 13 weeks, we created a product for Android devices that teaches students about gardening processes and tries to engage them in and out of the classroom. The project had a variety of unforeseen challenges, like creating an educational product for children that meets some of their educational requirements, and how to engage children in and out of the classroom to further enrich their learning. 

Tools and Processes

Unity 5.6.1

We used Unity for creating the project. We relied on a combination of User Interface elements and 2D sprites in a 3D scene top create the game’s 2D appearance. This method, while effective for prototyping 2D levels, presents an optimisation problem, because the simplified 3D scenes might not run well on the hardware it is designed for.

Furthermore, Unity is limited by its incompatibility with Version Control in its scenes. Scenes are not able to merge if multiple users use the same scene and make commits at the same time. To avoid creating merge conflicts, we divided levels into separate scenes and loaded them additively at runtime (in addition to directly asking if a scene is free to use) to avoid conflicts and give the appearance of a single level. Unity 2017.1 has integration with GitHub repositories and will actually inform users if anybody else has local changes to a file, which is another contingency that we should take advantage of.

Version Control

For this project we used GitHub for our version control, and I personally used Sourcetree as my Windows and Mac interface. Throughout the project, we have largely avoided conflicts by dividing Unity scenes among us and checked for permission before making changes to common scenes. We also used prefabs to save work externally to avoid losing changes. Our Version Control practices have been almost perfect and we have had very little issues in developing the project with GitHub and Sourcetree.

Mini-game Framework

Because of the variety of mini games within the product, we needed a way to easily implement key of the core functions of mobile games to save us time, instead of relying on programmers implementing every mini game we design. The mini game framework covered Taps, Swipes, Drags for objects and buttons for 3D Objects. It also created a framework to contain the games and integrate with Quest and Objective functionality to tie back into the broader experience. Furthermore, the Framework would save play data in an XML sheet to be referenced later.

The Framework was a very positive implementation to our game and future-proofs our design as we can expand on our selection of mini games while still tying into our experience.

However, the framework had a number of limitations. For one, creating Objectives relies entirely on using the Inspector to create all of them which is a convoluted method that means that changes can be completely lost if something happens to a scene. A better method would be reading from a file that contained all of the information necessary to build all of the Quests and Objectives, and provide rewards.

The Player Data XML Sheet couldn’t reference information within itself, and couldn’t have information added externally, and couldn’t hold other game-related information. As a result, we couldn’t reference the player’s name or personal data, and couldn’t save information such as their performance on Objectives, or save the states of their mini game performance, or Virtual Garden information. Lastly, the lack of these abilities means that we couldn’t create the Personas that would have explained the difference between students performance within the app, and how that will affect the mini games and states available to them. In this case, an excel sheet or similar implementation that allowed us to implement these states would have allows us to implement these, and the ability for Unity to properly make use of this information would have widened the options available to us for demonstrating the app’s features to the client.

Design Process

Project Sapling’s design process was very different compared to anything I’ve previously worked on, largely because this product was created for a client and it is an Educational AR App, all areas that I have nearly no knowledge or experience on. We took the following approach to developing the application:

1. Initial Brainstorm

When given our brief, we got together as a team to discuss where to go with the information we have. For Project Sapling, this happened after talking with Ralf. From here, we were able to identify our knowledge gaps and begin with a few ideas that need to be extrapolated with research, as below.

2. Research

We knew from the beginning we would need to tie together educational principles, gardening principles, and mobile app principles into an engaging app for kids. I knew nothing about these things, so there was a lot I needed to research:

    • Memory Retention Principles: How to apply it into a game for better learning enrichment.
    • Educational Apps: how educational apps operate to teach concepts and create engaging experienced to make learning seem fun.
    • Gardening Principles: How actual practitioners think and operate in their environment, and further experimentation on how to apply this in the app. For this app, we went to a community garden to work like practitioners and develop our skills in a real-life setting.
    • Mobile App Principles: what affordances mobile provides us and how we can use these. Furthermore, how other mobile apps engage users.
    • Kids’ App Principles: What other Kids’ Apps in the market are like and how they engage children and what principles they are afforded in this market.
    • Augmented Reality Applications: How other AR apps use the technology to amplify their experiences.
    • Curriculum Elements: What curriculum elements our app will actually target

3. Secondary Brainstorm

With everything that we’ve learned, we are able to work on more ideas and develop our concepts, essentially a second pass on our ideas. We can now scrap concepts or be more specific with others.

4. Prototype

The next phase is to create a prototype that demonstrates all of these ideas. It doesn’t matter if this product works well, it needs to demonstrate the spirit of the product and the ideas and intention of the final product.

5. Feedback

Our client gave us feedback for our prototype which gives us more specific areas to follow with our design. These feedback sessions occurred every fortnight and empowered us to focus on specific areas to better demonstrate the design to him and target any problem areas that we mightn’t be aware of.

6. Iteration

Using the feedback we receive, we make changes according to that. The cyclical process of Feedback to Iteration happened every fortnight

Project Management Methodology

For Project Sapling’s development, we used an Agile Methodology, including fortnightly sprints. We used Hack’n’Plan for managing the finer aspects of our product. Every day in class we would check Hack’n’Plan to discuss where we were at and where to go with the tasks remaining.

Every Thursday before our meetings with Ralf, we would discuss where we want to be and triaged what needs to be prepared before our meeting. This just resolved to minor bug fixes and documentation updates to demonstrate our core features. While doing fortnightly sprints before meeting the client was fairly effective given that we were on campus 2 times a week, we should try to employ weekly sprints to further triage tasks and break down tasks for everybody earlier. This will also allow us to encounter and address issues as early as possible.

Each day in class I would check up with everyone on the work they are doing, effectively a scrum session to check up on the progress and limitations of everyone and whether they needed help on their work. For the most part, people were fine given the way that we broke down tasks (into constituents that could be completed in a few hours), so in future we should employ

Hack’n’Plan use was fairly limiting. Not everyone would report tasks as often as they should have, meaning the hours people appeared to work were less than in actuality. Furthermore, work done in class or very minor extra tasks weren’t logged at all, so Hack’n’Plan wasn’t an effective way to monitor the progress of everyone.

To tie together our scrum and Hack’n’Plan to benefit both, we should structure the scrum meetings on the progress logged in Hack’n’Plan so the team can reflect on their progress. As we tick over a milestone, we can discuss our performance and limitations for why certain objectives aren’t completed and need to be moved over to the next milestones, which can help us better triage objectives for certain people and help people reflect on the progress they’ve made

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s