Building skills: Meeting challenges and overcoming obstacles – 7/31/13

Building skills: Meeting challenges and overcoming obstacles

By Connie Hildreth, fourth year, Hampshire College

The goal of SIP, MassDiGI’s Summer Innovation Program, is to make a game, from start to finish, over the course of a summer. From the beginning this made me nervous. I’ve been conditioned to make projects small and downsizable into even smaller parts, and everything about the program sounded worryingly large in scale. Sitting comfortably at the other end of the summer, I’ve seen that things turned out fine, but there were a couple extra challenges SIP had that I hadn’t even thought to worry about until they had passed.

Connie Hildreth

SIP operates by partnering local professionals that have ideas for games with undergraduate and graduate students studying game development. In the first week, they pitched us their ideas for games, and we divided up into teams among the projects. The game I’m working on goes by the code name “Robot Orphan Workforce,” which our team is working on under the mentorship of Ziba Scott from Popcannibal. It’s a construction simulator where orphaned robots build houses and famous monuments out of blocks. When we were shown Ziba’s prototype and given his pitch, though, that wasn’t initially clear to us.

Some other SIP projects had a single, clear path to becoming a finished game, but our game was more wide open. The prototype we saw had little shapes building larger buildings out of blocks, with the rest of the features and characterization left for us to decide. Because of this, all of us came to the table deeply excited about very different games that could not all be made, and picking a direction was a huge challenge.

What we could plausibly do with our game depended a lot on how much we expected to be able to get done with our group over the summer. The trick was we didn’t know each other. We’re all students, and intimately aware of what happens to group projects with even just one or two unmotivated, unskilled or uncooperative members. We didn’t know each other’s strengths or whether we’d be able to count on our whole team, so it was hard to say how much work we could manage.

The sneakiest problem, though, was that we had no idea what a summer was. As students, our whole lives have been punctuated by summer breaks, so you might expect that we’d know how long a summer was. Really, though, we had no clear picture of how much five people working full time could do over a summer cycle. Projects have, for us, always been done in semesters or shorter bursts of crunch time, competing with other academic, extracurricular and social commitments. We had no frame of reference for planning out a dedicated summer project difficult.

Still, we had to make decisions, and the first decision our team really made is symbolic of how we’ve dealt with these issues. We decided to make the builders robots that we designed modularly, with randomly assigned hands, feet, hats and clothes. It let us build as many art assets as we wanted to decorate them, while keeping it a non-tragedy when something we had made for them had to be cut.

Our game has gone through a lot of cuts gameplay-wise as well. We wanted players to be able to design their own buildings, but had to face the reality that we couldn’t make that a good experience and have the rest of our game still be fun in the time we had. Physics were going to play a major role at first. Orphans were going to be sorted into teams, which would be used to upgrade their stats, some were going to roll around on wheels, while others floated on rocket boosters. These things won’t make it into the game, and some were very hard to give up on, but by cutting them, we’ve made room for things like shooting rockets of oil to keep the orphans from getting rusty and hugging your orphans with rainbows.

More importantly than that, maybe, is that by cutting those features, we made our game completable. We now have an almost-finished game to match the almost-finished summer. We know what our game is now, and we know what each of us does well. We know now that our team was dedicated and skilled enough to pull off quite a lot. And now we know how long a summer is, though I wish it was a little longer so I could spend more time with my team and our game.

» Read More

Eyes wide open: Learning by doing – 7/19/13

Eyes wide open: Learning by doing

Blog by Rachel Roberie, second year, Northeastern University

I’ve been told time and time again that majoring in game design is worthless next to hands-on experience for getting into the industry. Before this summer, I felt unable to do anything hands-on without taking more classes; yet MassDiGI’s Summer Innovation Program (SIP) presented an opportunity for real work just after my freshman year, and the chance to create a game with the intention of selling it. Nothing has been more eye-opening for me.

Like many people who dream of making games, I started by playing them for years without any understanding of how they were actually made. SIP brought us to the process by turning 21 college students into a miniature game development company. We work in a habitat not unlike that of most indie companies: a brightly-lit, white-walled computer lab with uncomfortable swivel chairs, a scanner, and a printer. Each computer has the full Adobe Creative Suite and Autodesk Suite as well as Unity, GameMaker Pro, and various programming environments. Each team has its own row of computers and its own slice of whiteboard.

