Conclusion (Reflections)

What was your overall assessment of the process, and the outcomes?

Overall, I've truly enjoyed this process. I've done a lot of work, learnt a lot more about project management (which is extremely valuable to me), and I've had a hand in creating a game that I'm really proud of, and even in its current form would make a solid professional portfolio piece.

Our team works really well together- I've made some incredibly valuable contacts and I'm absolutely looking forward to working with them on Heroes of Yggdrasil next semester!

What role did you play/tasks assigned that was least satisfying to you?

Sound effects! Creating so many low-bitrate SFX was very taxing, took a long time and wasn't very rewarding.

On the other hand programming the sound management system (audio channels, pitch shifting, etc.) was quite rewarding.

In the future, I'll recognise how much work of that type is too much for me to handle on my own. Dividing the task into a sub-team of sound designers would have made the task much more manageable.
An alternative strategy, when it comes to a task of that size, would be to attempt to spread it out across a number of weeks.

What were the tasks undertaken that most used your skills and abilities?

Team management. Since starting uni, I've come a long way in terms of leadership. I like to think that there's no such thing as a team that cannot work well together. This might be wishful thinking - however - the principle behind my thinking is that given the right environment, communication frameworks and guidance, any team can excel. The main issue is that a lot of teams lack the motivation to improve teamwork pipelines.

As I'm hoping go into postgrad study, project management is an important skill for me. Plus, I enjoy it!

What were the lessons learnt with regard to time management, task planning and team processes?

One of the most interesting and important lessons I've learned this semester has been how different individuals will perform best in different environments. For example, one of our artists works best in his own space, at the time he chooses, free from distraction. On the other hand, on of our programmers needs a social/team environment with the expertise and opinions of other people to draw from.

Learning how to manage seven individuals like this (including myself!) has been extremely worthwhile.

The key to task planning, I believe, is establishing common expectations among all group members. If the group as a whole knows where we're headed, how quickly, and for what reason, the team members will work well together. When expectations are mismanaged, serious problems begin to arise. (See our viability presentation for that!)

What plans do you and your team have for the next phase of development of your project?

We have big plans! I'm quite excited to continue work on the project.

• We'll be expanding the playable character roster with unlockable heroes that have unique abilities
• Combined with our existing implementation, this will deepen our iterative gameplay and make each run a different experience.
•  Jotunheim, the world of the Giants. An icy realm with mountains, caves, and constant snowstorms
• New level generation and environmental challenges will give this world a much different feel to our existing world, Midguard. Having multiple realms will give our game a deeper sense of progression.
•  Level bosses and minibosses. These combat challenges will be a true test of skill for players of our game.
• Expandsion of the enemy roster with new enemy types such as flying or shapeshifting enemies.
• This will vary gameplay from level to level and widen the application of our party-switch mechanic.

If you couldn't tell, I can't wait to increase the fun and testability of our game. We have a very solid proof of concept, but it could be so much more! I'll certainly be working on this project over the holiday break.

Week 13: Presentation Skills

Since the Moot Pitch, I've been thinking about my personal presentation skills. It's an interesting case.
Naturally, I'm not particularly gifted when it comes to public speaking (which isn't uncommon in my line of study). Consequently, I've put a lot of effort into improving my presentation skills - which, for the most part, has paid off. I'm familiar with my own strengths and limitations, I hold a lot of extra-curricular positions that involve presentation, and I'm employed as a tutor for IFB103 where public speaking is my job for multiple hours a week.
At this point, I consider myself a very competent speaker. There is, however, an exception: I only maintain my confidence when there's a power imbalance in my favour. That is, when I'm in some position of power over my audience, I'm able to control the atmosphere of the presentation and keep myself in a comfortable state of mind.
Unfortunately, due to the nature of industry-style presentations, the power imbalance is always against me. This seems to consistently catch me off guard, and my presentation skills regress to a level of confidence I thought I surpassed years ago. As you can imagine, this is very frustrating for me!
I know I'm capable of more. I just need to figure out how to channel it!

EDIT:
Further thoughts -
My "power imbalance" theory is somewhat affirmed by my presentation in week 3 - when I was addressing the class (trying to gather teammates), rather than Laz and Alex, my presentation was much more confident and effective.
How I can use this -
Changing the angle at which I view the presentation could benefit my presentation. If I view it as "convincing industry professionals to invest in my game" rather than "presenting my game to be judged," chances are I'll do much better.

