RSS

Post-Mortem – New Intelligence (Studio 3)

05 May

Over the past 12 weeks the team (Adam Crompton, Joshua Textor, Nicholas Staracek) and I have stepped through the entire process of creating a mobile app for New Intelligence. An app for their client base to have an opportunity to practice the things they’ve been taught. As a first time working with and creating an app for a real commercial client, it was far from perfect. From our perspective it’s not ideal, and from New Intelligence’s perspective it probably isn’t either. But I’m glad it didn’t run perfectly. Because it means we have SO much to improve on and to learn from in the process.

In twelve weeks, the expectations and scale of this undertaking + some other inherit tasks that followed were:

  • Learn to work with a commercial client.
  • Learn their content (of interview techniques).
  • Remember their content.
  • Practice their content.
  • Research serious games and how they can present information in meaningful ways.
  • Learn how to use their content effectively in way’s New Intelligence agreed with.
  • Create content.
  • Learn how to present their content in meaningful ways.
  • Implement content.
  • Collaborate with the commercial client.
  • Create a survey that asks content related questions in a meaningful way to the commercial client’s clients (end users) to gather a very broad (but oddly) specific answers.
  • Get results and analyse results from testing.
  • Implement changes based on survey and testing.
  • Learn how to do this (effectively) on a mobile device. + Orange
  • Learn how to deploy (effectively) to multiple types of device. + Orange
  • Get this on Android and IOS marketplace.
  • Documentation.
  • Actually make the app and all of the game development processes.
  • Still do university.
  • Do other university classes.
  • Not to mention more that I’ve overlooked or haven’t written down.

The orange are thing’s we’ve never done before.
The purple are thing’s we would most likely struggle with or are time-consuming.
There is a difference to me between scope and scale of a project. Scope being the app and it’s content (in this context), the scale being everything I mentioned above. Don’t get me wrong, I’m not complaining about what was asked of us. But with the aforementioned I think that for 12 weeks, the scale of this project was drastically over sized. Especially considering the quality I wanted this to be and taking into account the things that we had to learn in order to make this a reality. Not that any of this isn’t do-able, just not able to be perfected with the time-frame given.

Project Management Triangle 1.png

Project Management Triangle

We weren’t and aren’t getting paid for our work on this. The “scope” for this project is “scale” instead, and time is the 12 weeks.

NI Project Management Triangle.PNG

The red is where I believe the points on the scale are relative to cost, scope and time. The black is a guesstimate of where the average point of them are. The blue is where I’d wanted it to be (cost irrelevant). But as the next picture describes, the area that the point would end in, doesn’t exist.

Quality Triangle

There is no hybrid of all three, it’s always 2/3


What went right.

Communication between designers.

Throughout the 12 weeks of development of the New Intelligence app all of us designers (in my opinion) could not have communicated better. Whether it was over discord voice chat, leaving messages in specific New Intelligence related discord channels, updating documentation, emails or collaborating in the work space, there were no gaps.

Why?

For a number of reasons, one of which is having very specific work times where we were all in a collaborative work space – University. Enabling to communicate in the most meaningful of ways, face to face for a decent amount of time. Another reason, but also still as important, because we all care about what we’re doing to actively pursue every necessary opportunity to push forward to the best possible outcome. I’d also like to believe it’s because we all enjoy communicating with each other, whether it’s about the project at hand or every day chatter.

What would we continue to do next time?

Continue to separate work related communication channels from anywhere that can have distractions. Don’t have personal conversations within work channels and vice versa. Don’t have work conversations in social media platforms where cat videos can easily get the better of you. This is one of the first project’s where we had very specific channels that only the New Intelligence game development crew had access to. Keep the conversation to work related only, and only give access to those who are on the project with you. Voice chat > text chat always. Face to face > voice chat > text (if possible).


Design and Concepting.

The New Intelligence app wouldn’t be what it is if there wasn’t dedicated time set aside to figure out what it is and to concept how to use content effectively. Here’s a blog I wrote about it.

Why?

