jranderson1mastery-blog

[jranderson1mastery-blog]

Group Post Mort em for M.E.G.A. project

Postmortem: Make Earth Great Again

Team members include:

James Anderson, David Ashbourne, Javier Chico, Teryn Cochran, Christine Dietz, Chris Dinkel, Tomas Gonzalez, Alexander Hudson, Hampton King, Andrew Lambert, William Longmate

Introduction

Make Earth Great Again started as a class project designed to teach the fundamentals of documentation and team management. Given our team composition, which was writer / designer heavy and light on developers, we decided to make a visual novel. From the beginning, we set a few clear goals we wished to achieve:

●      A compelling, dynamic story that draws players in, set in an interesting world.

●      Expressive character art for both human and alien characters.

●      Exotic background locations to set the story in.

By the end of the project, we felt that we had achieved our first goal of a dynamic story and an interesting world, but due to scope issues, communication breakdowns, and task dependencies, we fell a bit short on our other goals.

What Went Right

1.     Brainstorming Session

The first step of our brainstorming process was to toss out the prototype we had from a previous project and move on to something new. Given our new team composition, we decided to make use of our writers and create a visual novel with a complex story. We felt that we had enough artists to populate exotic environments and feature interesting characters and that the coding side of a visual novel would not be so strenuous as to overwork our single developer.

Once settling on a visual novel, we began discussing possible themes or settings we’d like to explore. After bouncing a bit between sci-fi and fantasy stories, an idea was brought up by one of the writers that immediately struck a chord with the team—the main character should be evil. Not an antihero or a lovable bad guy, but a genuinely evil person. The team loved the idea, and we latched onto it immediately. Next up was a discussion of narrative complexity. We played with the idea of allowing many branching storylines with separate endings, or even the same story simply told by different characters, before deciding to go with the simplest, cleanest approach.

By the end of our brainstorming session, we’d settled on a basic plot premise, a rough idea of our setting, and concepts for a few characters. The entire session functioned smoothly and the team worked well with each other throughout. The energy we had from that first meeting carried over into the work we all did during our first milestone.

(An early concept for the HUD, based on the brainstorming session.)

2.     Story, Themes, and Setting

The narrative work didn’t stop after the brainstorming session. We’d decided on a sci-fi story in a dystopian universe featuring a human terrorist as the main character, but that was all we had. The next few days were all about the writers. They got together to flesh out the narrative beats, laying out a world in which humans are oppressed by the equalitarian alien government that had taken up residence on Earth.

The story’s defining themes were nostalgia and the innate human desire to compete for success. Missy, the game’s protagonist, longs for the days when humans competed in a capitalist society to prove who was best. This felt like a fresh perspective to the team, who had grown tired of modern stories touting the same themes of equality and peace over and over. We wanted to work with a new idea and explore the truths and fallacies associated with Missy’s unpopular opinions. All of this, combined with our concepts for a unique human-alien world, kept the team excited throughout the production process, and was one of the highlights of our completed work.

(The Resistance HQ, where Missy plans to take out the alien government.)

3.     UI Artwork

Another highlight of our development cycle was the UI artwork that we received. Given that a visual novel is, at its core, a series of interfaces that allows the player to make limited choices, we felt that we needed impressive UI artwork to keep the player interested and to make the game screen more interesting.

Luckily, this is what we got. After defining the game’s themes and characters, our artists synthesized the narrative team’s core concepts with their own ideas of how an alien civilization might impact humanity’s art style. They incorporated a sense of mystery and eeriness into the menus and HUD to better allow the player to empathize with Missy’s plight.

This showcases one of the things that the team consistently got right throughout the dev cycle—namely, combining the various talents and artistic styles of our artists and writers to create a unique, interesting world with coherent motifs and an overarching sense of unity.

What Went Wrong

1.     Visual Effects

While our art team got it right, for the most part, regarding the style and delivery of our characters and settings, one thing that we missed the mark on was our use of visual effects. Early in the development cycle, we planned on incorporating particle effects into our backgrounds to give them more life-like motion, as well as to add to the ambiance. Unfortunately, we soon found that to be impossible based on how our developers were building the game (we were taking screenshots of 3D environments to use as backgrounds, so moving particles couldn’t have worked).

