The Apprentice Returns Postmortem

 The Apprentice Returns: Finale

By Joy Schulze

Role: Programmer

Sprint 5

This was our final sprint of the semester, and after all of the bugfixes we did last sprint, we were able to polish up and connect all the remaining systems and make something that I’m proud to have been a part of. First of all, I had to fix a couple more bugs regarding the UI, mana, and the new inventory system so everything worked together. I then changed the ui to all be pivot based so it wouldn’t look all weird in different resolutions.

Next thing I did was balance the mana values of all of the staffs, which we did several times throughout the sprint.

After that, the only thing I needed to work on was adding the new levels to the build and making sure they lead into each other. However, two of those levels were still being made, so I got to do some polishing. As you can see in the images, the staffs now have models, and they rotate, and they have particle effects. All of that was me waiting for the new levels to be finished and making some fun stuff. While art was not the focus of our prototype, we wanted to tweak the mechanics we had instead of introducing new ones seeing as this next playtest would be our final one, so after fixing and tweaking, art was the only option. Out of all the staffs, I like the fire staff the most, it’s like a lantern mixed with a rocket ship which fits with its super jump ability.

Once the new levels were done, I put the build together, and then we self playtested to make sure we had a build we were happy with. This involved more tweaking, and fixing a couple of collision bugs. The only major thing we added was more convenient options in the pause menu to exit to the main menu or just quit outright.

After that, we packed it up, and turned it in. I feel like this sprint went well because we had just fixed a bunch of stuff and we weren’t adding anything new. I wish we had more time to make levels as our first level is harder than the rest of them, but we have levels that show players all the staffs. It was a good end to a good project.

Postmortem

Across the whole project, I feel the best thing we did was prioritize and get stuff done. 

We all understood the core aspects of our game and got those off the ground as soon as possible. By the first electronic prototype, we almost had all of the staffs created and multiple levels to test them out on (even if one of the levels was only accessible in the editor). While we had to redo a bunch of stuff right after the playtest due to bugs and feedback, that’s just agile development. We had so much more stuff in our project from the get go, so we had a lot more time to iterate and improve upon all of it. By sprint 4, we were basically just fixing and tweaking all the stuff we made.

We also just made a bunch of stuff and we made it pretty fast.

8 staffs, each with 2 abilities

4 levels and a tutorial

5 enemies with 4 variants each

The only downside to all the stuff we made is that not everything got implemented into the final prototype. The things left out were a couple of environmental hazards like pushable blocks and some enemy variants, but that was ok.

I do feel like we had some pretty severe organization issues near the end. At the beginning when our stuff wasn’t really connected by much, it was great. But we didn’t really make a unified plan on how to structure stuff. This was the worst with the staffs as they had to connect to the movement code and the inventory code which was sometimes done in the player script and sometimes done on the staff script. This made it even harder when our lead designer was iterating on the movement and inventory system and we had to change all of the staffs to match. 

I’m also not sure if the designer’s vision was properly achieved. From my knowledge, our producer made all the levels besides the tutorial and I don’t think that our designer had any say into what those levels were. This kind of caused a disconnect from the stuff I was making and the way the game was being put together. Pushable blocks, water, fiery surfaces, and puzzle elements were originally a part of the prototype, and we even made some of them, but none of them were a part of the build at any point in time. There was playtesting or feedback that caused us to omit them, we just never used them outside of our testing scene. 

We also wanted levels where the player would have to choose between more staffs throughout the level to add dilemmas and alternate paths, but that was just never actualized. This may be my misinterpretation of the designer’s vision, but this seemed to be a key dilemma that we should have tested, but we just never got to. Granted, our inventory system wasn’t finalized until sprint 4 and it wasn’t a possibility for most of the time (unless we wanted bugs that allowed the player to pick up all of the staffs), but I do feel ashamed that we did not design a level to try that. 

I also feel that I don’t have much to show for all the work I did. While I did do an equal share of work in the group, I just worked on all the less important stuff. Our designer got first dibs on the base player movement and inventory system, and our producer did a bunch of the staffs and levels, so most of my work ended up being all the smaller stuff. I never spoke out about this to my group, I just let them work on what they wanted to work on because I wanted everyone to be happy and I didn’t really know how this process worked, but I have learned my lesson.

Next project I work on, I want to be a programmer, but I want to actually do most of the programming. I also want a clearer vision from my designer, I don’t need a full design document, but when things change design wise I would like more clarity on what changes are made and why. I really liked our teammates, Jacob and Will, they’re super talented and I would love to work with them again in a more refined structure. I think our strategy of just pumping stuff out worked out well for the very start of a sprint and for making a prototype overall, but on a large scale project I think we need to set some time aside to fix stuff and do more internal testing to make sure we aren’t just pumping out buggy nonsense.

I also think that we need to establish organization at the start. We made a group google drive and used a trello board, and a couple folders in unity, but we got unorganized pretty quickly. In the final sprint we organized a couple of things but it was too little too late. I now understand why our major has very strict file structures and naming conventions, it would make things a lot easier.