benortheymasters-blog

[benortheymasters-blog]

ASM Post Mortem

Asset Management: Team Post Mortem

In the Game Design Master’s degree program Asset Management class, our team was tasked to track and document four weeks of work on a digital game. There were six of us total - three designers (Colton, Kyle, Josh), one artist (Michael), one writer (Ben), and one from information management (Dante). For this project management exercise, we chose to continue work on our prototype project from month 7, “Color Control.” A 2d, side-scrolling local multiplayer game.

 The Problems:

1) Formatting of early documentation

Our early documentation was done in a very casual way, and our week 1 milestone presentation showed a lack of attention to detail. We understood the production assignments to be less robust than they were in reality, and we fumbled when trying to go into detail about comprehensive plans for the whole month. We hadn’t yet prepared our schedule for the fourth week of work, or defined tasks moving through the whole month. We had a rude awakening during that first week, and it was definitely an early growing-pain for the team.

 2) Lack of programmers

We only had one proper programmer in our group, Colton, and he was relied on very heavily every week. He often had to work extra hours to accommodate everyone’s needs for the project, and this resulted in several programming tasks failing QA tests in each week as they cascaded down to future milestones. Kyle took on some responsibilities with programming as he learned some basic coding to work within the menus of the game, but these tasks took longer for him as a beginner than they would have for Colton, so it was difficult to leverage this toward easing the burden of remaining hours on tasks.

 What went right:

1) Course correction

Although we only had 2 days between our first and second milestone presentations, we put our heads together and cleaned up our act a lot by that second day. We fleshed out our full scope of documentation and powered through a lot of extra hours to make sure that everything was properly tracked and above-board. With the recent embarrassment of milestone 1 fresh on our minds, we were determined to craft a better showing moving forward.

2) Communication

The team was very open and honest with each other about what we needed and wanted from the project, and we set our own goals early on. We each were able to define our own tasks for the month and stick to them, updating each other on our dependencies as they moved forward. It was because of our communication philosophies that we were able to get our documentation workable for the milestone 2 presentation and keep everything up-to-standards after that.

 3) Meeting goals

Each week, every team member completed most or all of his tasks and worked at least 10 hours on the project. Despite some problems with a tornado in week 4, we were able to keep our workflow on-point and share things with each other just in time to get QA and implementation settled. While some of the tasks ended up getting cut, like victory poses and 4-player support, we added a power-up collection mechanic to the game at the request of our professor and had it functional in the final build. Individual Post-Mortem:

This month I learned a lot about project organization. Our team got off to a rough start as we first build our schedule and presented it casually as an incomplete document in the first week. I worked very closely with our producer, Josh, after that point, to ensure that our documentation would be up-to-code from that point onward. This did interfere a bit with my role as the project’s artist, cutting into the time I wanted to spend working toward the game project. I became the unofficial group administrator, despite not having the production title, and I found myself doing more work than I was scheduled for every single week with organizational and leadership tasks, and running communications between team members.

After the second week, things got a bit easier, as our production documentation was mostly on-track. I continued trying to pass off the production and leadership tasks to our producer Josh, and did my best to fade into a background/support role. This worked in all but the most dire crunch times, when someone needed to lay down the law, and this was when my art role on the team was respectively hindered the most. Moving forward in team projects, I will make more clear distinctions between whatever my role is and the role of production, which I always seem to unintentionally fall into. Getting documentation on track as soon as possible should help with this in the future, as a team with a set course requires less in the way of micromanagement/direction.

[benortheymasters-blog]

Post-Mortems

Individual Post-Mortem

I wasn’t quite sure about the role that I would play on the team going into this month. With no programming or game engine knowledge, and many other people with niche skillsets on our team, I was just hoping that our game would have enough variety to it that I could have a proper role. Luckily, early on, Michael, our nominal artist, noted that he wasn’t interested in creating pixel art. Pixel art is something that I’ve always wanted to get into, so I jumped at the opportunity to create the characters in the game. I had a blast creating the visual character designs and animations, and although it was more time consuming than I expected, I was able to get a significant chunk of animations done for 2 characters in the game by the end of the month.

