Process Analysis Write Up

The Problem

            Soon after the formation of Studio Scrapbot for our capstone game development assignment we began hosting meetings. We started out strong planning each meeting at least a week ahead of time, printing out itineraries that outline the exact process of the meeting, and defining hard-out times allowing us to better budget our time. However, once Spring semester began this all collapsed. With the expectations piling up on the team’s leadership we were less able to contribute the time necessary to plan our meetings. In fact, meetings became more focused on explaining things than on making decisions. A massive redesign of the systems in Snowmads necessitated more meetings, and more meetings necessitated a shift in production focus.

The Observations

            It wasn’t hard to see that meetings were dragging on and keeping our developers from the work they needed to get done. Unfortunately, however, data collection didn’t come into play until further down the line, a month into development. We did, however, have our meetings in the studio schedule allowing us to have a solid idea of the length and the amount of time in between when it was scheduled and when it was held. This is the core of the problems we aimed to solve.

The Data
            The primary aim with adjusting our process was to reduce meeting times by 50%. This data demonstrates why meetings were a problem for our team. These were the averages for meetings before we made any adjustments. This graph shows averages without stand-ups.


In about one month of development we had held 17 meetings (33 including stand-ups) totalling 41.5 hours (45.5) individually. These meetings mostly included the full development team adding up to around 622.5 person hours taken away from development in one month. However, the most notable problem this posed was more centered around the high-water mark being 6 hours for an individual meeting. With 10 developers present we lost 60 hours of development time in one night.

Another core issue was the time these meetings were planned ahead of time. Many of these meetings were indeed important to hold, but frequently developers would not be able to attend, and the leadership would be unable to plan a schedule or make an itenerary for the meeting because they were scheduled last-minute. Namely, the average days ahead of time that January meetings were scheduled was approximately 2.5. This might not seem too last minute, but that value if we exclude meetings with our faculty advisor who often scheduled with us at least 7 days in advance that value drops to 1.6.

The Adjustment

            Around when our team focused our efforts in a large-scale design overhaul we made a number of process adjustments. These were largely focused around improving the organization of the development process. We transitioned from a Scrum methodology to Spiral. The changes that this incurred were removal of daily stand-up meetings, a dedicated risk-analysis day, a scheduled test and evaluation period, and most importantly, scheduled development time. Development time was set for Tuesday-Thursday and during that time leadership was strongly discouraged from hosting meetings. Instead we encouraged communication on an as-needed basis, and started setting our meetings for Monday, Friday, or finding alternatives to hosting meetings in the first place.

            Developers found this very beneficial. They reported feeling more focused, more interested in their work, and working better than before. Prior to this shift four separate developers from three departments reported that the time they were able to contribute to their tasks (and subsequently, their hourly requirements) were disrupted by excessive meetings. After the change each of these developers reported a more efficient workflow.

The Data Mk.2

            Qualitative information can only show so much, the data bears out that these changes were not a perfect solution, but they were successful at adjusting two major disruptions to the development process. After declaring a development period, meeting averages for the following month shifted dramatically. The average meeting length was 1.1 (bear in mind stand-up meetings were no longer being held) and the highest meetings were only 1.5 hours. Most importantly, however, the average time scheduled ahead was 5.6 (4.8 without advisor meetings).


The Charts


            As the chart demonstrates, there’s a clear drop off in total meeting time after the process adjustment was made. It’s worth noting that countless other factors impact times developers spend in meetings, but this bears out that at least the expected outcome was achieved.

The Flaws

            This adjustment did not come without any problems. Namely, the data is partially skewed by the natural development process. It makes sense that meetings will be far more relevant in pre-production than during core production working towards a vertical slice target. Developers and leadership have reported a dearth of communication between developers, a natural consequence of the absense of daily stand-ups. Further process changes to correct this discrepancy is certainly necessary. Developers have, however, reported being more available to do their tasks, and often overperform in doing so completing their tasks before reaching their hour estimates. Included now in their workflow is time spent communicating with other developers and working on paired tasks.

Walkthrough: Beginning with Wwise in Unity!

In Rapid Prototype Production at FIEA teams of four or five developers are tasked with making a game… in two weeks. This week we completed our second RPP project, and I had the privilege to work on two core learning outcomes I considered important to my growth as a developer. I’ll address one of those goals right here in this blog post.

Audiokinetic’s Wwise

The first of my learning objectives was to figure out how to integrate Wwise into a Unity project. Wwise is an audio management software that connects to the major commercially available game engines to facilitate the implementation of sound effects. I only had two weeks to learn this software so my understanding at this point is certainly very surface level. That being said, I was unhappy with the tutorials I found online, so here’s my quick and dirty tutorial for getting started with Wwise in Unity.

Integrating Wwise with Unity

1: Make an account and download and install both Unity and Wwise (both the launcher, and the latest version of Wwise). Default install options should work fine.

2: Create a Unity project, and go ahead and make a canvas and a button object. (This tutorial assumes you have surface level knowledge of Unity)

3: Open the Wwise launcher, and select the Unity tab. It should autodetect the Unity project you made. Make sure to close your Unity project first.


4: Select Integrate Wwise, default settings should work just fine, but comb through them nonetheless.

5: Restart your Unity project, now within the Unity editor you should see a WwisePicker tab (if you don’t see it it should be in the Windows tab). This is where you will find all of the events and sounds you import into Wwise, and therefore can use in your project. You might also notice the audio listener on your camera object has been replaced with new ‘AK’ components.

6: Download a good, short, sound effect. My go-to is a short pop sound. I’ve included one here, but any .wav file should work.

7: Open Wwise either from the Unity tab in the Wwise launcher (the ‘Open in Wwise 2018…’ button in the above image), and make sure your layout is set to ‘Design.’ The hotkey is F5.

8: On the left side you should see a tabbed window with Audio, Events, Soundbanks, and many more. Make sure Audio is selected to start.


9: Find the Actor-Mixer Hierarchy, and right click the Default Work Unit. From there select Import Audio Files.


10: Click ‘Add Files…’ and select your desired audio file, and finalize the import. With that you will now have your audio file in your Wwise project, but it’s not yet associated with a game event yet.


11: As you may have guessed, now select the ‘Event’ tab. Once there, right click the Default Work Unit, select New Child, and select Play.


12: Wwise will ask you for a name for the event, this is vital. The name of your event MUST match the name you plan to call in the script. If you are using my pop.wav sound, go ahead and name the event “Pop”

13: In the center window you should now see a sound effect element with an empty ‘Target’ field. Right click that field and select browse. Wwise will open a window to have you select which audio track or tracks you would like to play. Select your pop from the default work unit.


14: Test your event by pressing the play button in the bottom tab. You should hear your audio, and see a meter on the right that shows you the peak volume of the track. If you properly hear your pop sound you’re on the right track.

15: Next we will make a soundbank. In your game your soundbanks are the repositories for all of the audio events you want to trigger. It’s easily accessible from Wwise once you generate it. To access soundbanks you’ll need to change up the layout. We want to navigate to the Soundbanks layout. This is in the Layouts tab OR you can press F7.

16: Here you see your Default Work Unit. Right click that within the Soundbanks tab and select New Child then Soundbank. The name of this soundbank isn’t vital for this purpose. I suggest calling it ‘Main’. You should see this soundbank appear in the center window.

17: Navigate to the Events tab, and drag and drop your Pop event into the new soundbank in the center window. This adds the Pop event to your soundbank. You can see it’s there in the center-lower window.

18: Save your project! And select ‘Generate All’ at the top of the soundbanks menu. A window should appear confirming your soundbanks were generated.


19: Save again, and we can now move back into Unity!

20: In Unity create a ‘ButtonSound’ C# script. Open the script and write a method that runs the following line of code. This method will be called when the button is pressed.

AKSoundEngine.PostEvent(“Pop” , gameObject);

21: Next, attach the script to your button object, drag and drop your button object into the button OnClick() space, then select the drop down menu, and find your ButtonSound script and select your menu.

22: If you test you might notice you don’t hear the sound when you click the button, and Wwise throws an error. To correct this you need to select your Main Camera object. Navigate to your WwisePicker tab, and drag your ‘Main’ soundbank from the WwisePicker onto the camera as a component.

23: Now when you play you should hear the pop sound every time the button is clicked! You’ve successfully used Wwise to play an audio event. This might not seem faster or more useful than Unity’s default audio manager, but as a project grows in size Wwise becomes more and more useful as a hub for your sound effects, music, voiceover, and ambience.

I hope Wwise works for you, and this introduction serves as a helpful guide on getting started. For any questions about this feel free to contact me through any of my communication channels!

When things don't go according to plan...

...change the plan! It has been an absolutely turbulent few months. Since my last dev blog post, I have finished work on Toys 'N Tyrants (post-mortem coming soon), graduated with a Bachelor of Arts in Digital Media, taken a trip to Europe, gotten a summer job, started work on some freelance development projects, and prepared for graduate school at FIEA coming in August!

You may notice, suspiciously absent from that list is anything relating to Project Summit. Ultimately, over the last few months, nothing went according to plan. I want to clarify, Summit may be off track, but it's certainly not canned. I'm (very slowly) working through the broad strokes, and I will continue to work on it in the coming months. What I cannot promise here and now, is any sort of timeline for the project. Presently work has me exhausted most days, and solo game development seems so daunting.

Now, with Summit addressed, I'd like to provide an update on myself as a developer. It struck me that I neglected to announce my acceptance to the graduate school I've had in my sights since 2014! I could not be more excited to work with the other incredible folks in FIEA's 15th cohort! 

Toys 'N Tyrants also wrapped up development at the end of April! We released the title with four total levels complete with enemies, power ups, an equipment system, and a thrilling boss fight! As my post-mortem will clarify, the development was plagued with issues, some of which were my own doing, but I'd be doing the wonderful developers of Aardvark Games a disservice to not boast all of the fantastic features we packed into a ten minute game.

And of course, last but not least, I GRADUATED! University of Central Florida undergrad has been such an incredible time of my life. All of the incredible professors, students, and faculty I've had the privilege to meet have influenced me in an unmistakably positive way. I'm so proud of my fellow graduates, and cannot wait to move on to the next stage of my career as a game developer.


Summit Dev Blog #01 – Maybe if I write about it, I’ll work on it

            Summit is an idea I’ve been tossing around for close to a year now. I’ve pitched it to two development teams in my time as a student, and both times the teams have chosen a different direction. The pitch was originally for a gripping emotional tale of a climber reaching the peak of a seemingly insurmountable mountain. This idea has shifted greatly in the recent months. I now plan on gearing Summit more towards an interactable audio play. While the ultimate goal remains, the context has been adjusted to address stigma about mental disabilities, mindfulness, and emotional well-being. This is a tall order, but a drive to represent the reality and complexity of emotional issues has been nagging at me for some time. I can’t let this idea slip through the cracks. I feel game developers, as artists, can address more difficult themes in interactive media than we are often willing to entertain within ourselves. Summit will be my attempt to manifest that drive.

            So I’ve created a plan, and in my months of putting this off I’ve managed to complete the one element of that plan. Wwise seems to be the best system to address the depth I hope to represent through Summit. Now the daunting next steps are facing me, and I couldn’t be more nervous and excited to start working. I’m happy to say with confidence that the writing process begins today. This will certainly be a time intensive process, and I’m unwilling to rush this project. That said, I expect a playable Chapter 1 (Vertical slice) completed by the end of June. I feel this gives me sufficient time to faithfully represent real issues and to address important topics through an interactive medium. This dev blog post is primarily for myself, by publishing this I’m taking a stance. I’m getting to work.

Taylor's Development Blog: Book Review Edition


            This is a far cry from my typical development blog post, but it’s too important to me to not address. Over this last winter I read a book called Creativity Inc. by Edwin Catmull and Amy Wallace. The book is about one of the creative minds behind Pixar. It traces through the growth of the company from inception to modern day.

            But the history lesson isn’t the reason the book resonated with me. Creativity Inc. addresses media production from a creative, and more importantly, a leadership standpoint. As a game developer, producer and writer I feel I learned a number of valuable lessons from the book. More specifically, I’m not one to highlight the books I read. Creativity Inc. is the exception to this. Immediately into reading I found myself highlighting something on every page.

            Catmull and Wallace present a production mentality I haven’t heard elsewhere. The idea that error prevention should be prioritized over all else comes under severe scrutiny throughout the book. While it wasn’t something I was particularly passionate about before reading, I find myself adjusting my own development and communication style in that direction.

            While I’m sure not every idea put forth holds its value outside of the Pixar ecosystem, learning in-depth leadership methods of other mediums, studios and teams is value enough in and of itself. I cannot suggest this book more for anyone going into a creative industry. 

Madhouse Postmortem

"First of all... damn..."

That was the first comment we received after the premier of Madhouse in class. For a while the class was speechless. We had made a miraculous comeback since our bumpy start. Slowly, the class began to fire questions. We elaborated about environment of Lockwood Manor Mental Facility, the voice over, and the narrative. Since its premier Madhouse has been incredibly successful. At the time of writing this we have nearly 400 views on the page and similar numbers on the release trailer on YouTube! However, as with any project, it never goes perfectly. I'm no exception to this rule. There's some things I did well, some things I could have done better on, and plenty of things I would adjust if given the opportunity. So, here's the postmortem as it pertains to my own role in the project.

The team after presenting the final build of  Madhouse !

The team after presenting the final build of Madhouse!

Where I succeeded: To get a good scope of what others think of my skills as a producer, I asked them directly to give me 'highs and lows' for the duration of our project. The highs seemed consistent across the board. My role as sound designer seemed to surprise the team. From the beginning we were worried about how difficult it is to create quality sound for horror media. Much of the team felt I succeeded at a very difficult task in Madhouse. Another prolific comment was a complement of my organizational skills. My ability to keep everyone on-task, track their hours, and make sure the game was on track is something I'm very proud of. Lastly, the team mentioned my commitment to documenting the project. Game Design Documents, Dev Blog Posts, and Burndown charts kept the whole thing on track. After all, documentation was a core responsibility of mine on Madhouse.

Where I failed: There were a few aspects of development that, because of my inexperience, led to some bumps in the road. While the team agrees we had a miraculous recovery, I'd be remiss if I didn't address them. First and foremost is version control. In August I had no experience whatsoever with server administration and version control maintenance, but because we collectively decided to pursue Unreal Engine I had to learn. The learning process was a slow one, and we lost out on countless productive hours because of it. I’ve learned from this mistake, and I’m fortunate I had the opportunity to educate myself before I get any further in a career as a developer. My team unanimously mentioned that I could be stricter on my teammates. At the beginning of the semester I drafted a contract with disciplinary action for teammates who did not complete their work. Over the course of Madhouse’s development, I learned my contract was far too relaxed. As always, I take my previous documents and iterate them to improve over time. The contract is no exception, and come Spring 2018 I hope to not have this issue at all.


What I should change: A few team members advised me to “Keep doing what you’re doing,” but that’s too easy. I know there are adjustments I can make to improve my role in future groups I’m a part of. First and foremost is playtesting. Because of the rapid pace of school projects, we had very little time to playtest Madhouse, and I will absolutely be prioritizing the testing phase from now on. I’ve learned so much from my time on Madhouse, and much of that knowledge is on better ways to implement audio. Because Unreal Engine was a new experience for Goliath Game Studios, none of us truly knew what to do. For me that meant simply throwing in audio however I could and duct-taping it together later. That’s a pitfall I hope to avoid. I’ll be researching carefully how to cleanly implement voiceover and sound effect sequences for future projects.

I’ll be enjoying the holidays over the next few weeks. Expect a new project to begin in early January. Follow my Twitter for frequent updates!


Madhouse hits Alpha!

“This is it, Lockwood Manor Mental Facility. No one’s been here in years.”

          I think I speak for the entirety of Goliath Game Studios when I say I want to tear my ears out every time I hear that line. Those are the words spoken by P.I. Darren Hall at the beginning of Madhouse, our suspense puzzle game. Just yesterday we presented our game to a classroom full of other game developers for critique. The presentation exceeded my expectations by a long shot. The developers behind Madhouse have performed miracles to get our game to where it is now.

3D Render of medical assets by Art Lead Chris Jones.

3D Render of medical assets by Art Lead Chris Jones.

            Madhouse is my first experience managing a team of this size, and It’s going quite well so far. Visual fidelity is the most impressive aspect for me. GGS’s art team has excelled over the last few weeks outputting beautifully rendered assets to create a truly suspenseful experience. From daunting medical instruments, to a shockingly professional transition scene, the experience would not be the same without our artists.

            Mechanically Madhouse stands on its own. Our two programmers have created an experience that showcases our strongest points and creates a truly mind-bending gameplay experience. They’ve worked hard to implement mechanics that bring the game together. Mechanics like puzzles in a distorted, bloodied solitary confinement cell, to creatively placed collectibles that form the world around through a journal mechanic.

Screenshot from the lobby of Lockwood Manor Mental Facility.

Screenshot from the lobby of Lockwood Manor Mental Facility.

            My contributions are, for obvious reasons, far more abstract than the valuable work the other developers are putting in. Project management isn’t nearly as exciting to the typical reader as creating a dark stormy limbo to terrify the player (which our Creative Director did), but you won’t find me underselling myself. Team management is always a struggle, and Madhouse is no exception. When hours don’t quite add up it’s my responsibility to find out why. When it comes to team management, it’s difficult to imagine Madhouse going much smoother. Realistically, there will always be snags, but through clear communication, and valuable contributions we have found ourselves with an alpha that stands up on its own.

When I’m not bringing my loadout of spreadsheets up to date, I get to work on audio. This is the most fun part of development for me. I’ve recently begun experimenting with Avid’s Pro Tools, but most of Madhouse’s audio was synthesized in Audacity (what can I say, it’s free!). I’ve had the privilege to work with talented voice actors, form demo reels, generate ambiance audio, and work in engine to help implement the sounds of Madhouse. Moving forward I hope to refactor much of our sound effects, and better implement the breathtaking soundtrack we have had developed for our game.

Now, I need your help dear reader, Over the next three weeks Goliath Game Studios will be seeking play-testers of all kinds. Whether you are experienced with games, or only play Candy Crush, your input is valued. If you are interested in playtesting our experience send me an email. I’ll get back to you with a copy of the alpha build of the game as well as a playtest survey. (By the way, there’s tons of Easter eggs to find!)


Schrodinger's Lab Postmortem

Screenshot from the tutorial level of Schrodinger's Lab

Screenshot from the tutorial level of Schrodinger's Lab

Nine weeks was the time it took to complete Schrodinger's Lab. I have no delusions about the size of the project, it's a small experience, and it's certainly got its fair share of issues. However, it's worth looking at the project both critically and optimistically for the sake of future development.

For the unfamiliar, the game features 'Schrodinger's Cat' trapped in a sinister lab. The player character has had his mortality disrupted and is capable of traversing both the living and the dead world. In both realms the player is tasked with accomplishing puzzles and exploring the environment.

Technical problems were probably the most pervasive. As it turns out third person cameras are quite difficult to set up. Luckily our technical director struggled through these issues and produced something we were satisfied with. In the final iteration we had a camera capable of avoiding clipping, orbiting the player at different heights, and moving independently of the player itself. We had the cat controlled via tank controls; this choice was made because our limited time restricted the animations available, so it seemed to look best with the character never truly strafing.

Development wasn't without it's design issues. From the beginning we had a goal in mind for an overblown exaggerated world. Think Tim Burton's style, but throughout the process we scaled back extensively and went more for a sterile laboratory feeling. While I think the whole team would agree, our first concepts would've been ideal, it seemed out of reach. Our design also led to some questions. Initially we hoped to frame the game as a 'try again until you get it right' game, and while that design did reach the final stage, it's something that if we were remaking the game we might rethink. Because of some unforeseen issues during development level design lacked a core developer, so it became somewhat auxiliary.

The project wasn't all bad though. In fact it's probably more valuable than I'm capable of seeing it. We accomplished creating an interesting environment with interesting puzzles in only 9 weeks of development. This was also our first designed game. Prior to this we had only made recreations or strictly regimented projects. With Schrodinger's Lab we had complete and total freedom. We took that freedom and formed a creepy, dark comedy, exploration puzzler. If play testing is worth anything, our aesthetic shown through very well.

Screenshot from the main menus of Schrodinger's Lab

Screenshot from the main menus of Schrodinger's Lab

I've learned invaluable skills during this project. I got the chance to write and direct some voiceover, do full audio design for the game, and fulfill administrative duties like task distribution. The most rewarding component of Schrodinger's Lab was absolutely the play testing. Seeing our project in post-alpha actually being played by people who had never seen the game, and them successfully completing the experience was an incredible feeling. In particular, one of our play testers had entered a room and didn't see anything, but when he circled back he saw a map posted on the wall and had a visible eureka moment. Even through its issues we had designed it well enough to be played and understood by strangers to the title.

Of course, thank you so much to Brayden, Carlos, and Luke for play testing.


I Made a Game

More accurately, we made a game. Presumed Dead, a young team of Game Design students were tasked with making a complete game. My teammates and I went through some serious ups and downs during this nine week production cycle, but as of yesterday we have officially 'released' our title Schrodinger's Lab. From concept and documentation to marketing materials we have done it all.

From Left to Right: Zachary Richardson, Jodie Guenther, Kaitlin Black, Alex Nichiporuk, and Taylor Gorder

From Left to Right: Zachary Richardson, Jodie Guenther, Kaitlin Black, Alex Nichiporuk, and Taylor Gorder

At the beginning of the semester I set out to learn. While I had particular skill sets in mind, my broader goal was just to learn how to make games. With the semester coming to a close today I feel much more confident in my capabilities as a developer, a student, and a person in general. It's a freeing feeling recognizing that given enough time and motivation I have the skills ready to literally make a game.

And that's exactly my plan moving forward. In the coming months I expect to work through preproduction on an interactive experience 'code-named' Project Deep Media.

And of course thank you so much to all the people around me encouraging me to develop my skills, and become a better creative.