McCarthy Protocols Series
The McCarthy Show #5: Discovering Alignments, and Concluding My Own.
This is it! Week five. The final installment of my series on The McCarthy Protocols. I hope, if you’ve followed along, that these protocols have gotten clearer and clearer as they’ve been explained. There’s only two short protocols left. The Investigate protocol, and the Personal Alignment, arguably two of the most important protocols in the Core, and the latter of which is, in my own opinion, the cornerstone of what the Core is all about (hence, I saved it for last!) You may have noticed these introductions have been getting shorter and shorter, and that’s simply, I feel, because the pieces are falling into place. It’s less explanation and more internalization – that’s kind of how this process works. It always feels really goofy and silly in the beginning, but as it comes together, it really cements the dynamic of a team together. As always, you can return to the very first introduction post here and read from the beginning if something doesn’t make sense, or click here to go to official online Core Document. Additionally, leaving comments and feedback is a welcome way to Ask For Help on using the Core, or simply talk more about it in general. – I really enjoy working with them, and have done my best to implement them with the various teams I’ve worked on since graduating college even a few short months ago. Anyway. Let’s get started. Read on!
MAX/MSP: Delay Lines (A Beginners Tutorial)
Welcome to a quick overview of creating a Max/MSP patch. This is my very first tutorial on Max so it’s going to be incredibly simple. Any other Max Patches I create will likely show off something a little more complex, so experienced users might not find too much here for them. Max/MSP (M.S.P. standing for Max Signal Processing) is an incredibly cool program developed by Cycling ’74, created by Miller S. Puckette (another M.S.P.!). It is largely considered to be a much more user-friendly cousin to Pure Data (“Pd”) , which Puckette also designed. Since I purchased it a month ago, Max 6 has quickly become one of my favorite toys, and is incredibly fun to design audio with. It is a Digital Signal Processing application, which means that it can process audio in real time. We’re going to take a quick look at Max to get a glimpse at it’s capabilities and create a short, extremely simple delay effect. To avoid repeatedly explaining anything, when I say to create an object, just hit “N” on the keyboard and type in the name of the object that I write in a quotes. To start, create an “ezdac” object to create an output for your signal (a “dac” is a Digital-to-Audio Converter – a speaker(!) – and its inverse is the “adc”, the Analogue-to-Digital Converter – a microphone(!). You can use just a regular “dac” as well, but the ezdac offers a graphical interface). The interface of the ezdac is pretty simple. Click it to turn the audio engine on or off. The next step is to actually create the signal, so let’s create a new object called “cycle ~ 220”. “cycle” is a keyword to generate a sine wave. It is an oscillator. The tilde (“~”) is a signifier that the object deals with audio and not data – all audio-related objects end with a tilde. The 220 is an argument for the “cycle” keyword that specifies 220 cycles per second (a wave with a frequency of 220 hertz). If you were to plug this object into the ez-dac, you can hear – at your speakers maximum volume – a pure sine wave of 220 hz. To give yourself some control, create a “gain~” object and connect it between your ezdac and oscillator (make sure to connect all channels of the dac to the gain slider. Now that we have something playing a tone, we’re almost ready to create a delay line, but because we have a single tone playing, any delay is going to go unnoticed, so let’s create a number box (hint! hit I on the keyboard to create a number (integer!) box!) and plug it into the “cycle~” object’s top inlet. The number box will alter the argument of the oscillator, so whatever number you place into the number box will replace the “220” in the oscillator object. The trick here is that you can click and drag on the number box and hear the delay line as your oscillator […]
The McCarthy Show #4: Team Decisions
Week four! This series has now been running for a month! Is it weird to say I’m a little bit proud of myself at the moment? I know I don’t have a ton of readers yet, but even still, it feels good knowing that I can take something I learned and know it enough to the point where I can explain and demonstrate it to someone else. And after all, that is the purpose of keeping this blog: Showing to myself and to anyone watching that I know my stuff, through and through. As always, you can return to the introductory post to get an overview of all of the protocols, and read forward from there. Or you can go to the Official Core online page and get an overview (and more) over there. If you’ve been following along (Thank you!), then read on. This week I’m going to cover three more protocols. They are, in my opinion, some of the most practical ones in the Core set of protocols, and are important to keep things moving fluidly in a given team. More decisions being made earlier helps turnover, and turnover means more gets done. These protocols relate to decision making. Read onward!
The McCarthy Show #3: Putting Forth Your Intentions
Welcome back to Wednesday! It’s Week #3, so I’m covering a few more of those McCarthy Protocols! Like before, if you’re at all confused reading this, jump back to the very first post, the introduction, by clicking here. And, as before, just remember that protocols are the actions by which you interface with your team, and the commitments are the literal commitments to which the entire team abides by in order to create effective, efficient communication. This series of weekly posts is an analysis of these protocols and their associated commitments (as well as my experiences with them!), but as always, if you want to read the full “official” list, you can do so by checking out the Official Core Protocols document online. Read on, for another dose of The Core Protocols!
The McCarthy Show #2: Entering and Leaving the Group
It’s Wednesday, so welcome to the second post discussing the McCarthy Protocols! This is going to be quite a bit longer than the standard post, but welcome anyhow. I mentioned in Part 1 that my Game Project class used a variation of Scrum known as Scrum-ban with these protocols to organize our teams. Scrum-ban was the method in which we framed our work, and The Core [aka McCarthy] protocols were how we framed ourselves. It may feel silly in the early stages, but using this method, you may soon find yourself being much, much more productive. So let’s dig into the first sets. Remember: The protocols are actions, and the commitments are the reasons and promises to the team upon which those actions are predicated. If you’re feeling a little lost reading this so far, or want to see the full list (it’s not long!) of the protocols and commitments, click here to read the introduction post. Otherwise, read on…!
And If you can’t join em…
They say if you can’t beat em, join em. And if you can’t join em, just steal the uniform from the guards and pretend like you’ve joined em anyway. In the game industry, it can sometimes feel like a catch-22. You need to have shipped a title or two to apply here, but as a college grad, I haven’t actually shipped any real titles that weren’t school work…Not yet anyway. I’m still inexperienced, so it would seem, and that is just one more thing in the plethora of things I’m going to have to overcome. Another of those things is “get hired in the game industry.” And while it’s a bit difficult to even know where to start with something as nebulous as “Become a kickass game sound designer,” I’ve learned to take a bit of comfort in the unknown. Sort of. It’s still pretty scary. Back in school at Columbia College, we had a phrase when tasked with something and not being sure where to start: “Just go kill Castro.” It was kind of tongue in cheek way of saying “Just do it.” You have your mission. It doesn’t matter how you do it, just get it done. So with that said, I’m proud to announce that I’ll be spending some time with a second blog starting tomorrow, a development diary. It’s time to start getting things done. I’d like to direct your attention to the official blog of Team Lampyridae, a development team I have joined that was recently put together to produce the upcoming iPad/iOS game, Illuminate. It’s going to be sweet! A gesture-based iOS game in which you play as a firefly who…well…you’ll see in the coming weeks. I wont spoil the dev diaries just yet! I feel good right now. I’d be a liar if I said I wasn’t feeling a bit lost now that I’ve graduated from school. School was an anchor for me. Get up. Go to class. Go to work. Do homework. Go to sleep. Repeat. Being an unemployed graduate is difficult, and eating through my savings to support myself for now feels unproductive to say the least. But I have a passion to work on sound design for games, and if that means it takes a minute to crack into the industry, who am I to sit around doing nothing? Let’s get to work! Killing Castro might just be the most foolproof plan I’ve got, short of breaking into Bungie Studios and pretending like I’ve been there the whole time, cutting dialogue as they search for a localization editor for Destiny. –Chris Prunotto
The McCarthy Show #1: Introduction
Alright. It’s time to tell the truth: While I will definitely be focusing on audio and game sound design in this blog, there is a ton more to game sound design than just creating sound effects and music. Teamwork is important. So it’s time to talk a little bit about functional teams, and a great place to start is in the world of agile development. For those unaware, Agile development is a really neat paradigm which relies on creating self-organized, cross-functional teams. It emphasizes adaptability and flexibility in attaining long-term goals and utilizes many different approaches to create great software without being bogged down by heavy game design documents. The main advantage is that the designer of the software (in the case of a game) can “nail it and scale it,” as one of my former professors likes to say. The purpose of this adage is to allow the designer to find the fun aspects of the game and then build it up. As part of the curriculum in his class, we practiced a method of agile development known as Scrum-ban, which is a product of the joining of the Scrum and Kanban methodologies. I will talk more about Scrum, Kanban, and Scrum-ban in another series of posts, but what I want to focus on first is the McCarthy Protocols, which were an awesome experience to have in the classroom. Whereas Scrum tends to focus on the team members and their commitments to the other team members, I find that the McCarthy Protocols are more directed to the securing the individual commitments of each individual team member to the team as an entity in of itself. There’s a lot to discuss about “The Core” – the commitments and protocols utilized to promote great teamwork. In a nutshell, it is made up of several named protocols and commitments – made to the team – which help deliver effective team communication and ultimately, good software. I will cover all of these protocols and their associated commitments over the course of a few posts. For now, the these named protocols are: Pass/Unpass Check In/Check Out Ask For Help Protocol Check Intention Check Decider Protocol Resolution Protocol Personal Alignment Investigate Protocol The core commitments are: To commit to engage when present. To know and disclose To know what I want, what I think, and what I feel. To always seek effective help. To decline to offer, and refuse to accept, incoherent emotional transmissions. To immediately either propose for decisive acceptance or rejection (or explicitly seek the improvement of) when I have, or hear, a better idea than the currently prevailing one. To personally support the best idea, regardless of its source, however much I hope an even better idea may later arise, when I have no superior alternative idea. To seek to perceive more than I seek to be perceived. To use teams, especially when undertaking difficult tasks. To speak always, and only, when I believe it will improve the general results to effort ratio. To […]