To substitute for our missing particle effects, the team tried to incorporate some visual HUD effects in terms of screen flashes and shakes. Unfortunately, due to the rather static nature of the rest of the artwork, and the inherently slow pace associated with a visual novel, these effects often came across as jarring and out of place. Because of the late stage at which we decided to incorporate these type of effects, the screen flashes did not have an accompanying sound effect, and thus felt incomplete. Similarly, the screen shakes only shook the HUD and none of the background art. As these were supposed to represent explosions in the game world, this created a disconnect that did not serve the purposes of our story.

2.     Time-Gated Decisions

Another design-related element that didn’t go perfectly to plan were the time-gated decisions we implemented. These were originally designed to create a sense of urgency and responsibility for the player. However, for a number of reasons, this attempt failed.

For one, we implemented the time-gated decisions on dialogue options that really weren’t all that urgent (for instance, choosing whether or not to come downstairs for pancakes). This made the moments where things were urgent feel less so. Secondly, some of the time-gated decisions were set to choose a random option if the player didn’t answer in time. This resulted in an undesirable loss of player agency. Finally, other decisions like this were set to loop continuously after the time ran out, essentially negating the time mechanic and any urgency that might have come with it.

Whether we should or should not have used time-gated decisions at all is a discussion for another time, but it is clear that the way in which we used them was ineffective. These decisions ended up being more of a distraction than a tool by which we fostered immersion and player investment.

 3.     Communication and Transparency

Perhaps the most important of the things that didn’t go right for us was the communication and transparency of the team as a whole. Given that this entire project was an exercise in documentation, tracking, and communication, this failure stings.

The first area we noticed this problem was with our scope document, where each member of the team was supposed to report the hours they worked on each task. After a few mishaps with team members entering numbers in the wrong columns, the producers decided to close the document for edits and have team members post their hours in comments instead. This seemed to create problems for team members who didn’t know how to comment on a Google Sheets document.

However, the problems with the scope document were only indicative of problems elsewhere. There was a disconnect with some members of the team and the producers, where certain tasks would be completed but no worked hours were reported. This resulted in the documentation that didn’t accurately represent the work that the team had put in. Similarly, there were instances in which people were confused about the tasks they were supposed to complete, or where they worked on the wrong tasks at the wrong time.

If we were to start this project over, the first thing we would do is implement a new system of reporting hours. Clearly, the last system was not optimal. We would want a system whereby there is no confusion about who has to work on which task, and where reporting hours is convenient, intuitive, and does not make any extra work for the people completing each task. Perhaps the best way to do this would be to use production software such as Jiro or HacknPlan instead of relying solely on Excel. We would also try to open more clear channels of communication than simply relying on Discord and text messages.

 4. Capacity usage and task completion

Finally, our use of our capacity was sub- optimal. At the end of the project, we ended up being 79.3 hours behind in reported capacity. Some of this was due to non-reporting, as previously mentioned, some were due to dependency issues, and some was missing work. Without factoring in any missed QA tasks, we were missing 54.3 hours of tasks in our scope document. our overall completion testing showed an 89% pass rate on tasks.

Conclusion

Though communication was a major issue and there were many times at which our documentation felt incomplete, the team is happy with the product we created. We were able to implement an idea we all liked into the world we’d created, and despite the multiple hiccups we experienced, we eventually produced a game that satisfied, at least in part, the goals we had set out to accomplish.

[jranderson1mastery-blog]

Individual Post Mortem for M.E.G.A.

Post Mortem: M.E.G.A. (Make Earth Great Again) via James Anderson

  Introduction:

 M.E.G.A. was a class project that allowed us to attempt to make a visual novel within the timeframe available. In this class, the focus was on the accountability and documentation side of game development. The design process stayed the same: prototyping, designing, etc. But now we also had to account for man hours, tasks, workload capacity, and the metrics applicable to tracking true man hours. Like the last game created, Gravity Guerillas, class members will be asked to accomplish assigned tasks with an emphasis on the narrative design and art portions of the game. Our goals to achieve to make this visual novel a good experience was:

·        The game was visually appealing, with multiple backdrops and scenes where the story took place.

·        Told a concise, well-paced story that was entertaining.

·        A twenty to thirty-minute experience per playthrough

·        Gave the player/reader impactful decisions to make throughout the game that would affect the outcome of the story.

