For the last few weeks, my team and I have been scheduling our workload for our project called Wild’s Pyre.

We first worked on our Project Breakdown Structure (or PBS) as a team. We quickly created a flowchart and separated our project into 5 main sub-deliverables; each focusing on the documentation, art assets, audio, level designs, and programming necessities our project needs. We then broke those sub deliverables down even further into general elements our project needs, such as 3D models and particle effects in the art sub-deliverable. Each of these elements in each sub-deliverable should be ordered by their level of importance, but is instead ordered by a level of completion, where the first elements are worked on first and the last elements are worked on after those. I don’t agree with this structure, as game design is an iterative process where designers will frequently return back to some elements when needed. We then assigned values to each element, deliverable and sub deliverables, where the final project would be 100%, each sub-deliverable is a percent of the final project’s percentage, and each element is a percent of the sub-deliverable’s percentage. Now, these percentages should be representing something like the amount of work that will make up the entire project, and I expected and assumed this too. However, the team had apparently decided the percentages were the level of importance of each element, which I am still not agreeing with. I only learned of this when we got to the last few elements we needed to decide a percentage for, so for the most part I agree with the percentages if they represented the amount of work needed for that element.

We then went on to work on our Work Breakdown Structure (WBS), and this has gone smoother than working on the PBS. We split up and worked on each section individually, and I was working on my own programming tasks. I decide to further break down the elements from the PBS into things like the player’s functionality being comprised of their movement, what they can and can’t move onto, and abilities like jumping into the air when they explode. It was decently difficult listing what programming-oriented tasks were needed, since I know the known knowns and known unknowns of the project, but I don’t know the tasks that fall in the unknown unknowns category, and thus cannot properly write about them. When it came to setting the duration, even if it was an approximate amount, I found it was really surprising just how difficult it would be to assign that duration to a task. We each have other things in life and classes that we need to keep our attention to, and if we gave an equal amount of work to each of our courses, most of us could only give 20% of work to our project. There could be other hiccups such as unexpected emergencies or outings that can reduce the amount of time one can work on the project. I eventually settled on what I thought was a regular amount of time plus an extra day in case of any emergencies. I have found that it’s better to ask for more time from higher ups and be early than to not and be late with finishing something.