370 Blog Post 1

    During the first sprint of our project, I did not have very many tasks to take care of. My main tasks as Project Manager were management of the Trello board and the two group tasks for planning our paper prototype and creating a rule sheet. However, this proved to be quite an interesting challenge. Since the original game concept we used was intended for electronic prototyping, we were forced to work backwards to create our paper prototype. The task creating a plan seemed like a filler task at first, but we soon realized the task would take quite a bit of time and planning. For the rule sheet, it was a bit difficult to complete because most of the rule sheet contents were dependent on our plan for adapting to paper. Also, the game idea we used was Usume Jovi-Usude's, and I realized I needed to communicate with him exactly what he was thinking for the game, since myself and Patrick Williams did not actually know much past the original pitch. Luckily, this wasn't difficult to accomplish, and the rule sheet wasn't too taxing to create and use.

    Due to the nature of the project, our paper prototype did not have very many tasks to assign, and none of them ended up being assigned to me. Even the one task that was allocated to Patrick was just the group making sure we all had the correct version of unity installed, since it served as a good reminder for the entire group to check. However, I am sure the further we move into other sprints, we will have more tasks to split among the group rather than a few group tasks and Usume designing the paper prototype levels.

    This development process so far has been very different than any development experience I've ever had. I enjoy working with both of my teammates, and know both of them to some degree going into this assignment. Everybody completed their work within the time allotted, and cooperating on assignments has never been easier. I also love agile development so far, and I cannot believe how intuitive Trello is. It allows me as a project manager to both communicate with my teammates, and ensure the project is being completed in a timely manner. I understand why this form of development is so popular, and I honestly hope I can continue using Trello for future assignments in other classes.

    In terms of issues encountered, our biggest one has been adapting the game idea to a paper prototype, as discussed before. Usume's idea for Landscaping Madness required a physics engine, presumably the Unity engine, to function properly. The game revolves around moving, placing, and destroying blocks at its core, so how would we translate that into a paper prototype? Do we attempt to have gravity monitored by us, the designers, while the game is being play tested?? Well, the game is single-player, so that solution would be quite awkward for play-testers. Do we attempt to add more to make our game seem complex and interesting? Well our scope is already decided, so we can't add too much more. However, we realized we were overcomplicating things somewhat.

    Instead of trying to adapt the entire game to paper, we simply adapted to core functions to create a mechanics test, which in hindsight is the exact goal of the assignment. Usume designed a basic set of two levels, one tutorial and one practice, and myself and Patrick put together a simple rulesheet with emphasis on what could and couldn't be done. We unfortunately did not account for everything, but we were able to garner enough feedback to prepare for the next sprint.

Comments