Designing tips?

[japtar10101]

Is there any tips on designing games? I mean, being somewhat of a JRPG fan, I'm fast to jump to, "Artwork and story always makes a better game" fanboyism. Clearly, I'm brainwashed: I need some enlightening information for better and innovating designs (and/or documentation).

I'm particularly intrigued by Katamari, World of Goo, and Noby Noby Boy.

[hero twin]

Clearly, I'm brainwashed: I need some enlightening information for better and innovating designs (and/or documentation).
I'm particularly intrigued by Katamari, World of Goo, and Noby Noby Boy.

Some good advice I got on creativity: go experience things!
For example Katamari is great 'cause it draws from a deep pool of source material. The art was probably influenced by the superflat movement (see Takashi Murakami) and the music is videogame tunes meets brazilian samba. The story borrows some inspiration from Antoine de Saint-Exupéry's The Little Prince. Then if you look to it's very core katamari is just a route-planning game, the unique twist is that instead of increasing in distance traveled you increase in scale. These elements all work very nicely together, and the overall design is simple and effective.

It took one creative guy to put it all together, so to improve your designs it might be nice to go out and get inspired by as much different stuff as you can!
just passing on some advice I got that might help you.

[japtar10101]

Hmm, I guess I'm thinking about this too simply. I mean, my initial love for Katamari was because it was simple, and controlled well. Also the guilty pleasure of rolling people.