Rachel Roberie

Video games are the most multi of all multimedia, and as a result require extensive collaboration. Unlike movies, there is no one director – even for a very small production, there must be an art director, a lead programmer, a manager, and a designer that holds it all together, and every person has to be on the same page. In our five-member teams some people take on multiple roles. While most people call themselves either “artist” or “programmer,” everybody makes gameplay decisions, provides input on the art, and gives quality assurance (QA) feedback for their own team as well as the other three.

Since we are using a modified Agile production method, we post updated burndown charts on the board every morning and review our completed tasks in a scrum meeting every evening. We push new builds at least once a week and send them out to everybody for testing. The advantage of Unity is that it transfers easily between iOS and computer builds, and three of the teams, including mine, optimize for both platforms.

I haven’t gotten the chance to flex my writing muscles every much, since games with more elaborate stories and casts of characters are much beyond the scope of a six week development period (the last six are for post-development, so no new content can be added). I do feel my writing is better than my 2D art, and I enjoy writing more; yet being able to do both proficiently only means I can offer more to a workplace.

It took about a week not only to get settled in but to realize that this is an amazing job and to cement the fact that I’d like to do similar things for the rest of my life. I am getting paid to make art every day – something that I normally pay others to do in a classroom – and my work is going to be viewed and enjoyed by (theoretically) hundreds of people across the country.

My group is referred to affectionately as Team Wobbles, and we are sometimes also called the Nimbii, for Play Nimbus, the independent game dev group (also found on Facebook) that our fearless leader Nick Mudry formed in 2012. He’s our manager/scrum master and is in charge of social media. We also have Adam Roy, our star programmer, Mike Flood, our level designer, and Laura Gagnon, our lead artist and UI designer, all of whom were part of the team when Wobbles won MassDiGI’s Game Challenge in March 2013. I joined up in May 2013 for SIP, doing 2D art. I’ve worked on tilesets, environments and backgrounds, decorative assets, and some concept art.

The game is a puzzle platformer. You play a god-like figure responsible for a race of creatures called Wobbles that have little bodies, big noses, and enormous dreams. You guide them safely across stages and into the future using strategically placed gadgets, and their tech advances as time goes on: Cavemen start with fire that makes them jump, then in the Roman era, they discover an item that helps them land more safely, and on and on.

More information will be revealed in coming weeks. The first official release of Wobbles is in the beginning of August, when the program ends, though we can stick around even after SIP and make more content if the game takes off!

A version of this blog first appeared at http://rroberie.wordpress.com/.

» Read More

Agile: From zero to launch in 80 days – 7/16/13

Agile: From zero to launch in 80 days

Blog by Walt Yarbrough, producer, MassDiGI

The MassDiGI Summer Innovation Program has several overarching goals which influence our choice of Production methods.

Our primary goal is to produce fun, profitable, technically solid games.

Secondly, we want the SIP students to learn applicable real-world skills in a production environment.

Finally, we want the students to experience a complete product life cycle, from conception through release, to maintenance and updating.

With an 11 week program, our first production decision to reach these goals is easy. Ideally, roughly 50% of production time is devoted to bug fixing, tuning, and, increasingly, reaction to analytics. Given the initial week of orientation and team forming, plus the short Fourth of July week, the first six weeks are slated for production, and the remaining five weeks for ‘Beta’.

With the goal of teaching applicable skills, the choice of a Production method is also easy. Nearly all of our students had zero exposure to any production method, so we decided to use Agile (Scrum). Much like the decisions to use Perforce, Unity and shared documentation on Google Drive, we are not only choosing the industry standards for projects of this size, but also the best available technology and methods.

However, with four small teams co-located in two rooms full of production machines, the need for documentation and meetings to promote intra-team communication and coordination is minimal. Additionally, our projects do not have an Agile Project Owner available. And our Scrum Masters also must spend the majority of their time being individual contributors.

