zachschram-blog

[zachschram-blog]

Individual Postmortem

TEAM POSTMORTEM

Project

❖    Description

➢    Project Name: ASM Bombers

➢    Client: Roy Papp

➢     Project Manager: Michael Buck and Mitchell Ford

➢    Start Date: 11/19/18

➢    Completion Date: 12/16/18

Project Overview

❖    Discuss the project charter

➢    This project is meant to provide a lesson on how to manage a team’s assets as well as how to document a team’s progress while measuring goal attainability. The goal of the project is to create a digital product that meets the scope and goals the team agreed upon in post-production while also meeting all the requirements of the class.

This project was a disaster from start to finish. Between exceptionally poor instruction and a team that largely didn’t want to work on the project that was arguably decided upon, there was nothing to gain from this class. For those that want or need instruction on production methods, they get vastly superior experience from other classes or their capstone. For the rest of us, who are working on producing games or user experience, we didn’t gain anything either. No one wanted to work on this project, except Zane who came up with the train wreck of an idea. 

A 1v1 first person, hack and slash, bomber-man that’s networked. This was doomed from the start. There was no reason what so ever to network this project, specially seeing as no one has experience doing so, and no one was even remotely interested in working on this project. This isn’t even mentioning how much these mechanics clash with one another into a user experience nightmare. First person bomber-man alone does not work for clear reasons, and making the primary attack a hack and slash counters the use of bombs instantly. Why would anyone ever use bombs if you need to be directly next to someone, smacking them, when the bombs hurt both of you? Why would anyone use the hack and slash when the bombs are a ranged damage that keeps you safe? This is, of course, the caliber of thought that Zane puts into every project, which is to say none. 

Leading into the actual production, it's easy to say that no one read or no one paid attention, yet not one person understood the assignment which in itself says a lot. Of course, no one will make the changes that were offered because no one in this class wants to interact with this class ever again. So every week we have to make changes because we don’t know what the fuck we’re supposed to do. Bitch all you want that a producer will ‘just find someone else’, well in the same note, if the producer won't give adequate instruction and the entire team consistently fails due to this, I could only imagine that they would go find another producer.

When asked why we had inconsistency, beyond laughably inadequate instruction, on multiple occasions the team would have their rights to edit the documents revoked. This means that we can’t change our hours or edit the completion of a task. On top of this, tasks would be created and assigned without ever telling the individual that they had a task, leading to several tasks never completed. For example, giving me the task of audio, which was absolutely completed. I found out by looking at the document, and then when I uploaded entire files of audio for the team to choose from since I was given no instruction, it was left out. Gabe and I were completely unable to do the tests until after the due date almost every week due to the team consistently not posting a build, or posting the correct build. Every week was a complete hassle trying to get the testing done due to this.

In total, this project was a disaster from start to finish, and the outcome was almost exactly as predicted from the last class we had to do this. The entire groups combined efforts equate to what could have been achieved in a day by myself. This fact alone makes me question why this class is allowed to exist. If the point is adequately instructing production methods, then this was a massive waste of tuition and time.

[zachschram-blog]

Team Post-Mortem

TEAM POSTMORTEM

Project

❖    Description

➢    Project Name: ASM Bombers

➢    Client: Roy Papp

➢     Project Manager: Michael Buck and Mitchell Ford

➢    Start Date: 11/19/18

➢    Completion Date: 12/16/18

Project Overview

❖    Discuss the project charter

➢    This project is meant to provide a lesson on how to manage a team’s assets as well as how to document a team’s progress while measuring goal attainability. The goal of the project is to create a digital product that meets the scope and goals the team agreed upon in post production while also meeting all the requirements of the class.

❖    What was the project success criterion?

➢    A game that met all the tasks and features that the team laid out while also meeting the specifications laid out in the classroom.

1

Local Networking

Bombs that move the players and damage them

Performance

❖    Key Accomplishments

➢    What went right?

Development tasks that concerned the player were met

Networking was accomplished

The team was able to resolve repository issues

➢    What worked well?

Player shooting

Player movement

Explosions

Networking*

Pickups

Powerups

*After networking was implemented some issues arose but networking technically worked.

➢    What was found to be particularly useful?

The repository

Discord

Clear timeframes

➢     Project highlights

Getting all of the player tasks completed

Getting networking to work

❖    Key Problem Areas

➢    What went wrong?

Lack of effective communication through the team outside of actual class time.

Conflicts between sections of code caused some confusion and set back primarily for the third milestone presentation.

➢    What project processes didn’t work well?

Hour tracking.

Task integration

➢    What specific processes caused problems?

Allowing everyone to track their hours separately almost always lead to some level of confusion come the time to present information to the instructor.

Due to a lack of a quality checking before work was integrated into the build we ran into many conflicts in our code. These conflicts would often make one or more of the team members work from the week unusable for that milestone.

➢    What were the effects of key problems areas (i.e. on budget, schedule, etc.)?

