My name is Oleg Brodskiy, and I’m the guy who has been running this blog from behind the scenes. I’ve written a few of the posts, but for the most part, I’ve tried to give you the view of the team through their eyes. Today, you’ll see these three projects, OnCall, Nanoswarm, and Energy Drive, through my eyes. You see, I’m not part of any of the teams, but I spend a large chunk of my week with them, both at work and at play. This gives me a unique perspective on the whole SIP program, one I will try to impart to you today.
OnCall is an interesting beast at SIP. It wasn’t a winner at the MassDigi Game Challenge, so there isn’t a third-party ‘project owner’. That means that the SIP team has a lot more flexibility in doing the things they need to do, because there’s not another layer of people they have to please. That said, it being a serious medical game, they have to spend a lot of time getting the medical facts just right. Since it’s being developed as a game-based medical training tool, the cases have to be realistic, otherwise the training falls flat. As you may have read from Cordell Zebrose’s dev diary, ’Simulating an ER’, this isn’t the easiest thing to accomplish, even from just a case pipeline standpoint.
The game has some serious challenges ahead of it, especially with time rapidly expiring. But the team has been rising to the challenge, and I can’t wait to get my hands on a playable build.
Nanoswarm isn’t Nanoswarm anymore! Unfortunately, that name was taken by a now-defunct government-sponsored game, so the team is soul-searching for a new name. However, that hasn’t stopped them from rapidly prototyping their game, with up to twelve basic level concepts designed already. The gameplay feels impressive already, with a lot of variety in their potential puzzle mechanics. The team has been working hard, and they’re getting ready to roll out into serious testing while they continue to crunch to add in functionality.
Energy Drive has gone through a lot of revisions since it was called USB. As Brian Little discussed in ‘To Pollute or Not To Pollute’, one of the core mechanics is still in development. The game has started to enter small scale testing, and I’ve had the opportunity to play with one of the early builds. My experiences have been mixed (it is, essentially, a pre-alpha, so it’s still in transition), but I can already see the diamond in the rough. I’m excited to be able to talk about it, even the little of it that I can, but hopefully we can begin to release a few more teasers, like some screenshots, over the next few weeks.
» Read More
Cordell Zebrose, deep in thought.
My name is Cordell Zebrose, I’m a senior at Worcester Polytechnic Institute, and I’m one of the three programmers currently working on OnCall at SIP. OnCall is an iOS game built to help communication between medical and nursing students. It does this by simulating an emergency room and forcing players to make decisions similar to what they would have to make in a real emergency room. One of our first challenges with OnCall was determining a way to simulate cases within the small scope of the project. It was a balance between the time we had and the realism we wanted. We wanted a realistic simulation which could viably be completed in a couple months.
Our first idea was to use decision trees to trace the progression of a case from start to finish. The problem was that the longer a case was, the decision tree would create exponentially more work. Every possible situation would have to be entered manually into the system. While this wasn’t necessarily a problem the first couple of times, it would be a big problem for future scalability.
Clearly, we needed another method. Our solution was to systematically generate symptoms from a list and then tie treatments to specific symptoms. We needed to create a database of symptoms for each condition, then generate the case so we could randomly pick which symptoms the patient had and which symptom was the patient’s chief complaint. Afterwards, we’d attach symptoms that the patient was experiencing to certain treatments which the nurse could administer. Once a treatment was given, the patient would be cured of some symptoms. A patient was cured once all the symptoms connected to his condition were cured. We liked the idea of systematically generating symptoms from a database, but the execution needed some work. The main problem was that it wasn’t a very good simulation and therefore wouldn’t work well as a teaching tool. So, we went back to the drawing board, with the idea of creating a symptoms database and possibly a database for treatments and tests too.
After some more brainstorming, we came up with a system, which we think will meet all the requirements. We want to have a list of vitals and test results that will return either a positive/negative value or a number. These vitals have a range where the patient is considered stable. Each test or treatment which the nurse or doctor administers will increase certain vitals, decrease certain vitals and do nothing to some vitals. In addition to this, there will be a protocol of treatments that the doctors must give the patient in-order to cure him of his underlying condition(s). Over time, the patient’s vitals would change and the doctors would need to stabilize his vitals while treating for the underlying condition. If the patient’s vitals ever left the stable range, then he would code. All available doctors & nurses will be able to respond to the code, in an attempt to save the patient.
Now that we have a basic system in place for creating cases, we can start working on an electronic prototype of the game and understand the software architecture that we’ll need to implement the final version. – Cordell Zebrose
» Read More
Bob Ferrari and Monty Sharma talk to SIP Teams
A few weeks ago, Bob Ferrari, CEO of Bare Tree Media, dropped by to talk to the SIP teams about monetization. Bob was a big fan of free to play games, informing the teams of their relative advantages, such as the low bar of entry, the ability to attract large numbers of players, and then to convert a small minority of those players into paying customers, allowing for a veritable cornucopia of conversion dollars. Bob was also favorable toward licensed products, extolling their virtues, such as the easy availability of a built in audience, as well as the financial support of a vested partner.
The teams the laid out their original monetization plans, and Bob suggested ways to improve them. Here are a choice pair:
The Blind Horizons team, the original owners of Energy Drive, first proposed creating unique USB drives that would feature the game as an executable, and then sell those. Players would play for a month and then pass on the USB to a friend. Their second proposal involved creating a paid app that would go on Facebook. Bob recommended the Facebook option as the surer route, since the sort of timed Farmville-like gameplay would fit snugly into Facebook’s niche. He further argued that releaseing it for free would greatly increase their audience, and that adding microtransactions (like an instant build or doubling energy production) would create an effective business model. Upon consideration, the team agreed, and the game has had a different direction since.
80HD has wanted their unique touch-based puzzler to come to iOS devices since its inception. But the monetization model has confounded them. They debated having both a premium paid app and a free ‘demo’ app versus having a free app with microtransactions. While neither idea was bad, Bob suggested that a free app with microtransactions was the better option. He proposed that getting your product out to as many people as possible by removing the barrier to entry was the way to go, and then following that up by letting players buy coins or other types of microtransactions would net them more players in the long run. – Oleg Brodskiy
» Read More
Brian Little, seen here mentally preparing his design philosophies.
My name is Brian Little, and I am student at Becker College and the designer for the MassDiGI SIP team working on the game Energy Drive. Energy Drive was brought to MassDiGI by the efforts of Blind Horizons, a team from Rochester Institute of Technology consisting of Dustin Kochensparger, Blake Gross, Torey Scheer, and Amanda Imperial. Their game, then called USB, was the winner of the “Best Serious Game” award at the MassDiGI Game Challenge and brought into the SIP program as part of their prize.
One of the major goals of Energy Drive is to make the player understand the consequences of energy production on our environment. As a designer, my challenge has been figuring out how to represent that theme in the game while still making the experience fun for the player. In the prototype that we started with, pollution was represented as a cloud which was generated at the start of the game. This cloud contained pollution-producing buildings, such as a coal plant or an oil refinery. The pollution manifested on the map and prevented the player from building in the spaces it occupied. Pollution-producing buildings, as their name implies, would keep creating pollution until they were destroyed. While this created an interesting dynamic, we did not enjoy this puzzle-like element. We felt that preventing building placement wasn’t fun.
Another interesting part of the game was that you couldn’t build any of the buildings that caused the pollution; you could only build clean energy, such as solar panels or wind turbines. I felt that only letting the player build clean energy did not feel like a very realistic scenario, and that it ultimately made the game less entertaining. To solve this problem, I proposed that Energy Drive should allow the player to both create power plants that create pollution and those that don’t. This allows the player to decide how much pollution they are willing to create, while reinforcing the theme of the game by creating consequences for players who pollute too much.
In order to implement our solution, we designed the pollution-causing buildings such that they cost less to build per unit of energy when compared to clean energy buildings. While this makes them more attractive to the player at the start of the game, passing a certain threshold of pollution will trigger penalties that make the game noticeably harder. If the player chooses to build clean energy sources instead, they will produce power at a slower rate, but will also be eligible for positive events. This also allows a player to strategically pollute to get a hefty sum of energy, then demolish the polluting buildings and build clean energy once pollution becomes a serious problem. I feel that this type of decision process is more in line with the kinds of choices that are actually made in the real world.
By no means is any of this final. One of the most important aspects of game design is its iterative nature. Thus, as we continue here at SIP, we’ll be developing and changing Energy Drive in order to continuously improve the game. Hopefully, this gives you a better understanding of the realities of design, as well as the methodology we use to get to where we’re at. – Brian Little
» Read More
Walt Yarbrough presenting to the SIP teams.
Last week, MassDiGI SIP staff member Walt Yarbrough, who has spent a large portion of his game industry career working on Dark Age of Camelot, took some time to describe the standard game production process. Walt broke down the production process into pieces, and I’ll be sharing the first couple with you!
As it applies to SIP, Walt believes there are three key features to getting out of the concept phase. You must have a short, catchy elevator pitch that defines your game, a short, two page design document that outlines the core fun in your gameplay, and finally, a business model that works. Those three things are incredibly important and will form the basis of all of your future work. I’ll go into depth about what they mean in future installments.
The demo is the first real test of the game. This is where you’ll be feeling out your technical constraints as well as encountering the problems in your design. This will define what your project’s realistic expectations are. If, for example, you want to have hundreds of units on screen and your hardware simply can’t support it at the graphics level you want, you have your constraint.
It’s important that the base gameplay works in your prototype. You need to have fun in there too. If your prototype isn’t fun to play and that’s your base gameplay, well…what are the odds that your game is going to be fun if you just keep layering stuff on top of it?
That’s all for now, but stay tuned for more soon! – Oleg Brodskiy
» Read More
Members of Recruits discuss pre-production with Walt Yarbrough. From left to right: Alex Jersey, Jim McCarthy, Steve Everitt and Yarbrough.
Welcome to MassDiGI’s 2012 Summer Innovation Program Blog! We’ll be working throughout the summer to bring you regular updates from our game development projects as well as glimpses into the work of the project teams as they progress. Our goal is to shine a light on the game development process and share our experiences. Periodically, we’ll also have insights written by the team members themselves and the game industry mentors who guide them. But first, a little background.
The Summer Innovation Program, or SIP, was created to give college students an opportunity to spend 11 weeks immersed in a mentored game development environment. Essentially, SIP is a full-time, paid summer internship at a game development studio. When complete each student will be better prepared than ever enter the workforce or become an entrepreneur. SIP is underwritten by Becker College and an array of corporate supporters. (more…)
» Read More