Sprint #3 Retrospective

This past Friday concluded our third sprint on Sheep Protector, to great satisfaction for both us as developers and our peers as playtesters.

Game/Team Progress

Our game is progressing at a satisfactory pace, however, it feels a bit slower than we would have liked. Our direction as a whole remains intact from our initial high concept and proposal, which we’re particularly proud of; it felt as though the majority of our progress during this sprint was simply refining our concept, something that’s always good to see. In terms of actual progress, we got quite a lot done: all of the bugs we noticed during our MVI playtest were fixed and more core mechanics were successfully implemented, so that we were able to get good feedback on their actual play during the latest playtest.

As a team, we also began implementing different approaches to our project organization based on a retrospective discussion we had after our last sprint. These management decisions were really helpful in making sure that we were all on task and understood each other’s contributions.

Playtest Retrospective

Overall, our second overall playtest went much better than our MVI playtest, primarily due to the fact that we had significantly more game to present now: we had a prototype that included the majority of our core features.

Like with our previous sprint, our goals for this next sprint are to resolve any bugs found in this playtest and keep steadily implementing core and secondary mechanics. Although we didn’t have as much to present, especially when compared to how our finished product would function, the feedback we received during playtest was very insightful in helping us understand the reactions that a variety of players would have to our game, which, in turn, gives us a good direction for what our next sprint goals should be.

Luckily, this time, our playtesters did not report any bugs. Much of our feedback related to the lack of environment that the players were presented with so, for our next sprint, we will focus on creating this environment through gameplay and visual details.

This would include:

• Creating and implementing assets to be used in engine We currently have the sheep and dog as billboarded assets in build. Next, we’d need to texture our map and implement additional environmental art, like a parallax effect in the background, for example.

• Editing UI to be aesthetically pleasing and consistent with assets While this appears simple at first glance, maintaining a consistent aesthetic is crucial to crafting the correct atmosphere for our game.

• Focusing on a finalized map layout This is related to the above point. The map composition will be the foundation upon which we’d develop the aforementioned aesthetic choices. In our playtest, we experimented with a more maze-like map design– mainly to test the barking mechanic– which had rather satisfactory results. Expanding this map base into a final version would definitely aid

• Continuing to implement core mechanics Notably, the “herding” that we mention in our design document, where the player is able to manipulate the sheep’s navigation behaviors without key inputs, is the only core behavior mechanic we have yet to implement. Considering that our other mechanics were implemented with little difficultly or hassle, herding should follow accordingly.

  Moving Forward

  In terms of organizational or management changes, we haven’t seen the need to alter our current sprint or meeting processes. Our current organizational hierarchy, in terms of assigning goals and milestones, is well structured. We distinguish our tasks based on priority– for the last couple of sprints, our core mechanics have been designated as P0, for example– and we decide who takes which task on our weekly meetings.

Going forward, it’d do us well to stick to a formula that works for us to avoid disrupting our current flow.