Not only would we need to teach each contributor Agile, we would also need to train Scrum Masters and Project Owners if we were to implement Agile “by the book”. Going by the book would also add to the documentation and meeting load on the teams. My post mortem of the 2012 Summer Innovation Program was that our teams got overwhelmed trying to fill all of the Agile roles and requisite documentation and meetings, an overhead burden that limited the benefits of Agile. This burden often fell completely on the Scrum Masters of the 2012 teams.

Walt Yarbrough

So, I chose to modify our Agile in the following ways:

We eliminated the Project Owner – replacing this role with weekly team goals on the whiteboard. Constant communication from management in the same room and daily builds are the tools used to keep the Projects on track.

We eliminated the Project Backlog and Sprint Backlog – replacing them with a standard set of preproduction documents for each team, including an Elevator Pitch, Sell Sheet, Design Document and Art Style guide.

We eliminated the Sprint Planning Meetings, Sprint Review and Sprint Retrospective – these proved to be too much of a burden on an inexperienced Scrum Master who is also charged with individual tasks.

With only six ‘production’ weeks, we set our Sprint length at five days – Monday to Friday. That gave us many chances to course correct each project, if needed, something that would have been extremely limited with two week or three week sprint durations. It also gave our students more practice and experience at estimating their own tasks, as for many of them this is their first games job – the first time they have been paid to work 40 hours a week, and the first time results are expected and measured.

While the elimination of the meetings helped reduce the burden on our inexperienced Scrum Masters, I didn’t stop there. We charged every contributor with delivering 32 hours of planned work to their team Scrum Master no later than noon on each Monday. I then took it upon myself to critique and request revisions on these task descriptions, to ensure that they were crisply defined. While the tasks would not be ‘by the book’ User Stories estimated in Planning Poker sessions, my review would ensure that they would match the spirit of Agile and be tasks that could be measured, delivered and agreed as ‘done’ by the team. In other words, I’ve taught everyone how to describe a user story correctly in their burndown without teaching them user stories.

We consciously did not specify how each team was to agree upon their 32 hours of work for each member – my experience and the post mortem of the 2012 SIP program was that small teams on small projects like this organically know their next steps to meet their overarching goals. A specific method to discuss and debate would just be an unnecessary burden.

Our Scrum Masters print one initial burn down Monday at noon – tracked in a Google doc spreadsheet, then hold standup meetings every day at the end of the day and print and post an update. The MassDiGI managers or other stakeholders can review the physical copies with a walk around the room or check the online repository for status and feedback.

With everything we eliminated from Agile – how can I even call this Agile? Remember, one of the key points was to look at this from the student’s perspective. As individual contributors, they are estimating their own tasks, standing up daily to report progress and seeing their progress tracked prominently in their workspace. All of these are key components of Agile from an individual contributor standpoint. The fact that this modified Agile allows MassDiGI management to track remotely and on-site with ease is just a bonus.

To date, the production changes we made for the 2013 program have worked out well – the students, at this stage, are writing clearly defined tasks, and productivity on all five teams is high. I can confidently state that the overhead burden required for Scrum has been more than offset by the benefits. The management has a clear communication tool to track progress, and the students have gotten great exposure to the industry standard.

» Read More

Easy street: Using standard industry tools – 7/12/13

Easy street: Using standard industry tools

Blog by Nicky Mudry, sophomore, Becker College and Play Nimbus

My game development history goes back many years from working on games during my free time in high school to helping out on various teams. Currently, I’m working with my own team, Play Nimbus, at the MassDiGI Summer Innovation Program (SIP).

When I started in SIP this past May, I knew I’d learn and expand upon my previous skills a lot. SIP brings 21 undergraduate and graduate students from across the Northeast together to work on several different game projects alongside industry mentors and advisors. Our team’s project is Wobbles. Wobbles, which won the student entertainment category at the MassDiGI Game Challenge back in March, is a game where you guide creatures across a treacherous landscape by placing various gadgets.

Wobbles screenshot

Since day one at SIP, we were aware that many problems arise during game production. Problems such as the trouble of managing all of our files as they pass from person to person, the difficulty of sending out new versions of our game to the rest of the program partners to test, (as well as our friends and family), and the challenge of being able to track who is playing our game. We quickly learned and adopted industry standard software tools such as Perforce, TestFlight and Game Analytics for Wobbles – and for every project at SIP. Each of these software packages allows us to easily solve the problems mentioned above.