Because the team had such poor communication, all members were unsure of what the final version of the game was supposed to look like. Additionally, their were problems like poor formatting, work that didn’t meet specifications, unfinished work, and misconceptions about things getting done.

Allowing people to complete record their own hours was a problem as phantom hours would appear all at once from members of the group that would throw off information presented in the powerpoints or what was recorded on the schedule.

Not having a proper testing format to catch bugs and issues with the game allowed many problems to make it to the presentations but also into the latter milestones.

➢    Technical challenges

Networking was a definite issue. Only one member knew how to work in networking and it took time to get things networked and completed. This was a pipeline plug and caused errors later on. All of this stemmed from networking.

❖    Risk Management

➢    Project risks that have been mitigated:

Scope

Networking

➢    Outstanding project risks that need to be managed:

Certain scripts were not created to be implemented as they are into a networked game. These scripts need to be modified to create a better experience for the players and the team while continuing to work on the project.

❖    Overall Project Assessment

❖    Criteria

❖    Score  from 1 - 10

❖    Performance against project goals/objectives

❖    7

❖    Performance against planned schedule

❖    5

❖    Performance against quality goals

❖    5

❖    Performance against planned budget

❖    3

❖    Adherence to scope

❖    7

❖    Project planning

❖    5

❖    Resource management

❖    4

❖    Project management

❖    6

❖    Development

❖    7

❖    Communication

❖    1

❖    Team cooperation

❖    1

❖    Project deliverable(s)

❖    2

❖    Additional Comments:

➢    Other general comments about the project, project progress, etc.

The game is technically up to date with what was planned but things need to be looked at again now that networking is in.

The team needed to be better acquainted with what the final version of the game was going to look like.

❖    Key Lessons Learned

Communication is vital.

Always plan for someone not to finish their work.

Only people that need access should have access.

Complete testing with enough time to fix issues found.

❖    Post Project Tasks/Future Considerations

➢    Ongoing development and maintenance considerations

Should the project continue the end product of the game should be reconsidered. Currently, the final vision of the game is too fluid and is not shared consistently throughout the group. For the project to continue in any meaningful way the final vision needs to be solidified and a vision holder of the group should be established.

The members of the team should also be reconsidered if the project was to continue outside the jurisdiction of education. Certain members of the team have proven to be uncooperative and unproductive. It is not vital for each member to be a master at all areas of development, but it is necessary that they are willing to work as a team.

➢    What actions have yet to be completed and who is responsible for them?

UI: Emilio

Fix networking: Zayne

Player controller: Antonio

Audio: Zach

Levels: Gary

Animations: Toby

Complete the production plan to specification: Michael and Mitch

➢    Is there anything still outstanding or that will take time to realize? (i.e. in some instances the full project deliverables will not be realized immediately)

The levels were not completed as the team wanted.

Audio was never implemented.

Player controller and networking need to be worked on to be compatible

UI needs to be worked on as their are redundant buttons and stock components

[zachschram-blog]

MEX: Mastery Journal Assignment

The work we did this month was closer to my research topic than I had originally anticipated. While working as the user experience team for a mobile game, it became apparent that their issues were quite close to that of my research topic. To clarify, the topic I chose was the GDC design track, or more specifically their level design. With that, I originally aimed to provide a theory as to why there should be a specialization between single player and multiplayer level design. it was quickly realized that this was far out of scope for the entirety of my degree program, much less a months work. So now, with the experience I’ve gained with the UX Lab and the MEX class, I have refocused my theory to be the constructs that should be focused on in Multiplayer specialization. In short, this basically means that I aim to research and define what variables are most common, or most vital to the success of a multiplayer level design. The only downfall to this class was that it was not presented to us prior to my work with the UX Lab. Aside from that, the work we did with our MEX development teams, combined with the reading we did on the physical/psychological effects was exactly what I needed to redirect my focus onto something more realistic. Though the new focus for the theory is still very broad, I have managed to find several theses that have become the foundation of my current efforts. My next month will be focused on finding further evidence to support these findings, or possibly different constructs entirely. 

[zachschram-blog]

Project Management Mastery Journal Tumbler Blog

I was very confused by the existence of this class at first. The idea that an entertainment business class would be put in the middle of a game design course made no sense to me. While I understand that the skills and assignments are a universal tool for all people who aim to work in a business of any kind, it diverted a lot of effort that could have been put elsewhere. 

That being said, the class did have some value to it, though nothing that wasn’t easily understood from the other classes that Full Sail has already offered. The biggest issue is that this class shows a lake, but it’s only an inch deep. There was much more that could have been done, and that may be the fault of the class only existing for a singular month which tends to be the case with most classes. However, this shows the issue of Fullsail in total, where the degree will constantly switch paths and can’t make up its mind as to what it wants to teach. There’s no reason to teach business to someone who specifically wants to learn research and game design. There’s no reason to teach design to people who want to learn business. The college just devalues and muddies the waters for anyone searching to learn a specific task. 

