Archive for ‘Project Rumble’

October 10, 2010

Project Rumble: Concept Document

It’s done at last! Finally completed the Concept Document for Project Rumble. It actually shouldn’t have taken that long. As I explained last time, I used Tim Ryan’s template for what should be included. I’d actually finished all but one of the parts on the day I started. But, the description part took me a while. I guess I just had writer’s block. So I’ve spent the last half an hour doing that and, while it’s way too long, I think it’s ok enough for a first stage concept document. In the end, I’m not trying to persuade anyone to make the game so this whole exercise is more of a learning process (as compared to trying to get investment with a snazzy concept).

read more »

September 27, 2010

Project Rumble: Deciding my battlefield II

For those who haven’t been following Project Rumble, I’ve become sort of stuck with where I want to set my multiplayer deathmatch style top-down shooter. For the full story, check this post. My next posts about PR will take a look at various settings that I could use, and evaluate them.


You know, I was thinking about how many settings I could choose from in Project Rumble and I’m hit somewhat of a roadblock. I thought I’d have at least 3-4 posts, analyzing the sorts of locations that my combatants in PR could duke it out. Alas, I’m doing Space already and I’m only on part II.


read more »

September 23, 2010

Project Rumble: Deciding my battlefield I

For those who haven’t been following Project Rumble, I’ve become sort of stuck with where I want to set my multiplayer deathmatch style top-down shooter. For the full story, check this post. My next posts about PR will take a look at various settings that I could use, and evaluate them.


It’s fitting that I start with this particular setting after a post about BioShock. BioShock was praised for its inventive setting as an underwater city, a sort of Atlantis. It had never been done before and this setting gave the game a distinct feel, both aesthetically and functionally.

read more »

September 16, 2010

In two minds…

Just over a week ago I posted about game design documents and decided that I would start working on my Game Concept Document for the game I’m planning to develop. As soon as I’d finished that post, I had the Core explained and a feature set which, according to game designer Brenda Braithwaite, should be a list of elements that all make the experience of the Core possible.

Braithwaite uses the example of a pirate;

Let’s say we wanted to be a pirate. What things would we need to simulate that experience?

  • A pirate ship
  • An ocean we could explore
  • Other ships that we could plunder (and steal, perhaps)
  • Seaport towns that we could plunder
  • A combat system that allowed us to attack and defend
  • A place to sell our stolen goods or people to sell them to
  • Cannons and swords
  • Some indication of the power we have and the fear we generate as a pirate
  • Fellow pirates

I’ve done all that too, all features which emphasize and create my core goals.

Also required is a description of how a user experience would work. This has been taking me more time. It’s strange. I’ve got this concept in my head, I’ve had it there for months and I know I could explain it very easily to someone in person. However, I can’t seem to settle on a description. Yes this is a concept document, I’m sure not everything is set in stone, but I’m asking myself questions about the description which could possibly impact the core.

Here’s my core so far:


Project Rumble is a multiplayer top-down shooter which pits an eclectic bunch of combatants against each other in a battle only a few miles above the Earth.


Pretty simple, yet it has enough to come up with a detailed feature set. The problem I’m facing is that I’m still not entirely convinced with the theme and setting. Unfortunately in a game as simple as a multiplayer shooter… the setting is core. The setting determines your character, your weapons, the battleground… everything!

This is where I’m in two minds.



1st Mind

Using a Space theme gives huge flexibility when it comes to weapon design. Now I know that’s lazy (only a poor workman blames his tools) but it does seem space is a pretty versatile playground. Another reason space is great is that it’s a zero gravity area… this gives the opportunity to include space physics which really do make these dogfighting style games a lot more fun. Finally, and this is a big one, I’ve got quite an interesting plot that involves a link with Earth. Being in space is the only thing that makes sense for my story… if I change the setting the whole thing has to be scrapped.

2nd Mind

Space is really, really overdone. I was reading various articles about Flash games, and a few tutorials, and space really is the training example and result of a lot of independent productions. Geeks and sci-fi is so bloody generic. I want to do this project to showcase my creativity and innovation, which is difficult to do in the most standard theme known to the gaming world. Furthermore, the game I’m basing this on (Rumble in the Void) is set in space… which will make it difficult to avoid comparisons. I’m not just cloning it, but people might think that way.

So this is where I’m at right now. I can’t finish my concept because I can’t settle on a theme. Perhaps my next few posts will consider various themes I can give for my multiplayer shooter… discussing the pros and cons of each theme and the potential plot lines that can result from it.




