As a lead designer, I spend a large portion of my time discussing ideas with other designers (also animators, programmers, and artists – but mostly designers). There will always be differing opinions on everything that goes into a game: How many weapons? What are the damage types? How many hours of gameplay are we shooting for? How should the control scheme be set? Frustratingly, these discussions can go on endlessly.

Good communication is often listed as a requirement for design positions, but what does this actually mean? Obviously, it means that all parties understand each other, but you can still have understanding and disagreement. For me, good communication is an essential gear to the larger goal of efficient decision making. Here are some tools that I use to make those decisions, and communicate them. Read the rest of this entry »

Designing melee attacks has been part of my weekly routine for a while now, and I think it’s time I sit down and distill the process. Here are the steps, along with an example. Read the rest of this entry »

In order to appeal to a larger audience, PGD is adding a second player: Joe Q (yours truly)! I’ll be migrating some of my more relevant posts from my previous blog and merging with Patrick since we aim for the same goal. Personally, I hope we can get some info out there so developers can stop reinventing the wheel on the basics, and spend more time innovating fun game ideas!

People are always asking, how to you get started as a game designer. My answer is always the same, make a game. Whenever there is a paying Junior Game Design position opened, there are plenty of applicants. All of these applicants are passionate, and really, really want to work in games. At least that’s what their cover letter and resumes say. Unfortunately, most applicants have no idea what is actually involved in making a game, especially with a team of 80 or more people on it. Just like the best way to get better at painting is to paint and to be a better basketball player is to play basketball, the best way to become a game designer is to design games.

Read the rest of this entry »

Documentation in games is a tricky subject, as it does need to exist at some level, but I assert that most of the documentation that teams create doesn’t need to be created. It has been my experience that on large teams, almost all of the internal documentation available to the team is out of date. It’s all well and good to say “we are going to update our docs,” but it’s quite another to actually do that. The easier solution is not to create the documents that are frequently out of date within a week of them being written.

So what documentation needs to be written?
Read the rest of this entry »

If you know me, you’ve probably heard me rant about how most Game Design articles or presentations are a little too theory-based for my liking.  If you don’t know me, you are unfortunately not going to get the honor of hearing me rant about design articles for the first time, however if you stay tuned, you will likely be in luck.

I personally think the best game industry articles and presentations are in the Tech and Art/Animation disciplines.  This is likely due to those disciplines being more similar to disciplines in other industries, and those disciplines sharing a common vocabulary.   Across companies the art terms of texture, frame, bone, vert, poly, point light, etc do not change, just as across companies, programmers all use stack, float, tick, heap, memory, etc to mean the same things.  Unfortunately, for design a lot of these low level technical terms are not shared across companies.

However, I don’t want to just create a giant list of terms, but rather I’d like to try to write some things that would have been useful to me when I was starting as a designer.  Hopefully, if enough people write enough technical design specifications that are freely available a common language will emerge.

But I am jumping ahead of myself, as this is the first post, we must start at the beginning.  What does a game designer do? (disclaimer: I am going not going to try to focus on Level Design, for two main reasons.  First, that subsection of design is leaps and bounds beyond the rest of the discipline, as far as what information is available.  Secondly, it is not my primary area of expertise.) Contrary to popular opinion a game designer job does not revolve around sitting in a room spit balling about how we are going to have the best story or how the game is going to let you do everything (affectionately referred to as the 10 year olds dream game).  A Game Designer’s primary job is primarily to find practical solutions to problems.  These include figuring out large problems like what setting to use for a game, what features you need, and what story you are trying to tell, but for more junior designers, the problems are more like what enemy should I place in this room, how should I design this room, what reward can I put in this corner, should the machine gun reload slower, does this sword deal enough damage, and what item should I ask the player to collect.  After working in this industry, I am amazed that people keep solving the same problems in slightly different ways, so I am hoping to come up with a generic set of solutions that work on most of projects.

You may be thinking, hey wait, you (me?) just said that there was going to be some meat to this, but I (you?) have one question for you (me?).  Where’s the beef?

Well to that I say, it’s a blog, I’ll see you tomorrow (or whatever day I get off my lazy ass)!

Patrick

P.S. In addition to my noble goal of contributing to the industry that provides me countless hours of entertainment at a low, low cost (go buy some games!) and pays my rent, I have the selfish goal of wanting to work on my communication, especially written skills.  So I am incredibly interested in feedback not only about the topic at hand, but at ways I could improve on communicating my ideas.