If we hit on all these goals, in my mind, we would’ve given the player a quality visual novel experience. Many visual novels however often fall short of the optimum experience given to players, and ours did as well. As we got further into the game making process, some goals seemed unattainable, or we just did not have the time to put emphasis on the gameplay experience. This could’ve been remedied by having just an expanded timeframe to make this visual novel a premium experience, or better accountability for tasks needed.

 What I Felt was Good:

 Early on the lack of game developers in our group dropped our scope of what we could accomplish development wise. Over the course of the last few months, as expected, we have some talented people as we progressed in the program. So, to accommodate the loss a game dev, we decided that less programming intensive game would suit what we needed for class.

 The brainstorming session to find the narrative ideas for a game of this type was important, and I believe a good back and forth between the narrative writers and the dev team early on was good. The producer also had his hands on what he wanted. This helped concrete what we need as far as features to present to the artists and audio. This also helped set the overall scope necessary for the game.

 What I Felt Could Be Improved Upon:

 This month was as bit of a challenge as the scheduled break for the school happened at the midpoint of the class. This hurt momentum that we were slowly picking up as we got into the last few weeks of creating the game. If we had planned better for the break for tasks to be accomplished, then I’m sure we would’ve had a prototype going into the final week of class.

Another problem we faced in this class was the lack of accountability and communication. At times, it felt as though only a select few of the class were performing tasks and giving quality work. Unlike the early communication and standards created in the beginning to create a solid foundation to work from, we instead were met with the lack of report or just incomplete task completion. This was more so due to the miscommunication between teams, and just lack of creative direction from the design portion of the project.

  Conclusion:

The final prototype was adequate to strike some interest with the instructor, however, I feel like we could’ve been a better. Ultimately, it was up to us students to create an appealing game experience, but somehow, I feel we fell short. Again, I mentioned before, if we had more time to develop the great art our team could create and stay on the people who had tasks to accomplish and didn’t, we could’ve had a better prototype to show.

[jranderson1mastery-blog]

Individual Post-mortem for Gravity Guerrillas

Post Mortem: Gravity Guerillas via James Anderson

 Introduction:

           Gravity Guerillas was a class project with objective of building a functional prototype. You were start with the basic steps of developing a paper prototype, then evolved it into a proper digital version by class end. Each class member had a role to fulfill, and we were to find a commonality between each role to ensure that by the end of the class met full capacity. As we came up with an initial concept, we made sure that game had clear and concise goals:

·       The game would have simple mechanics that allowed complex dynamics

·       An aesthetically appealing setting with humorous elements present throughout the game

·       Had a lot of replayability

Personally, I thought that game had a similar mechanic to that of games like Angry Birds: Star Wars and those of that ilk, which could be appealing to the casual audience. Although we created a good base, some goals and tasks fell short of what our initial goal was set to develop this prototype in the beginning phases of creation.

 What I Felt was Good:

           The team performed admirably in the progression of making the game become better and better as we transitioned to the end of class. There were moments of “ah-ha!” and “that makes sense” early and often in the brainstorming and early concept phase of the game. Everyone seemed heavily engaged in creating this game (for the most part), and contributed great ideas and first versions early on in development.

           Since my role as game dev was to implement the Art Team’s assets as early and often as possible, constant communication was established. With their help, we created an aesthetically pleasing title and menu system, that wasn’t hard on the eyes.

           Also, since I little experience performing programming for games, the rest of the dev team were encouraging enough to allow me to sit next to them, and perform as best I could. When needed, they gave the necessary tutoring to help make sure that the tasks I was performing were up the standards needed to create a solid game.

What I Felt Could Be Improved Upon:

           My criticisms can be justified due to the weeklong event that occurred at school. This event caused a disruption in flow and communication due to mandatory involvement, as well as former grads that came and spoke about current happening in the industry. Had it not been for this, I believe the final prototype could’ve been that much better.

           However, we, as a group, could not just blame the school’s schedule for our lack of drop-off in quality and development during that time. We should’ve took it upon ourselves to gather at least twice during that time to confirm current developments cycles and hurdles, and planned for future tasks a bit quicker.

           Finally, lack of interest in the latter stages of development and design, hiccuped the small momentum we would’ve had going into that last week. Late submissions, low quality work, and downright cutoff in communication disrupted most of the final prototype’s development. Again, this could be attributed to multiple reasons, but as a team, we should’ve nipped it early on.

 Conclusion:

           As a team, we accomplished much throughout the month for our final prototype to be presented. I believe through our persistence, hard work, and ingenuity, we accomplished much in our development of the game. At the same time, we have much to learn, and that showed itself often as we were going through the development cycle. Now, as an individual and a team, we must build on these qualities (for better or worse) to reach even greater heights.