Perforce, a source control software, was something I have heard almost every time I talked with someone in the industry about keeping a project’s files managed. I attempted to use it once on an old project but never had a full production project that would allow me to fully use it. With Wobbles, we’ve utilized Perforce with our game files, allowing us to have a consistent and safe place where we can store our game’s files. When you have multiple programmers or artists who need to access the same files, issues occur. With Perforce, you are able to “check out” a file for editing, preventing mistakes or errors that happen when two people are using the same file.

When developing games, one thing you need to do is test them – and test them a lot. Testing doesn’t become easier the more familiar you become with the project, in fact it becomes harder. Once you exhaust the ability to just bring your iPad over to one of your colleague’s desk, you need to go further. Unfortunately, Apple lock’s the apps you create to a device, thus you must find a way to share it with new testers. That’s where TestFlight comes in.

TestFlight is a vital piece of software that we are using for testing. TestFlight allows us to easily distribute the latest builds of our games to everyone here within the program, our mentors, and other testers that may not be in the area. It saves us time and trouble and it gets us feedback from testers quickly.

One very important thing we knew we needed to do is analyze our players. Sure, we can stand next to players with a notepad and a pen and take notes but you’re not always standing next to them. So, when we send a build of our game to someone we can’t watch play, we use Game Analytics.

Game Analytics is probably the most important piece of software that we’ve used on Wobbles and all of the projects in SIP. Using analytics allows us to see who’s playing our game in-real time. We are able to see where people are getting stuck, how many people are coming back to play, how long people are playing, and many other really valuable statistics. Without this, we’d be unable to figure out how our testers who aren’t in the same room with us are doing. Game Analytics will also help when our game is released to track total number of downloads and how interested in the game people are.

The software we’re using in the Summer Innovation Program is not only ultimately benefiting our projects, but better positioning us to work in the industry. The tools we are using impact each and every project in SIP and allow us to have a streamlined, flexible workflow. Using industry standard software such as TestFlight, Perforce and Game Analytics allows us to learn more, improve our project and become better game developers.

» Read More

Great expectations: A new arrival’s story – 6/17/13

Great expectations: A new arrival’s story

Blog by Sam Goodspeed, third year, Hampshire College

I had no idea what to expect from professional game design work. You’d think that as someone who’s spent, at a conservative estimate, 50% of my leisure time in the last year gaming I might have had some idea of how they get made. The fact is, despite games occupying such a large slice of the entertainment industry (grossing $30+ billion annually worldwide), I’ve found that most people have an at best vague idea of the game design process.

Now that I’m here at MassDiGI‘s Summer Innovation Program, I can’t remember what I ever imagined a game lab to look like. I knew what not to expect: that not much time, (if any) would be spent gaming. I knew that it wouldn’t be the adult-playground style work environment we’re led to believe companies like Google or Facebook keep for their employees. My parents have been remarkably supportive of what could have seemed like an unrealistic dream, but I think part of that comes down to my correcting misconceptions as early as possible. For instance, a work-day spent making games doesn’t include any actual game-playing. There aren’t even any game controllers in the whole building!

We work in relatively spartan, climate controlled computer lab; four teams, with about five people per team. Most people are either a programmer or an artist, with a few people working entirely on abstract content design. As a programmer, I spend most of my day looking at code, or at Unity, the game development software we’re using. Unity’s job is to handle all of the complex or technical things (talking to the operating system, lighting, physics, display and platform settings) that would be out of the scope of our program to code by hand. I’ve found that when I talk about my work, one of things people find most difficult to imagine is what I might have on my screen while I work. Allow me to introduce you to the Unity user interface. The ‘hierarchy’ keeps track of everything in the level currently being edited, the ‘project’ is a master list of objects in your game, the ‘inspector’ panel lets you tweak the variables of selected objects, and the ‘toolbar’ has utilities for running and pausing our game, as well as navigating the 3D space. I wish I could describe what the artists do in as much detail, but honestly, I would only be exposing my own ignorance. They use professional art programs to make beautiful art for our games at a remarkable pace, and that’s really all I’m qualified to say.

