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.
You can follow us on Twitter at: https://twitter.com/MidnightDefense and on Facebook at: https://www.facebook.com/MidnightTerrors.
» Read More
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
» Read More
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