This is a combination of the planning and retrospective documents from the third sprint of the game, reformatted and uploaded here for your viewing pleasure.

Planning Notes

Goals

Our two main goals for this sprint are to build upon and polish the work we’ve previously completed over the last sprints. At the end of the last sprint we finished the core components of the game and now we intend to continue to add onto that base. This includes adding things such as enemy variants, enemy attacks, and overworld objectives. We also intend to polish some of the rougher edges from the previous sprint to create a smoother running core loop.

Planned Improvements

• Overworld Objectives
  • In our original plan we intended to have the bees you befriend terraform the planet you're playing on. So we would like to have them make some sort of change to the environment. At this stage, we are going to implement a system wherein befriending enough bees opens a door to a new area. 
  • If we have enough time we would also like to implement a visual change to the environment in an area each time you befriend a bee. This would be to show the player that they are making progress in their objective to revive the planet. This is a lower priority objective. 
  • Working on This: Alessandro
• Enemy Attacks
  • We are going to add in enemy attacks to make the core gameplay loop more engaging to the player. For this sprint we would like to implement at least one basic attack that would damage the player if they tap the bee at the wrong time. Time permitting, we may add one or two more, otherwise that can be saved for a future sprint.
  • Working on This: Alessandro, Mike
• Enemy Variants
  • Another aspect of our original pitch that we would like to implement are simple enemy variants. In order to keep combat fresh and fun for players, we planned on having bees with different hats, outfits, stats, and potentially even attack moves (time allowing). Changing the outfits on the pre-existing bee sprite would drastically lower the time taken to create different enemy types, and would make the bees even more cute and endearing to the player (hopefully motivating them to continue playing and to save the bees’ home world). We’ve planned ahead while coding for variant bees as well, so we can change the amount of health, speed, time they take to rest between movements, how often they attack, and damage dealt between each variant bee.
  • This goal will probably roll over into the next sprint as well to keep the enemy variety up.
  • Working on This: Abby, Alessandro
• Tilemaps in the Overworld
  • Now that we kind of have an overworld in place, we can work on bringing it to life. For this project we’ve decided to use Tilemaps and Tilesets, so we can quickly change things up as needed.
  • Basically, the plan is to add in the actual Tilemap system and start working on the layout of the world.
  • Working on This: Cori (Layout), Abby (Tilesets)
• Buggy UI
  • The UI still has some bugs. Nothing game breaking, but things that we would prefer to iron out sooner rather than later.
  • This pretty low priority so if it has to be pushed back until the next sprint, it definitely can.
  • Working on This: Cori

Possible Roadblocks

• Communication Dies Out
  • If we don’t communicate as often as we should, we will definitely run into some major issues. We’re at the point where we can no longer work within our own little bubbles on our own parts of the game, so communication will be the key to our success. Thankfully, we’ve set up some plans like using our team slack over discord to encourage accountability and our Trello board to make sure we know what we’re all doing even when we can’t talk with one another.
• “Communication” Between Scenes Doesn’t Work
  • Two of our goals—“Overworld Objectives” and “Enemy Variants”—rely heavily on the ability for information to be passed between the overworld and combat scenes in Unity, which was something we weren’t able to implement for the last sprint. If we once again are unable to successfully pass info between the two, we may be unable to implement two of our goals. We plan on mitigating this issue by having multiple people working on it immediately—that way we can change our plan early on if necessary. We can also potentially circumvent this issue by limiting the information being sent between the scenes; ex: maybe every bee on the overworld would look the same, but it would be a random variant once you enter combat.
• Other Things Come Up
  • As always, we can’t exactly control how busy we are and how much work other classes give us so there will probably be times when we can’t all work on things as much as we would like. As long as we keep in touch with each other and communicate often when such things occur then this shouldn’t be too much of an issue.

Retrospective

Game

What went right?

We were able to successfully iterate on our MVP from the last build and create a more in-depth experience from the last sprint. We accomplished this by adding a more detailed overworld, a more in-depth and fully realized combat system, variant enemies, and music/SFX. Though the length of our game hasn’t changed—it’s still only a demo—the entertainment value of our game has drastically improved thanks to all of our additions and improvements. We were also able to complete most of the goals we had laid out in our planning document too, which will give us more time to work on making our little demo into a fully-fledged game. We were also able to fix our issue by integrating each other's code from last time, which was a nice touch.

What went wrong?

One of the bigger problems we faced with the development of the game was that some of us had trouble finding time to work on the project. This issue was also magnified by the increased workload we’ve all been receiving from other classes due to the semester ending soon. For better or for worse we planned to do way too much work, so we were still able to get a lot done, just not as much as we would have liked. Another issue we ran into was with version control. We had an issue pop up where work was lost due to a merge error and to restoring old code. Thankfully we were able to redo it relatively quickly, but it was still time an energy wasted that could have been spent elsewhere.

What would you do differently?

If we could redo this sprint, we would definitely be less ambitious with our planning doc. Even though we accounted for the possibility of us not getting through all of that work, it’s still disheartening that we weren’t able to get it all done. We’d also start pushing code to different branches on our github to ensure that we don’t accidentally ruin someone else's work or push broken code.

Team

What went right?

Even though it wasn’t as much as we had hoped, we were still able to get a lot of work done this sprint, thanks in part due to our improved communication. Like we planned in our last sprint retrospective, we have been using Slack and Trello more to communicate and keep on top of our work and increase our productivity. Our group has gotten significantly better this sprint, and we’ve all been working pretty well together.

What went wrong?

Thankfully, not too much went wrong this sprint with our team; everyone worked efficiently and to the best of their ability. The biggest issue we had was that most of us missed one or two stand-ups with Emily/weekly team meetings. We kept this from being too big of an issue by filling in each other on what was missed and by updating Emily through Slack.

What will you do differently next sprint?

Next sprint, we’ll do our best to keep track of scheduled meetings, and will try to remind one another when they are to ensure that we all attend them. Otherwise, there isn’t much we’d change with our teamwork and group dynamic from this sprint.