Greetings! We are Team ULTRABIRD, a group of three university students. Half a year after releasing The Legend of the ULTRABIRD, we are now excited to share with you our new game Minesheeper! We developed this game over the course of four weeks, and we hope that you have a lot of fun playing it. This devlog is a postmortem on the game's development. In it, we will be answering a few questions and speaking about the experience we had.

Team ULTRABIRD
Justin (Rxlling_Pxly): Programming (player, level generation, camera)
Blythe (MAGPIE1o1): Programming (tutorial, dialogue, UI/UX, sound)
Michelle (Fyropi): Art (3D models, animations, visual effects, illustrations), programming (art implementation)

Questions

What did you change from the initial plan?

• We initially wanted to implement saving/loading, but then realized we didn’t have enough time and that it wasn’t too important for our game
• We stuck to classic minesweeper gameplay instead of something more action-oriented (initially we were looking into modifying the minesweeper format to be more actiony)
• But overall, a lot of our original plan ended up making it into the final version, we think the vision was pretty clear and well-realized

What went right with your final project?

• Looks and feels great
  • Sheep animations (idle, looking around, eating, flagging, jumping) all look smooth, and the eating particles add juice without being distracting
  • Block physics: block generation looks great, as does the explosion
  • camera juice: panning/rotating has a subtle drag/acceleration effect
• Scalable
  • Tried to limit hardcoding
  • Game can generate levels of many sizes, difficulties, and terrain looks (elevation of blocks is randomized using perlin noise)
  • Dialogue system can support dialogue in scenes other than what’s showcased in the tutorial, supports pauses in dialogue, preconditions for dialogue triggering, and events associated with dialogue lines

What went wrong with your final project?

• Issues importing the models we made
  • Not all animations imported properly (fixed)
  • animation controller and triggers were hard to design (some animations not playing/playing at the wrong time)
  • blender to unity pipeline not very reliable, ended up using .fbx file for the models instead of .blend files
• Issues building the game (build initially did not include the tutorial for some reason)
• Lots of merge conflicts
  • Led to a lot of extra work, had to stay up very late to finish (almost didn’t have time for sound effects)
  • Confusing, we weren’t sure how to resolve them at first
  • Unexpected difficulty due to there not being many merge conflicts earlier in the project

What would you do differently next time?

• Justin
  • Right now what comes to mind is making my own implementation for creating drag for the player sooner. For the majority of the game's development, the player had no friction and the only thing that was stopping it from sliding endlessly was the drag value on its rigid body. This approach worked and it felt pretty nice but that was only because it had to face a very limited amount of scenarios. When it became time for the player to start moving on uneven surfaces, and get exploded, that approach started to fall apart. Things in real life have friction and work because there's friction, and so I realized later on that I should have stuck closer to reality with the player if I wanted to have real things such as explosions.
• Blythe
  • Before this project, I had never implemented my own dialogue system from scratch. It was deceptively difficult; there were a lot of core features I had taken for granted while using other dialogue systems/writing-oriented programming languages that I now had to spend a lot of time implementing myself (line breaks/pauses, preconditions, dialogue events, different dialogue boxes, etc.). And while I’m proud of the work I did, looking back, there were a lot of ways to make my implementation more organized and efficient. For example, creating a Character class would’ve made it less tedious for me to assign dialogue (rather than having to manually select the right portrait and name for each line). And if I had to make another dialogue system, I would take the time learning how to incorporate JSON files. Minesheeper’s dialogue was written in the Unity Inspector, which made it difficult to organize and keep track of (along with being prone to bugging out). It was fine for this game as the tutorial was fairly short, but it definitely wouldn’t have worked well for a game with more narrative.
  • Another thing I’d do differently next time is pay attention to the execution order. I had no idea that the Unity editor approaches execution differently from actual game builds, so I spent a lot of time struggling to figure out why certain features were working in the editor but not the actual build of the game. It took hours of combing through the build’s output log text file and writing debug statements to finally understand the issue. But now that I’ve had this experience, I know how to prevent it in future projects (and now I know how to use the output logs).
• Michelle
  • All of the 3D models in Minesheeper were made by us in either Unity or Blender. Although it added a nice touch to the game, it was really time consuming to model, rig, animate, and export Blender models over to Unity. Next time I would consider using more premade assets. I chose to use low-poly 3D models for this game because they're the easiest to make but next time I definitely want to try making and using more detailed 3D models. I would also experiment more with terrain texturing.

If you could add one more week of development, what would you add?

• Justin
  • Sound and particles. I was going to add these things in the last week of development but I miscalculated how much time we had left to complete the project and so what I thought was the second to last week of development actually turned out to be the last.
• Blythe
  • I love writing! And while Minesheeper isn’t a narrative game, I definitely think there’s room for more dialogue. I had a lot of fun writing for the tutorial (especially trying to include as many crow and sheep puns as possible) and it’d be great to have some more NPC interactions in the main levels as well.
  • It’d also be nice to add an achievements system. I think it’d be fun to include NPC reactions to specific achievements (e.g. filling every block in a level with poop) and, for hidden achievements, find ways to hint to players how to get the achievement without telling them outright.
• Michelle
  • If we had more time to work on Minesheeper, I would add more NPCs, background decorations (forest, flowers, etc.), particles, and improved 3D models. I want the game to look even more aesthetic and polished.