Game Design Intro

There are a variety of ways to approach beginning a game project. Each has its benefits and pitfalls. One can begin with a mechanic, narrative, a demographic, or using the iterative process.

Working from a core mechanic allows you to tackle the game play directly, addressing what mechanics are used or needed to improve the experience.  This forces the designer to focus directly on the game and how it plays. However, once mechanics are completed, it can be hard to address the context of your product.

A narrative start, follows a main character or group through a compelling story. This approach is excellent for providing context to place your characters into. A dominant risk however, in using this as a starting point, is a tendency to get too involved in the story and lose track of how to get the player to experience it interactively.

Designing for a demographic genre forces you to consider what your customer wants and try and build something based around that target group. This can be very useful for getting an idea started and moving toward a finished product. However, this method also lends itself to a series of similar and redundant games.

The iterative process is a cycle of add something, testing it, then evaluating what that’s done for the product and whether or not that has improved the product as well as what is needed for it next.  An excellent method this is, as it allows you to evaluate every adjustment as it is added, and how the game is developing. Conversely, if taken too literally or if too much content is being added, this process may hamper the production speed of your product. 

I’m noticing looking back, that with some degree of discrepancy, it is almost impossible to claim to start with any of these processes. If you’re starting with your core mechanic, by the time that’s been decided you already have a demographic in mind, intentionally or not. Once you add a second mechanic, you’ve already begun to give your game context or a narrative. If you start with a story, it will almost immediately lend itself to a specific genre and mechanic, even if the designer isn’t aware of it. And to have a genre in mind, the game is automatically leaning toward specific mechanics which will in turn determine your context. Admittedly, the iterative process doesn’t fit neatly into that triangle, but that would be because a core mechanic, narrative, and demographic are all starting points, where as the iterative process is an method for proceeding toward post-production.

As a preference, I think I prefer a core mechanic approach over any other. Mostly, since I can’t think of a better way to refer to starting from the player’s experience. Well, I suppose the argument could be made that the player’s experience would be easy to interact with by working from a genre or demographic, but that’s kind of pigeon holding your creativity since you’re resigning to a targeted group of players and a specific way of play. A narrative has almost no affect on the player’s experience, unless the game is an action-adventure or role-playing game. But even then, the player’s experience is guided by the narrative, but what the player’s going to be playing is the mechanics and not the plot.

Now for the “fun” part, game engines. As a programmer, I find this a much more daunting subject to try and tackle. Having learned a few things about BASIC programming, I think it’s absurd to be choosing an engine based on its capabilities.(BASIC for those that don’t know is an assembly language, which means it’s very primitive relative to what games are coded in, but without BASIC we wouldn’t have the user friendly game codes we do.) All the capabilities that people go on about in the game engines, is mostly just someone’s superior code. I’ll admit that’s a bonus, but that shouldn’t be your deciding factor for engine X over engine Y. Code can be written lots of different ways.

Now, if I were the programmer, I can admit, I would probably rather have the engine that has most of the work already done for me. Which is why if I could use my preference of engines, I’d probably want the Phyre Engine. I will sadly admit that I’ve only played one game that used this engine and it’s also predominantly a foreign engine, however, that one game sucked up a good two years of my life. Especially, considering the project I’m working on now, this engine has everything I need to make the game run and render beautifully.

Sadly, Phyre Engine is only available to Playstation 3 developers. As a second choice, I’d probably look into Unity, Cry, or Unreal.  Unity, being a free download engine is very appealing. Unreal is a fairly famous engine, but I’d be a little worried about how much code would need to be added to make a non-FPS run smoothly on it. Cry is another great engine, though it’s another FPS dominant engine.