On art, I am generally interested in Rene Magritte's artwork, and always thought it'll be interesting making a game based off of surrealism. I have no experience with 3-D modeling, though (I'm a studio art minor).

I'm also interested towards fleshing out characters but my story-telling is terrible. It's a programmer's curse.

On a random note, what about level and enemy design? What tips are there in making them more convincing and less of an annoyance?

[DrunkenDragon]

I tend to make an AI that can perfectly fulfill its task, like hunting down players and killing them, and then add random variance to different areas to make it possible to defeat.

For example, you could set up a waypoint system for a robot to patrol. When it "sees" an enemy (usually through a cone trigger projected in front of it), it then turns on its targeting algorithms and proceeds to chase the player until the player dies, escapes, or kills the robot. Using a waypoint system for pathfinding is very important for levels unless you've got some gigantic outdoors map. You can link waypoints to things like cover and alternative routes if you want to get fancy. In any case, the initial form would never miss and could use cover perfectly. In order to make it possible to win against multiple ones of these, I added a random variance to its firing angle. Basically, giving it a 60% chance to hit at medium range. I also added in a random chance for it to ignore cover and keep charging. With both of these, the AI didn't do the same thing every time and fulfilled its purpose as a mildly intelligent guard bot.

My main advice, though, is to make a simple AI that does the job in a moronic fashion. Then watch it and make it work around its stupidity step-by-step. Each genre needs a different AI type, so there's never a one-size-fits-all AI. However, you can generally get it working pretty efficiently if you start small and work your way up.

[Zen]

Iteration is very important and tends to make what great games you know great. Frank's method of enemy development sounds strongly like Serious Sam. Which interests me very little. Otherwise it can be difficult to come up with enemies. Prototype as many small ideas and find what you love. Best way I think is to be observant and bounce ideas off good friends or us.

The means to fun games is simply defined but difficult to apply. Prototype small ideas until you find something fun and awesome. Then build on it. Its hard to know what is fun and cool until its done so keep your methods agile and your code-base maintainable. Recent Indie title, World of Goo, started life as a prototype and then was developed by iteration with little design doc. Design docs are good for management of ideas but feel free to change it.

[Justin Tolmar White]

On gameplay design:
Maximize the amount of depth-per-complexity you can get. This means you should make sure there's potential for an interesting interaction between every element in your game before you add a new element. Interactions don't need to be complicated or even specifically coded: for example, an enemy that chases the player and an element that slows the player down are already interacting. Hand-coded interactions are alright too, of course - it's always fun to have an enemy that eats another enemy - but keep these to a minimum because they're not only less intuitive, but also a major sink in your development time.

Pick one, maybe two emotions and nail that. Make a goal of having the player experience a sense of flow, or be in a constant state of terror, or feel the wonder of exploration. Make the player feel these through gameplay, not writing. An RPG with fantastic writing could make a player laugh, cry, and fall in love, but that still doesn't count: your gameplay is acting as an accent to the story at best.

On enemy design:
Code each enemy's AI by hand whenever you can. For each enemy, pick one thing and make the enemy do that thing as aggressively as possible. In most games, enemies last a very short amount of time, so they need to show up and do their thing as soon as possible. The longer you expect a specific enemy to last, the more effort you can spend giving it multiple behaviors. But even boss enemies don't need more than a handful of tricks. Unless your game is entirely about the player's conflict with a single AI opponent, you don't have room for detailed approaches.

You don't need to pull out heavy AI tools like predictive pathfinding, learning, need-based AI, or decision trees unless you have a very specific and very good reason to use it. Even relatively basic AI tools like regular pathfinding are frequently unneeded. Melee monsters using A*, for example, are usually more boring than enemies that just seek x/y.

For games aiming at being frightening (hey, it's my specialty), there's a shortcut to coming up with an interesting focus for an enemy. Pick an apparent rule of the game and break it. Try an enemy that gets bigger as it's damaged, or an enemy that goes through walls, or one that can't be damaged.

On level design:
With hand-coded levels, introduce one of those interesting interactions we talked about at a time. At any given point in time, the player should be either looking at something entirely new or a new combination of elements they've seen earlier. Making a few exceptions to this rule is of course a good idea, but you should have a specific reason in mind every time you do this. One good way to break the rule would be throwing in the occasional easy situation from early in the game so the player can blow through it and feel good about their progress. Another is repeating an older challenge on a much larger scale to show the player they can handle things they wouldn't have been able to go through earlier in the game. A great example of the latter of these is in World of Goo, which repeats the basic bridge-building puzzle at bigger sizes a few times.

With procedural levels, don't worry about introducing those interesting things one at a time. Instead, do what you can to make your generator conducive to as many of your interactions as you can. If possible, make it so the number of elements the player has to consider increases with each level, but don't tailor the specific interactions. Using our old examples of a chasing enemy, an enemy that the chaser eats, and terrain that slows you down, an ideal level generator will sometimes start you on a level with the chaser and the prey, sometimes on a level with the chaser and the slower, but never on a level with all three: it saves that for later.

[japtar10101]

Pick one, maybe two emotions and nail that. Make a goal of having the player experience a sense of flow, or be in a constant state of terror, or feel the wonder of exploration. Make the player feel these through gameplay, not writing.

Thanks for the extensive advice, Justin. I particularly like this quote the most, although I debate whether this should be expressed by art or controls (or both).

On a different note, how can you tell you're in the right or wrong direction? For example, how do you know if an enemy is too confusing or not? A boss isn't fun when its weak-spot is either misleading or uninformative (If the big red dot isn't the weakpoint, why put it there?). Another concern, and one I think JRPG should start focusing on, is figuring out the limit between beautiful artwork, and ridiculous ones.

Finally, I wanted to note that Psychonauts rarely repeated itself in design, and I loved the game entirely. Shouldn't I keep rehashes of the same mission to a minimum? It seems like an artificial way to lengthen a game.

[Justin Tolmar White]

Making a player feel your target emotion through art is a triumph of art, not a triumph of game design. Hitting your target emotion through art and writing is a good thing for a game as a whole, but it doesn't count towards how good your game design is. A perfect game would nail it on every front: art, music, writing, and design. But... this is a discussion on game design, so the rest isn't important here.

For enemies being confusing... ask yourself what an enemy does, ignoring minor details. If it's only one thing, you're doing it right. If you answer with a list... you're doing it wrong. For more complicated enemies like bosses you might have to answer with a more abstract thing. For example, simple enemies could be "it chases", "it dives from the ceiling", "it clings to walls" or whatever. A more complicated enemy could have an AI of "it ambushes", which is more abstract but still entirely understandable.

If you're really unsure, the best way to test is always to grab innocent bystanders and make them play. If you're doing your game well, they'll usually start talking to themselves while they play, and you can tell a lot about your game from that. The key you're looking for on enemies is that they see an enemy and say "oh yeah, that's the one that _s". If they don't have a firm idea what that enemy does after a few encounters, you need to focus its design more.

And yeah, rehashing is bad. That's why you should keep it to a minimum. Once again though, looking at World of Goo will give you a good idea what amount of rehashes are worth it.

[hero twin]

It looks everybody has a lot of good stuff to say about a many different areas of design, maybe if we break this conversation up into different parts we can get more out of it. Feel free to start a topic with your own 2 cents about some area of design (like difficulty, AI, feel, that kinda stuff)

[blindvisionary]

Time to add my spin...

Fundamentally, I rate games in five distinct categories: Challenge, Story, Flow, Gimmick, and Value. Challenge is everything that brings a sense of accomplishment in a game - without this there really isn't any point to keep playing, and players will get bored. Story is everything that goes beyond the mechanics of a game and creates emotional attachment to its world. Flow corresponds to control polish and generally smooth transitions (be it in emotional reactions, abilities, etc.). Gimmick is what separates the game from others out there, and makes it worth buying over something else. Value encompasses playtime and overall cost (I generally use a cost/hr rate), and will determine how your game sells when everything else is good.

While these categories don't necessarily fit into design, I've always kept them in mind when I was designing something. I feel that they are a pure description of the "goodness"/"fun" of a game (you may feel differently...).

Other than that, as a developer, there are a few things you should consider:
- Make sure players blame themselves for failure, not the game. This is necessary for your game to succeed.
- Try to go above and beyond expectations: When a game does something of particular technical/emotional merit out of the blue, it makes it all the better for it.
- Don't iterate. Propogate: Constantly adding onto old code/design will just create a mess. Take what works and scrap the rest of it.

Lastly, don't separate things simply because there are different words for them (i.e: Design, Gameplay, Story). If there's one thing I learned in SD&D, it's that people take these terms too seriously. Challenge and Mechanics should affect Story, and vice versa. In the end it's all one experience, so the more things you can keep in the front of your mind, the better.