This opportunity – to work in a facsimile of a real game studio – is about as much a dream come true as I can handle. The development process has been so inclusive to every team member’s creative vision, since so many decisions need to be made in just a single day of work everyone gets to have their own stylistic perspective integrated into the project, right in front of their eyes. Artists are consulted about game design, and programmers are consulted on art design; it’s really wonderfully collaborative work! It may be a long time before I get this much creative control and self-direction on a project again, but I’m reinvigorated to achieve my dream of being a professional designer by this experience. Now that I’ve seen it firsthand, I can say this is a professional environment I could really see making a life in.

» Read More

An indie’s crowdsourcing survival guide – 5/31/13

An indie’s crowdsourcing survival guide

Blog by Ryan Casey, High Class Kitsch

Kickstarter is a very odd beast. There are projects hitting all levels of complexity and from just about any kind of people you can imagine. You could see a one man team looking to get a pet project funded for just $500. Then again, you can see Zach Braff asking for $2,000,000 for a new movie. However, no matter the size of the project or who is running it, one thing remains the same: You must find people and convince them that your project is awesome enough to give money to.

I am one of four members of a brand new indie studio, High Class Kitsch. Toward the beginning of April this year, we decided that we should run a Kickstarter campaign to help us release our game, Pandora: Purge of Pride. Nothing too odd about the story so far, right? Well, there are a couple things you should know about High Class Kitsch. When I say we are a brand new studio, I mean it. We originally formed as a student team to work on our senior project at Worcester Polytechnic Institute. That project is what would become Pandora: Purge of Pride, our debut title. This lack of direct, tangible evidence of previously published titles or big-name companies that we had worked for was going to make running our Kickstarter tough.

This wasn’t going to be easy.

However, we went for it. We set a goal of $5000, and I we buckled down for a busy month. I am happy to report that our Kickstarter ended today, and we exceeded our goal, reaching $6101. We are by no means rich off this, but we met each and every one of our goals. Now that we are at the end of our Kickstarter experience, I have some insight for anyone who is planning to fund their game, especially if you are super new like we are.

1.      Know what you are selling

This may seem obvious. You may think, “But Ryan, I’m selling my Minecraft meets Octodad indie mega-hit!” First off, that would be an awesome game. However, that’s not all you are selling. You need to determine what makes your game absolutely incredible/irresistible in the first place. What’s your hook? Why should anyone care about your game? Figure that out before anything else. With Pandora, that was largely our art style. People responded well to the hand-painted look, and they found the Victorian setting unique. Thus, we showed off the art as much as possible.

There’s still more that you are selling though. As much as you need to sell your game, you need to sell yourself. What’s your team’s identity? What makes you interesting? Are you wacky and absurd? Are you a group of “mad scientists”? Where did you come from, and what’s your story? We at High Class Kitsch have a story, and we try to make it something unique. First, we came from being a student team and are now working at what we love full-time. That’s an innately interesting story. It’s also immediately apparent that we are friends and that we work well together, bouncing ideas and jokes off each other at a rapid-fire pace. Further, we make games that are enjoyable by the larger audience of players (eschewing the “bro gamer” or the “hardcore”), and we like to turn gaming tropes on their head a little bit. Finally, we let our sense of humor show in our team name (High Class Kitsch, taking a stab at the idea of games being essentially product-art, or “kitsch”) and in our mascot, Kitschy Kitty. Once you have the identity for your team and your game figured out, you can move on to actually working on your Kickstarter campaign.

2.      Form relationships with other teams on Kickstarter at the same time as you

Working with people proved invaluable while we ran our campaign. Indies love helping out other indies and seeing them succeed. In that spirit, I reached out to a handful of indie teams looking to fund their games at the same time we were.

In some cases, I had met the designer before. I had met Mo, the man behind A.N.N.E., at MIGS last November when both of our games were in extremely early stages of development. When I saw he had a Kickstarter going as we did, I sent him a message and asked if he would be interested in cross-promoting. He was, and we ended up referring each of our projects’ backers to the other project. I can’t speak for Mo, but I found this hugely helpful. We got a solid bump in backers and a whole bunch of gamers who may not have heard of us before got to thanks to Mo.