Week 13: Moot Pitch Reflection

I've just come out of my Week 13 Moot Presentation. Overall I think it went soundly. A few of my own key reflections on the presentation:

• Unfortunately, my presentation skills could definitely have been better. I'm disappointed with how I presented.
• I lacked confidence
• Nerves caused me to skip through a lot of content
• Our trailer was very satisfactory
• Particularly the teaser image of Fenrir (which I was excited about) :P
• The sell sheet was up to scratch
• Our slides were visually appealing and showcased game art

How I might improve for Monday's final presentation, in terms of speaking skills:

• I'm considering using a script on Monday. Not to read from- just to remove the possibility of skipping important information.
• I'll need more rest before Monday. Week 13 is an exceptionally busy time, but being rested for the final presentation is a priority.
• Change my outlook - I think approaching the presentation in a different mindset (converting nervous energy to excitement, for example) will help me to come back into my strong suit in terms of presentation.

Following the presentation, the PartyQuest team met up briefly (as per custom) to discuss our individual reflections on how it went and what could be improved. As always, notes have been compiled and posted to Slack and Google Drive.

Week 12: Coding tools to make design easier

This week I've made a few alterations to the inner workings of our character movement script, with the intention of smoothing out the workflow for designers.
Essentially, designers need to be able to tweak the movement values for each of our characters quickly and easily for the purpose of testing.


The old system:

• Input: Jump force
• Input Gravity
• Output: Character jumps, although you won't know how high until you test it.
  

The new system:

• Input: Required jump height
• Input: Gravity
• Output: Character jumps using the required force, as calculated according to inputs.

An aside: I had to use derivitives to calculate this- I haven't done this stuff since Grade 12! It was quite difficult.


This new system is much more accomodating to designers. In future, I'll definitely be considering "designer-friendliness" when designing scripts and script relationships.



As a side note- I've also done a fair amount of work on the camera movement this week. We now have fluid and intuitive camera movement, both horizontally and vertically. This will allow for vertically scrolling levels in the future.

Week 11: Bug or Feature?

A quick update this time:

As part of my work this week, I've been helping Dan Troy program character knockback. As a matter of convenience, we've been using the characters' maximum horizontal speed and ther jump height for this. We were intending on changing these values, but...

As it turns out, it's quite a cool feature. It means slower characters are affected less by knockback, while speedier/lighter characters get knocked further! This is a feature that aligns with our party mechanic, but it's not something that we'd thought of on our own.

Week 10: Teaching Group Members New Skills

A team management problem we've had this week:

In order to implement enemy AI in the system they'd designed, our programmers needed Finite State Machines (FSMs) to describe enemy behaviour. Unfortunately, our team's designer, Shea, hadn't ever heard of an FSM.

This is what he was able to supply us at first:

I organised a meeting, so that Shea could describe his vision of enemy behaviour to the programmers in-depth. However when it came to implementing the behaviour, we found that we still didn't have enough information.
Rather than making behaviours and conditions up myself, I figured it would be worth it to teach him the ins and outs of FSMs so that we could continue to work through that pipeline in the future.

Shea's first attempt:

Definitely not what we're after. Following some feedback, here's Shea's second attempt:

Closer, but still not enough information. After working with him alongside an in-depth conversation and referring him to some online resources, here's the third attempt at an FSM for the behaviour of a wolf enemy:

Much better. Now we have something useful for programming, plus an infinite supply of more FSMs for future enemies. Reminds me of the quote: "Give a man a fish and he'll eat for a day. Teach a man to fish and he'll eat for a lifetime." And, in this example, he'll feed his other group members too.

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

Week 5: Change in setting! (PART TWO)

As a group, we'll need to do a lot of research and background reading about Norse mythology in order to get the most out of our style. We've opened a new channel on our Slack collaboration called "#research". We've been having some interesting discussion as a team and have found the setting to be influencing our design choices in unexpected ways!

I've stopped by the library and got some books out.
[image]
This should keep me busy over the weekend!

Some examples of how the setting has ended up informing our design:

• It was already decided that the player could purchase permanent upgrades between in-level "journeys". We've now realised that we can use the Norse concept of magic runes for this purpose.
• Odin's raven companions, "Thought" and "Memory" served to survey the land and report their findings to him. In our game, these could be used as scouts, gathering information about upcoming levels. This would help the player to read the situation and make better choices regarding party composition.

Week 5: Change in setting!

