Today is my first #AltDevBlogADay post, so I suppose a short introduction is in order to preface my post. Currently, I am a computer science student at Michigan State University and a game programmer for the Games for Entertainment and Learning Lab. In the GEL Lab we generally develop serious games for contract or research purposes, and this post is going to be about an aspect of serious game development that I think is often not realized.
If I were to ask any random developer as to why developing serious games is challenging, I think I would typically get a response about the game design challenges associated with serious games. While it’s no cakewalk to try to make a game that is both fun AND teaches the player some other skill (such as financing a car or managing a power plant), there are some very likely pitfalls that will inevitably impact the entire team beyond the designers.
You can’t go it Alone
The issue that I think often goes overlooked is that because an average game developer is just an expert at making games, a serious game developer will have to consult an external source that is an expert in the subject matter of the game. More often than not, that source of expertise is also the source of funding for a serious games project. An example is a company contracts a developer to make a game about workplace safety, and the developer will have to work with them to understand what that actually entails.
“The Client”
This places people outside of the development team, who typically know very little about game or even software development, in a very powerful position. The delicate relationship that arises out of this is, in my opinion, potentially more intricate than that of the developer-publisher relationship. Personally I suspect it is more like working with an IP holder on licensed work because they care much more about how their content appears in the game. Often if the client wants to be too hands on, the game ends up not being fun, but if the developer just runs wild, the game could end up not teaching the players what it’s supposed to, which is just as much of a failure in serious game development. It has to be a symbiotic relationship to result in a successful game, and I’ve compiled a couple of pointers from my personal experiences from the past couple of years.
-
Figure out if the client understands what a fun game is, even if they don’t know how to make one. If they do, make playable versions of the game a high priority. If you’re on the right track with your game , make sure your client can play it and be on the same page as you, or else they might demand you scrap your work and change directions without giving your hard work a chance.
-
Be ready for change. If the game isn’t meeting its goals, the design team is going to want a change, and that change is necessary. Huge design changes are in, my opinion, much more likely when you have to teach the player about something typically less than fun. Convincing the client that the change is needed can be hard though if they are worried about meeting deadlines, especially if your code base won’t easily adapt to the new direction. Or the change could come at the demand of the client, which could be even more drastic, as one meeting can leave you commenting out half of your code base.
-
Be afraid if your designers and client don’t get along. You might notice that the client is portrayed in polar opposites in the past two points (wanting change and not wanting change), yet both can happen on the same project. Anything less than a good relationship between your designers and your client is an early sign of approaching trouble. As I said before, a successful serious game needs a balance between the entertainment and the game’s subject matter.
-
Keep in mind that sales is not the goal of the project. From a client’s perspective, a failure to meet the goals doesn’t always result in financial trouble. It can result in the client looking to fund a “do-over” of the project. If you didn’t obey point #2 is reworking the entire game going to be a nightmare? This is especially possible if the project was funded by grants. A failure of one project just means that it is the basis of the next grant proposal to fund the fixing of the first game’s shortcomings.
So there, a little peek into the world of serious game development. I’ve begun to wonder if the challenges of separated expertise is one of the reasons why it seems that there is a high concentration of serious games that are quite good at what they do because their purpose is to teach the player about game design.
@JonManatee in the Twitterverse. I promise I’ll write about something more technical next time around :)