It’s been a month after GDC, and things have calmed down enough here at DigiPen for me to able to take a step back and reminisce about it. It was the first GDC I’ve ever attended, and while my excitement for conventions has been dulled due to years of attending PAX East, it was still far more interesting than I thought it would be. I’ve wanted to do a “postmortem” style post for a while now, as I took a large amount of myriad info and experience away from it.
My preparations for GDC were repeatedly rushed and panicked; I had a lot of repeated good fortune, and as a result of this I was able to go to GDC for the whole week as a CA while staying with my brother in Oakland (for free). I applied to the CA program in the fall, and after a fellow student (and good friend of mine) gave me a recommendation, I got accepted. While looking for housing, I told my brother that I was going to GDC, and he replied that he was as well, and that his apartment was only a 30 minute train ride from the convention center. After realizing that I was indeed going, I hastily spent an entire week producing business card designs, and finally came up with one that I liked quite a bit. I spent a large amount of money getting them shipped to me as fast as possible on good card stock, and immediately after that, I was off to San Fransisco.
Being a CA was an awesome experience; I got to meet a lot of awesome people, and the work could barely be classified as such; I oversaw a lot of panels, scanning badges and briefing speakers at panels I would’ve attended anyway; being an audio engineer, I mostly attended audio panels (as there were a lot), and got to see some really awesome tech displayed. I also attended some leadership-centered panels, and a few about statistics, data gathering, and psych applied to game design. I got a lot out of my GDC experience, got to talk to a lot of crazy intelligent people with a lot of experience, and thoroughly enjoyed it all.
That’s all I have to say about what I did, and now I get to talk about the various things I took away from the conference. I’m not going you give you details on the tech shown at the conference, because I’d have to understand it completely to be able to teach you about it, which would be rather difficult, and I’d also ultimately just be plagiarizing from them, which is kind of illegal. I’ll mostly just be sharing work tips, fun facts, and interesting ideas that I got from panels or from talking to industry professionals. First things first;
Encourage quick iteration loops!
In one of the design panels I attended, the dev team talked about how they would quickly gather model data from mocap scenes and render them overnight so they could review them the next day and make whatever changes were necessary. It was a system they engineered and planned specifically so they could act out the scenes quickly and then quickly make changes or updates. This is useful for the acting and choreographing, but it applies to every step of every design process. Having design iteration loops is an effective way to zone in on exactly what you want to do; however, it is timely and may require a lot of work; finding ways to mechanize this process is a fantastic method of making it more simple.
A simple method of quick iteration would be making one level sketch a day, every day, just so you continue revisiting the game’s mechanics. A way to mechanize this process would involve doing these “sketches” in a level editor, and then having that level exported to the game and put in a playtesting queue. Anything works, as long as you emphasize a repeating process of doing quick work, getting immediate feedback, and working off that feedback. (This is arguably mandatory when working on a large game in order to keep a consistent theme.)
Conflict is indicative of opportunities for innovation.
This one was kind of eye-opening when I first heard it, as it makes a lot of sense when you think about it a little. If your dev team has a conflict concerning an individual topic, and people can’t seem to agree, there’s an opportunity there to resolve that conflict and satisfy both parties in the process. This is a much nicer way to look at conflict; in my mind, it was always a difficult thing to deal with, a “how do I resolve this problem without any lasting resentment between either party”, or something similar, where you’re playing the game of finding the smallest tolerable disappointment.
Keeping the above concept in mind, however, it becomes more of a logic problem, or a difficult game design problem; just another challenging logical puzzle to solve, where the more work you put in to finding a satisfying solution, the more interesting the solution is going to be, and in turn, all parties involved will come away happier.
Diversity in teams is important, as long as everyone maintains equal levels of contribution.
Something I can’t provide that this point was originally accompanied with was statistics; this point was gleaned from a presentation that gathered data on a lot of student dev teams, and were sharing some of the more interesting things they discovered. There was a trend across a lot of the slides, and that was that the concept of diversity always helped teams more than it hurt. Regardless of the percentage distribution, different ways of thinking always assisted the development process. This is an awesome, awesome point. Everyone seems to want diversity, and it’s never a bad thing, but it’s extremely satisfying to come across data that, in a sense, “agrees” with what people are pushing for.
This applies to any kind of diversity; gender, culture, race, discipline, work ethic, or expertise. Having several extremely similar experiences is not nearly as rife with potential for innovation as a diverse set of experiences would be. An important accompanying point, however, is that all people working together should have equal levels of contribution. This is key to having an environment with a lot of mutual respect and empathy, two things that are extremely important to have on any team, let alone a game team.
To get the best out of a team, orchestrate a creative and relaxed design environment.
Now, you’re going to have to take this with a grain of salt, as I am probably (assuredly) not the most experienced dev out there, but I can definitely say that from my experience and the experience of quite a few producers and leaders I’ve talked to, that this is a good idea. To explain, the concept of orchestrating a creative design environment is the idea of setting up a system, whether it be through regularly scheduled meetings, design sessions, group playtesting sessions, or anything similar, that allows everyone on the team to be as open and creative as possible.
It’s extremely easy for a culture of groupthink to be established in teams, and especially game teams, where you’re all working on this one game, and changing the main goal of that game is unthinkable, or “only up to designers”.That thought process of keeping ideas to yourself is contrary to the goal of allowing everyone on the team to be as effective and creative as possible, so it’s important that a group leader or producer does something to dissuade that way of thinking. That’s the concept of “orchestrating a creative design environment”; it’s about establishing a culture of creativity by providing a space for it, and allowing anyone to attend, but not enforcing or requiring it.
This is in the context of a game team working at the same level together, however; this can easily become more difficult the more devs are involved, or as company policies are introduced.It’s definitely something I learned a lot from, and I’m definitely going to experiment and see what the most effective methods to accomplish this are, whether it be meetings, dedicated working shifts/dedicated play shifts, or anything in between.
That’s all the stuff I got out of GDC that I can actually talk about; there was a lot of audio tech and code practices that were awesome to see, and I can’t wait to try them in the future, or even possibly improve upon/evolve them. As far as future posts are planned, I’m definitely going to do several post-mortems on the tech used in my game engine, as my project ends in the middle of April (3 weeks from now). A lot of the sound layering tech has improved, there’s some cool sound spectrum tech via FFTs, I’ve really wanted to do a follow-up reflection post, and there are quite a few systems in the game that contained extremely interesting problems to solve; my favorite and ongoing problem being the recording system we have for the game, and trying to compensate for the difference between the FPS that the recording was taken in, and the FPS that the game is playing at (as well as being able to compensate for any hiccups along the way). Stay tuned, person who apparently got to the bottom of this unnecessary lengthy article.
