Chris Gengler with an early NanoSwarm level design.
Hi, I’m Chris Gengler, a student at Becker College and lead programmer for 80HD Games, winners of the MassDigi Game Challenge, and I’m working on our game NanoSwarm, at SIP. When we won the Game Challenge, we still had a lot of questions floating about regarding how we would put the game together. What devices do we want the game to be on? Should we write our own game engine or use an existing one? What language would we use?
We soon found our answers in our requirements and constraints. We wanted to play the game with a touchscreen, meaning we were targeting smartphones and tablets, like the iPad. We also faced a limited timeframe in which to make the game, and since we wanted a prototype up and running quickly, writing our own engine was easily ruled out.
While looking at the available game engines, Unity was clearly our best option. Unity made it easy to release the game on Apple devices, while giving us the ability to easily port it to another platform, like Android. The Unity editor makes it easy to bring in assets like 3D models, textures, sound effects, and music, and then immediately see how they work together. Unity also appealed to me due to its use of C#, which I like quite a bit. Even better, two of our team members already had experience with iOS games in Unity!
From my experience with other engines, I was initially skeptical of Unity. I worried about potential limitations (most game engines are built for a specific kind of game, and it can be a real nightmare trying to force them to behave differently) and complexity (some engines essentially require you to research and understand their inner workings before you can use them effectively. *cough* Source *cough*). But Unity has proven to be remarkably flexible and surprisingly straightforward. There’s no need to mess around with loading file data and setting up model, world, and projection matrices just to get some graphics on the screen – you simply drop a 3D model into the scene. But what really impresses me is that Unity gives you the adaptability to add in as much or as little as you want. For example, you can write your own shaders to really take control of how your game looks. You can even extend the editor environment to better suit your needs, creating entire new panels and features. Here’s a screenshot from Unity showing some of the special editor extensions that I wrote for Nanoswarm.
The panel on the right is the Level Data Editor panel that I wrote just the other day – it lets us easily change the order and grouping of the levels in the game, along with some other nifty things. The red and blue lines are part of a system for communicating between puzzle pieces. I built it such that the level designer can build puzzles without having to write a single line of code!
Our choice of game engine was critical to make the game we wanted in the timeframe we have. Unity has definitely proven to be the right choice, and I would recommend tha other small dev teams check it out. It’s perfect for quickly bringing your ideas to life and it’s flexible enough that you won’t feel limited by it. I definitely will be using it again in the future! – Chris Gengler
» Read More
80HD and Walt Yarbrough breaking down their design.
As students working on several game projects at SIP, we’ve found that making a video game isn’t as simple as drawing some art, assembling some code, and selling it. As we work on our projects we got the chance to workshop a project that Brian Kaskie, CEO of Social Media Applications LLC, and his team are working on.
Social Media Applications is interested in making a game that will teach its audience the joys and challenges of parenthood. They hoped to coordinate with businesses and charities to provide materials for the audience on what raising a family really entails. Kaskie pitched the game to SIP, but found that the questions and comments had less to do with their partnerships and more to do with the game itself.
When it comes to moving from concept to execution, the SIP participants have found that grasping the scope of the game is incredibly important. What is being attempted? Is it feasible? And, most importantly, is it fun? Even if the project is realistic, retaining perspective will help ensure that the game doesn’t suffer from feature creep, and keep attainable project goals.
One of the details that the SIP interns focused on was that Kaskie’s team had less gameplay than monetization. Understanding that without a fun game there would be no audience, the team went back to really figure out the core fun of their game. The fun would drive the monetization.
Games are a method of escape, of release. The most important word in the phrase ‘sponsored game’ is ‘game’, not ‘sponsored’. Knowing that, the SIP interns thought of comparable games, and were able to present an idea on how the game would be played in the social gaming market. The group understood that while the social impact of the game was important, the focus had to be on building a good game first. As ideas were kicked around on the theme of raising virtual kids we were able to come up with some neat mechanics and game concepts. We look forward to see what develops. – Oleg Brodskiy
» Read More
Alex Harrington ponders the mysteries of the universe, and whiteboards.
My name is Alex Harrington I am the lead artist on OnCall and a student at Springfield College. My main challenge has been to present the interface in a very simple and clean fashion. The biggest problem is that the forms available to doctors and nurses are incredibly detailed; translating that information on to a tablet required massive amounts of simplification. In order to make these screens user-friendly, I implemented some simplified forms.
The first primary screen is called “The Whiteboard.” Here, the player can see their available cases, their character, and the code button. Additionally, the player can go to their character profile page, the shop, leaderboards, and options. Our challenge here was to find a graphical method which would present the information in a digestible manner. First, there was the “code” button. I wanted this button to act as a logo, imitating a beeper, drawing the player’s eye to the center of the screen. Normally it’s a cool dark blue, but when a code is called, it’ll turn bright red and pulsate. The player will be able to press the logo button and enter the case which had called the code. The next step was to create the case buttons, separated by severity. These buttons would have the patients’ name, age, and present condition, so they had to look comparatively similar. I ended up color coding the corner of each button along with a white cross. This way, the game can guide the player’s eye to the information that matters most. It also allows us to easily show the player an event when it occurs, by using a flash, for example.
If this post has shown anything, I’d hoped that it has shown how important it is to develop your main menu. As the first screen that the player looks at it, making sure they can quickly and easily do what they want is a huge challenge. A challenge we believe we’ve solved. – Alex Harrington
» Read More
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