In an unexpected twist of the events, from now on, I am the new team leader.

Stay on target!

Big news: I am the new Team Leader. Our supervisor let me know this just a moment ago by email. Slightly shocked by the news, I felt compelled to let everybody know about it as soon as possible. Since a rarefied atmosphere has been around within the team over the last two weeks, I have to seriously think of trying to apply a strategy to avoid wasting time and making everybody feel that they all heard along with their suggestions, ideas, and support. Although I have some experience on these issues, we have to make a big effort to put our problems behind and get back to focus on the project.

However, the new condition of our team required a re-evaluation of tasks, as Macklin and Sharp states on chapter 8 of Games, Design and Play: on small teams, the roles and responsibilities tend to mix (a designer who also programs, an artist who handles project manager, etc) and this is a potential reality on our case; so I called a new meeting in order to make each task and responsibility as clear as possible under the current situation.

First thing though, to split the team into two departments: art and development, our supervisor judged that this would not be necessary given the small size of the group. My greatest fear was not being able to appease a very strong feeling of anxiety pushing everyone to get to work on something even if they did not know precisely what. While it was important to make up for lost time It was also imperative to review and reassign responsibilities as follows:

Game design (determination of the game’s goals, play experience): It would continue to be in the hands of the four at least for a couple more weeks.
Programming (coding implementation allowing the game to be played and tested): Phil and Patricio
Art direction (what the player sees while playing the game on art terms): Debbie and Will.
Narrative design (game’s backstory, world, characters): full team.
Testing (planning, organising, running and documenting play tets of prototypes): Patricio and Phil, with my sons (11 and 17 years old) as first line of play testers.
Project management (schedule, tasks distribution): Phil and Patricio.
Music and sound fx (musical score, environmental or ambient sounds): Debbie and Patricio.
Visual fx (particles, shaders): Phil and Patricio.
Marketing (media presence, social networks, website): Phil, Will and Patricio.

Detecting and resolving conflicts in groups

All my experience leading workgroups have been with few members, never more than 4 or 5 persons during very focused projects. Even having done some training in this area, managing groups is not something that I am passionate about.In fact, if my independent animation and game development studio project takes on a larger scale in the future, my first concern would be to hire an experienced manager. Knowing different techniques, tools, and approaches is very handy, but putting them into practice is something that I would rather avoid or eventually delegate, but this is not the case here and I’m resolved to do my best, and to put all my ‘know how’ to bring this ship to a safe harbour!.

Put talented, passionate people together, and you are bound to encounter differences of opinion, personality, methodology, and so on. This is inevitable. The trick is to find ways as a team to work through your differences and turn them into strengths, not weaknesses. (Macklin 2016 :279-282)

Macklin and Sharp also makes reference to 3 main types of conflicts in teams: procedural, affective and sustantive (based upon Woventext by Rebecca Burnett and her collaborators).

Procedural conflicts: does someone feel unheard based on how meetings are conducted? Is the schedule too loose or tight? Do team members feel constrained by or uncertain of their responsibilities?
Affective conflicts: this relates to each member goals, needs, and wishes for the project.
Sustantive conflicts: deals with the commitment to the project and wanting it to be the best it can be.

In our case we experienced a lot of affective and procedural conflicts from the very beginning, being the first category the most noticeable: I discussed about anxiety, some ego problems.

Procedural conflicts are second in importance, but not for that reason neglect: I feel myself part of the problem here, not having not an extensive background using Agile’s methodologies or even a professional use of a version control software like GitHub.
Speaking of the latter, Phil has had the patience to train me in this software, but surprisingly its use is complicated and erratic in the extreme to me. Even at this point, we have not managed to synchronize our work efficiently, and it’s all because of me. This is something that I must resolve urgently to avoid possible friction and loss of time.

Concerning the affective conflicts mentioned above, I’m following my instincts (call it experience if you will), being open to other points of view, developing active listening, and giving enough room to each member to express their feelings and proposals as much as possible. All major decisions are going to be communicate by me via email on a regular basis, each week after our supervisor meetings or personal meetings.

I did not talk a lot about sustantive conflicts because everybody in the team feels that we have a fantastic idea to work with, great individual talents, and commitment to success. I do believe we’re all in the same page here!

Fig - Team Performance Curve for The Wild Branch on Week 3 based upon Katzenback and Smith scheme — Fig 4 – Team Performance Curve for The Wild Branch on Week 4 based upon Katzenback and Smith scheme

Game pillars

While studying more about the concept of game pillars, I found an article that appeared in issue 52 of Wireframe magazine of great interest. This article covers two game development tools that are designed to help decide what’s important in the game you’re making. The iron triangle revolves around the practical realities of making a game, while game pillars cover the creative side.

A game’s pillars are a list of around three ‘core statements’ created early in that game’s development. You could come up with your pillars before you’ve started development to help narrow down the possible game you might make, or you might do this after prototyping has given you an idea you want to pursue. You can even retroactively create pillars to help rescue a game that’s been in development for a while and has lost its way. (Maine 2021)

Each statement should be short – no more than a sentence – and each should be phrased as a rule you will follow throughout development.
Use active language. We will, we like, this game is, our audience wants, and so on. Don’t use negative language if you can rephrase the same statement as a positive.
Make your pillars focus on how your players will feel over the things they will do.

Pillars should focus on the feelings and emotions you want your game to evoke, rather than how you’re going to do it. That’s because pillars aren’t a feature list to check off, more a tool to help remember the things that are important when you’re submerged in the day-to-day realities of game development. (Maine 2021)

Pillars are a tool for staying on track, not for coming up with ideas.
They should serve to guide the creator to make decisions. If a new mechanism, no matter how great it may seem, does not fit these pillars, it should be best to put it aside.

As the author suggests, this is probably the most important concept here, so I’d like to put those concepts into practice enumerating some of our pillars under the central idea of focusing on the sustainability of the environment and the responsible use of resources.

Survival: keep the fire alive to survive on a prehistoric dangerous world.
Scavenging: players are constantly needing to go through the world and search for items and new technology.
Comedy: use humor and humorous situations in puzzles resolution and game mechanics.
Family friendly: safely inquire into survival and exploration without expose young audiences to explicit violence.
Trust: being responsible for the entire tribe continuity and endurance is going to be very rewarding.
Reward small actions: with amazing (visually appealing) outcomes.
It is not our game. It’s the player’s game: let them play how they like and face consequences

It seems strange to express it this way as this is a paleolithic game, but those pillars should not always be set in stone, but it is advisable to avoid changing pillars each time someone had a new ‘great’ or ‘revolutionary’ idea. As the mentioned article warns: changing pillars can just lead to a different – but not necessarily better – game, and going round in circles.

Closer to the pillar (good!)	Neutral	Works against pillar (bad)
Portrait the elder as a wacky character, half chaman half madman
Chopping trees to keep the fire alive with the wood	Picking logs from the floor	Chopping trees for fun conduction to 'deforestation'
Privilege wit instead of violence	Use physical force to overcome situations	Use violence or brutal force to solve problems
Use the music to guide the player towards a goal, or keep the sense of excitment	Use ambiental music to provide a fun atmosphere	Use music for the sake of it
Use pixel art graphics and animations		Use hyperrealistic graphics

The secret of the pyramid

During the creation of my first commercial game, and especially when I had already developed more than half of it, It was becoming more and more evident that it would be impossible for me to finish it the way I would have wanted from the beginning. For this game I’m still having very decent reviews every week, (4 stars average rating over 9.64K installs to this date) but sometimes I also get some hard ones like these ones on Google Play:

Fig 2 – Google Play reviews from one of my games

And what can I say?. They got it right!. Well, almost.

Due to budget restrictions or compliance with the stipulated deadlines (not to mention a pandemic!) I had to start balancing time, money and quality in order to deliver the product. I never lost interest on making the game, as the customer wrote, but I had to face exhausting situations and overcome burnout. To sum up the situation, I found myself trapped inside this infamous triangle:

Fig 2 - The iron triangle representation for Sol 705 and Keep It Burning — Fig 3 – The iron triangle representation for **Sol 705**, my first commercial game, and **Keep It Burning**

As you can imagine, the three vertices on the triangle are all interrelated, and the rule is you can only control two of the three points. So towards the 3/4 of the production I had to make some decisions choosing my priorities. the longer the game stayed under development the more money it was costing me (and it was running out very quickly!). So my only option at that point was looking for time and money, having to make some compromises concerning the final quality of the game (eliminate some secondary passages of the adventure by shortening its duration, leaving some minor bugs alive, etc) in order to release the product on schedule, being perfectly aware that the public was not going to be completely satisfied.

I’m bringing all these facts to the table because, as the team leader on Keep It Burning, I have to deal again with those three aspects; but unlike before, I knew that these decisions had to be made from the very first moment.

Since money does not play an essential role in this exercise, the two parameters to balance turned out to be time and quality. Choosing your game’s pillars helps you focus on what’s important, and choosing which two points of the iron triangle you want to control helps you focus on the reality of making a game or a prototype.

Moving from design to production

The iterative design process is one that takes a lot of time, patience, and energy. But it is also just the beginning: it is the design of the game. There is still another phase to go: production. Production is when the game’s design, technical planning, and other related preparatory work is complete and what is left is building the final game. (Macklin 2016 :404)

Fig 3 - Basic stage of development for Keep it Burning — Fig 4 – Basic stage of development for Keep it Burning

We started to work on some basic routines to control a character over an isometric world following an excellent tutorial on this subject published on 2019 by the official Unity Blog. This article was a great starting point to understand how to work with the Isometric Tilemap support (following by the Hexagonal Tilemap support) which was added in the 2018.2 release of this engine, a full brand new replacement for the previous isometric management system. In addition to this information I found an amazing YouTube tutorial made by Beaver Joe based on the same material but shedding light on some confusing or neglected aspects in the original text.

Fig 3 - Personal notes on character control on isometric projection — Fig 5 – Personal notes on character control on isometric projection

Fig 4 - Early tests for a keyboard control and isometric tiles on Unity — Fig 6 – Early tests for a keyboard control and isometric tiles on an early build

While Will was working on the original pixel art for the tiles, we decided to temporarily use some elements drawn by Debbie for the surfaces and a generic sprite for the character taken from a free asset.

After a few rounds of play testing, we realised that controlling the protagonist with the keyboard had several drawbacks: using the keys to move the main character was extremely confusing, and the tiles were gigantic!

The game map

While working on the Game Design Document we spent quite some time to come up with ideas for the different environments or zones, inside this world. As wood and fire were almost an single entity by themselves our first attempt was to place our heroes inside a forest. It seemed like a good starting point, and the art team was more than anxious to start drawing things!
Note: It wasn’t until many weeks later that we realised that we needed a little more contrast between nature and characters for the level to enjoy a little more interest

Finding our own path

So the next step was very clear: I was going to replace the keyboard controls by a point and click or follow mouse approach, an excellent opportunity to investigate how to apply a classical pathfinder algorithm in unity, specifically on an isometric projection.

With computers, the mouse/keyboard control comes with a whole host of affor- dances—not just from other computer games, but from non-game applications. You can expect players (even those who have never played a game before) to understand the relationship between the physical movement of the mouse and the movement of an on-screen cursor. Computer users can be expected to recognize push buttons and know that left- clicking on a button activates it. (Brathwaite 2009)

Fig 4 - Personal notes on an A* Pathfinder algorithm — Fig 7 – Personal notes on an classic A* Pathfinder solution

I decided to investigate a little more about these methodologies to evaluate if it was worth implementing such a system in our prototype, during this research I find a very detailed paper about of using this A* pathfinding algorithm in an isometric (grid-less) environment in Unity.

The A * method can be implemented well in isometric non-grid games with the requirement to create a virtual grid for search space. A* can solve the shortest path regardless of the obstacle shape as long as the generating nodes have not caught in the dead end. The reason A* lose on the term of shortest path compared to obstacle tracing is that of jagged movement pattern caused by the grid or when the gap between A* node is larger than the gap between obstacles. However, obstacle tracing is better on runtime performance. (Husniah 2018).

Having spent a good part of the weekend testing different ideas (including Unity’s NavMesh 3D navigation system), it seemed pretty conclusive the need to create ‘by hand’ a dedicated grid on our map to aid the navigation. At that point, I was pretty sure we had no need for such an implementation in the prototype, and after discussing the issue with Phil the Monday after, we decided to try using traditional colliders on tiles and objects.

Fig 5 - Point and click controls over an isometric map on Unity — Fig 8 – Point and click controls over an isometric map in a new Unity build using pixel art from Will

There are a number of problems that arise during the playfield design process that should be avoided. First, it can be frustrating for the player if movement through the playfield is too restrictive. There are times, of course, when a pathway has to be restrictive, either because of game engine considerations or because the player‘s suspension of disbelief will be shattered. Players will explore the playfield thoroughly and try to find other possible routes through a level or map, so having only a single path can be a letdown. (Moore 2011 :308)

We faced both of this issues described by Moore and even one more: our first map was ridiculously small and the player’s eagerness to discover new territories made the character go beyond the map’s limits, entering the dark area surrounding him. As he also suggest it helps tremendously to think out a map or level before committing art, programming and design resources to build it. A paper prototype is also useful in this cases as it is possible to play out the whole game on paper before any other teams are asked to work on the assets, and problems can become manifest and resolved early in development.

There is still a lot of work to do.

My very first attempt at a paper prototype. Not useful but fun to make! — Fig 9 – My very first attempt at a paper prototype. Not very useful but fun to make!

List of figures

Fig 1 – Team Performance Curve for The Wild Branch on Week 4 based upon Katzenback and Smith scheme
Fig 2 – Google Play reviews from Sol 705 Complete version on Google Play Store. Screen capture by the author.
Fig 3 – The iron triangle representation for Sol 705 and Keep It Burning, scheme by the author.
Fig 4 – Fig 3 – Stages of development (c) Fueller 2008.
Fig 5 – Personal notes on character control on isometric projection. Photo by the author.
Fig 6 – Early tests for a keyboard control and isometric tiles by Phil
Fig 7 – Personal notes on an classic A* Pathfinder solution. Photo by the author.
Fig 8 – Point and click controls over an isometric map working on my Unity build. Video by the author.
Fig 9 – Paper prototype for Keep it Burning made by the author.

Table 1. Game pillars core statements.

References

Macklin C, Sharp J. 2016. ‘Games, Designs and Play A Detailed Approach To Iterative Game Design‘. Pearson Education Inc.

Burnett R, Frazee, A and Wharton, R. 2012 . Georgia Tech WOVENText version 2.1. New York

Main S. 2021. ‘Plan your game using pillars and triangles’.Wireframe magazine issue 52. Raspberry Pi Publishing.

Di Mento A. 2018 ‘How Santa Monica Studio nailed exploration on God of War‘. [online] Available at: <https://blog.playstation.com/2018/12/05/how-santa-monica-studios-nailed-exploration-in-god-of-war/> [Accessed 12 June 2021]

Pears, M. 2017.’Design Pillars: The Core Of Your Game‘. [online] Available at: <https://www.gamasutra.com/blogs/MaxPears/20171012/307469/Design_Pillars__The_Core_of_Your_Game.php> [Accessed 2 June 2021]

Hinton-Johness A. ‘Isometric 2D Environments with Tilemap‘. [online] Available at: <https://blog.unity.com/technology/isometric-2d-environments-with-tilemap> [Accessed 3 June 2021]

Beaver J. Youtube channel. ‘Making 2D Levels with Isometric Tilemap in Unity‘. [online] Available at: <https://www.youtube.com/watch?v=ruDXAXcgqmE&t=466s> [Accessed 3 June 2021].

Moore, M. 2011. ‘Basics of Game Design‘. Published by Taylor & Francis Group, LCC.

Brathwaite B, Schreiber I. 2009. ‘Challenges for Game Designers‘. Charles River Media.

L. Husniah, R. Mahendra, A. S. Kholimi and E. Cahyono, 2018. “Comparison Between A* And Obstacle Tracing Pathfinding In Gridless Isometric Game,” 2018 5th International Conference on Electrical Engineering, Computer Science and Informatics (EECSI), pp. 489-494

GDD730 Week 4