Going back to the roots of rapid concepting and rapid paper prototyping was a big contributor to this. Pumping ideas out on pieces of paper that allows us to move on and do this over and over to get a collection of ideas but then to also have a physical pile of ideas that we can reflect on.

What would we continue to do next time?

Do the same as mentioned in the blog. Design concept, Paper concept, paper prototype. Don’t just dive straight into unity. Dive into unity when you have something worth prototyping. Don’t build from scratch and fumble in the dark.
Also: USE A GIANT WHITEBOARD OF A WALL. I can’t stress how useful it is to have giant wall to draw on. Big enough for a few people to all draw at once. It’s like having a physical 3ds Max, Unity, Source Tree, Google drive, Paint, where everyone can sculpt pathways and plant trees. Take photos of it, put it in a shared google drive for everyone to reflect on.


New Intelligence received and app.

They got an app. We Delivered. Although it might not be to the original scale that was expected of the team, the project was still delivered, and in the form of an app.

Why?

We followed a project schedule and a project plan. I wrote about project methodology in this blog here, which helps define that this project plan was in no way linear. It was incredibly hard to account for the amount of possible changes or challenges to occur, although I’m sure this is just called game development. The reason why we were still able to push through was because of this project schedule and project plan. That and treating this as a real job. You don’t go to work to not work right? Well at least in my mind I go to work, to work. This opportunity had importance and outcomes, the team and I treated it accordingly.

What would we continue to do next time?

Continue to have project methodology. Know it, understand it, plan it, document it and use it. Have a project manager to enforce project schedule and project plan.


What went wrong.

GDD Documentation for programmers.

This is the most critical thing that went wrong with the project. Although the designers and I were pretty on top of the documentation, there was one flaw within the GDD. We had documented for 1 of the 3 types of question types. The functionality of the question type and how it operates within the app, how user’s interact with questions to achieve the desired effect. The three different question types each had different functionality. Because they had different functionality they needed to be presented in different ways. There were different amounts of information that needed to be presented in different sizes and places. Somehow in production it was decided that we we’re procedurally generating questions. I think we were trying to go for procedurally generated UI is so that the system would be infinitely expandable and it’s just self handling. That would have been fine if we had the time to do so. In this instance I don’t think we did.

We spent 3 weeks waiting on programmers for the system to have been created to procedurally generate UI and questions and all of the bits and bobs so we could start pumping content in and for it to self handle. In those three weeks us designers were doing other things, it wasn’t just 3 weeks of downtime. But we (kind of) hadn’t even opened up Unity until this point. It came to the point where the programmers said “Yup this is ready for you to do what you need to, here’s how it works, aaaaaand Go”.

Because there was so many different types of answers, and sized answers and structured answers with ever-changing amounts of text and the location, how the programmers handled it worked but it wasn’t user-friendly at all. It wasn’t easily decipherable or customisable. We couldn’t put any of the content in the app and have it user-friendly, in the right location, size. Every UI panel was different and we couldn’t possibly procedurally generate everything we needed and have it formatted, sized and placed properly in order to be coherent. I’m not saying it can’t be done. It just couldn’t be done to the level of expertise we needed it to in the time frame given. The solution was a hybrid of the designers manually constructing UI panels and attaching correct functionality to where it was needed. Then for those panels to be instantiated under the appropriate conditions of activity and exercise. It’s a lot more manual labour, which is what we were trying to avoid. But it was a necessary evil in order to get where we needed to be.

Why?

There were gaps in the GDD. There were gaps in the GDD because in the entire development process, it got a bit messy, focus changed and some things got left behind, some things got lost. This comes down having such a large-scale project in such a short time frame. Part of this was also because there’s so many different new things we were trying to learn how to do at once distracted us from the things we already knew how and what we should do. This isn’t an excuse but rather a point to reflect on that lack of experience with so many areas affected part of this project.

What would we do next time?

In the project schedule have a specific iteration time for documentation. I can’t specifically state where in the timeline that this went awry. I can’t and won’t point fingers, but if this process was implemented and every member on the team went and did iterated over documentation weekly I’d like to think that there’s a strong change that this could have been of less impact. Isolate specific areas that we don’t know how or what to do, gather and practice knowledge that allows us to not fumble in the dark.