In the end we cross-promoted with four indie games (A.N.N.E., Boon Hill, Magnetic by Nature, and Dog Sled Saga) and a local musician (Danielle Staples). This sort of promotion is great because both parties benefit, but it also helps in the long run by setting up cooperative relationships between your team and other teams around the world.

3.      Keep your backers informed and involved

This point is another one that may seem obvious, but you have to consider how you will inform your backers before, during, and after the campaign. Before you even start, you need to make a good project video. Kickstarter drives this into your head as you are making your project, but, seriously, do it. It’s a great chance to showcase your game and your team’s identity.

Posting regular updates helps a lot too. These will allow your backers to know what your team is up to, what’s coming in the future, and give them an opportunity to post comments. Those comments are great. Pay attention to them and respond in a friendly, informative manner. This will help keep your backers feeling connected to your project.

4.      Use social media

Social media and keeping your backers involved go hand in hand. You probably already have a fair amount of friends, family, and followers on various networks, and you can use them as a springboard. However, do not depend on them. Expand. One particularly useful idea for us was to have a Reddit AMA. Yes, Reddit can have some trolls, but that’s fine. For every troll you get, you get 3 good questions and potential backers. Use this to your advantage. If I learned anything about people during this Kickstarter, it’s that people are much more willing to support you if you actually talk to them openly and honestly.

5.      Use the actual media (a.k.a. Interviews rock!)

I am referring to a couple things when I say the “actual media”. Basically it’s anything where someone else is writing or talking about you, be it in the newspaper, online, in a blog, podcasts, or on the radio. Over the course of our Kickstarter we had a solid amount of interviews with various outlets. These ranged from being the first guests at The d-Pad radio show on UNRegular Radio (our episode isn’t up yet) to a very nice piece on our studio from nJoystic. We had a couple bloggers give us a shout out, and we even had the Worcester Telegram & Gazette cover us (twice!). Do not skip over any opportunity to talk about your game. People want to hear interesting stories, and you can provide them with plenty. Game development is crazy, and is very interesting, especially to outlets that are not directly concerned with games.

That said, this will not just happen for you. Reach out to journalists and bloggers. Arrange deals with Let’s Players or streamers to demonstrate your game. Take the initiative. Not everyone will respond or be able to cover your game. However, some people will be able to and will be more than happy to. The only way to make sure no one covers your game is to not talk to anyone.

Any time you get to talk about your game is another place that will send their readers/viewers/listeners to your Kickstarter.6.      Get your game into the hands of gamers

Gamers love playing games. Gaming is probably their primary hobby. They are excited for something new, and you have that new thing. Go to absolutely every single event that you can demo your game in-person. Nothing is too small or too big.

We were at PAX East this year. Pandora was one of four games being shown at WPI’s booth. That booth was behind the immense Capcom and Double Fine booths, and right next to the very popular Divekick booth. We used this as an opportunity to bring in as many gamers to play the demo we had. While they were playing we would talk to them, get feedback, and generally have a pleasant conversation. There is nothing better for your game than a bunch of gamers playing your game, enjoying it, and then talking about it with other people. I have had people telling me that they were happy to see us on Kickstarter based purely on the demo they played at PAX.

Oh, and remember: anyone can be a gamer. One of our biggest fans at PAX was a woman who hadn’t played games “in ages”, in her own words. However, when she sat down to try out Pandora, she loved it. She said it was the first game she really loved since the classic adventure games of the early 90’s. Another huge fan that we gained at PAX was a kid around 9 or 10. He loved exploring the mansion and hearing Pandora’s narration while his dad helped him with the trickier puzzles. These gamers will be more than happy to back you on Kickstarter as well.

7.      Care about what your Kickstarter page looks like

Back to the actual Kickstarter page. Your Kickstarter needs to look good. This is especially true for games. Taking the time to address small details, such as making your own section headers rather than simply using bold text, will show potential backers that you care. An eye for detail on your Kickstarter page will convince them that you had the same eye for detail while designing your game.

This carries through to your backer video as well. This is one point where we were criticized. Our video didn’t look polished, and that’s largely because it wasn’t. It was a bunch of footage caught on shaky-cam and compiled. My recommendation: find someone who actually knows how to shoot and edit video, and get them to help with your backer video. They will do a much better job that you will.

