Going pro: The evolution of a game dev student
By Andrew Krischer, sophomore, Northeastern University
College has the strange effect of making me feel like a really old kid. Going to classes and working with professors is like playing doctor was when I was younger. I go through the motions of acting like an independent adult: managing my sleep schedule (sort of), buying groceries (sometimes), and interacting with professors in a professional setting. Despite all these changes, I always caught my roommates and I acting like children: Sticking gummy bears all over our walls, building and then destroying our snowmen, ordering large pizzas at ungodly hours, and not going to bed until the sun rises.
This summer, I find myself in a similar position at MassDiGI’s SIP. This program is my first introduction to a professional, albeit creative work environment. My previous work experiences were all in the front end of the food service industry. Every day I’d meet lots of new customers and get to chat with them while working. And the thing is, as Tyler Durden puts it, many of those interactions were single-serving. Never before have I established professional working relationships with others in the sense I have since interning at SIP.
I’m working primarily with four other extremely talented team members to transform our concept, Limbs, in to a full-blown game. These are folks I see, chat and work with five days a week nine hours a day. All the while, I can’t but help feel as though we’re impostors just going through the motions of professionalism. We set our deadlines, hold our meetings, and charge our tasks. I’ve got to be honest, it’s strange telling a teammate who’s older than you to complete menial tasks. That being said, we do everything playfully and I wouldn’t have it any other way.
I remember when one of our team members was feeling especially frustrated with a program we were all trying to coerce into working. At the time, we had no art or code 100% finalized, so we had an entire blank column on our Kanban whiteboard. She sauntered over, defeated, draws a skull and crossbones and writes in a speech bubble, “I’m DEAD.” Over the next few days, that doodle became a focal point of creativity. One of our artists drew an incredible doodle of a giant squid screaming “SO MANY LIMBS!”, as our game heavily focuses on the theme of body parts. The next day a dragon was born devouring the giant squid.
And the best part is that an entirely different team working on an entirely separate game did a similar thing on their board – turning it entirely into cat puns, rife with accompanying images.
We’re now in our fifth week at this program and I’ve made a really cool realization. These motions of professionalism and development aren’t just theatrical – it’s how our workspace works.
We all love fun, video games, and, begrudgingly, cat puns.
My prior knowledge of professionalism has come from popular culture and in many ways my family. It turns out I can develop my own style of professionalism that’s creative and productive at the same time.
Now, I can’t wait to see what kind of compelling video games we create after working in such a creative and fun environment.
» Read More
Teamwork: A sound guy’s perspective
By Renzo Heredia, senior, Berklee College of Music
Before college began for me, I always saw myself becoming a composer who would never have to talk to anyone. If I was making a game, I imagined myself alone, just sitting in my safe cave, creating some music tracks and sound effects, sending them off to the director, and then waiting for the product to be released without worrying about having to meet people and talk about anything while working on my next project. I’d totally get away with that, right? Not being social, just making music for other people. That’s a way to get around, right?
If I still believed in living in a shell, this program proves how I would never survive reality. And you know what? Because of this program, I am already thankful that I will always try to break away from that mindset.
For MassDiGI’s 2014 Summer Innovation Program, I am the music composer and sound designer/editor of the 4 games being created. Usually, I am just known as “The Sound Guy.”
I have to confess, it can be quite odd being in charge of an element for 4 games at the same time. For instance, each morning, the 4 teams have stand-up meetings that allow the team members to discuss their daily tasks and objectives. Obviously, I can’t clone myself and attend all 4 stand-up meetings that happen at the same time. That and I need to keep track of audio assets for everyone. This includes tracks of music that loop, sound effects that will be added to the UI and the characters in the levels, and, on occasion, needed dialogue for narrators or character lines. And to top it off, we’re required to talk to each other. This seems rather intimidating.
I can’t just stop talking to the teams as I’ve already gotten to know everyone after spending time with them while also living at Merrill Hall, a Becker College dorm.
But, by being with them at the dorm and during work hours from Monday to Friday, 9:30am to 5:30pm, I realized something amazing. These designers are incredible people to spend time with. I already consider them friends, and am still blown away by their modest attitude in their incredible work and their conscious efforts in making sure that everyone in a team is satisfied with the current progress of a game. There is no away that I could let these people down.
Sure, I don’t know a thing about coding mechanics or drawing/rendering art, let alone draw a shape or figure of any recognizable kind on paper, but I could listen to their amazing ideas and maybe even suggest an idea or two when making the ideas for the games. Maybe in a tower defense game about toys coming alive, we can have teddy bears. Or dust bunnies. Or maybe even milkshakes that come alive. That’d be so cool.
And yeah, sure, some of these ideas don’t make it, but there’s such a joy I’ve come to love in having so many ideas put on a piece of paper and working as a team to look at what’s best for a game concept.
Even though SIP orientation week was tough in that we had to go through quick exercises of creating game concepts in less than 10 minutes by talking with each other in groups, I realized that no matter how tough a task may be, there is never the feeling of being left behind. I’m just a weird, artsy sound dude, and yet I can contribute ideas to these game concepts. That was a powerful feeling and made me realize that communicating with these incredible developers I can call colleagues may not be as daunting as I thought.
Our Alpha builds are ready to go and be play-tested. With each week come more ideas and objectives put as tasks on our Kanban boards. The creativity of these teams has helped me immensely in pushing myself to give music and sound to these projects. There’s a lot done already, but so, so much more that needs to be made. And, now I think I can speak for all of us in saying that we now see the beauty in the amount of work that lies ahead. This summer will be hard work that we can share with each other, and no matter how the games come out, they will be products of combined perspiration and confidence.
I’m going to miss everyone when this is all over. For now, it is time to get to work.
» Read More
Game programming: A step outside the Ivory Tower
By Benji Smith, sophomore, Northeastern University
For the past three weeks at MassDiGI’s Summer Innovation Program, I’ve had to do a lot of learning when it comes to programming. But I’ve also had to do a lot of unlearning, specifically some of the things I learned during my first year at college.
During that year, I learned about coding in a very academic fashion: functional programming, the correlations between computer science and mathematics, and other aspects of pure programming theory. I’ve had to unlearn them, but that’s not to say that these things didn’t have merit. In fact, many of the lessons I’ve learned in the classroom carry over to the real world perfectly. But there are some assumptions when doing academic programming, assumptions that you can’t make in other contexts. And it’s these expectations that I’ve had to reconcile with what really happens.
Before I continue, I’d like to say that I have nothing against academic programming, or those who do it. I think pure coding is a great starting point, and with it comes a certain beauty that comes from seeing the connections between subjects, connections that get blocked and dragged down by real world constraints. And as said before, there is plenty to be learned from a purer form of coding, it just can’t cover everything that needs to be learned in an actual coding team.
In my first year at college, we learned functional programming, first in Racket/Scheme and then in Java (Java isn’t functional, but we used it in a functional style). For those unaware, that is programming by merely defining functions. There is no concept of state or global variables, and the program just calls functions that call more functions, etc. Academics like this kind of programming because it makes programs easier to reason about. And it does have its uses, on a philosophical level. Code written in a functional style automatically becomes modularized and easy to test. Each part can be thought of as independent of the others, since there’s no global state to keep track of.
The problem though, is that functional programming is really bad for games. First off, the languages tend to be obscure: Scheme, OCaml, and Haskell don’t have as many fluent coders as C/C++, Java, Python, and C#. Secondly, as said before, pure functional programs don’t have any idea of state. Unfortunately, as my classmate Matt Kolosick put it, “Games are state-ful.” Whether it is graphics, physics, or AI, holding variables in memory is simpler, easier, and faster. Let’s say you wanted to repaint your room to be green. In standard imperative programming, you’d simply change the wall’s color to be green. In functional programming, you’d destroy your house, duplicate it, and then as you’re rebuilding your room, you paint it green instead of its original color.
When it comes to how to deal with incorrect use of one’s code, the academic and real philosophies split again. In all of my classes, we learned to make assumptions about what the user passed as arguments to our functions. If a function couldn’t handle negative numbers, then we were told to just assume we wouldn’t get any. It’s simpler to reason about, it’s easier to teach, and it (technically) runs faster. But it would never fly in the real world.
In the real world, your code will be tortured. It will be called on all sorts of arbitrary inputs, including on nothing at all (if the language supports null). This could be an accident: some other function didn’t properly handle things and returned incorrect values, or it could be a mistake: some programmer wrote 3.0 instead of 3.0f. In any case, they will happen, and it’s your responsibility to handle as many errors as you can, so they don’t propagate through to someone else’s function. Simply documenting a function’s contract isn’t enough, it needs to be in the code itself, and it needs to be easy to trace back to what happened.
Because of the different purposes for the final code, programming for academia allows for certain assumptions. Code doesn’t have to quite work, it doesn’t need to be extendable, and it doesn’t need to meet industry standards. There isn’t anything wrong with this, it’s just necessary to re-evaluate the assumptions you make when coding for a particular audience. Especially when that audience is subject to change.
» Read More
Kanban: From zero to demo in three days
By Walt Yarbrough, producer, MassDiGI
For the past two years during the MassDiGI Summer Innovation Program, we used a heavily modified Agile as our production method of choice (which had strengths and weaknesses) as noted in this blog post last year. At the end of the 2013 program we went through our post mortem process. Every option was examined and discussed with our inexperienced student intern teams who gave us the following feedback:
Successes
- The interns learned to track their own work and report it on our burndown charts
- The managers had a good tool – the burndown charts – to track and monitor progress
- The interns learned the value of the standup and good team communication
Failures
- Failure to use any of the predictive and projection powers of Agile to help guide our projects
- Scrummaster and team are conflicting roles by design in Agile, and for many interns in their first real job – they were unable to easily handle this conflict and these roles
Looking back at what we had achieved with two summers of Agile – we had stripped it down so much that we were very close to the results of the Kanban process. Kanban requires much less in terms of overhead, at the cost of losing predictive and budgeting powers – features we were not able to implement in the process anyway.
Kanban is a production process focused on providing a ‘snapshot’ of the team’s work that is up to date and accurate. Kanban literally means signboard in Japanese, and the production process uses a board with a note for show each individual task, each worker, and columns to detail workflow.
Given our results in the past, we made the decision to switch to Kanban for this summer’s program and set about teaching Kanban to the interns at the beginning of the summer.
For the the 2014 Summer Innovation Program, we gave the interns the following guidelines to set-up, using the whiteboards in the collaborative studio workspace provided by Becker College.
- Each team member has one sticky note in one color to indicate themselves. They list their name and contact information (if they
- happen to be out)
- Each task has a sticky note clearly defining an individual component of the game. We color coded the tasks as follows: Yellow – Audio, Green – Art, Blue – Code
- We laid out the whiteboard with markers and a To-Do, Work in Progress, Feature Complete and ‘Final in Perforce’ columns
- These columns are to represent the quick and dirty workflow required for Demo/Prototype work
The Kanban process is flexible and we will adjust it for each different phase. To help the interns get used to working with and tracking their own tasks, each student was tasked with taking the sticky representing themselves, attaching to a task, and moving each task across the board as work was completed. At the end of the day, they take themselves off the board and place themselves in the ‘Out’ box, then when they come in in the morning, they go back on the board.
As each student has no experience with Perforce – we added the ‘Final in Perforce’ requirement to their Kanban boards to force them to learn Perforce early in the summer. At later stages in the summer, proper file control will be critical. One of Kanban’s strengths is that you can use it to identify workflow problems – a strength we used to our advantage by forcing ‘Perforce’ as a workflow step. No task can be considered complete until it is Perforce – so the students and managers saw this a problem immediately, and that workflow problem remained until the students solved it.
Another strength of Kanban is the flexibility of the production process. The interns rapidly made two modifications to our boards 1) They chose to use the unused pink sticky notes to represent Design and Documentation tasks and 2) Our most OCD student brought in colored tape and re-laid out the board to be geometrically precise – a process that we duplicated on each board.
The rapid ramp-up process for Kanban and low overhead let the students jump right into creating demos and proof of concepts of their projects.
After three days of work, two teams had already completed their demos and moved on to creating their Vertical Slice for the Alpha phase of the project. Now, after two weeks, most are nearing completion on their Alpha work, and are looking ahead towards the Production phase.
So far, we are pleased with the use of Kanban and very proud of the interns’ progress to date. As we move through this summer, we will adjust our production methods to match, and we’ll post mortem again for 2015.
» Read More
Jumping right in: Actually making games
By Pat Roughan, senior, WPI
Being a student of game design and being a game designer are two radically different things. In the classroom, time is spent explaining the terms and ways of the industry, explaining the successes and analyzing the failures. Sometimes, in one class of a term, students get to try their hand at making an actual game, but it’s usually only brought into the prototype stage when the class ends. Work on it is done at random hours, whenever the students can find time between meetings and other class assignments. The rough husk that’s made by then is either brushed up a bit for a portfolio piece or forgotten, and the student group breaks up and moves on.
Actually making a game, a full game with intent to sell, is a whole different challenge. Do you have the required budget? Is the scope reasonable compared to your resources and allotted time to work? Is there a market for the game? If so, who is it? How much will they pay? These questions are either briefly touched upon or ignored in the classroom setting; after all, no one expects a profitable game to come out of such an environment. They are very real questions that game designers have to answer (that is, if they want to eat). On top of that, in a work environment of making games, there’s no other work interfering with the game creation process. Your job is to make the game and get it out to players, not write a ten-page essay on Paradise Lost and do a biology lab while maybe getting some coding done on the side.
Jumping right in
The first two weeks of MassDiGI’s 2014 Summer Innovation Program were the first time a group of students, including me, from colleges across the northeast got a taste of what being a working game designer is really like.
The goal of the program is to create then launch a product, and the student interns are given all the tools to succeed in a space where it’s okay to fail. We are tasked with making a game that will get an audience and, hopefully, a profit, and work eight hour weekdays with no other obligations. The space operates as a small studio, where the we have to openly keep track of tasks, create builds to show higher-ups, and work towards having a finished product by the end of the eleven-week program.
To help us learn and create better games, industry professionals come in once a week to talk about a section of the game-creating pipeline and offer advice to the us about their own games.
The program is currently beginning it’s third week, the first week being orientation. During that orientation, the staff explained the development pipeline to us, and showed us how to work out well-scoped ideas with a discernible market. We came up with a number of different ideas for games to make for the program, and voted on four games from that pool to work on. The first week of work had us jump right into creating, with a demo build deadline at the end of the week. During that week, four teams of students who had only meet the previous week and had only a brief design to start with created four working demo builds and full documents outlining the plans for the finished games and our target markets.
As one of the interns in the program, the experience has been great. Making games in the classroom is one thing, but making them for players, real paying people, is different, exciting, and nerve-wracking, all at once. Speaking with people in the industry about your game and having them give you great advice back, putting your demo in front of a player and watching them completely break it, making a quick draft of the art and having people respond exactly as you had intended, and everything else I’ve been through these past weeks has been this exhilarating roller coaster that makes me certain of my love for creating games in a way that learning definitions and working in hypotheticals never could.
And the best part is, it’s only just begun.
» Read More
Please join us for the 2014 MassDiGI Summer Innovation Program Open House!
For the past 11 weeks, 22 students from 11 colleges and universities have worked on 4 amazing games. You are invited to come on down and play them!
Games include:
To register, please click here.
When: August 7, 2014 – 1:00pm to 3:30pm
Where: Becker College, Weller Academic Center, 61 Sever St., Worcester, MA 01609
» Read More
Drop by the Boston Games Forum’s June Playtest Night and visit the MassDiGI table featuring demos from SIP. Registration information for the event is available here.
When: June 28, 2014, 2:00pm to 6:00pm
Where: Microsoft, 1 Cambridge Center, Cambridge, MA
» Read More
Drop by WPI’s Touch Tomorrow festival and visit the MassDiGI table featuring early demos from SIP. More information on Touch Tomorrow is available here.
When: June 14, 2014, 10:00am to 4:00pm
Where: WPI, 100 Institute Rd., Worcester, MA 01609
» Read More
Drop by Boston TechJam and visit the MassTech Collaborative booth featuring early demos from MassDiGI SIP teams. More information on Boston TechJam is available here.
When: June 12, 2014, 4:00pm to 9:00pm
Where: City Hall Plaza, Boston, MA
» Read More
Join MassDiGI at the annual Merrimack Valley Sandbox Summit. This year’s theme is “Entrepreneurship for All.” Details on the summit are here.
When: June 9, 2014
Where: UMass Lowell Inn & Conference Center, 50 Warren St, Lowell, MA 01852
» Read More
I remember when one of our team members was feeling especially frustrated with a program we were all trying to coerce into working. At the time, we had no art or code 100% finalized, so we had an entire blank column on our Kanban whiteboard. She sauntered over, defeated, draws a skull and crossbones and writes in a speech bubble, “I’m DEAD.” Over the next few days, that doodle became a focal point of creativity. One of our artists drew an incredible doodle of a giant squid screaming “SO MANY LIMBS!”, as our game heavily focuses on the theme of body parts. The next day a dragon was born devouring the giant squid.