[jranderson1mastery-blog]

Collaborative Post-Mort em for Gravity Guerrillas

Postmortem: Gravity Guerillas

Introduction

Gravity Guerillas started as a class project with a focus on prototyping. We were to start with a paper prototype, take what we learned and apply it toward a digital prototype, then use consecutive iterations to clean the game up and inch closer to a final vision for the game. Given our team composition and the prerequisite that everyone had to put in equal hours toward the project, we decided to establish a few clear goals:

●      A game with a single, simple mechanic that allows for complex emergent dynamics.

●      An aesthetically appealing setting, with humor elements spread throughout.

●      A game with a short play time and lots of replayability.

Ultimately, our mechanic created interesting gameplay and complex interactions, however we fell a bit short on our other goals. Our prototype did not fully convey the tone and humor we were hoping for. Also, our playtime was a bit longer than we anticipated.

What Went Right

1.     Brainstorming Session

Our initial brainstorming session started out with four primary game ideas. We played with the idea of an endless runner, a reverse tower defense game, a platformer / shoot-em-up, and a gravity-based shooter, which we eventually settled on. Using scope and production time as the primary condition allowed us to move away from the more complex ideas of reverse tower defense and the shoot-em-up. Then, a discussion of which idea can be used to create more novel gameplay resulted in us dismissing the endless runner and moving toward the idea of a 2 player, Bowman-like game where players launch projectiles at each other. Rather than using the traditional approach to this (everything falls downward), we decided to place the game in space and use actual planets as gravity wells that attract and redirect projectiles.

By the end of the brainstorming session, we had settled on the game genre, the setting, the backstory (thanks to some creative ideas from our writers, who desperately wanted to write about space monkeys), and we even had a name: Gravity Guerillas.

 An early concept for game aesthetic and level layout.

2.     Setting & Art Style

Right from the start, we had a clear direction we wanted to take the game. The backstory involved secret clans of gorillas sent to space during the Cold War in an attempt by both the US and the USSR to find new habitable star systems before their opponent. In reality, all we were trying to do was pit space monkeys against each other in a banana-flinging, gravity-based catapult game.

The art style, then, was developed to incorporate both the inherent silliness of space monkeys with the nostalgic, propaganda-esque artwork of the Cold War.

We accomplished this through creative use of the colors of the US and the USSR as well as incorporation of gorillas in poses that we would normally associate with humans or soldiers. This humanized our characters, while also highlighting the ridiculousness of the aesthetic that we were working with.

3.     Paper Prototype

It can be difficult to create paper prototypes with a high level of fidelity to the final product, but thanks to the nature of our game, we found this part not only easily managed, but also helpful. Because the game is not reflex based, and instead relies on predictive action, the paper prototype allowed us to model the same choices players would make in the digital game with high accuracy. Working with the entire team, we created a physical version of our game with turn-based movement and mathematical calculations to determine speed and gravitational pull. In the end, we managed to accurately replicate what we foresaw as being the core mechanics of the game.

4.     Scope

Our core mechanic is simple enough that it didn’t take the developers long to figure out a way to make it work in-game, but allows for enough variation that we were able to create an entire game around it. Level design plays a huge role in how the game is experienced, and different level designs let the game to feel large without expanding our scope too far. Keeping that mechanic tight also gave us the opportunity to explore other features (such as colonization and invasion) that expand the dynamics of the game without blowing scope.

5.     Final Level Design

Level design was a struggle for us early on, but by the time we reached out final prototype iteration we had figured out what needed to be done. A star system with an odd number of planets, some habitable and some not, each with varying sizes and differing strengths of gravitational fields, creates an interesting level. We wanted to force the player to use the gravity to hit shots, but give the rare opportunity to make a straight shot if the timing is right. We also wanted to keep the levels balanced on both sides so that neither player has an advantage in terms of planetary layout.