September 7, 2010

Game Design Documents – Getting the impossible underway.

It’s now hit the glorious month of September. The weather here in Shanghai is becoming bearable (humidity is not my friend) and graduate job applications are beginning to open! Yes, the lord giveth and the lord taketh away.

The main point of this blog is to work as a diary and semi-portfolio of my work in game design. The ultimate goal is to get into a game development company back in the UK, starting from September 2011 (that’s when grad schemes begin). Therefore this point of the year signifies my 1 year deadline. While I obviously have to impress companies before I get offered the job, I’ve still set myself the deadline to finish my game by September 2011. As I was thinking about this target, and my complete lack of art, coding and testing ability, ‘impossible’ came to mind.

My current company is employing a small team and wants a game released from concept to execution in 4 months. These 5+ people have skills, they know how to make certain visual effects using Photoshop. They know ActionScript and they have the resources to test their games. 5 people, with knowledge, will be taking 4 months to complete. I am 1 person. I have no knowledge. Actually that’s not completely fair. I can use graphical software at an intermediate level, not Photoshop though… I hate it. I use Adobe Fireworks (formerly Macromedia). I’ve designed logos which have been used professionally, and I’ve designed interfaces and websites with my current skill set. Therefore I’m not too worried about menus and the user interface of my game. Creating models and effects on the other hand…


ActionScript 3 - My potential new language


During this year I will be teaching myself ActionScript from scratch (I think… more on that in an upcoming post), albeit with a slight background in Flash animation. I also want my game to have multiplayer functonality, so I’ll have to teach myself how to connect multiple players to my game through the internet. All this, in 12 months.

Impossible does seem to be the correct word to describe this, but my god I’m going to try!

So how do you start? How do you begin creating a game, from scratch? Fortunately I don’t need to impress investors, I’m doing this for free and for no-one but myself. Therefore I can make the game I love. However, I want this to be as professional as possible, so I’m going to do things properly. That begins with a Game Design Document.

Being the novice that I am, I had to Google the term to find out exactly what I have to do.

The first link I clicked was ‘The Anatomy of a Design Document, Part 1: Documentation Guidelines for the Game Concept and Proposal‘ by Tim Ryan on Gamasutra. This article is 11 years old, but I doubt the process has changed much (except perhaps a focus on social networking features which has emerged since then).


The purpose of design documentation is to express the vision for the game, describe the contents, and present a plan for implementation. A design document is a bible from which the producer preaches the goal, through which the designers champion their ideas, and from which the artists and programmers get their instructions and express their expertise.”

Tim Ryan, Gamasutra


The key things to pick out of this are; goal, ideas and instructions. Ryan goes on to explain the benefits of guidelines to a design document, saying;


Elimination of hype. Guidelines eliminate hype by forcing the designers to define the substantial elements of the game and scale back their ethereal, far-reaching pipe dreams to something doable.

Clarity and certainty. Guidelines promote clarity and certainty in the design process. They create uniformity, making documents easier to read. They also make documents easier to write, as the writers know what’s expected of them.

Guidelines ensure that certain processes or procedures are followed in the development of the documentation – processes such as market research, a technical evaluation, and a deep and thorough exploration and dissemination of the vision.

Ease of drafting schedules and test plans. Design documents that follow specific guidelines are easy to translate to tasks on a schedule. The document lists the art and sound requirements for the artists and composers. It breaks up the story into distinct levels for the level designers and lists game objects that require data entry and scripting. It identifies the distinct program areas and procedures for the programmers. Lastly, it identifies game elements, features, and functions that the quality assurance team should add to its test plan.

Varying from the guidelines. The uniqueness of your project may dictate that you abandon certain guidelines and strictly adhere to others. A porting project is often a no-brainer and may not require any documentation beyond a technical specification if no changes to the design are involved. Sequels (such as Wing Commander II, III, and so on) and other known designs (such as Monopoly or poker) may not require a thorough explanation of the game mechanics, but may instead refer the readers to the existing games or design documents. Only the specifics of the particular implementation need to be documented.”


From reading this, I can see the most important benefit to me (as an individual and not a development team); “Design documents that follow specific guidelines are easy to translate to tasks on a schedule”. Even though I’m not organizing a multi-functional team of artists, coders, producers and designers, I am in need of some structure to my project. As a complete novice, I could come up with what I think would make a good design document, but I’m sure there are important things I’d miss if I didn’t seek outside information on the process. Planning is good, so I intend to make a good plan based on the structure of my design document.