Writing a questionnaire.

We ended up spending almost a whole week trying concepting and coming up with very open questions that aren’t very specific but oddly evoke a very specific answer that we can extract an array of information from. It was dragged out a little longer than what it could have but this was going directly into the end users hands after it went through NI. The downfall was that the questionnaire never got sent out. So we never got any answers back that would have helped inform the design of this app.

Why?

This is completely out of our control. New Intelligence had the list of their clientele, and for confidentiality reasons we did not, nor would we or could we gain access to it.

What would we do next time?

Email New Intelligence so frequently asking them to send the survey to the point where they get so annoyed that they actually send it just to shut us up.


Some other side notes.

Intertwining two projects into the same repository.

This wasn’t terrible, but having so many members and not so many scenes we wanted to avoid conflicts with merges, Designers had 1 project, programmers had another. It was in the same repository (repo). Because the programmer repo was where all of the magic was happening and I/we weren’t exactly familiar with the layout of their project/hierarchy. The ‘designer’ repo that I set up for the designers to use was where all of our work went. I guess it was basically me just testing different things out as a ui designer, getting a feel for what the app could possibly look and feel like / layout etc. And by no means did I think this was going to be the repo that the app was getting built from. I was dabbling and implementing different ideas in my own time to test things out before production on the app actually started. By the time production actually started it was inside of the programmer repo. The ground work that I had done before was still good content and was going to be transferred into the programmer repo. The designer project wasn’t a complete app, but had the foundations and templates of how the app could/might work/look. It came to a point where we transferred the current progress of the designer project into the programmer project. We ended up importing individual prefabs of activities from the designer project into the programmer project. Packaged it and put it into the programmer repo.


UI.

There was a few problems with UI scaling and when the panels got instantiated the entire panel didn’t scale or position correctly on different devices. A large portion of this was from having prefabs that we exported through packages (from the designer project) with specific anchoring points/stretch position etc. Because there were so many people working on this project. In source tree somewhere every time the prefab was overwritten to correct the prefab and or the ones in the scene, somehow they were getting overwritten. It was a never-ending loop of tracking down an anchoring position for a while in a meta file or something rather? Luckily, eventually a source tree wizard was able to track it down and we halted production on all the prefabs, deleted old ones from the projects and refreshed to only have the up to date ones and push those.


UI Design.

On this project I was the lead UI designer. Learning specific things from – Steve Krug’s: Don’t Make Me Think.

Having specific buttons always in the same location. Easily Navigable. Make things that need to be pressed “Buttons” look like they can be pressed. Make things that don’t need to be pressed look like they don’t need to be or can’t be. Headings, always let the user know where they are. Tell them, show them how to complete activities and how to play. [I’ll link to a blog post here about the things that I’ve learnt and the traits that I’ve carried over and implemented].


Working with a client.

It was daunting but also thrilling to work with a commercial client. Getting to meet real people who work for a real company that have sought our area of expertise to help them achieve a desired output is a real confidence booster. Having those initial meetings where we lay the foundations and approach the scope of the project is something that I look forward to doing again in the future. It’s so unfamiliar yet so intriguing. Then to go on and go through their interview technique training course made it surreal. They’re actually investing in us with their time. In this case we didn’t get paid, but they spent money and didn’t ‘make’ money to provide the training that they did. We walk away with that knowledge and also had the opportunity to work with a real commercial client whilst we were still university students. Ultimately there wasn’t as much contact with New Intelligence that would have liked to have, but it’s still one part of the spectrum on how contract work can go. When we did have contact, they were always more than supportive and invested in what we were all trying to achieve. They had opinions and expertise and they weren’t afraid to express it, but did so in a professional manner.


Designing for content to go into an excel spreadsheet.