What Went Wrong

1.     Where is the Humor?

While we decided on an aesthetic early on, and were able to create art that aided us in presenting that aesthetic, we struggled with incorporating truly humorous writing and art into the game. Scope-wise, it quickly became apparent that we wouldn’t have the time to implement written dialogue or in-game barks, and this meant we had to convey all of our humor through art. We struggled to create animations that added humor to the game, and the final versions of our UI art, while arguably humorous in a sardonic, wry sort of way, didn’t quite convey the silliness that our game concept begs for.

2.     Early Level Design

Early on, we struggled with creating interesting level designs that allowed us to truly test the limits of our game mechanics. From the paper prototype onward, we had to consistently revise our level layouts to allow for more interesting gameplay decisions, as well as to prototype the different functions a planet could plausibly have.

We started off very basic, not realizing how much of an impact planet location and the size of each planet’s gravity well would have on gameplay. We experimented with symmetrical and asymmetrical level design, with multiple planet types, and with moving objects versus static objects. While we did eventually end up with a solid final level design, the iterations we struggled through in the beginning cost us time and effort that could have been better spent elsewhere.

 3.     Balancing Capacity

With a team composed of mostly writers and artists, it was important from the start to make sure that everyone had work to do. We were creating a digital game, so it was obvious that our developers would have plenty to do, but it became a difficult job for the producer to find tasks for the writers to work on. This only became more prevalent as it became clear that we wouldn’t be able to work a lot of the writing into the actual game. In the end, writers had to learn some dev skills, or apply themselves to level design and production in an attempt to use all of our capacity efficiently.

4.     Design vs. Development: Communication

The final thing that went wrong with this project was the disconnect between what was originally designed, and what made it into each of the prototypes. Communication increased with each subsequent iteration, but from the beginning it was clear that the devs didn’t have the clearest idea of what the designers wanted. This resulted in a few clashes between team members that had to be resolved, as well as a few steps backward by devs in order to accommodate the vision that the designers originally had. The final prototype is the most faithful to the original design, but that accuracy could have been increased if time had not been wasted ironing out these problems early in the development process.

 Conclusion

We struggled through a number of hiccups and set-backs, but in the end, the team was proud of what we were able to complete. We had a working prototype with interesting and entertaining game mechanics, attractive aesthetics, and an overall design that we were all happy with.

[jranderson1mastery-blog]

November 2016 Mastery Journal Update

I am going to keep the current topic in the program field of Design and Visual Arts. This topic is going to heavily influence my future career field, so I think it would be diligent of myself to immerse in some of the research used by other game designers and developers to help strengthen my portfolio and knowledge.  

I want to continue research character development and creation, and its impact to the immersion process. Creating a character from scratch, and the world around them, is something I’m looking to do. Many recent games have a create-a-character UI system within its game play to appease the diversity factor of their game. I enjoy this but it causes limitation on the world building dynamic as your character is relatively flat and has little to no reaction to dialogue and events. At the same time, if I create a character that looks, sounds, and acts like myself (African American), I may push a portion of the gaming community and audience. This is the balance I want research and establish a foundation for.

[jranderson1mastery-blog]

Mastery Journal - Project and Team Management

In the beginning of this course, I was asked to set a goal. I set two instead: one for a project, one for personal reasons. I accomplished both. For the project, I started the game design document (GDD) for a personal project that is something I want to work on. Between character profiles, images, gameplay mechanics, etc., I have a solid base to work with on my personal, off-game. For my personal goal, I achieved what I set out to accomplish the goal moving my family to a new home. As I finished the task, my focus came back to learning as much as possible from the instructor, Nick Carver. This course, Project and Team Management, focused on teamwork, conflict resolution, team management, budget, and team building. What this did was build upon the last course, which focused on the dynamics of being in a team and the scientific methods that comes along with it. Taking the information Nick has given us has allowed me to focus more on the human side of being in a team. The entertainment industry is often a team based endeavor that depends on each member evenly. Taking what Nick spoke about in this class should help with this. Many teams face adversity and strife, so knowing methods that will settle petty dispute should be used often. Techniques used in this class are universal in nature. They can be applied to almost situations that occur inside the team room. The project management side I also useful for team application and project management. I didn’t realize that much detail had to go into detailing each aspect of the budget and project development timeline. You wouldn’t expect the problems being presented, even if it was just practice, to occur as often as it does. The old saying “be prepared for everything” really takes precedence in budget and project planning. Using these practices and past assignments as templates, I should be able to at least have an idea of how things should work as far as developing each step in the project.

