Cataclysm Cleaner
June 2018. The world has been devastated. Destroyed by its own inhabitants. Our game attempts to convey the destruction of climate change and life changes it would dictate. Our game contains absurd-ism as we created a sole player, the janitor, whose job is to clean up this destroyed world without destroying himself. His oxygen is limited and he must spend each day collecting and incinerating garbage. We decided that what would make the game absurd, would be having a janitor trying to clean something that is literally a global catastrophe. Through the level ups the player can get, we hope to give them some sense of achievement, even though their ultimate goal of trying to clean the whole world will never be fulfilled. This game also has a message about climate change, and how our earth is the only one we have, it goes to show the extreme side of wastefulness, in that the whole world will be covered in trash. We cannot clean up the world alone!
Inspiration. Our game design style is similar to a PacMan perspective of top down, and the controls are simple WASD movements. W for up, A for left, D for right, and S for down. The space bar picks up trash and moves the character inside/outside of the bus. The enter button is used for other general interactions. Our level design differs from PacMan as our game has closed borders instead of open off screen play. The maze walls use stacked up cars to give it a better look and feel. Our inspirations came from Ghostbusters as well. We added a trash sucking gun, similar to a ghost gun on Ghostbusters. Our art ideas were taken from Earthworm Jim and Stardew Valley for the pixel art inspiration and general graphic feel.
Summary. I listed this under project management as the majority of work was completed by the group. I was responsible for organizing tasks and communication as well as all documentation. This includes composing and designing the game design documents. I did not code any of this project but supported the coders in providing them with resources or idea generating when they became stuck. My attempts at task managing were not as successful as I wanted them to be. They became more of guidelines which some team members would follow and some would ignore. This led to confusion and angst among the group. If doing this again, I would create a clear expectation from the beginning on how task would be managed along with gaining team buy in to the method. I then would be able to hold everyone to the same accountability rather than having some team members carry more responsibilities than others.
Project Development Process
October 2017. My company’s Project Development Process, or PDP, was revised the beginning of my IMD Junior year. The development team had been struggling to commit to and meet deadlines in an accurate fashion. They either missed the deadline or did not meet the feature requests. In school we were taught the Waterfall and Agile methods of development. As I analyzed these methods and compared them to my company’s current system, I realized we were trying to combine the two. The CEO developed in an old school thought process that worked within the waterfall method. While his development team was using an Agile method of development. He did not realize, none of us did, that the inability of the two systems to communicate led to development failures and misses. I was struck by this thought in class and upon my return to work I had a closed door whiteboard session with the Development Manager. We sketched out how the functional requirements were created and transmitted by the CEO. Then how these requirements were translated by the development team. We created a new methodology which combines the two into one smooth system. I defined three sections: project setup, project implementation, and project completion. Here is an example of the document I created, “Approved projects require a FRS (Functional Requirement Specifications) to be written. An individual or a team is selected to own the FRS. This individual should have subject matter expertise and be able to understand the business implications. Currently these are written by the CEO.” This document is still being revised today almost a year later. A process like this is extremely complicated and takes much effort and expertise. I am proud to have authored such a document. The difference in meeting development deadlines is already significantly better.
Due to non-disclosure agreements I cannot provide any more textual representation of this project.
IPTV – 1.3.1 Project Name: Velociraptor
July 2018. One of the most successful and stressful projects I had the responsibility to Program Manage was the release of my company’s Internet Protocol Television, or IPTV, DVR feature. The DVR had been in development for months and was the required feature to take our product to the next level. This release needed to go smoothly as the stakeholders were impatient and vocal. I began by clearing the other action items from the entire technical team. Anything less than severity one was put on hold to test the DVR and prepare for its release date. I broke the testing and release tasks into sub projects and assigned them with deadlines to each individual. We held daily team meetings to ensure everyone was on task and meeting their deadlines. The Help Desk and Interns were given a development quality release to bug check and document. The Automation expert created an analytics system to monitor the release and data driven by the DVR load. The Development lead addressed bugs and wrote the newsletter which would preface the release to our beta testing group. I kept updates and resource requests flowing between the Development Manager and the CEO. On the day of the release I moved from my desk to the Network Operations Center and monitored every step of the process. Upon its success, we called the CEO with the statistics and congratulated our team. This process took about a month to organize and complete. There is really nothing I can think of that would have made the release more of a success.
Due to non-disclosure agreements I cannot provide a physical representation of this project.