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:
- 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
- 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
The importance of community in games
By Malinda Statder, sophomore, Becker College
A little over a week ago, Ichiro Lambe from Dejobaan Games stood in front of a crowd of Worcester-area college students in the lecture hall at Becker College. He spoke animatedly, not about the secrets of creating a great game or the magic to becoming a big name indie, but about something few think about when the subject of game making comes up: community and collaboration.
Students already know the value of collaboration on a small scale; we have all taken part in game jams or, failing that, have worked with one another to complete a project. But, the idea of an entire community based around the creation of games is still a bit of a foreign, out-side-looking-in concept.
Ichiro discussed the growth of gaming communities in different places around the world – from Boston to Vancouver; beginning with, in some cities, a few interested people in a pub and then growing, as he described it, Katamari Damacy-style, into huge, vibrant communities. A community that collaborates provides anything a budding indie needs to make a name for him or herself, from industry connections to honest constructive criticism from programmers to artists and everyone in between.
He also stressed the importance of networking, talking about how simply knowing one person might mean the difference between success and failure in the industry, because it’s not always about what you know, but who you know as well. Ichiro ended his lecture by insisting that all students regularly attend the Boston game development community meet-ups to introduce ourselves to future peers and begin making the acquaintances which may one day be the catalysts for our success.
» Read More
Summer game camps for kids
By Tim Loew, executive director, MassDiGI
Each spring I receive questions from middle and high school parents about information on summer computer camps that offer game making. Given the interest, I thought a quick post on the subject might be helpful.
Locally, there are actually quite a few options for kids and I’ve listed several offerings below for parents to consider. If you know of any others, please let me know and I’ll add them. That said, poking around the internet, checking the summer programs scheduled at your local college or university and leafing through community papers might also turn you on to any number of others as well. Let the games begin!
» Read More
For all to play: Making a game, making a difference
By Elias Aoude, producer, For All To Play
The idea for our game, Grail to the Thief, came about when we were researching (the For All To Play team are all alumni or current students at WPI) game design for the blind. We conducted interviews at Perkins School for the Blind and performed extensive research which led us to discover that few games are available to the blind and visually impaired, and many of the games that are available are severely dated, lack the quality and polish of games for the sighted, and rely on synthesized computer voices such as screen readers in order to play. Grail to the Thief will address these problems, and the game will be just as accessible and exciting an experience for the blind and visually impaired as it will be for the sighted.
So, with that in mind and a build in-hand, we started up an indie studio in Worcester and are at the halfway point of a crowdfunding campaign for Grail to the Thief on Kickstarter.
You can play a browser-based prototype of the game. It requires Google Chrome or Opera and can be found here: foralltoplay.com/prototype. If you have some time, please check it out.
The game, when launched, will be an interactive audio adventure for Windows, Mac, and Linux (a standalone executable will not require a web browser) that can be played using only sound, without the need for visuals. Grail to the Thief has been designed with the needs of the blind and visually impaired in mind but can be enjoyed by everyone. The game will deliver an exciting, immersive experience in which the player will always be fully aware of what is happening through the use of voice-overs, sound effects, ambient sound and music.
Game players will make choices through a conversation tree from which they can select commands, eliminating the confusion and frustration that comes with traditional text adventure games which require players to type in commands to progress. It is a nostalgic throwback to childhood favorites such as Zork, The Hitchhiker’s Guide to the Galaxy, Day of the Tentacle, and Grim Fandango, and draws inspiration from old BBC radio dramas and the movie Time Bandits.
If our Kickstarter campaign is successfully funded, Grail to the Thief will be available as a DRM-free download for Windows, Mac, and Linux in August 2014.
» Read More
SIP14 students selected
By Tim Loew, executive director, MassDiGI
Each year applications to our annual Summer Innovation Program (SIP) have grown in terms of quality, quantity and diversity. This year we received applications from 157 undergraduate and graduate students representing 31 colleges and universities from across the country – making it our most competitive year ever.
Needless to say, selecting only 22 was a challenge. After much discussion, the committee chose a great group. This year’s SIP teams will be made up of students from 11 institutions including Becker College, Berklee College of Music, Hampshire College, MIT, Mt. Holyoke College, Northeastern University, Rhode Island School of Design, Smith College, Tufts University, UMass Lowell and WPI.
SIP begins on May 20 and concludes on August 8. Over those 11 weeks or so, with guidance from professional staff and industry mentors, SIP teams will be responsible for all the work required to successfully launch their games in the market. There is no internship program like it in the country.
As in past years, SIP students will receive housing courtesy of Becker College as well as a modest stipend. More importantly they will all receive the greatest game development experience of their lives. Sure, it may be a lot of work – but it’s also a ton of fun. We can’t wait to get started.
Revised on 5/3/14.
» Read More
The real video game high school
By Michael Morley and Duncan Elliott, students, Millbury Memorial Jr./Sr. High School
One word to describe the 2014 MassDiGI Game Challenge would be “phenomenal.” That “phenomenal” feeling was experienced by about 20 Millbury Memorial Jr./Sr. High School students during their participation in this year’s Game Challenge competition. With limited game programming or design experience, all the Millbury students, including us, jumped into the Game Challenge with both feet. In addition to fielding six different teams for the competition, the Wasteland Trials team from Millbury took home the first place trophy in the high school category.
The impetus for the participation of Millbury students in the Game Challenge was created by a school visit from MassDiGI’s Monty Sharma. After learning a bit about game designing and careers in the game design industry, the Millbury students enthusiastically took on the Game Challenge. Millbury teacher Mark Sutphen allocated classrooms and set-up meetings that allowed students to gather and formulate ideas and join teams. As an after-school activity, students were left to form groups on their own, usually dividing teams up into specific tasks. One student played the role of “Creative Director”, and another as the “Lead Sound Manager”. Other students filled vital roles such as, level design, character artists, code-programmers and business manager. These high school teams met weekly, every Wednesday, in Mr. Sutphen’s classroom. Additional time spent on the project had to be found outside of the school setting where meetings were run through social media, e-mail and social gatherings.
On the first day of the two-day competition, the Millbury students boarded a school bus headed down to the Microsoft New England Research and Development building, located near the campus of MIT in Cambridge. Though initially somewhat intimidated by the surroundings, the students quickly adapted and fully participated in a fantastic fun-filled day. From the vendors, food and eventually the competition, the students thoroughly seemed to enjoy what the Game Challenge had to offer.
On day one, each group attended lectures from Monty Sharma, Jason Della Rocca and industry professionals who talked about how to improve game quality, how to market games more effectively, and how to make contacts in the gaming industry. Feedback from professionals and peers was a key to the students’ learning experience. This feedback would then be used by the students to make final adjustments before the day two of the Game Challenge.
During downtime at the competition, students were able to test out some awesome games and game technology from several indie game companies who were displaying their latest design prototypes and ideas. A friendly atmosphere allowed the students to feel comfortable in hobnobbing with college students and professional designers. Students felt right at home exploring the playground known as floor one of the Microsoft N.E.R.D.
Win or lose, every student left the competition with a smile on their face and a full belly. It was obvious that MassDiGI spared no expense to provide a generous banquet of pizza, club sandwiches, salads and desserts. Soda and chips were laid out by the table, and a hot chocolate/coffee machine was left out for almost every Millbury student to indulge upon.
To top it all off, each and every student had the opportunity to learn something new. Not a barrage of dates from history but instead on a topic that draws the attention of teenagers with the same intensity as iron to a magnet: video game design. More importantly, the Game Challenge left students with a lesson on the marketplace – how to create a successful game in terms of generating revenue – making a profit! While it can be seen as beautiful for designers to view their game as a work of art, it is no doubt also important that their game possesses relatable, feasible business concepts that allow for the prospect that the game will actually make it in the market.
As students of Millbury Jr./Sr. High school and Game Challenge competitors ourselves, we can say that Millbury High is already looking forward to competing in the next year’s Game Challenge.
» Read More