26 August, 2015
Blaugust, Day 26
So, I’ve got most of our fundamentals almost out of the way, and now I’m ready to get my hands dirty with details. For today’s post I’ll focus on one development task, a prototype, and one design task, choosing a setting.
The seed of an idea
When developing a game, it’s often a good idea to do something a bit different than what others have done in similar games. This allows the game to stand apart from the others of its gameplay genre, and will provide a unique selling point for marketing in the future.
But, new ideas often carry risk. It’s one thing to say some new feature will work, but it is often better to demonstrate it working on a smaller scale. This calls for a prototype!
The prototype is often created by the team (or for what will be a larger team, the core of the team) to test out a concept. For example, programmers might put together a demo showing a new technical feature, such as a renderer or a new bit of artificial intelligence. Obviously the programmers won’t be able to explore the entire possibility space doing this, but they can test out some theories and learn some lessons in a limited environment that doesn’t have to be “production ready”.
Designers might want to try out some new concepts as well. In this case, they might want to create a paper prototype of the game using simple, re-usable materials like cards or easy-to-use materials like post-it notes. By simulating the gameplay, a designer is able to find flaws and address problems before writing a full design document and committing the team to a design. Usually paper prototypes can explore a good bit of the possibility space.
For art, this state is usually built into the actual development process as “concept art”. You have some artists, sometimes specialists, draw out concepts for the art in the style of the game to see what works. This often makes great publicity material, showing off what the game could look like in simple form. Some of these sketches and drawings will later be turned into the sprites, models, textures, and animations that are part of the final game.
Expanding upon the basics
One you have the basics, then you can build upon that. When doing a programming prototype, there is often a question of if you should re-use the code or throw it out and start again. Re-using the code gives a head start on developing the full game, but sometimes that code wasn’t created to be robust and reusable. Sometimes it might be best to use that as a library to separate out the code an allow it to be rewritten without having to rip it out from the general code base.
For design, the initial paper prototype can be expanded. Notes on what you could do to expand upon the concepts can become part of the design document written for the game. It might even be worth keeping the paper prototype around to play it again in the future if there needs to be changes to the design, or if someone has a suggestion or improvement.
For art, those initial concept pieces could be cleaned up and used for later marketing material. A lot of games have special collector’s editions of the game with art books that are rather popular. It gives insight into non-developers of the process, and gives people a little glimpse of what could have been in the game.
As the prototype is being developed, I will also want to focus on a primarily design task of development. I already picked a setting genre a few days ago, so now it’s time to think of what specific setting I want to develop for this game.
License from others?
One answer is to license an existing setting that is appropriate for the type of game and audience I want to play. If I want to do a space epic for your typical adult, then Star Wars is an old stand-by. But, there are plenty of settings to license and use.
The good news is that an existing setting often has a built-in fanbase that is often loyal to that setting. For example, Star Wars games are infamous for selling a respectable number of units seemingly regardless of quality. Of course, when you do a high quality game, people might remember it fondly. If the game is released near another major release, you can get even more cross-marketing potential. Another benefit is that the setting is already fairly well detailed and flushed out, so a team will spend less time filling out details that may or may not be used in the game, and more time focusing on aspects unique to the game.
There are two main downsides to using a licensed properties: cost and loss of control. Licensing a setting means paying fees and royalties to the owner. On top of that, any agreement will have to be negotiated, which means that lawyers will be involved, which increases the costs. The owner will also want some measure of control over the product to make sure it fits and doesn’t damage the reputation of the setting; this can cause restrictions in the design and any sort of conflict will need additional design to work around.
Sometimes there are compromises. For example, Dungeons & Dragons Online uses the established Eberron setting from tabletop D&D, but is set in an area that was less defined in the tabletop sourcebooks. As I understand it, this was intentional to allow the developers more freedom to do interesting things without as much constant oversight.
Roll my own?
The alternative is to create an original setting. Whereas this doesn’t have the cost and loss of control, it requires a lot more work and marketing to make it work.
Since an original setting won’t be able to tap into an existing base of fans, the game project will likely have less results from marketing efforts. Essentially, part of that marketing will go toward educating people instead of being able to get people excited by using some brand name.
The project will also need to dedicate some people to developing the original setting, and working to maintain consistency. It’s easier to define new parts and pieces to the world, but this can be fraught with peril as the setting can start to feel like a patchwork of ideas rather than a unified whole.
The reality is that your first few games may not feel as unique. For example, in the Elder Scroll series the earlier gameDaggerfall feels a lot more generic compared to late games like Skyrim. Part of this is the specific game world locations and the technology behind the games, but it’s also likely that there was less of the world defined very well in the earlier days.
You also run into problems of getting people to care about your setting if its only in games. Gamers are good at cutting through the “fluff” and getting to the gameplay underneath. For example, how many people really know much about Final Fantasy lore beyond chocobos, moogles, and black mages? Yes, there will be people who put together wikis with cross-references, but the more typical gamer will think, “My black mage casts Flare!” and leave it at that.
There’s also a middle ground, where you tap into a shared setting that is in the public domain. Taking a fairy tale or series of medieval tale and giving it your own spin is a way to get people to recognize an original setting without the cost and loss of control. Do a good enough job, and people will start to see your version as the “true” version of the stories!
After this, I would have a prototype and a detailed setting to work from for my game. My next step is to start thinking about what it will take to actually make the thing that people will play.