I’ll be discussing and looking back on my latest project, a serious game made as a supplement for New Intelligence’s training program.
New Intelligence flew up from Canberra and spent two days teaching us the workshop. They condensed three days of workshop into two. In doing this they skipped over the test run roleplay and analysis they usually do with clients. This was a big opportunity missed, to learn how they give feedback and how they frame practice for interviews. We asked and received forms that they would normally give for feedback which helped. In the future I would have expressly asked what was being condensed in order to let them know what activities and parts would be more helpful than others.
While I was taking quite a hands on approach with our programmers, there was a lapse of information with work done outside of class and from class members that had missed class. This was due to disorganised documentation. We had three separate documents and the google drive hierarchy was confusing. The reason we didn’t keep the documentation up to normal standards was because we had to have a GDD, TDD and multiple activity data sheets to keep consistent across. When one was updated, each had to be updated individually and consistently. This was a nightmare for upkeep and got neglected later in the project.
In the future I will use more central documentation which links to other sections with more detail. This will allow a clear division of information.
Programmers were working mostly from GDD, which was a pain to keep up to date along with the marvel app and the activity sheet data. Having a more centralised document would have solved this.
Team mate dependencies
One of the critical problems we had was a teammate having personal problems in the last few weeks of the project. He had the very important role of lead UI, being that it is a primarily UI game. This mean I had to fill in and take the responsibility for UI. At this late point in the project I was basically doing damage control. There wasn’t enough time to get it to the level I wanted and would have had if it was my responsibility from the beginning. The client seemed to like the look and flow, with which I’m pleased .
In the future, it would be prudent to have more than one person assigned to such important systems and contingency plans around that. It’s impossible to avoid personal problems and the solution will have to be flexible and modified for every project.
Adam handled most of the scheduling and projections for the project management. I believe the biggest problem of this project was how little information we had at the beginning. This led to us over scoping the project and giving our clients too high an expectation. Because this project was predetermined by the course, we gave it our best try but ultimately what we created was a prototype of what this application could be. The milestones we set got pushed back constantly. This was partly because of our inexperience making a mobile application and the scope of the project.
In the future having a better idea of what the project is and what the clients expectations were, would help us better scope and manage.
The first half of the trimester was spent doing paper prototypes and mock up programs. I discussed them in more detail here and here. This allowed us to quickly think of ideas, test them and then iterate. There was no dev time cost and no dependencies of needing programmers or equipment. when we start on the actual we knew we had solid questions formed and tested before any development. This agility was extremely useful and is something I will look to use on projects and ideas in the future.
Working on Android
This was the first serious Android game for me and the rest of the team. This came with some unique roadblocks like having to playtest on a separate device. This required constant building of apks and transferring into tablets/mobiles. The uni computers had varying sdk versions and required firebase systems installed in order to build correctly. This meant we primarily built on one computer manned by one person. This created a dependency on that one person and meant it was primarily his job to build and transfer to devices. But when Marv was busy, it was a pain to get a build. In figuring out this problem, this pushed back our beta by a week. This was mainly caused by slack times in communication.
The unity editor extension for Android would have allowed for a faster and a more direct pipeline and would have made testing small tweaks a lot easier for each individual person.
We also ran into the problem of Android’s many different resolutions across devices. There were many times it looked fine in editor and tablet but then slightly clipping text on phone. We just ended up primarily focusing on an Android phone. This still gave us some grief with us having multiple Android phone devices with differing resolutions and aspect ratios. I had to go through and anchor all of the canvas and UI elements correctly.
In the future knowing exactly what target device/s we are aiming to ship on would save a lot of time and effort trying to make the app dynamic and work on multiple.
I’ll be covering this in a separate blog post, here.
This project is my first time offering my service for an external stakeholder.
There is an important distinction between stakeholder and client in our project for new intelligence. The stakeholder’s were New Intelligence and the clients were the people that had completed New Intelligence’s training. When designing we had to keep this separation in mind and design for both what the stakeholder wanted and what we thought would be best for the end client once it was in their hands.
Communication was disparate and difficult with the stakeholders. We had 2 Skype meetings and 2 face to face meetings. This was not enough back and forth to show activities and our progress. We had to take liberties and make design decisions without their direction and because we have no experience in the fields their clients work in, we were really stabbing in the dark for some of the situations in the activities. In the future having more open and consistent communication lines would allow better direction and authoring of content from our clients.
Having worked with the other core designers made communication easy. We primarily used discord and regularly had voip calls to work and discuss team matters. We saw each other every Tuesday and Thursday in class also. We had clearly defined roles and were available to help in anyone else’s part.
I learnt lots from this project and think it was a great insight into software development. I will take these lessons of working with a client and working with a more separated team into future projects.
Thanks for reading