[jranderson1mastery-blog]

Mastery Journal Assignment

First to explain my research topic before I can relate it to the RTD. My research topic is how the gaming industry uses character to creation model to give the illusion of diversity. We see this more and more in recent games, but there very is little context or plot involved with this method. Yes, each experience is different, but the player is often regulated to a silent protagonist role, or pre-generated responses. This loses some authenticity as these are vague responses at best. These characters lose characteristics that could make them stand out and fill the role of eyes and ears in the game world with lack of input from one’s own point of view. The connection we feel with the character is “me”, but this is an artificial feeling that only guides us through the game for just long enough to enjoy the game for one play through. Pokémon is a prime example of this situation. They added depth by adding multicultural characters such as Gym Leaders and other NPCs, with the addition of you customizing your controlled character. This was a good idea of change because there was always a good chance you could run into a NPC that looked and sounded like you, and you could attach to them for whatever little time you with that NPC. Other games fail at this by giving you character creation, but there’s a strong chance very little to nil NPCs will favor you or your characteristics. And many would argue that this is a good way to do diversity, but that not’s diversity, it’s just character creation with no depth. RTD will allow me to understand research techniques needed to justify my argument, while still finding resolutions that could appease the majority audience. Team dynamics that were applied in course allowed me to have a better understanding of how studios work, as well as the team building needed to be a successful team. The articles I found did help some, but not as much as I originally thought when I searched them out. Although they assisted in making a basis for research, they did not generate the spark needed to influence me to make them a pillar of the research materials.

[jranderson1mastery-blog]

This is an ongoing argument that is still rampant in the gaming community against those outside it. Even though the voice is much smaller than before, there are still some out there that think games influenced people enough to cause great tragedy. I personally believe if you’re a parent, and you don’t want your kids playing certain games, find the appropriate ESRB rating involved with the game you’re about to purchase. If your kid is playing Grand Theft Auto at 10, and you’re offended, then you can’t blame anyone but yourself. 

Image retrieved from: 

http://iwastesomuchtime.com/on/?i=87303

[jranderson1mastery-blog]

These are the monthly checklist for the upcoming courses in my Game Design mastery journey. Each slide has three goals, and three strategies for accomplishing those goals. These are here to remind me of what I need to accomplish on my journey to my Masters degree.  

[jranderson1mastery-blog]

My Game Design mastery course timeline for the next year. 

Reference:

Full Sail University. (n.d.). Retrieved August 25, 2016, from http://www.fullsail.edu/degrees/game-design-master/courses

[jranderson1mastery-blog]

This a quote that sums how many debates and conflict. Many times there is no good or evil, just disagreement based on we feel. We let this overwhelm us at times and irrationally blame the other side for their faults, instead of finding a common ground and goals. 

Reference:

Video Game Quotes. (2015, August 11). Retrieved August 18, 2016, from http://aminoapps.com/page/video-games/9078417/video-game-quotes

[jranderson1mastery-blog]

A screenshot of my feedly.com RSS feed. 

[jranderson1mastery-blog]

Here is my board to reference and update gaming news, rumors, research, and development/designer tips. 

[jranderson1mastery-blog]

A purposed logo for my brand. The colors offer a cool feel with a shielded storm. 

[jranderson1mastery-blog]

This a quote from Shigeru Miyamoto, the grandfather and president of Nintendo. This quote is is something to live by as a game design, but can be applied to other forms of media as well. You can a something delayed, then its released, it can be something great. But if you release a bad anything (game, movie, song, etc.). it can look bad forever and ruin your reputation.

[jranderson1mastery-blog]

This a quote from Shigeru Miyamoto, the grandfather and president of Nintendo. This quote is is something to live by as a game design, but can be applied to other forms of media as well. You can a something delayed, then its released, it can be something great. But if you release a bad anything (game, movie, song, etc.). it can look bad forever and ruin your reputation.