Problem: Feedback informs us that our classic D&D-inspired fantasy setting is very generic and lacks any eye-catchingness. Consideration shows that this is true, and causes me to acknowledge my bias.

This was a big issue that needed to be solved ASAP so that we could continue to move forward with our design work in time for next week's presentation. It took us three meetings in the space of three days to come to a conclusion! Some of the hardest work we've had to do so far.


Step one: brainstorming! Two potential new settings were thought up:

• A steampunk/neo-victorian era world. 
• "Retro-futurism," an 80's style take on sci-fi. 

These very new ideas would certainly bring some uniqueness to our game. Our artists were encouraged to create some art as a demonstration of how these settings would work for PartyQuest:

After an intense group discussion, it was largely agreed that the main unique feature of the game would still work best in a fantasy setting- the party of heroes undertaking a quest. We were able to come up with three new fantasy settings:

• A world set in Scandinavian mythology, 
• A dark mysterious magical forest, 
• A world of floating islands prominently featuring skyships. 

While these are still fantasy settings, they are no longer generic- they posses a unique flair of their own. This is exactly what PartyQuest needs.

Following is some concept art grabbed from the net:

Dark and magical forest

Vikings and gods!

Sky islands

It took a lot of refining before we were able to decide that the Scandinavian/Viking setting would work best for us.

---------

Bonus edit:
In our discussions, the idea of combining settings was discussed. A very novel idea arose from this: A Scandinavian viking + 80's sci fi mashup. The idea of gangs of vikings wandering the streets wearing varsity jackets really appealed to me :P

Drawn by me.

This idea was actually taken seriously! However in the end we determined that it was too abstract of a concept to communicate in our game- we wanted the focus to be on gameplay and how that worked with the world, not on storytelling.

Week 4: MediaWiki

We have a new organisational tool this week! MediaWiki is an open-source PHP wiki package, that can be used to host Wikis of any description.

I've used wikis in game development before- they can be an excellent resource to be used alongside the game design document.
All the technical information about the game should go in the wiki. By giving each Class, Scene, Script, etc its own wiki page, it provides a logical way to list dev info such as animation lists, functions and their access levels, UI elements, and anything that's relevant. It also makes all this info accessible and easy to search.

One of my first tasks this week is to populate our wiki with some basic pages and categories. From there, other team members will be able to fill in some info about character stats and the level generation algorithm. The wiki will continue to grow alongside our game design info!

EDIT: We've now integrated the wiki with Slack- team members will now be notified of any new pages or edits!

Week 4: Making Players Want To Swap Characters

One of the main mechanics in PartyQuest is the ability to swap between different playable characters that have different attributes and abilities.

A constraint in our current design is that it must be possible to complete any given section of level with any character- if all your ranged heroes are dead, you still need to be able to progress using a melee hero! Otherwise there would be a lot of frustration.

An example of why levels must be beatable with all hero types. Excuse the stickmen!

Some of the most important feedback from Laz in Week 2 is that players may become attached to a single hero, and only feel the need to use that one. This leads to a situation where other heroes go unused, and if/when the favoured hero dies, there is no reason to continue playing.

Thanks to my new group members, we were able to come up with a solution at today's meeting!

The Damage Triangle

Each character will have one of three "damage types". Certain damage types will be super-effective against certain enemies! This rewards players for swapping to the correct character, and encourages keeping all characters alive. If a player was to lose one of their characters in combat, they wouldn't be too harshly punished, either. We're confident that, if executed properly, this is a great solution to our problem.

Week 3: Final Game Pitch

Final pitch presentations were today. I felt a little unprepared- I might have been able to improve the way I presented. Regardless, I got the necessary information across and recieved some valuable feedback from Laz and Alex.

