Click here to read Renzo Heredia’s post about SIP ’14 on BetaBoston.
Why analytics matter
By Benji Smith, sophomore, Northeastern University
As game developers, we often tell ourselves stories when making games. Not the ones that you see in a script, but ones about the people who will play the game. “Okay, so this part will introduce the player to mazing, and then they use that to defeat the boss, and then they’ll feel awesome.” Every pixel, line of code, or variable changed all has a purpose, and we tell ourselves that the player will interact with it in a particular way and get a specific reaction out of it.
In reality, things aren’t that easy. Our stories about our games are often as fictional as the stories within them. That’s why we playtest. But playtesting isn’t an exact science; it’s often much more qualitative. And that’s good! There are a lot of changes that require qualitative feedback more than raw data. But there are also a lot of risks that come with it. We tend to gloss over feedback more easily. Every piece of info we receive gets contorted into our story. It’s all too easy to assume that the tester is an anomaly, that most players will play the game ‘properly.’
But with quantitative feedback collected from all players, the illusions disappear. It’s no longer, “I didn’t see the button,” but rather “Out of 100 players, 63 didn’t see the button.” Likewise, it’s no longer “This player just doesn’t understand,” instead “63 percent of players just don’t understand.” This summer, we’re using Splyt Analytics to help drive our decision making on Midnight Terrors. It’s hard to argue with the data, because data doesn’t tell a story. Data is the story.
That’s not to say data is infallible. It can be outdated or incomplete, and it can certainly be misinterpreted. But it can never be wrong. That’s because data is just what happened. It doesn’t carry any analysis of its own, it’s just a series of numbers and events.
In some ways, it’s a bit intimidating to use analytics. It’s effectively handing off your game, and letting whatever will happen, happen. You can’t coach people, and you can’t hide from the results. In some ways, it’s like launching a title (just with a quarter the stress). But it’s absolutely necessary, because polishing a game can’t just be an art. It needs to be an art and a science. And for that, we need data.
A farewell to arms: Making Limbs
By James Spavold, senior, Becker College
At this point it is safe to say that many people have played a match three game (cough, cough Candy Crush Saga), or a variant of the genre. Match three was the idea given to us to brainstorm about at the beginning of MassDiGI’s SIP, so we took it as far as we could. Starting with “we should throw ragdoll limbs at a wall; that could be fun”, and from then on that was the idea that we embraced. Eventually taking on a mad scientist feel and a more friendly robot zombie limb approach, after much debate, Limbs moved forward out of the planning phase.
Limbs features a little alien kid named LAK, but he has a few problems. He came to your planet to make some friends, but those friends eventually turned against him and you must protect him. Of course, you do this by throwing limbs at those that turn against LAK. Combat isn’t just simply matching three colors; you need to plan ahead for certain limb combinations that make combo creatures. Limbs tries to break the boring routine of match threes and offers interesting battle mechanics that effect the game board as a whole. Plus, throwing ragdoll limbs at an enemy is extremely satisfying.
- Renzo Heredia – Audio Engineer and Composer – from Berklee College
- Andrew Krischer – Producer and Programmer – from Northeastern University
- Sienna McDowell – 2D Artist – from WPI
- Catherine Shen – Art Director, 2D Artist and UI Designer – from RISD
- James Spavold – Lead Programmer and Build Manager – from Becker College
Working in the team has been a great experience for all of us. Personally, I have worked in a handful of teams in my college career, and they have been on both ends of the spectrum. This has definitely been the most motivated team I have ever been on. At first SIP’s eleven weeks seems like a large amount of time, then you start and get halfway through the process and it feels like no time is left. Even when our team hit that point, we didn’t lose much motivation, and this was the first time that one of my teams has powered through that.
It feels great to be working in this environment. Meeting my team, and also the other teams working alongside us, was a great opportunity. Not only to make games and extend your network, but also to make some great friends with similar interests and feelings towards games. With this great atmosphere, working forty hour weeks isn’t that bad at all. In fact coming into work feels great knowing that by the end we will have a fun and interesting game to show our friends, family, and future employers that we made start to finish.
Leap for joy: Making Many Mini Things
Motion control technologies have fascinated and frustrated players and developers alike. They’re great when they work, but long or difficult gestures increase the chance of hardware losing track of the motion and players feeling cheated. When our team approached the Leap Motion, a USB infrared camera for PC and Mac that tracks hand and finger movement, we knew that whatever game we designed would have to feel natural for the player and work well with the device’s capabilities.
From that emerged the idea for Many Mini Things, a mini-game compilation game. In it, you’re standing at a capsule machine, popping in coins to get toys. To get the toy, however, you have to defeat the mini-game lurking inside each capsule. In order to win, you’ll have to move, spin, point, swipe, and grab through fast-paced games to attain sweet victory – or hilarious failure.
Many Mini Things is the product of a seven-person team from various colleges:
- Pat Roughan, WPI – Producer & Artist
- Yuka Ninohira, Becker College – Art Director & UI/UX Designer
- Aaron Lin, Becker College – Lead Programmer
- Owen West, WPI – Build Manager & Programmer
- Oliver Awat, Becker College – Level Designer & Unity Programmer
- Hannah Klales, Smith College – Level Designer & Unity Programmer
- Renzo Heredia, Berklee College of Music – Composer & Sound Designer
The idea for Many Mini Things started with us MassDiGI SIP interns being greedy, wanting to have a bunch of different ideas as the final game we were going to pitch at the end of our quick 10 minute brainstorming exercise. However, we quickly cut down each idea because of how short the game would be or how tiring it would be, and that continued until we had nothing left. Eventually, we came up with the best idea ever, which was “Let’s just put them all together in one game!”
Over the course of development, Many Mini Things has gone through several drastic changes. And by drastic, we mean it almost looks like a different game each time we look back. We went from a 4-scenario game to a game where a knight is adventuring through a cave, and ultimately ended up with a game where you play with a capsule machine.
In the past 7 weeks, we’ve faced a number of challenges and obstacles from coding to art, but we’ve also gotten closer to our goal, close enough that we can actually sit a person down and watch them enjoy our game. There is nothing more rewarding in making games than a person coming up to you telling you that they enjoyed what you worked on, and want to play it again someday.
We’ve got 4 weeks left in development, and we’re hard at work making every day, every hour count (with occasional donut breaks, of course).
You can follow our progress on our social media pages:
Facebook – https://www.facebook.com/manyminithings
Twitter – https://twitter.com/ManyMiniThings
Things that go bump in the night: Making Midnight Terrors
By Joe Lajoie, senior, Becker College
As children we were always afraid of the noises and shadows we would hear and see at night. On those nights the only way we could fall asleep was to have either our parents check our room or leave a nightlight on. Whether it was the monsters in our closet or the monsters under our bed, we always had the feeling that we were not alone. Midnight Terrors follows a young child named Casey who is tormented by things that go bump in the night. Like all children Casey solves this problem by using imagination, giving life to the toys to keep the monsters away.
In Midnight Terrors you play as a protector of Casey, using the toys to build a maze to keep the monsters from reaching Casey. Whether you use the windup robot that shoots electricity from its arms or the toy soldiers who use their plastic rifles – it’s up to you to keep the monsters from reaching Casey. During the game all types of monsters will challenge you and you must use a combination of toys to keep them away from Casey. Midnight Terrors is an old school tower defense game that focuses on mazing and tower combinations as the main strategy of the game.
The Midnight Terrors team consists of 7 students from 6 different colleges and universities.
- Anthony DelBuono – rising senior at Becker College – Studying interactive entertainment – Lead 3d Artist & Texture Artist
- Aromie Kim – rising junior at Tufts University – Studying cognitive and brain sciences – Art Director & Producer
- Loren Sherman – rising sophomore at Massachusetts Institute of Technology (MIT) – Studying computer science – Build Manager & Technical Artist
- Benji Smith – rising sophomore at Northeastern University – Studying computer science – Lead Programmer & System Scripting
- Ning Xie – rising senior at Mount Holyoke College – Studying computer science – Programmer & Code Review Prep.
- Renzo Heredia – rising senior at Berklee College of Music – Film scoring and electronic production and design – Composer & Sound Designer
- Joe Lajoie – rising senior at Becker College – Studying interactive entertainment – Lead Designer & 3d Animator
The concept for Midnight Terrors came about from an idea I had been working on for a few weeks. I submitted this idea to Monty Sharma before MassDiGI’s Summer Innovation Program (SIP) began, and I was allowed to pitch this to the other interns to see if they would be interested in turning this idea into a reality.
As you can tell by now the idea was a hit with all the other interns. During the first week of SIP, the interns were broken up into groups and we given a chance to brainstorm and expand on the idea of Midnight Terrors. From this session the number one feature that everyone wanted was the aspect of light. This would later become known as the “flashlight nuke” – the ability to turn on a flashlight and clear the entire field of monsters.
During the next few weeks, the Midnight Terrors team began creating a prototype of the game so we could start obtaining feedback on how the gameplay and design was looking. We received a lot of positive feedback; testers thought the concept and story of the game was great! Some people even commented that it was fun to lose just to hear Casey scream.
I’m amazed every time I look at the game how far we have gotten in such a short amount of time and the work ethic of everyone on this team. Some members even work during the weekend just to get it done and into the game before our next build.
Everyday I come to work excited and happy to see how a little concept has slowly turned into a full-fledged and working game before my very eyes. It is exciting to be part of such a talented team. It is so awesome and satisfying to see someone pick up the game, get a giant grin on their face as they play and know that you have been a part of their excitement through the game. When we are not working on the game 40 hours a week, we are showcasing the game at events such as Boston Post Mortem and Boston Game Forum. Both of which I highly recommend attending if you are interested in game development.
We are in the final stages of development for the game, and are having people playtest the game weekly to fine-tune the balancing. We are getting all the feedback we can and changing parts of the game to improve the readability and playability of the game to make it a better user experience. Midnight Terrors has also made an entrance into the social media sphere. We are working on getting our games name out there in order to have an amazing launch. It has been a crazy experience for all of us to make a game in 11 weeks that we can all be proud of. We are excited to see how our hard work has paid off.
Surf’s up! Making Cat Tsunami
By Ryan Canuel, senior, Becker College
So, I’m sure that you’re already thinking to yourself “what the heck is a Cat Tsunami?” Well, a Cat Tsunami isn’t very different from the tsunami waves that you are accustomed to; the only difference really is that a Cat Tsunami is made entirely of thousands and thousands of cats.
Now, you’re probably wondering how a tsunami wave of cats is formed. It all started like any other day, except this was no ordinary day. It was Black Friday and sales could be found everywhere, but there was one sale to rule them all; a catnip sale. Immediately thousands of cats began to claw over one another trying to be the first to make it through the doors of Cat-Mart and purrrrchase some low priced premium gold-label catnip.
You play as Kai the surfing cat. Kai was quick to realize that being a part of a mass horde of cats wouldn’t get him any closer to his dearest desired catnip, so he came up with the one thing he must do to be first to the store. He must surf the waves of cats!
This idea spawned from a number of ideas all created in a brainstorming session at the beginning of MassDiGI’s Summer Innovation Program to make a game about cats, crazy huh? The team of people you can blame for creating this are:
- Lili Sun, MIT – Lead Programmer
- Matt Metzger, UMass Lowell – Build Manager & UI Programmer
- Paige Coblentz, RISD – Art Director
- Aislynn Kilgore, Hampshire College – Lead 3D Artist & Animator
- Renzo Heredia, Berklee College of Music – Composer & Sound Designer
- Ryan Canuel, Becker College – Producer, UI Artist, & Lead Designer (also, the person to blame for writing this)
I’m amazed every time that I look at where we were compared to where we are now. In these few weeks we have progressed from little more than a title and crazy concept to a fully-fledged and functional game, and that is absolutely amazing. It’s wonderfully satisfying to be able to see someone pick up the game you were a part of making and see them smile, laugh, and become slowly more and more frustrated with virtual seagulls.
The amount of work that goes into creating a game is something a person playing can easily overlook, but the amount of time everyone here puts into their games proves that it has to be a labor of love. Working a 40 hour week, implementing things on the side, showcasing the game at events in Boston on the weekends; are all things done to achieve the goal of developing a game we can all be proud to say is something that we made.
We have reached the stage now where we are constantly getting feedback on Cat Tsunami and what can be done to improve it, and while after working on your game for a long time it can be hard to hear what you’re doing wrong it’s also enormously beneficial as a step towards releasing a final well-polished project. We’ve already begun making changes this week in response to feedback that we’ve received, and will continue to do so into the next few weeks remaining. One of the best parts of developing a game is how interesting it is to watch as the game evolves to meet player’s feedback and become something they enjoy playing as much as we enjoy making it.
You can follow Cat Tsunami on Twitter: https://twitter.com/CatTsunamiGame
And on Facebook: https://www.facebook.com/CatTsunami
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.
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.
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.
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.
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.