Michael, our group’s artist, ended up deciding to create some pixel art anyway, and draw the backdrops for the game’s levels. Our problems in the art department arose when the communication between Michael and I was not clear enough. Although it was decided that he would make black and white backdrops in the style of the menu screens, he instead provided colored backdrops in an entirely different style, which was not so much pixel art as it was simply low resolution images. I should have worked with him more closely in order to develop a cohesive style for the game, and there should have been more interaction between the two of us overall.

Team Post Mortem

In the Full Sail Masters degree program Prototyping class we were tasked to create a digital prototype together as a class. In our class there were 6 of us, and each of us came from different backgrounds, we had a we had three designers (Colton, Kyle, Josh), one artist (Michael), one script writer (Ben), and one from information management (Dante). Our game that we decided to go with is called Color Control, a competitive couch game where player platform around a map in order to control the most area.

What went right:

1) Choosing Unity as an Engine

We decided to use Unity as the engine because it was the most familiar engine. Only one in the group has not used Unity and his tasks did not require him to be familiar with it. Also Colton our programmer was most familiar with it, and it was important for us to choose an engine around what he is able to do since we relied on him to piece our work together and build the game.

2) Putting people in the correct roles

We were able to put everyone in a role they were comfortable in. Colton was the strongest programmer so we put him in charge of a implementing all the games mechanics in Unity. Dante was comfortable in Unity and wanted to work on level design so we put him into that role. Josh plays music in his spare time and want to work on audio for this project so he was assigned to work on all audio aspect of the game. Ben’s background in script writing was not needed for this arcade style game we worked on so we needed to find another spot for him. He wanted to improve his abilities as an artist and work on pixel art so he worked on the characters and their animations. Kyle wanted to improve his abilities in UI and scripting so he worked on the Menus and UI. Michael wanted to work on some art for the project so he worked on the backdrops. Everyone in their assigned role was comfortable with their assignments and willing to learn what they needed to in order to create the digital prototype.  

What went wrong: 

1) Communication

We didn’t communicate as often as we should have; there was long time between responses in our group chat. It was difficult to get everyone together to meet at the same time in order to get on the same page as far as what was expected. We needed to be more specific with what everyone’s task was we would simply ask for the score to be fixed, or get one level done. This ended up making people interpret what that was intended and the result would be different then intended

2) Being on the same page with Art

Describing what we wanted the art style to be was difficult. We found examples of what was intended, but when it came to creating our own it turned out to be very different from what was proposed. Instead of wasting what little time we have redoing work we moved on with what we had.

3) Waiting until the last minute to put everything together

In par with communication, we had a hard time getting together during the week with everyone’s schedule. So we would meet on Friday to see where everyone was, then put everything together Sunday or Monday. This made it difficult to focus on some of the more detailed aspects of the game like jump height, and player speed.

4) Not using source control

We thought that we would be able to easily put Dante’s levels into Colton’s build with little problems since Dante got Colton’s base build. But in order to set the scale the backdrop correctly we changed the scale of characters, platforms, and the UI. Because we didn’t use a source control Dante never got any of the updates and was unable to edit his levels accordingly. We changed around the physics and jump heights of the characters and with that meant that Dante had to wait on Colton to merge the build in order to edit his levels accordingly.

5) Relying Heavily on one person

We relied a lot on Colton to get playable versions of the game working and because he was focused on making everything functional it was hard to focus on some of the detail, which end up being very important.

Moving Forward:

From this month we will be setting up communication norms and more frequent meetings. These meeting will be with those that are required to be there, so meetings between the programmer and level designer or UI artist and Artist. There will also be mandatory team meetings at least once a week. Early on in the project we had broad tasks assigned and this ended up leaving things up to interpretation, so in order to avoid that being a problem we will create finer task lists.

[benortheymasters-blog]

Month 5: MEX Mastery Journal

In this month I learned reliable and valid ways to gather data in testing. I learned about usability testing procedures and human factors ideology that shape the way playtests are conducted in the games industry. Deepening my understanding of validity and research is always evolving the way that I think of my mastery journal research topic, and it’s been an exciting journey getting resources together to form hypotheses and theories.