Below are the key points of feedback (which I've fleshed out a little):

• Refine scope
• Present a defined narrative
• Character personalities/backgrounds
• Setting and story 

• How our "retro fantasy theme" is different to other 80s fantasy games
• Draft some art:
• More character art (with narrative)
• Background art
• Level art
• UI Elements

I aim to address these points at tonight's team meeting, and have solutions to present at next week's "desk critiques".

Week 3: First Team Meeting

After recieving a lot of interest in PartyQuest, I organised a team formation meeting (using a Doodle Poll to do so. Great tool.) which took place this afternoon.

The meeting overall was a great success. Following an agenda, we were able to quickly introduce ourselves and nail down all the important team formatting issues.

The meeting's agenda.

Key points of the meeting:

• The team will include a full suite of seven members.
• Three artists
• One designer
• Three programmers
• The individual team member's skillsets allow for a lot of cross-disciplinary work, including sound design and UI design.
• We'll be using Unity, BitBucket (with the SourceTree client), and Game Maker 8 (for rapid prototyping)
• Team meetings will follow the scrum format, effective immediately.
• Three weekly meetings. Meeting times are as follows:
• Mondays from 3:30pm
• Wednesday tutorials from 9-11am
• Weekend "Working Bees" with flexible hours, on Saturday or Sunday

Week 2: Second Pass at Pitches

The main points to reflect on following the Week 2 round of games pitches are:

• The reception of my game pitch

and

• Interesting points of other game pitches

To begin, I believe my pitch was well recieved amongst my peers. I attribute this to having an engaging presentation and being able to effectively convey my vision for PartyQuest.

Including GIFs like this in my presentation helped to draw and maintain attention without distracting from what I was saying.

Important feedback points:
In my presentation, I presented two different options for game progression:

The audience was most receptive to the "one big level" idea. This is due in part to the "campsite" mechanic I presented, which fits the game very well thematically.

Following the presentation, a very important point was presented by Lazaros. How do you effectively encourage players to swap between characters? I'll need to consider this in-depth before the final pitch.

Other Game Pitches
The pitches I was most keen to hear the progress of included: Point the Way, The Skeleton War, Icarus (previously The Super Ultimate Championship Games of the Universe), The Red Enemy and Cobra.

After putting so much critical effort into my own presentation, it was hard not to be critical of other presentations! However for the purpose of reflection and group formation, taking a positive consideration as well would be beneficial, so I'll strive to do that.

The best and most interesting points of the day included:

• "Icarus" has come a long way from the initial concept. It's now quite simple and almost a little elegant. Could be fun to work on.
• Cobra has had a change in focus as a response to feedback from the last pitch.
• Point the Way has a great concept, but seems exceptionally difficult to execute. While I really like the idea, I'm inclined to stay away from that project.

Week 1: Refining My Pitch

During my first pass at the game pitch, I didn't use a PowerPoint presentation. While this was fine at the time, it would've been a benefit to me regardless! So for Week 2, I intend to create something especially nice to look at.

I personally hate presentations that are all text- I believe that a few pretty images go a lot further than repeating yourself via text. This has been reinforced after watching the Week 1 pitches.

Ideally, my presentation will have:

• No more than two lines of text per slide. (EDIT: Harder than it sounds...)
• Pretty GIFs.
• Images that are examples of what I'm talking about.
• At least one diagram.

EDIT: Here's a link to my finished presentation!

Week 1: Initial game pitches

For the first tutorial, everyone with a game idea presented their pitch; including me.

It seemed like a marathon event that ran from 9 til 2:40.

I elected to present two ideas- a "party-based platformer", and an RTS called "Forbidden Forest". I received some very good feedback that helped me to decide which game to stick with for next week's pitches and how it can be improved.

The largest and most important pieces of feedback I recieved were to cut back my scope for the first game, and to narrow down my idea for the second game. Some of the implied feedback that I picked up on is that my first idea requires a sharper, more eye-catching and unique hook.
Lazaros suggested that in order to properly develop my game ideas, I should cut one now.
If I am to cut an idea, my intuition says I should stick with the party-based platformer. This is because it seemed to have a warmer audience reaction, and possibly more potential. More reflection on this will come in a later blog post.

Some of the stand-out pitches of the day (from my view) included:

• Skeleton Wars
• The Red Enemy
• Unnamed Side-Scrolling Arcade Shooter & Unnamed RPG Racing Game

Skeleton Wars seemed like a very novel concept- the use of bones as a team-wide health resource. I enjoyed the uniqueness of this mechanic, and thought that some of the other less interesting areas of gameplay (combat, match objectives) could be changed to embrace the bones mechanic more fully.
I personally am wary of working on the project, simply due to the fact that my ideal vision for the game may be too different to the pitcher's.

The Red Enemy had a great setting and narrative. I feel that the gameplay described may be somewhat lacking, but this could be changed to more fully embrace the game's strong points- the story.

The ideas presented by Robert (Unnamed Side-Scrolling Arcade Shooter & Unnamed RPG Racing Game) were very novel and eye-catching! Unfortunately he seemed to require no further programmers.

I've requested the presenters of these games as "connections" on LinkedIn.