DREAMWILLOW

ABOUT

A long term project completed over the course of a semester by around 30 University of Michigan students, Dreamwillow is a lighthearted faux top down twin stick shooter about a necromancer ressurecting their foes to help them escape a dark forest.

DEVELOPMENT INFO

  • Developed by WolverineSoft Studio
  • 3 month development cycle (09/08/2019 - 12/08/2019)
  • 30 developers
  • Made using Unity Engine

CONTRIBUTIONS

  • Programmer

POST-MORTEM

WHAT WENT RIGHT

  • Programming based on UnityEvents allowed for abstract interfaces between code, audio and animation
  • Pod system allowed consistent communication between different departements working on the same task
  • Usage of Jira Project Management Software allowed for transparency of who was working on what and how the team was doing as a whole



WHAT COULD BE IMPROVED

  • The lack of clear documentation guidelines and requirements led to decentralized and outdated documentation as the game grew - programmers had major parts of their tasks changed mid-sprint
  • Workflow continously changed during sprint, requiring members to learn new skills during sprints
  • Severe lack of code reviews led to buggy code making it into production
  • Very little time was spent on preproduction, resulting in many mechanics not being fully desgined before programmers were tasked with implementing them



LESSONS LEARNED

  • Far more time needs to be spent in pre-production, to hammer down mechanics so programmers can easily implement them without worrying about changes
  • Use some form of structured documentation software, such as Confluence
  • Clearly and quickly communicate any pivots or changes in design to programmers

CONTRIBUTIONS

My major contribution to this project was the implementation of the shop. Due to not enough time spent in pre-preproduction, the shop design was revamped multiple times throughout development, sometimes even during sprints. It was my job to initially implement the shop, take care of these problems and reimplement features when neccessary. Initially, the player was supposed to be able to buy upgrades to their main attack in addition to health and extra necromancy slots. The proposal was that players would be able to pick up an attack upgrade, test it out, but if they try to leave the shop without paying, the door would close and stop them from leaving. This was implemented within a few weeks, and the player was able to test out the new attacks. However, to the end of that sprint, it was decided that the player would not be able to upgrade their attack. So, that option was removed, but right after the sprint, it was again decided that you would not be able to pickup items, and you would simply buy items on the spot without having to pay by going up to the shopkeeper. At this point, I should have simply rewritten the entire shop system from scratch, as many of the features had been removed, and the complicated eventsystem that was in place was entirely uneccessary. However, I decided to just use what I had already created. This made it difficult to further update the shop whenever anything was added, because I had to go through the system that I had implemented, instead of having a simple trigger based system. However, I did end up finishing the shop, and it currently perfectly functional within the game.
During production, I learned a very important lesson, and it is that not all my work will always make into the game, so I should cut my losses as soon as possible to avoid uneccessary work.