In our textbooks this month, we studied the origins of ergonomics and human factors, and learned the scientific ways of looking at human-machine systems as they interact in the world around us. We learned about different methods of gathering data, and the strengths and weaknesses of these methodologies. Measuring engagement can be really tricky, and it’s good to know your options for sample acquisition before diving into a procedure. Physiological measurement systems are especially interesting to me, as they provide the most objective take on behavioral preference and performance.

Within this month’s curriculum, we were given the opportunity to run our own usability test for a game of our own choosing, and select the factors within the game that we wished to test. My group tested weapon preference among new users for the popular platformer “Cuphead.” This informed the way that I think of my own mastery journal research, as it is another topic concerned with user preference and enjoyment in interaction.

[benortheymasters-blog]

Month 4 Journal Entry

The research I’ve decided to explore is the effect of win/loss conditions on player enjoyment of video games. The basic hypothesis of this study is that based on the conditions required for player victory, certain games are fun regardless of whether the player wins or loses, and some games are inherently empty and disappointing regardless of whether the player wins or loses. Examining factors like luck, technical skill and game sense, this research will attempt to uncover which systems in game designs are most rewarding for players, and which are least rewarding. By uncovering the deeper success criteria for game design in general, this research could benefit the industry by providing a clear direction for how challenges should be built in future games to satisfy and delight audiences.

           This month, I researched several articles which seemed to support the win condition of skill as a very positive factor for player enjoyment. In future months, I will be directing my research toward the conditions of luck and game sense in an attempt to find the effects of these factors on player enjoyment. That will provide a baseline from which I can begin to compare these factors and determine which element or combination of elements is most effective for producing enjoyment in players.

           This research topic is very closely related to my capstone of choice, User Experience Design. I am very preoccupied with the user/audience side of art experiences, and the notion of fine-tuning design in order to satisfy the desires of audiences. My desire to rework design philosophies around principles which most effectively provoke intended responses from an audience is the cornerstone of both my research topic and my preference for the UX Design capstone. As an aspiring game designer, this research will further my future career by informing me of the challenges that should be gainfully designed within games. It will inform my gameplay design philosophies and give me quantifiable resources from which to draw creative wisdom and inspiration.

[benortheymasters-blog]

Project Team Management: Mastery Journal

In this course, I expanded my vocabulary of knowledge within the project management world. I learned about project management methodologies, the proper formatting and creation of work breakdown structures, and the principles of budgeting. Below, I will a few specific examples of my education.

There are several project management methodologies that have stuck with me since week one of the course. Waterfall is an older, rigid style often employed by Hollywood or other “tough” industries. It is a top-down, by-the-books approach to project management that doesn’t take no for an answer or tolerate adjustments. Lean is a style characterized by frugality and minimization of resource spending. The Kanban style breaks tasks down into “done,” “doing,” and “to do,” often listing tasks visually in these 3 rows or columns. Sticky notes, white boards and cork-boards often serve as the canvas for this methodology’s visual layout. Agile is a style of increasing popularity which allows for some flexibility with dates and task definitions. This is a popular style among modern workplaces that put an emphasis on employees over bottom-line, and quality over speed and profit margins.

I learned how to divide up tasks into work breakdown structures in a practical way this month. I learned how to do this using Excel to generate an editable sheet of legible and effective information. This also served as a beginner’s crash course in Excel for me, as I have limited experience utilizing it up to this point. We created two work breakdown structures this month, of very different scope and specificity, and both were helpful for learning best practices of different-sized models.

Overall, this course taught me some valuable keywords in the context of the business, production and team-management worlds. I think that I can be a more effective producer, according to conventional standards, now that I have learned these core principles.

[benortheymasters-blog]

RTD: Mastery Journey

My time in Research and Team Dynamics has furthered my mastery journey by improving my research skills and giving me multi-disciplinary teamwork experience. Through several writing assignments throughout the month, I performed research analyses on peer-reviewed articles and learned to look at scholarly studies both critically and scientifically. I learned the vocabulary surrounding several psychological and experimental concepts, including validity, operationalization, threats, limitations and models. I developed the beginnings of my own research article around the topic of the win/loss condition in video games and its effects on player enjoyment. I gained experience and sources dealing with this topic through several exercises, including a prototype of my theoretical presentation in the final paper of this class.