Time to fill this up!


Ryan begins with a Game Concept Document, which is used to persuade the Product Design Manager to take the idea past a concept, to explore the possibility of creating the game. He details that a concept document should have;


Introduction: The introduction to your game concept contains what are probably the most important words in the document – these words will sell the document to the reader. In one sentence, try to describe the game in an excited manner. Include the title, genre, direction, setting, edge, platform, and any other meaningful bits of information that cannot wait until the next sentence. The edge is what’s going to set this game apart from the other games in the genre. For example:

Man or Machine is a first-person shooter for the PC that uses the proven Quake II engine to thrust players into the role of an android space marine caught up in the epic saga of the interstellar techno-wars of the thirty-seventh century.”

Breaking the introduction up into several sentences for the sake of clarity is acceptable. Just know that the longer your introduction, the more diluted your vision will seem.

Background (optional): The background section of your game concept simply expands upon other products, projects, licenses, or other properties that may be mentioned in the introduction; so it’s optional. The background section is physically separated from the introduction so that readers can skip it if they already have the information presented. But the background section is important for licensed properties and sequels and concepts with strong influences from previously released titles in the same genre. If you intend to use an existing set of code or tools or to license a game engine, then describe these items and their success stories here.

Description: In a few paragraphs or a page, describe the game to the readers as if they are the players. Use the second-person perspective — “you.” Try to make this section an exciting narrative of the player’s experience. Encompass all the key elements that define the core game play by describing exactly what the player does and sees. Avoid specifics such as mouse-clicks and keystrokes, but don’t be too vague. You want the readers to become the player’s character. Hover your detail level right above the GUI interaction. You would say something such as, “You scan your tactical radar and pick up two more bogies coming up the rear,” instead of “You click on your tactical radar button and the window pops up revealing two bogies coming up the rear.” The description section should make the content and entertainment value of the game obvious and convincing.

Key features: Your game concept’s key features section is a bullet point list of items that will set this game apart from others and provide goals to which the subsequent documentation and implementation should aspire. It’s a summary of the features alluded to in the description. These bullet points are what would appear on the back of the game box or on a sell sheet, but include some supporting details. For example:

“Advanced Artificial Intelligence (AI): Man or Machine will recreate and advance the challenging and realistic AI that made Half-Life game of the year.”

Determining how many features to list is a delicate balancing act. Listing only one or two key features is a bad idea if you’re doing anything more complex than a puzzle game; listing more than a page of features implies that the project would be a Herculean task and may scare off the bean counters. Listing too few features might sell your concept short; listing too many waters down the concepts’ strongest features.

Keep in mind that you need not list features that are given, such as “great graphics” and “compelling music,” unless you really think such features are going to be far superior to those of the competition. Great graphics, compelling music, and the like are the understood goals of every game project. On the other hand, if the particular flavor of graphics and music provides your game with an edge in the market, then you should spell that out.

Genre: In a few words, define the game genre and flavor. Use existing games’ classifications from magazines and awards as a guide. For example, you could choose one of the following: sports, real-time strategy, first-person shooter, puzzle, racing simulation, adventure, role-playing game, flight simulation, racing shooter, god simulation, strategy, action-strategy, turn-based strategy, side-scrolling shooter, edutainment, or flight shooter. Then you can refine your game’s niche genre with these or other words for flavor: modern, WWII, alternate reality, post-apocalyptic, futuristic, sci-fi, fantasy, medieval, ancient, space, cyberpunk, and so on.

Platform(s): In a few words, list the target platform(s). If you think the game concept is applicable to multiple platforms, you should also indicate which platform is preferred or initial. If you intend multiplayer support on the Internet, indicate that as well.

Concept art (optional): A little bit of art helps sell the idea and puts the readers in the right frame of mind. Use art to convey unique or complex ideas. Screen mock-ups go a long way to express your vision. Art for the game concept may be beyond most employees’ capabilities, so requiring it would limit the number of submissions; thus, it is optional. If a concept has merit, the art can come later from a skilled resource. Often art from previous projects or off of the Internet will jazz up a document. Just be careful with any copyrighted material.”


I believe my first goal will be to complete this concept document before moving onto the next stage. I’ve had a concept in my head for months now, so I’ll get it written down properly and post it on the blog.

Before I leave you for today, I also wanted to link to “The “Core” of a Game” by Brenda Braithwaite on her blog Applied Game Design. I will also be using the advice given in this article to help establish the key features of my concept document. It’s interesting reading so please give it a look!