8.      Set reasonable goals, but add some crazy ones too

Ah, here comes the ever-thrilling topic of money. How do you determine what your goal should be? How do you set backer rewards? What actually works?

You need to form a budget. There is absolutely zero way around this. Crack open Excel and start documenting every single expense that you need to cover with your Kickstarter. What software and licenses do you need? What legal fees do you need to pay? Don’t forget any hardware you might need as well.

Then, look at how much you should have for yourself, if you plan to cover any development-time costs with your Kickstarter. A good formula is as follows:

Cost = (Amount of money you need to live on/month) * (months to develop game) * (# of people)

We were lucky in that regard, in that we got to do a lot of our development while still students at WPI, and that counted for school credit. If you are developing games full time, however, this will likely be your greatest cost.

Then you have to create rewards and budget for them. As a general rule of thumb, you should spend 15-20% of a given reward level on the reward you are giving to the backer. This ensures that you are making money, but the backer is getting a good value reward. Another fun fact to consider: the most common level backers will go with on Kickstarter is $25. However, you can bump up that average (as we did, to ~$35) by offering some creative rewards for higher backer levels. These rewards should include something that actually involves the backer in the game somehow. Maybe they get to be an exclusive beta tester. Maybe you include them in-game somehow (we offered portraits of them to be included in Pandora’s mansion). This is where you can get really creative, so have fun! Which leads me to my final point…

9.      GET PUMPED!

Get really pumped! And stay pumped! The best way to get people excited about your game, your Kickstarter, and just about anything that you do is to show that excitement yourself. Think about this: you are making a video game that other people can play. It will be distributed via a massive network of computers, and funded by a worldwide audience of awesome people. Even a generation ago, this would have been essentially impossible. You are doing something awesome, so you should definitely show your genuine enthusiasm in everything that goes into your Kickstarter. It may seem cheesy, but it helps. People get excited when they can tell someone is doing something they love.

Setting up and running a Kickstarter is not easy. Not at all. It is worth it though. Hopefully this helps some of you out there who are going to fund your projects on Kickstarter in the future!

P.S. Kicktraq is a super useful resource for you once your Kickstarter has started. Check them out.

Ed. Note – High Class Kitsch is currently working out of MassDiGI’s summer accelerator space at Becker College. This post originally appeared on their website.

» Read More

Summer in the city (#gamedev style) – 5/8/13

Summer in the city (#gamedev style)

Blog by Tim Loew, Executive Director, MassDiGI

It is that time of year again! MassDiGI’s 2013 Summer Innovation Program (SIP) is just around the corner. Beginning on May 21st, 22 students  representing 10 colleges and universities – Northeastern, Berklee, UMass Lowell, WPI, Becker, Hampshire, RISD, Champlain, RPI and Union – will join us in the game lab on Becker’s campus in Worcester for what is the most immersive (and fun) game development internship program in the region.

This year, for the 22 positions, we received 84 eligible applications from students, both undergraduate and graduate, representing 24 colleges and universities. That’s an increase of 29 applications over last year.  Needless to say, this is a very competitive program and selecting participants from such a high-achieving, talented applicant pool was a challenge.

The 7 women and 15 men taking part in SIP can expect, to paraphrase one of last year’s participants, “one of the best, if not the best, learning experiences you’ll have.” With support from veteran game industry staff, mentors, entrepreneurs and advisors, the students will be working on 4 great team projects. The projects are: Wobbles (winner of the best entertainment game – student category at this year’s Game Challenge), a collaborative project with NeuroScouting, a collaborative project with the Indie Game Collective and a collaborative project with Zeebi Lab (runner-up for the Overdriver.com best online game (serious) at this year’s Game Challenge).  We think this mixture of projects will be really exciting for all the student artists, programmers, designers and producers.

In addition to these great projects, students, who receive a stipend as well as free residence hall housing courtesy of Becker, will have the opportunity to visit area game development studios, attend game industry meet-ups and events.

From time to time during the course of the summer, SIP teams will be blogging about their projects, business models, technology challenges, design choices, art styles, team dynamics, mentor sessions etc.  so keep an eye out for some cool posts. And like last year, we’ll be holding an Open House in early August where teams will demo their work.  Follow us on Twitter @MassDiGI or like us at FB/massdigi for updates all summer long!

5/18/13 – Update – A student from UMass Lowell received great news and will not be in SIP this summer. Therefore, in the program at this time there will be 21 students representing 9 colleges and universities.

» Read More

Winners! – 3/2/13

Winners!

Blog by Tim Loew, Executive Director, MassDiGI

Congratulations to the 44 competing teams and all the attendees, mentors, judges, volunteers and sponsors who spent two great days great days of talking, pitching, working and playing at Microsoft NERD for the 2013 MassDiGI Game Challenge! Winners this year are:

We wanted to get this posted as soon as possible.  See our news feed for more information!

» Read More

Spend your summer with MassDiGI – 2/8/13

Spend your summer with MassDiGI

Blog by Tim Loew, Executive Director, MassDiGI

Are you studying game design, development, art, production, music, or programming etc? Entering your sophomore, junior or senior year at a regionally accredited college or university? Want to spend your summer working on games, learning a ton, getting paid, living for free, meeting new people and having a great time? Yes? Then, do we have something for you: The 2013 MassDiGI Summer Innovation Program! We call it SIP, for short.

Last summer, we received 55 eligible applications. Of the 55, 18 students ultimately were admitted representing 9 different colleges and universities including RPI, Springfield, WPI, Becker, Mt. Ida, Northeastern, Berklee, Champlain and Mt. Holyoke. In addition, student volunteers from Becker, Emerson and Binghamton are also involved. You can read all about last summer by clicking back through our blog or visiting the 2012 SIP Archive page.

Here are just a few comments from last year’s SIP’pers:

• “I learned an absurd amount of new things this summer.”
• “I MADE A GAME!”
• “Overall, I suspect the SIP is one of the best, if not the best, learning experience I’ll have at college.”
• “The mentors and the company visits were by far the best part of the program.”

This summer, we hope to admit up to 24 students and accomplish even more! For all the details and a link to the 2013 application, please click here.

When applying, please keep in mind that this is a competitive process. Only the best mix of students with the right skills and talents will be accepted.

SIP has everything you need as a student to kick-start your game development career:

• A chance to work on a game prototype from the ground up
• Work with a team of students to help create the “next big thing”
• Industry mentors to help guide you
• A free place to live and a stipend

This is not just another internship, but a chance to hold the fate of a game in your hands.  There are mentors and faculty to help you, but in the end it is up to your team to build a successful game.

The 2013 SIP application period opens February 1, 2013 and closes April 5, 2013. Successful applicants will be informed by April 15, 2013. The 2013 SIP runs from May 21, 2013 to August 9, 2013.

» Read More

Would you like to write a blog? – 12/7/12

Would you like to write a blog?

Blog by Tim Loew, Executive Director, MassDiGI

MassDiGI is proud to announce an exciting collaboration with the Boston Globe and Boston.com on the establishment of a regional game industry blog for The Hive. In order to support this effort, MassDiGI has committed to organizing gratis, crowdsourced content from local game ecosystem authors, curating and editing the submissions and feeding them to The Hive for posting.

Over the next several weeks, MassDiGI will be gathering a handful of posts, testing and producing guidelines/FAQs for prospective authors. The goal is to have a steady flow of cool content organized for an official launch by mid-January 2013.

The first test post, published today, “Making a game of “Game of Thrones””, by Disruptor Beam CEO Jon Radoff can be viewed here.

This is great opportunity for everyone from studios and campuses across the region to let the world know about the amazing work and research being done right here in Massachusetts. If you have an interest in writing a blog, please contact me (timothy.loew(at)massdigi.org) for more information.

12/19/12 Update – Blog submission guidelines can be found here.

1/18/13 Update – Other test posts to date include: “The big payoff when video games are free” by MassDiGI’s Monty Sharma; “I was a teenage congressman” by Muzzy Lane’s Chris Parsons and “With a little help from my friends: a day in the life of a game developer” by The Tap Lab’s Dave Bisceglia.

2/8/13 Update – The State of Play blog is live and can be found here.

» Read More