In my group project, I learned how to balance creative work between a group of people who all come from different creative backgrounds. I learned to leverage the diction and communication skills of writers, the visual and spacial skills of artists and the mechanical abilities of game designers toward a single project. I exercised my leadership abilities delegating and parsing out this workload in order to ensure maximum efficiency and timeliness for group deliverables.

[benortheymasters-blog]

Mastery Journey Timeline, Part 2 (Part 1 below)

[benortheymasters-blog]

It’s inspirational to see a master at the peak of his craftsmanship. This video unpacks a scene of Anthony Hopkins’s acting in high detail. It inspires me to become a master of my craft an to elevate the art I take part in creating to the highest degree I possibly can. References: Puschak, E. (2016). Westworld: What makes Anthony Hopkins great. In     YouTube. Retrieved July 30, 2017, from https://www.youtube.com/watch?     v=4kSGkGKwp9U

[benortheymasters-blog]

Mastery Journey Timeline, Part 1 (continued above)

[benortheymasters-blog]

Above is my LinkedIn screenshot, Feedly screenshot, Papaly screenshot and personal brand logo. This logo uses my initials for my first name, two middle names and last name. Here is a link to my Papaly board: https://papaly.com/categories/share?id=99c997a453914b02a9d59a5ab8d9c022

[benortheymasters-blog]

Although on the surface this looks like a game review, or a comparison of a classic game and its remake, “Thief vs. AAA Gaming” is a comprehensive masterclass in game design. This video explores, breaks down and analyzes good practices of game design as well as bad, delving deeper into the technical and artistic facets of the medium more powerfully than any other educational resource I have ever encountered. This video inspires me to create excellent and unique game designs. It also serves as an encyclopedia of knowledge to help the aspiring game designer do so. References: Giuca, D. (2014). Thief vs. AAA Gaming. In YouTube. Retrieved July 21, 2017.

[benortheymasters-blog]

The theme of this video can be extrapolated beyond film, into all art-forms which have had the misfortune to fall into the hands of mass-market businessmen and shrewd economic demands. It touches on what it means to make great art, even within that sphere, and why that is such a gravely important task. It inspires me to create art that is real and human -- that can connect with people on a personal level. And maybe I’m an elitist, but ragging on “passable” movies in a precise, calculated and intelligent way is cathartic for me. References: Puschak, E. (2016). The Epidemic of Passable Movies. In YouTube. Retrieved July 14, 2017, from https://youtu.be/Ukk5TJL27pE

[benortheymasters-blog]

My Mastery Journey

I am here at Full Sail to build a practical portfolio and make key industry connections. I want to learn new skills and polish my toolkit, as well as earn a credit on a shipped title. I want to work with the career center intimately in order to get a knock-out resume off the ground and start shaking hands with some HR professionals in the game development world. There is a lot of work to do, even just to get to some of the points listed above, but Full Sail is an exciting place to be and I wouldn’t have it any other way.

Although I am well versed in the theoretical components of design, and I’m a huge nerd for game mechanics, level design and balancing, I have little experience in the formal world of game development. I need a greater scope of where my skillset will be most helpful on a team. Shadowing the capstone programs and seeing these groups in action will help me gain a better grasp of where I fit into the game industry, and applying for and completing a capstone myself will give me confidence and practice in that role.

Making connections will certainly take a lot of leg work as well – from countless visits to the career center perfecting my resume and portfolio to finding niche industry openings for which I might gainfully send-in. I will rely heavily on the resources available to me at the career center and plan to build my relationship with them very early, starting this month, rather than waiting until I am assigned an official representative toward the end of the program. I want to pursue their help in perfecting my resume for the industry as well as getting me in touch with industry HR connections and Full Sail alumni.

Learning the day-to-day tasks expected of game designers, as well as the different flavors of roles they tend to fill in a practical, career environment will help me more than anything else in the coming 12 months. Getting in contact with industry professionals certainly won’t hurt either. I’m very excited to develop new skills, connections and portfolio items here as I complete my master’s program and launch into the professional world.