Xavier Smith, Week 9 Journal PPJ, Blog post w, GMAP 378

Cleanup – 4 hrs
Fixing up games – 2hrs
Poke Games – 3 hrs

Lots of work done this week! We saw a lot of things that needed improving during our group meeting so I went ahead with all the tasks I assigned myself. Firstly I fixed up the Controller Select scene, and then Angela improved the art for it and made it look way better! Then I noticed the animations were pretty laggy in Stello Says, so I sped up the animations to match the game speed, as well as switching the background to a less noisy one and removed some of the obsolete text. After that I did a little tweaking for the balance in QWOP and did a fair amount of cleanup on Crazyball. The overall game should be a lot smoother and coherent now!

Finally, I started working on the PokeGames that we’re going to implement. I’d say they’re about 80% done right now, but here’s a quick preview as to what it’s going to look like. Player 1 will move left and right, Player 2 will launch the finger (foot for now) and the aliens have to try and avoid getting shot.

Content Positive:

- The game looks a lot better and is a lot less buggy!

- The instructions are a lot more consistent and coherent!

Content Negative:

- Didn’t quite get to finish the PokeGames

Total Time Spent: 9 Hours

GDC Vault  Postmortem Breaking Into The Game Biz

I chose this postmortem as it was a topic I am personally invested in. 

The presentation detailed how professionals within the video game industry got their start before Video Game programming was taught in schools. The first individuals, Randy Smith spoke about how he had a list of companies he wanted to work for upon graduating and would cold-call companies. However he advised that this is not a good approach for the modern day, however the enthusiasm behind the decision is what is important. 

The second individual,  Tess Snider spoke about how she taught herself and built up a resume on her own over the years, and eventually just sent her resume around to employers and found a job within a week

The third speaker, Ralph Koster spoke about how his first game was an unsuccessful board game project with one of his friends. He then proceeded to receive tests from Eldin online whereby he improved the system until he was eventually brought on to the team. He stressed the importance of creating a portfolio, regardless of what level you are currently at. 

The final Speaker, Gordon Walton spoke of his time before games were sold commercially, but advocated the previous speaker's point of putting your games out there. 

The speakers then talked about the most self-destructive behaviours within candidates. Behaviours mentioned were talking about never having played the company's game, generic programmer resumes, and finally speaking about where they want to be in the company rather than how they could help solve the problem within the job description. They then advised to look up requirements and learn the things consistently listed in them. 

Afterwards, they spoke of the things that stood out within no-experience candidates. The most pertinent points seemed to be passion and having a portfolio that displays interest and skill within the field. 

Finally, they discussed tips for candidates to work on and get noticed. The advice from the panel was to aim for a job that you really want, having an attitude where you are willing to improve, creating projects, networking with individuals regardless of their position, and finally having a passion for creating/making games rather than playing them, avoid getting typecast 

Cory Zicolella, Week 8 PPJ, Blog Post 8

Fixing up Survey - 2 hrs.
Faces for Poke Games - 2 hrs.

This week I hadn't anticipated a large problem: that the video edits I wanted to do to our final trailer in fact were impossible until our Wednesday large playtest.  There, I plan to capture new footage for our trailer in a much more quiet location hopefully) where the volume is normalized and it is easier to understand.

In lieu of this, for my other work this week I focused on firstly the playtest survey (since plenty of people (hopefully) will be taking it), and the faces for the poke games.

For the playtest, I had to figure out how to insert pictures into the questions that needed them so testers had context if they didn't know the name.  So time was taken first gathering the pictures, which took more time than it should because of the slot machine system; constant trial and error until I got the games I needed pictures for.  Then I reworded things that I thought needed tweaking, and removed a large amount of questions that either weren't relevant anymore or that we already got a large amount of data for.

For the faces, I wanted to start with something simple, then add more as I felt was needed, sort of like a template.  The part that took so much time was that I tried many different combinations of faces and the like before I settled on two that I enjoyed.  These can obviously be improved, with shadows or whatnot as needed.  They might look a little weird or creepy for what we are going for, but these are simple enough where they can be easily changed:

Content Positive:

- Fixed up the playtest survey for our big scheduled testing day (2 hrs)

- Made some faces for the poke games that are easily editable (2 hrs)

Content Negative:

- Didn't realize the scheduling conflict with the playtest date until mid this week, so I couldn't focus on the trailer like I wanted to.

Total Time Spent: 4 Hours

---------

As an additional thing to add to our PPJs this week, we were asked to go to GDC Vault and look up a post mortem of our choice, watch it, and discuss it here regarding how they handled it and our reaction.

The video I watched was entitled "4.5 Million Players in 100 Days: Lessons from Dying Light" ( http://www.gdcvault.com/play/1022816/4-5-Million-Players-in ).  The video was ~30 minutes in length, and I believe nicely sums up the process that the company went through from production pre-release to work post-release.  The speaker went into detail as to how everything was created and handled with anticipation of release day, and the features they definitely wanted included in the final release (along with their priority).  For Dying Light in particular, there was an emphasis on choice: they wanted the player to enjoy killing zombies, so melee combat was their first priority.  This was quickly followed by the choice to not indulge in violence at all, instead being able to run from zombies using a parkour system they designed to be very fluid and intuitive to a player running through unknown areas.  I find this aspect to be perhaps the most important take away from the speech, even if it was work done technically before the release, as it highlights that having a goal in mind is extremely important, and you want to keep a certain vision for your product by the time of release.

Nowadays watching post mortems are pretty interesting, because games do not so easily 'die' as they used to.  Updates, patches, and DLC keep trickling in, at least for a few years, and so to get a true post mortem is difficult (particularly for successful games).  Dying Light is now exception; the conference was held about 3/4 of a year after its initial launch, and the speaker talked about how it is very important to keep the audience engaged in the product, so they keep coming back.  According to their stats, which they track meticulously (for patching reasons - i.e. if very few players use a certain trap, they might patch in a subtle way to show people they can use that trap), they had about a 35-40% retention rate on the game.  This was referred to as a 'good thing,' because not all players on release keep playing, and to have nearly half of all people play it a year into its life is amazing.  But the speaker stressed the importance of player content, and how using the Steam Workshop added life into the game, with nearly 150 user levels.  They also engaged the community on Youtube with various challenges, and set up Skype pre-recorded message centers for little easter eggs having to do with the game.

When applied to Alien Arcade, I think it is important to keep in mind the audience we are trying to attract as well, and to keep them occupied with our game.  Obviously it is really different as this is a small college assignment with a team of 11, which won't be continued in any way past this term - unlike Dying Light which is patched still.  But being able to realize if we kept our initial 'vision,' not only though this term but through all 20 weeks of development, and if we considered our audience enough will be a large portion of the personal postmortem for me.

Tj Heiney, Week 8 Journal PPJ, Blog post 8, GMAP 378

This week I had the simplest tasks for the project that I have had all term. I was very grateful for this as re-learning unity has been a point of contention for me this term causing me stress. We needed to get the games up to BETA level. Refueled has gotten much better over the weeks. It was hard to nail the original concept.
I needed to add a new model and texture it for the game this week. I also put sound into the hose so that a sucking sound was made on alignment. I finally fixed the way draining works on the hose. It is now iterative so it counts down while you are colliding. I need to add the following code.
   void FixedUpdate()
   {
       if(colDet && humanFuel < 100)
       {
           humanFuel += amountDrain;
           alienFuel -= amountDrain;
       }
   }
    void OnTriggerEnter(Collider mCollision)
    {
        audioSource.PlayOneShot(refuelsound);
        if (mCollision.gameObject.tag == "Refueled_FuelLine2")
        {
            colDet = true;
        }
    }

    void OnTriggerExit(Collider mCollision)
    {
            colDet = false;
    }
The changes for Refueled:
3 hours

Shooting gallery only needed sound to be added.

The changes for Shooting Gallery:
1/2 hour

Total Content Hours: 4

Postmortem, Divinity Original Sin, Swen Vincke:
 This postmortem was really interesting. It was interesting because it tried to teach a lesson opposite of what most software companies teach. Although this postmortem was about Divinity: Original Sin, most of the talk focused on the entire company and the brand of Divinity. The talk focused on the larger aspects than just the game itself but the company. Divinity Original Sin is the latest game in the Divinity series.
The quality of games in the series had been swiftly declining. The talk started out with the lessons that they learned prior to Divinity. The most important lesson is a simple one, broken games don't sell well. So why did they put together a broken game? The list of issues was distilled into: A reliance on middleware, too many iterations, fragmented focuses, team issues, no control from publishers, no day 1 money, a lose of identity due to publisher involvement, and insufficient financing.  Divinity Original Sin was born out of the need for a reboot. The series had taken too many poor turns under publisher control.
The team set out to correct the franchise and put it back on track. They decided that they needed to be independent of publishers to allow them to work with freedom. When they went independent they established pillars to guide development. These pillars were: take control of the project and stick to the vision, make your own tech which enables you to control what your game is built on, self publish to set release date, and establish a strong identity. All of these are important lessons but Mr. Vincke stressed that Iteration is very important. Iteration is the most dangerous thing in software in my opinion. If you iterate too much you will never get a finished game. His take was that iterations allow for multiple visions and you can settle on what works the best.
The talk also focused on marketing your game. It is very important to create your brand so that people see your work. I think this has been the biggest challenge of this term since it was hard to test AlienArcade. 

Ricardo Yanofsky, Week 8 Journal PPJ, Blog post 8, GMAP 378

Content with Hours:

Exporting last week's animations proved to be much more problematic than I expected. The first issue was with the skin of the character not exporting properly in the fbx. It took me a few hours to even figure out what was going on, since I could not find anything online. Turns out that a few vertexes were missing skin weights, which maya had no problem with, but the fbx export did. However, after figuring it out it was an easy fix. On the other hand, after I sent the animations to Ryan, he had an issue blending between them in unity, and I had to put all the animation for the scene in a single fbx, which was easier to figure out, but much more tedious to actually do. Unfortunate that this happened, but it will not happen again.

(4 hrs)

Because of the time lost with this issue, I was not able to animate as much as I would have liked. I started on a run cycle for the "shoot the alien" game but I am not sure how to approach the rest of the animations for that game. I also made a looping "floating in space" animation that can be stuck in several scenes as a fun decoration.

(3.5 hrs)

Content Positive:

-All issues with exporting animation are fixed.

Content Negative:

- Lost a lot of time fixing issues between Maya and Unity

Total Hours for the week: 7.5

Post Mortem Reflection:

80 DAYS Post-mortem: Letting the Game Tell the Story by Jon Ingold

I chose this talk because 80 Days is a game I very much admire, but still find it oddly flawed. Many of my questions were answered during this talk. A good portion of it is Jon Ingold talking about the short history of his two-person indie studio, which is somewhat important for understanding how 80 Days came to be. Inkle was founded in order to create simple and intuitive text games, more interactive story than game. They built an engine specifically for this and worked with different writers to bring their stories to life in an interactive format. They did just that with their first few games, and then created Sorcery, which incorporated some more complex elements such as maps and items. 

The idea behind 80 Days was to re-skin Sorcery, based on Jules Verne's novel of the "Around the World in 80 Days". Ingold explains that they thought it would be a simple game to make, with most of the content created would be the text. He makes it seem like they started working on it right away and it evolved into something much more complex. The way he tells it it seems like the game was developed more during the process than in planning. Some games are carefully planned beforehand, and some evolve and grow in the process. These are the types of games that win "Excellence in Narrative" at IGF and Game of the Year from Time Magazine.

John Frankel, Week 8 Journal PPJ, Blog post 8, GMAP 378

Content with hours

Update Transitions

I spent some times to update the transitions.  The transitions will now show the controls for the next game sooner on.  Also I switched out the old circus tent for a new textured one that looks a lot nicer.  It looks a little awkward when you get close to it, so there is some room for improvement.
I also fixed some of the GUI control displays so they should be accurate now.
(2 hour)

Update Slot machine
I spent a lot of time updating the slot machine.  I had to add new games, and new icons and make sure all of the new games.  It was a bit of a pain to track down all of the assets but i did finally get them.



These along with others were added and updated We now have 22 games total!

(1 hour)
Add new game
I spent some time to create a new game.  The player is placed on a tic tac toe like grid and has to find the space with the O on it.  After the time runs out, all of the blocks that have an x on them falls and the player falls unless he made it to the O space.  This game was neat and my first game in the project.  At least I got one in.  I am still missing some controls so I will need to update it next week.


using UnityEngine;
using System.Collections;
using UnityEngine.UI;
using UnityStandardAssets.Characters.FirstPerson;

public class TTONMaster : MonoBehaviour 
{
    /// <summary>
    ///     Keeps track of the overarching game info (start, end, timer, score, winner) and updates UI
    /// </summary>

    // Amount of time for the game
    public float timerGame = 5;
    public float timerWin = 2;
    public bool drop = false;

    public GameObject[] blocks;
    public GameObject above;
    public Sprite Osprite;
    void Awake()
    {
        StateHolder.MiniOver = false;
        CustomTimer.TimeLimit = timerGame;
    }

    // Use this for initialization
    void Start()
    {
        int index = Random.Range(0, blocks.Length);
        GameObject selected = blocks[index];
        Destroy(selected.GetComponent<CubeDrop>());
        selected.transform.GetChild(0).GetComponent<SpriteRenderer>().sprite = Osprite;

    }

    // Update is called once per frame
    void Update()
    {
        // Update the timer and score UI
        if (StateHolder.MiniStarted)
        {
            if (StateHolder.MiniOver)
            {
                drop = true;
                foreach (GameObject g in blocks)
                {
                    if (g.GetComponent<CubeDrop>())
                        g.GetComponent<CubeDrop>().Drop();
                }
                above.GetComponent<CubeDrop>().Drop();
            }
            else
            {
                CustomTimer.SceneTimer();
                // Add to alien's score if time's up
            }
        }
    }
}

(3 hours)

Total hours 6 hours

Pros
I made a game
Cons
I had trouble finding assets.


GDC Vault Tower Of Guns Post Mortem

Tower of Guns Post mortem.

Tower of guns is a game that was created by a single developer, and his brother doing the music.
77 on metacritic.

People can and will praise you for the same things that other people will criticize you for.

Don't compete with tripple A, they have way more resources than a single developer can have.
Triple A however, does not have much flexibility and depends solely on the profit margin.
Look at what makes a game great when you were little.  Things should look fun over beutiful.
By looking fun, things can be a toy as well as a game.  Thinking of things a playgrounds instead
of arenas was a huge drawing point of tower of guns.

Some things in the game, like the perk system were interesting, but not fun.
In a similar but opposite system, the entier main mechanic of dodging bullets in a dance like
system, was changed mid development cycle based on player feedback.

Adopted a heirarchical design where he created on fun boss and from that boss created enemies and
from those enemies created more enemies and so on.  That way the enemies were like the bosses but
smaller and also potentially fun.

SOmetimes you have to chop out content that is not fun. ANd sometimes doing this method listed above makes
the game feel samey.

Art was done is a way to maximize speed, and the limits kept the art style constrained so that he could
make the best game he could realisticly.

There is a problem with indie development and that is the lack of Motivation.
If you are alone, it is hard to get motivated and easy to think that you are not doing good.
In a group the people around you everyone thinks together that something is good.

Have a public log to have some accountability and also do your best to get out and demo your game
and talk to other people.

Find Fans
Release builds for cheap where you under promised and over delivered to surprise and envigorate your
fanbase.  Each build should feel new.  Talk and get a feedback loop with fans.

With indie development you are not anonymous and people will know you.


If you are an indie, get an identity for yourself.

David Monteleone, Week 8 Journal PPJ, Blog post 8, GMAP 378

Content with Hours (Examples included):

                The group tasked me with going through several of my own games along with games from last quarter and fixing several bugs in them. I also added several enhancements throughout the games. The first game I needed to fix was Space Aim. The movement style was switched to using AddForce many weeks ago. As a result the gameplay was completely different. It was changed in order provide a more fluid experience on the motion base. The group decided it made the game much worse, so I was tasked to change it back. Another fix in Space Aim that I had to do was to make the “collision box” encompass the feet. The feet no longer clip through geometry or walls! Last, the controls for Space Aim had a slight bug from the work I did on them last week. The controls would still flip every so often. After bug hunting for a while I did find the issue. It was related to old code from last quarter… I hope it works correctly now!

 (1 hr)

                Next, I moved onto bug fixing the newer games that I produced. The Press game needed to have sound effects added to it in order to enhance the experience of winning and losing. Thus, I had to rework some of the code to allow for some time to play the sound clip before moving onto the next game. I did the same for the Quiz game. There are now distinct, and fun, sounds for when you win and lose them. In addition to adding sounds, I added some cabin motion for when players win. Previously there was only a shake when the players lose. Now there should be motion for winning or losing (different types of course). The Water Gun game required a number of tweaks that the group asked of me. First, I switched the controls from being “holding” to “mashing”. Based on the in person feedback the group said that players kept mashing the bumpers in Water Gun. This took a fair amount of time as the code for shooting was tide to holding the buttons instead of mashing them and had to be rewritten/restructured. The alien controls for moving their target up in Water Gun was switched to the spacebar instead of the up arrow. This was also based on group’s and player’s feedback. I then made the cardboard waves in the Water Gun game move up and down. The group’s feedback indicated that they didn’t realize that they were supposed to be on water and moving the waves may help. The Water Gun game had a slight bug where the balls being shot would spawn behind the gun and go through the water gun. I fixed this and now the shooting looks great! Last, the Water Gun game had some stale code from the beginning of the quarter that result in some weird controller behavior when relating to the new controller scheme I implemented last week. I took the old code out and fixed the places that broke after taking it out. Water Gun, Press, and Quiz should be ready to ship now!

(4 hrs)

                My last major task for the week was to rework the initial welcome/controls screen. This is the screen that players first see and use to define who is player 1 and who is player 2. I brainstormed with the group at our weekly meeting to decide what information the screen should convey. After a couple iterations I found that the screen shown below is the best version. I reworked the screen to get the logo in it, add proper controls where the players should be looking, and even told the aliens where they should start paying attention to. I had to make control images from bits and pieces of other controls that Angela had made. I just Photoshopped them together. The goal of this layout is to get the humans and aliens looking in the correct spots from the start of the game! After we play test this version I hope that my intuition is correct.

(1.5 hrs)

Content Positive (Duplicate hours from above):

-          I fixed Space Aim hit boxes, movement, and controls bugs were fixed (1 hr)

-          Numerous Water Gun game bugs were fixed by myself (Button mashing, shooting, waves, controls…). The Press and Quiz games got some added audio effects by myself. They also had their code reworked to display the new controls on the dashboard instead of text. (4 hrs)

-          I reworked and created the new control screen/welcome screen scene(1.5 hrs)

Content Negative

-          None

Total Hours for the week: 6.5 hrs

GDC Vault Post Mortem Reaction:

I chose to watch the Among Friends – An Uncharted 2: Among Thieves Post-Mortem from the GDC Vault. The game studio behind the game is Naughty Dog. I’ll give the general layout that Naughty Dog chose for the hour long talk and then give my analysis, take away, and reaction to it. The general flow could be summarized as follows:

1. Introduction to the studio and game (Who they are and where they’ve been)
2. Idea and direction of the game (Where the team wanted to go with the game)
3. Preproduction and concept designs (Ideas that the team wanted to implement)
4. Macro design and layout of the game as a whole (High level game layout and flow)
5. Full production of the game and micro design (Methods for full production both art and code)
6. Methods used for full production and organization (Development models used – 1 week sprints!)
7. Technical Challenges and how they overcame them in production (Art and Code)
8. Analytic tools and methods used to test and gain data from testing (How they collected data on the game)
9. Play testing methods along with example test data gathered (How they tested the game in alpha and beta stages)
10. Final conclusion and turnout of the game (Obviously it was a huge success)

My main reaction to the overall presentation is that game developing is incredibly fast paced and it’s difficult to organize almost anything. By the time production begins the team is on such a tight schedule that everything is on either a daily or weekly basis. The developers made a point of saying that at some point talking about what to implement needs to turn into actually implementing it. They claimed that this is the best method of game development. Simply implement as many things as you can and see what works and what doesn’t. You can’t just keep things on the whiteboard or on paper.

A point that I felt deserves being discussed is that fact that they seemed to only go heavy on play testing at the end of the game’s development. This is different with regards to how we play tested on game. We play tested in grey box stages. I’m not sure which is the best, but it seems like they just internally play tested during the early development stages.

When they discussed preproduction I found it rather interesting that the simple most important deliverable from preproduction wasn’t any GDD or anything like that. It was more of a high level abstract layout of how the game would flow from start to finish. This gave the team the ability start breaking our tasks into chunks based on levels and gauge how much team was needed for each section.

Time management and estimation was an interesting topic that was peppered throughout the talk. The team made several points that showed just how inaccurate time estimates can be. They cost the team significant production delays and ended up having to wait on either artists or programmers to finish certain sections. Eventually they had to build their work schedules around these pieces that took the longest to make. Time estimation is something our own team has learned that is critical to timing the deliverable of any game. It’s interesting to see that even professionals struggle with it.

The last section of discussion that really stood out to me was how even within this face paced development, the team was able to take time to optimize the game. Usually from my experience at Drexel, optimizing the game is almost an afterthought. The team specifically set aside time to make sure that each level ran at a consistent 30FPS. They were thinking entirely about how the end user would experience their game. In contrast to the games I’ve made at Drexel, the teams usually don’t think as far as pleasing the end user since the games are done at the end of the term. GMAP 377-378 are slightly different though since the games will be kept on the motion base.

In conclusion, the Naughty Dog team created an excellent game and the development of the game was not exactly organized, but was directed enough to get to the finish line. Ultimately it was an excellent game that tackled many development challenges that were explained in the talk.

Ryan Crim, Week 8 Journal PPJ, Blog post 8, GMAP 378

Content with Hours (Examples included):

Getting closer to the end of this project, my main focus this week was to clean up different aspects of the game structure and my individual games, as well as implement a new one if I got the chance.

To begin the week, I tried to make the game more uniform by adding the pink bar of pre-game instructions I had in my mini/micro-games into each of the others as shown in Figure 1. This required modifying the timer and stateholder scripts to consider when a game actually “starts” (instruction bar disappears) as well as updating the scripts for each game to consider this new logic. Furthermore, there was the issue of the low amount of points the game awarded from playtesting, so I centralized and increased the point values and updated all the game scripts to use these variables so that the point values can be easily modified. Lastly, in terms of structure, I noticed that when I updated the transition screen to compare the scores from the last game to decide what music should play (as part of my score changes from the last build), I accidentally had the updating of previous scores in an if-block so it did not update every time as it should and does now. (2.50 hrs)

Figure 1. Screenshot of pre-game instruction bar in existing Runnerz game

Moving on, I made a few additions and updates to my each of my existing games listed below...

• Abducktion (0.25 hr) 
• Added sound effects for X-ray and cup swap (whoosh) 
• Draw at Noon (2.00 hrs) 
• Created an animation controller and added/modified scripts to handle animating the alien as shown in Figure 2 
• Modified motion of human knockback to coincide with the alien’s as well as to keep the camera on the animating alien 
• Fixed issue where alien would shoot itself after Ricardo shortened the transitions 
• G-Switch (0.25 hr) 
• Slowed spinner speed to make it easier for aliens to affect the game 
• Added sound effect for jump to make it easier for Human 2 to know when to switch gravity 
• Dance Off (0.50 hr) 
• Modified motions of player object and added slight motions to camera to try to get more consistent motion and feedback

Figure 2. Animating alien model in Draw at Noon

After modifying my existing games, I had a bit of time to create a game based off of the Whac-A-Mole arcade machine (cleverly called Whack-An-Alien) as shown in Figure 3. Just like the real machine, moles (or aliens in this case) randomly pop up out of the nine holes. The humans need to position the hammer over the corresponding hole (by holding in the correct direction(s)) and slam it down on the alien in order to get points (see the screenshot for controls). After a short time of not being hit by the hammer, though, the alien will retract into its hole and the aliens will be awarded points. Aliens continue to pop up randomly until time runs out. The work for this game consisted of building the scene up with all of the assets (including modelling a simple Whac-A-Mole-esque machine in Maya), writing the two scripts to handle the moles and the hammer, and retrieving the background music for it (http://www.playonloop.com/2016-music-loops/dolphin-ride/). (3.50 hrs)

Figure 3. Screenshot from Whack-An-Alien micro-game

Lastly, since we are nearing the end of the project, we were required to watch a post-mortem presentation from the GDCVault in order to familiarize ourselves with the mindset we should have in thinking about how the project went well and how it could have gone better. After watching parts of a few different presentations, I finally settled on watching Chris Harvey’s “Learning From Our Mistakes: A Post-Mortem of Guacamelee!” all the while taking notes. Below you can find my summary of these notes. (1.75 hrs)

As a co-founder of DrinkBox Studios, Chris had a prime viewpoint to see how the process of creating their first game, About a Blob, compared to their process for creating their much more successful third game, Guacamelee, and thereby outlined what changed to bring this success. Within this presentation, Chris split the process into three main stages: Concepting, Development and Marketing.

In the Concepting stage, there were a few different aspects that needed to be considered, including choosing a concept, defining the game and finding the fun. In terms of choosing a concept, they changed up their process by having members of the studio in all different departments meet and create single page pitch sheets outlining a game idea complete with genre, platform, target audience, story and mechanics. Therefore, they could select the game idea that the consensus enjoyed and refine the selected idea with pieces from other pitches to make it even better. Moving on to defining the game, DrinkBox refused to enter production until they understood and nailed down the basics of the game and had as few loose ends as possible. That way the team could stay focused and synchronized meaning that time would not be wasted later on second guessing decisions. Lastly, in terms of Concepting, Chris mentioned that in order to find the fun while keeping consistency, the fundamentals of the game should be conservative and individual elements should instead be riffed on. There is no need to reinvent the wheel for every aspect of your game, and it is better to have existing similar games to see what works and what does not, since that could end up wasting a lot of valuable time in the process.

In the Development stage, there were also multiple aspects that needed to be considered, including pre-production, deadlines, personality and charm, toolset and target platform. Starting with pre-production, Chris mentioned the importance of having a small, dedicated team (from different disciplines) with clear goals and roles to get the process rolling and keep it focused. He also stressed that the leads of the project should not be working externally or this focus could easily be thrown off resulting in rebooting and second guessing. Lastly, he mentioned the importance of keeping constant discussion and to work on small pieces at a time instead of trying to create the whole game at once. This led directly into the idea of setting incremental deadlines with small and obtainable goals. On this front, Chris also noted the effectiveness at making the deadlines external to publishers/the public, since it would put pressure on the team to actually get it done, allow the team to see what each person is capable of and to identify what in the project is not as important as originally thought. Despite having deadlines, though, the DrinkBox team found the importance of switching to the mindset of saying “yes” to more of the team’s ideas so their personality could define it. Therefore, they would have team meetings to see in-progress work from all departments and accept feedback/suggestions as well as encouraged experimenting, which created a more positive atmosphere and revealed unexpected talents from individuals on the team. In addition to being more open and creative, the team realized the importance of making the development faster, easier and more efficient in any way they could. Therefore, when they found a deficiency or an iteration process to be slow, they made modifications to the process to improve the situation, such as creating a programmer-driven, artist tunable system to create visual effects instead of relying as heavily on the artists. Lastly, in terms of determining the target platform and the release process, Chris said they had basically no change in the result (still self-published), but they did change their attitude to question presumptions and to put proper thought into it before making a decision.

Moving onto the last part of the process, Marketing, Chris laid out the importance of making the game as visible as possible through the game reveal, public relations and the launch. Starting with the game reveal, DrinkBox was initially scared to show About a Blob early due to changes possibly confusing people and the belief that showing a game not polished enough would ruin the reputation of their game, however, this resulted in a lack of anticipation for the game. For Guacamelee, though, they took the opposite approach and announced the game just out of pre-production with an announcement trailer that was not perfect, but it still built excitement. Furthermore, they showed the game off as early and often as possible anywhere they could. This lead to them to continuously work with a PR firm to help with the marketing side. Chris mentioned that there was not much media coverage for About a Blob since they were trying to do it themselves and put it off until the end. Considering marketing is a huge part of selling a game, it makes much more sense to hire people who know what they are doing, instead of trying to figure out it out yourself and wasting time that could be spent on the game. Lastly, Chris discussed the importance of planning and taking the launch extremely seriously, including a press tour, reviews and store placement/timing.

Overall, Chris started out the presentation sounding a little nervous, but I think he definitely warmed up throughout it. The information provided and the idea to compare the process of creating a successful game to one that was not so successful really helped drive home the points he wanted to make. This presentation definitely brought a different set of ideas that I never really considered and I plan on putting more thought into the process next time I work on a game.

Content Positive:

- Implemented a bit more uniformity with pre-game instructions and centralizing point values

- Added to and fixed up various parts of my four existing games (including alien animations in Draw at Noon)

- Created Whack-An-Alien micro-game

- Watched a very interesting and helpful post-mortem presentation

Content Negative:

- N/A

Total Hours for the week: 10.75 hrs