DDQ: Double Tasking…Will this DOOM us?

As Sprint 4 started, our team headed full steam into production.  We took some risks by double-tasking.

1st sign of trouble…Our producer, Zach was so caught up with helping the team to create art assets that he did not manage the team properly. Things started to go off. Our game designer conceptualized such complex mechanics for the game that it started to get too complicated.  We were deviating from our initial plan.  Our programmers built a random tray array of possible fruits for tower construction and added in a swiping motion for movement on land.

After an external playtest session with our target audience, it was apparent that no one appreciated the tray array.  It was a good call to reduce our scope to focus on just three towers and give players the choice of which towers to build.


Struggles We Faced

We realized that time was running out as the countdown to our first public play testing session, termed ‘Demo Day’ began.

We were all crunching – Zach was helping out with the 3D modelling and animation of our art assets. Yan Yee was busy with sound fx and background music. Pei Xuan was creating the user interface (UI) and environment assets such as rocks, trees, the ground and most importantly, the base. Yong Xin and Zhi Kai just plugged in their headphones and tried their best to code. Zhou Kun and Yan Yee planned and created detailed tutorial levels. We were all just trying our best to deliver the game by the end of the GIP.

Some of the problems faced by our programmers was committing too much time to game features such as the A*star pathfinding (which was really tough) at the cost of other features due to lack of prioritization at our project level.

Production decisions suffered as Zach, our producer became too busy with the art functions, mainly because he was keen on accomplishing the task on hand rather than managing the team. We fell behind schedule as he had to juggle his production responsibilities whilst factoring time to produce 3D art assets to help Pei Xuan who is not really proficient in 3D.

You might be wondering “Why is the game in 3D instead of 2D?” if our artist is not really proficient in 3D.  Our rationale for this decision was to address the following:

  • Unity is more suitable for creating 3D games.
  • Camera rotation in-game considerations to avoid fruits being blocked by stacking mechanics.
  • Sharing out the art assets creation workload.
  • More flexible, easier to scale and more potential to change the design of the game.
  • 3D models can use shaders to improve aesthetics.
  • Saves a lot of time when doing animations.
  • Depth issues for projectiles, enemies and fruits if the game is in 2D

However, as the alpha sprint came to an end, Zach realized that the team was lagging far behind.

With Demo Day preparations, a test plan compilation, sound effects, visual effects plugins and enemies yet to be sorted out, it was an interminable crunch just to get a tutorial of FRUITY DEFENDER out the door.  Were we doomed to be the first GIP team to fail gold submission?

Leave a Reply

Current ye@r *