This is not to say that this class is without value. As I’ve said, the ability to manage a team and a project is very valuable. Were every person within a team to have these skills, it seems likely that a project would go through much less turmoil when everyone understands all aspects. Perhaps if the class were to have more assignments, each valuing much less than 15%, there would be more ability to explore the value of the class. While yes, there isn’t much that needs to be explained about how a budget works, there are many assignments and tasks that could go into explaining how detailed a budget needs to be. The same could be said of almost all of the tasks assigned.

[zachschram-blog]

Mastery Journal Tumbler Blog

There was a lot that was covered in this month. The information was a lot more varied than I had anticipated or had been led to believe. We covered team dynamics, research methods, and to some degree game design and documentation for it. Though I was let down by how little the actual game design mattered, I was able to practice building a better design document throughout the class. Whether or not this is vital is yet to be understood, but it has absolutely given me a greater foundation for building and outlining my own side projects. Though the game itself wasn’t necessarily important as far as grades go, the team dynamics were. We covered, extensively, how to create a team as well as how to properly maintain one. While not covered in those words, that was definitely how it was practiced. The diversity of skills, perceptions and backgrounds was shown in our team as well in our decision-making process. Most importantly though, we were taught important research principles and practices. It was made clear that this was simply an intro to later classes and applications. This was surprisingly difficult to adapt to as it applies to documentation and research in large. The earlier assignments were very challenging for me to understand as we were expected to learn and “master” every form of validity within the first week. While I question whether or not I fully understand some of this, I know that I now see research in a different way. I believe this will make my path to the UX lab much easier and provide me with a much greater understanding by the time that I become a member of the research team.

[zachschram-blog]

TimeLine

[zachschram-blog]

Motivational Post 3

Motivational (n.d.). In SantaBanta.com. Retrieved April 29, 2018, from http://www.santabanta.com/photos/motivational/2107329.htm

This may be a fairly generic motivational picture, but it ties in with game design very specifically. It’s easy to find a problem and think that there’s simply no way to answer it. However, with modern day game design tools, there is literally nothing that can’t be done. Remembering this will mean that any task that I run into will be possible, I just need to find a way to do it.

[zachschram-blog]

Inspiration 2

Wallpapers/General (2014, December 13). In Archives. Retrieved April 21, 2018, from https://archive.nyafuu.org/wg/thread/6024353/?download

This almost needs no explanation with how clear and concise the phrase is. This is very much what it means to be in the master’s degree. It can be difficult at times, just hoping that inspiration or fortune will find you, and sometimes it does. However, this doesn’t work forever, certainly not often enough to rely on. We have to set out and find our success. Though finding it isn’t enough. You have to be willing to do what it takes to take it as well.

[zachschram-blog]

Bookmarks and Photos

https://papaly.com/zachschram/drP7V/Bookmarks

[zachschram-blog]

Inspiration

THE WEEK OF VIDEO GAMES (GDC & PAX) (2015, March 12). In renzogheredia. Retrieved April 15, 2018, from http://www.renzogheredia.com/blog/2015/3/11/the-week-of-video-games-gdc-pax

While this doesn’t appear to be an inspirational photo at first glance. Inherently this isn’t inspirational at all. What makes this photo of two different logos inspirational are the meanings behind them. Both of these conventions are made by game designers, for game designers. The only difference between the scale of these two events is the scale. GDC is made for the larger scale companies and more well-known individuals within the industry. PAX, however, is made specifically for the small teams and the unknown indie titles. Every year there are hundreds of independent studios, or even the lone creators, that make their success because of PAX. At GDC there are thousands of creators that meet to share ideas and information about the industry. These events are designed to share experiences, promote those who put their hearts into their work. When it comes to finding inspiration in the game industry, you don’t need to look far when at one of these conventions.

[zachschram-blog]

Mastery

Over the course of this degree, I intend to learn more about game design from other aspects and points of view that I have not had the chance to see yet. In the bachelor's degree, I learned the direct aspects of how to physically make a level, how to make a character, how to program, etc. These are more the 'physical' aspects of game design, the actual creation. I hope to learn more about the team aspect, and preferably the psychology. If I can learn more about the psychology of how a player makes a decision, or rather why they make it, I believe that this would lead to a vastly better product. These goals and aspirations are what are offered by the degree course, however there are other goals that are not. I made a mistake by not using my free time during the bachelor’s degree to make side projects. I will be making strides to correct this by creating at least one complete game on my own time with what I have learned thus far. I have already begun to work on no less than three side projects, and work on them when time permits. This has already begun to help keep my skills sharp during classes where there is no relevance to game design. I’ve also been taking as much time as possible with a mentor from my bachelor’s degree. Though this does not directly progress my degree or my profession, the talks have done a great deal towards teaching me lessons that I couldn’t have gotten from any degree at FullSail. Depending on what specific degree track I go, as well as depending on how much time permits, I may be adapting my side projects into mods for different game engines to help diversify my resume.