The back-end systems were being designed by the programmers. We were to design content and put it in very specific ways in an excel spreadsheet that they would be able to do their wizardry on and sift it back into unity. The point of this was so that if we ever needed to extend or change content we wouldn’t (or if other people worked on it, they wouldn’t) have to sift through different parts of unity to try to find where it needed to be changed. It would all be within very specific areas of documentation. It also aimed to be self handling so in the long run it’s a lot less manual labour.

XML

Adding content into an excel spreadsheet and formatting it appropriately for the programmers to export into an XML spreadsheet and read into through Unity.


Opening Unity a little earlier.

I wish we Opened unity earlier as a team, and got to fiddle with different aspects sooner. Such as UI layouts and starting to discover all of the fires we’d come across later in mobile development because there was quite a large portion of this project that we had never done before. Testing out reading specific elements from the XML and being able to format it right and position it right. Understand that there’s so many differently sized information that a one size shoe wouldn’t fit all. But how could we possibly have known that we needed to open Unity earlier instead of honing in on the design concept? It’s like a double-sided sword. Open Unity too early and design suffers. Open Unity too late and the fires have already been burning. Wasting the week waiting on the questionnaire could have been used more effectively. But again, how were we to know? This project has ended from being solely on us to complete in 12 weeks to – hopefully – a bit longer of a project that others might get to pick up on and continue with. Or New Intelligence might want to keep pursuing this with us at another time? Who knows what the future holds.


Stepping Down.

This is one of the first projects where I’ve stood down from being the point of contact for the other disciplines and also stepped down as project manager. I explain the project management side of things in [this blog].

But as for being the external talent liaison, Art and audio was Nic S, Programming liaison was Josh. There were times of conflict that the programmers were literally in the next room and that it was much easier for me to go and discuss what I needed to than relay it to Josh to then walk next door to do the exact same thing. But one of the problems was that because josh had been the point of contact between the programmers and the rest of the group he ultimately had all of the knowledge on what was going down. And I didn’t. What I thought ‘must’ be right and the right way to do it wasn’t necessarily the case. So stepping away and respecting the fact that he was the liaison was something I actively had to remind myself of.


Stepping Away.

This is one of the first projects that I’ve actually had some pretty heavy personal issues come up that effected my ability to ‘do life’ among other things. Heavy enough that I dropped off the face of the earth for over two weeks. I never said anything to my team mates (and I’m sorry for that), but at the same time without me needing to say anything they were able to pick up on the fact that I needed space and continued to power on without me. While the approach that I took wasn’t the best, because sending a message isn’t that hard at all, It’s important to take away that in a team like ours woven so tight together, If one thread comes loose the entire weave doesn’t fall apart. Foundations and frameworks had been built for the project and as people who allowed the team to follow through on what needed to be done. I like to think that I’m a team player and contribute the best I can so walking away isn’t something I’m particularly familiar with. I’ve been told that sometimes maybe I need to ease off a bit and spend a little bit less time working and a little bit more time for myself before I burn out. This was one of the only times that I’ve barely been able to function as a human being, and I apologise if this is a bit personal for a game development blog (and this isn’t exactly something I’m comfortable with leaving sitting on the internet for public consumption), but I’m leading to a point. I’ve always been so worried about spending time away from part of my career journey because I’m pursuing something that I love and I’m contributing to something that’s part of a larger picture. But in times where we can’t possibly ‘human’, how can we even think about work? We don’t. We shouldn’t.

We need to take care of ourselves before all else.

Balance. The world keeps going. If the frame of the picture you’re in, doesn’t put your well-being as the most important pixel, you worry about you and do what you need to do to be right. I’m writing this in the post-mortem because these wise words have been spoken to me, and I’m speaking them to you. That, and also so when the time comes that I’m sifting through this blog in a few years time I can reflect on this moment and know that I made it through and so did the project.

If you wish to read any of the other post-mortems from any of the other designers:

Adam: Post-mortem.
Josh: Post-mortem.
Nic S: Post-mortem.

Until next time –

Nic

Advertisements
 
2 Comments

Posted by on May 5, 2017 in Uncategorized

 

2 responses to “Post-Mortem – New Intelligence (Studio 3)

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s

 
%d bloggers like this: