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.

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.

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!

Toys ‘N Tyrants was my second workshop game for my undergraduate education, and as all cobbled together student projects it had a fair share of issues. I feel I’ve learned far more from the failures of projects I’ve been a part of than the successes. There would have been no Madhouse if we had not presented a slideshow instead of a vertical slice. I’m very proud of the team that worked on Toys ‘N Tyrants and I feel we succeeded in the vision we had from the outset. Now, with some distance from the project, and with some perspective I feel comfortable considering the reasons I could have done so much better. This is not a post mortem of the game itself, but rather my own contributions it.

What I did right

First of all, I feel I did what I was tasked to do very well. I took on the responsibility of making sure everyone on the team can get their work done to the best possible level. It was my responsibility to pull the strings with Unity, HackNPlan, and Discord to get work and communication flowing. At this, I feel I succeeded.

I also feel I succeeded at knowing when to reduce scope. Before Alpha the Creative Director and I had to make the decision to cut four enemy characters. We made the decision to either create a product with four unique levels, or a product with eight unique enemies.

This was the first project I had worked on with a strict hierarchal structure. I had a team of four other leaders reporting to me with the successes and failures of their team. These leads were invaluable to managing a group of 15 students all of whom were working remotely. Communication between leads was generally free-flowing. This did not functionally translate downwards, and easily constitutes…

What I did wrong

Communication quickly became a recurring issue. Members of the team felt leads weren’t communicating properly, and leads felt the team was not listening or engaging with our communication. During the process I felt this couldn’t possibly be my fault. I cannot control the way others communicate. Since then I have learned, it’s not a producer’s job to control anything. It was my job to facilitate communication. On that front I failed to convey my ideas properly, and lost sight of the fact that everyone wants to succeed on a team.

Expressing expectations is not something that comes easy to me. I expect great things from those who work with me, but with Aardvark Games we quickly established a precedent of low expectations. It was my responsibility to rectify this before it became a problem. Unfortunately, I didn’t see this until it was too late. Over the course of the project we put in countless hours beyond what we would have needed to had we been clear where we placed the bar as leadership on the project.

What I would change

How can I answer this question without mentioning scope? No scene makes a movie, and no line makes a scene. I don’t remember where I heard that, but I feel it rings true in games. That scene in games is the dreaded It’d be cool if… a phrase I love to hear in preproduction, but can easily result in feature creep beyond. The easiest change I could make would be to simply cut down sooner.

I’d also facilitate a more refined vision for the game sooner; one that can garner unilateral support among the team. Often in development it felt like five people were driving one car.

Lastly, I’d talk more to more people. This part is difficult because we all worked remotely. Communication channels were almost exclusively text-based and I seldom got to know the skilled developers working with me.

Ultimately, the project turned out well. We succeeded in most of our goals, and its pretty fun to play! Here is the itch.io page for anyone interested in testing it out. As is the nature of the beast for educational projects, we are no longer developing Toys ‘N Tyrants, but I always welcome feedback in any way.

...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 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.

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.

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 itch.io 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!

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!

“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.

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.

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!)

With the semester trudging along despite the rude interruption by Hurricane Irma, Madhouse has been an exhausting endeavor. Note that this development blog is about my roles, and my own growth through each project. The team behind Madhouse, Goliath Game Studios, has been great, and their work exceeds my expectations at every corner. I've personally learned a number of valuable lessons already, and it feels like a necessity to put them down in writing.

Production documentation is tough! I consider myself fairly capable when it comes to organizational skills, and keeping track of myself throughout the course of a project. What I was not prepared for is keeping track of the eight other creators behind the project. The team moves at a wild pace, and keeping up with them while maintaining organizational habits is well beyond what I expected. However, through all of this, it's been an enjoyable, and I'm sure it will be a rewarding experience.

Audio is far more involved than I thought it could be. This semester I've dedicated myself to learning how to record and process audio to make deep interesting sound effects. Through this time I've learned how truly deep audio can go. Researching professional game audio has led to a world of interesting ways to get different sound effects synthetically. As we move forward, I'll certainly be diving deeper into this.

After a hiatus of artwork development, I've reclaimed my position as producer on this semester's Game Design Workshop project. Some clear challenges lay ahead of Goliath Game Studios (GGS) for this semester, but I'm confident we have the best team to tackle these.

This is my first time managing a team of this size, and certainly my first time organizing and tracking time expenditures at a consistent rate. It's already proving a more difficult task than I ever imagined, but serving as a conduit for the team to communicate, develop, and create is quite a satisfying experience.

Project Madhouse is an exciting project to move forward with. I plan to update with a development blog to better represent the goals for the experience at a later date, but at this point, we know Madhouse is to be a Horror-Suspense Puzzle game set in a mid 1900s asylum. The manifestation of this game thus far has the asylum itself as the driving factor. Concepts like asymetrical storytelling, sentience in setting itself, and the failings of memory are all to be present in Project Madhouse. We've taken inspiration from stories like The Shining, Pulp Fiction, and P.T. I think it's safe to say the team as a whole is quite excited to move ahead with this project.

Sometime last year I found myself locked in a discussion with a friend and colleague about our gripes regarding the Game Design program at our university. While I think some great points were made throughout the discourse we did reach a disagreement over the importance of traditional artwork courses.

I took my first college level art class my first semester here. It was 2D Design with Professor Cooper. I found the experience a unique challenge and highly educational on the basic concepts of composition, color theory, and value. Since that class I've taken a fundamental drawing course, an illustration course, and I've practiced digital painting in my own time. Despite my lack of interest in traditional artwork as a career path, I found these courses immensely helpful in the grand scheme of design. These are a few of the concepts that those classes taught me, and why I feel they were important to my development so far.

Thumbnails are so easy to lose track of, but in my experience, it's vital to a successful project. Thumbnails in an artistic context are small bite-sized images that are meant to represent the roughest draft of a piece. They're often done in groups of 10 or 20 to give the creator some scope on what type of image they hope to create. Thumbnails become even more important once a project becomes a group project. This is because they give the rest of the group a stage to voice their concerns, ideas and complements before the larger piece has already been done. Not to mention they make great work-in-progress posts for social media.

Attention to medium is another lesson I found quite useful. It's easy, especially when caught up in programming, to forget what the end user will be experiencing. When creating a traditional piece artists will often take a few steps away from their piece, or close one eye to attempt to view it from another lens. This is something that seems to be done less in creating interactive experiences. Testing is used mostly for bug fixes making it easy to miss glaring issues with the end user experience. These problems can get all the way to playtesting when it's too late to shift the design. I speak from my own experience in Schrodinger's Lab. Had I taken those steps back and done a better job of playing the game as a stranger might play it, I think some of our design problems would've been easily solved.

Iterative Design is fundamental to any large scale project. This one is a bit of a cheat because I'm confident every class I've taken in the digital media program has stressed the importance of this. The first idea is seldom the best idea. A number of times I've found myself swept off my feet by a concept, and when I start work on it even I get bored. In traditional artwork courses iterations aren't suggested; they're mandatory. It can be frustrating to work through 20 thumbnails when I already know exactly the piece I want to make, but I think it goes beyond simply exploring ideas. I think creating thumbnails, value compositions, final black and white drafts, color compositions, and multiple final pieces forces me into the proper head space for creating artwork. This isn't necessarily something I've seen notably absent from my past projects, but it is something I feel art courses teach very early. It's something I won't easily forget.

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

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.

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.

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.