Week 9: Development Documentation

 So far, our documentation practices on this project have been really great. We've set a high standard when it comes to keeping a paper trail of everything that happens.

Here's how:

• Consistent meeting minutes
• Slack
• Version control (SourceSree)
• Multiple sets of feedback notes at each desk critique
• MediaWiki
• Weekly summaries

Having such comprehensive documentation makes it easier to do many things. We can track past changes, use the info to write/update blog posts (haha) and keep an accurate portfolio. It's also useful to be able to refer to previous documentation in meetings..

Week 9: Having Overlooked the Title Screen

Quick update this time:

As it turns out, the team has completely neglected to consider a title screen for our game. This isn't a big deal in the long run. It's annoying though- it throws out the Gantt chart and the asset list, simply because we forgot to account for the time it'll take to draw a title screen.

Again, it's not really causing any problems, it's just something that we would've liked to have in the prototype that will cause us to have to work overtime.

It's interesting how a small mistake like that can be such a thorn in the side of project management.

Week 8: Desk Critique Reflection

This week's desk crit went really well! Scarily well! Laz was actually concerned that we'd done so much work that we didn't have much left to do! We convinced him otherwise by explaining the things thathave yet go into the game, such as the UI flow (map pictured below), the upgrade system, the camping system and much more. However I'm confident that, having established solid workflow foundations, we can keep up our output in future weeks and continue to impress. The positive feedback is much appreciated from a morale point of view.

There are a lot of different screens to this game :P

I've been putting a lot of effort into organisation for the group and this has seemed to serve us well! Keen to keep up our frequent meetings, and our use of online collaboration tools. Areas for improvement over the next week include solidification of art direction, along with some continuous teamwork issues we've been having with Daniel Coster (which I've sent an email to Laz about).

I'm very much looking forward to making more and more elements of our game playable (and therefore testable)!

Week 7: Desk Critique Reflection

Today was the day to definitively prove ourselves to be deserving of a green light.

I was feeling quite nervous, but also determined. We'd put a lot of effort into preparing for this presentation. I had Pat help lead the discussion, and made sure other group members were involved in discussion as well (team involvement was one of the key issues we'd learnt of before the break).
It went quite well. We were able to make it obvious that we'd done a heap of work over the break. Laz seemed confident that we were past the greenlight stage (which was a big morale boost!) but we definitely also had some work to do if we wanted to get into a good position with our game.

Feedback points from the critique:

• Work needs to accelerate from this point onwards. We've set the bar here now.
• Design work is solid. Now time to focus on implementation.
• Concept art must be in the game's unified art style (bright pixel art! with nordic accents)

How we plan to address this:

• Clear priorities must be set regarding tasks and work for this subject
• Engagement with Slack must be continued. I'll be chasing anyone up who isn't posting update of their work.
• At the next working bee, the artists will be working on unifying existing art, and set some standards regarding colour palettes

How we managed to pull it off this week:

• Setting very high work output goals for the group.
• I've been very persistent when it comes to chatting to group members about their progress updates.
• We've been very active on our online collaboration tools (Slack, Trello, MediaWiki, etc.)

Week 7: Programming Script Hierachy

Earlier this week I have been working with Daniel T and Pat, the other programmers,  in order to design a system under which to organise our programming.

Some individual programmers may prefer to work ad hoc, but when there's more than one person working with a code repository, certain design considerations need to be made.

What needs to happen (from a leadership perspective):

• Code must be well documented.
• Functions must be implemented according to a specification.
• Class relationships and hierachies must be adhered to.

Having established these expectations with the other programmers, work can begin on the code design. Following is a rough draft of a script heirachy that I worked out as an example to show Pat and Dan:

 We'll refine and expand on this as a team, then I'll define some specification documents and upload them to our wiki for reference.

Mid Sem Break: Meetings and Working Bees

Meeting in person is very important for our team. We meet for an hour or two Mondays, then again on Wednesdays after class in order to compare progress, make sure everyone's on track, and often nut out some of the tougher design problems as a team. Then on the weekend, we come together for a whole day (usually from four to seven hours) for a working bee. That's a minimum of three meetings per week.

At working bees, everyone at in the team gets together with one thing in mind: to get as much work done as possible. We find that working together in the same space is really motivating- you're simply less inclined to get distracted when the guy next to you is working hard.

We run the working bees alongside (but seperate to) our regular meetings. By separating the work from the management/design side of things, we're able to concentrate on issues like integrating our work and establishing conventions etc outside of the design meetings. This frees up those meetings for important, straightforward issues and makes everything run smoother.

Having the programmers and artists work side-by-side really helps with team building, too. Plus, things run so much smoother when it's time to import new assets if the artists and programmers both work on it at once.

Working bees really establish a sense of ownership among the team. The artists get to see their work in action, the designers see the bigger picture coming together, and the programmers get to work with something prettier than the grey cubes they've been using as stand-in models.

Feels good when it all starts to come together.

In short, working bees are great! They work really well for us as a team and we'll keep doing them until the game is done!

Mid Sem Break: Usefulness of Slack as a collaboration tool

Since Week 2, we've been using Slack as a collaboration tool. It's essentially a message board that integrates with all the other team software we've been using: Google Drive, Trello, SourceTree and MediaWiki. Whenever there's an update in these areas, Slack automatically posts in the relevant dev channel. It's been incredibly useful for team communication- especially in the last week, as shown in the following stats:

We've been busy! Lots of progress, but lots more to do before our next desk critique on the 15th.

EDIT:
Here's an update. It grows! To be expected, as the amount of work we need to do continues to ramp up. I'm glad that my organisational skills have been up to scratch so far- seven people are a lot to maintain!

Week 6: Viability Presentation

Our Viability Presentation this week has gone very poorly. We've recieved a red light, and feedback says that it feels like we've moved backwards from last week. Now it's time to figure out what went wrong and how to make sure we can catch up as quickly as possible.

What went wrong?

• A lack of effective communication amongst team members has lead to a disjointed vision of the game.
• We'd only met up twice this past week, rather than the regular three times.
• We've been struggling with design decisions
• There has been a slight lack of collaboration in the past week. It's proven tough to integrate all the artists' work.
• There were some unmanaged expectations amongst the group - some group members were expecting different outcomes this week.
• This is bad! The key to smooth teamwork is having everyone on the same page.
•  In summary, the entire team should have had a hand in creating the presentation.
• What actually happened was that I promised them I'd take care of the presentation, then presented something that didn't align with the group's vision or the task's requirements.

All we can do is look forward from here. Damage control:

• Assessing the situation was the first step to moving forward. Acknowledging what went wrong and why was integreal.
• Apologising to teammates was the next step. As team leader (and the one who wrote the presentation), this mistake is largely on my shoulders.
• Finally, we need to take steps to ensure such mistakes don't happen again.
• From now, all group members will be involved in the creation of presentations
• Presentations will be practiced amongst the team prior to the delivery date.

What have we learned from this? Coping strategies for future:

• Delegating a lot of the content aggregation to individual team members.
• Collating content in a team environment (either skype or a working bee)
• Fully discussing the framework / plan for the presentation before beginning work on it