Duck Master
Duck Master is a puzzle adventure game built on Unity 3D for Production 2 for spring semester. The team consisted initially of 5 members one producer, one artist, two designers, one programmer. By the end of the semester the team grew to 12 members You play as the Duck Master who takes care of his little buddy “duck” across an adventure. This game is played on either PC and mobile.
Contributions
Duck AI
Worked on all interactions with the duck. The duck AI script follows a enumerated state chart. Technically, the duck itself itself is not a fully functional AI and instead of individually doing its own actions it normally reacts to the player’s commands and follow a set of rules.
Grid Pathfinding
The game is tile based movement with puzzles. In order to have the player and duck to move around the puzzle, the A* algorithm is implemented. Because the game is built with the intention of being on mobile, we had to limit the usage of the algorithm to reduce the cost of running the game. The path finding function is contained in its own script and is a static function which then can be called anywhere.
Bait System
The duck bait system is a item targeting for the duck. Currently in the game there are three baits currently in the game. Each bait does varying effects to the duck but the overall purpose of this was give the player more agency.
Challenges
The challenges in Duck Master was like a jenga tower, at first every sprint we would move a piece and add more content not realizing that we were starting to break our foundations. It was until a few weeks before the final build was due and we had to submit the game to QA. The build at the time broke completely and everything went down. None of the mechanics worked and the game was riddled with bugs. Some of this was due to us changing how the tile data structure was built and then some of the data weren’t going through properly. as well as new mechanics. An emergency meeting was called and we had to re prioritize our next sprint. The plan was simple, fix and patch the foundations or the base systems that connect everything. We had to prioritize systems that would cover the most ground and also re evaluation of the current code. A lesson I have learned from this project was that we should get the base system cleaned and polished before moving onto building other systems and mechanics on top of it.
As for team dynamics because of our team expanding from 5 to 12 in the middle of the semester, we did not have a proper team structure set up. Our team leaned to discipline silos where programmers don’t interact much with designers or artist and vice versa. We also did not take priorities and there was a lot of looping back in forth before a conclusion took place. One example was we took mechanics over the game systems as the things needed to be implemented or worked on. Lastly there was a problem of linchpins where certain systems was focused by a single person which means if there was an issue within that system only that person was able to fix it. In our emergency meeting, we did a retrospective and worked on agreements of changing our team structure for the better. Toward the later end of the semester, most of these issues were ironed out.