The new forums will be named Coin Return (based on the most recent vote)! You can check on the status and timeline of the transition to the new forums here.
The Guiding Principles and New Rules document is now in effect.
yet another game design question
Calica
Registered User regular
Registered User regular
I'm a programmer who has occasional ideas for games I'd like to make, or at least tool around with in my spare time. I don't care if I get published and I'm not looking to make any money at this. What I'm wondering is this: are there any good resources on the nuts and bolts of designing and balancing complex systems? Googling "game system design" and similar turns up a lot of designers answering the question, "How do you design games/systems/puzzles?" with, essentially, "Well, I just... you know... design them."
People have been making computer games for decades, and other kinds of games for much longer. Is there a way to access all that accumulated wisdom without having to reinvent calculus by myself?
People have been making computer games for decades, and other kinds of games for much longer. Is there a way to access all that accumulated wisdom without having to reinvent calculus by myself?
0
Posts
A quick google search of "how to design puzzles" pulled up about 20 resources with specific types of gameplay and game designs.
Aside from high level concept, understanding usability is probably the next most important thing when it comes to design. How your player will work and play with the objects you give them. A general design book like The Design of Everyday Things can start this sort of discussion, but really trail and error is a decent bit of puzzle design if you are wanting to make something unique.
Practice. You have to try and fail a lot to get to the good stuff. Its from the things that don't work that you can start to figure out what does work. I know this sounds like a 'just design them' comment, but its more of a 'you shouldn't expect yourself to have perfect design from the get go and its more valuable to be getting things wrong while doing it than trying to figure out good design and not doing it' comment. Which is a bit of a mouthful.
at the tutorial level there's only so much you can learn that is beyond what you'll figure out anyway
do it just like you would do anything else: try it yourself, and if it sucks, figure out how to do it better next time
and prepare to make about two dozen game demos before finally nailing it
we also talk about other random shit and clown upon each other
game "design" is overrated at this level
just model on existing concepts, and make changes where you think there is more fun to be found
Listen to and/or read the thought processes of John Carmack when creating the original Wolfenstein 3D
hardly what would be considered a "formal" game design process, but still thoughtful
we also talk about other random shit and clown upon each other
Try and figure out a few descriptive sentences for what your game will be. Then sit back and think about those and what you had planned for game play. Unless you have a pretty firm notion of what you wanted to do, there will probably be a few changes on your design as you go.
Be sure and save ideas, sketches, code fragments for bits that don't fit. You may revisit those later and make them parts of other games or outright titles themselves. (See Valve and what became Portal).
Look over what you have and see if it is fun or tedious. If you have a group that you trust, describe things to them and see what they have to offer.
What are you good at / have experience with in programming? I mean this seriously - every programmer has some aspect of their professional life they can leverage into recreational programming. My brother is a lead programmer for a bank's checking software website, but it's his expertise in javascript and network programming that lets him doodle game ideas for multiplayer browser based tetris-esque games.
I'm not against coming up with a cool game idea first, but I find it's easier to explore a space where you're confident and see if a game idea doesn't come to you. You have to foster that confidence. I'm an artist with basic programming skills, so I set out to make a fucking pretty game with simple mechanics. Don't start an uphill battle.
Most of my experience is in web development using ASP Classic and some .NET. I've written some non-web stuff in C#, mostly simple tools to make my life easier at work. (I prefer C#; we just don't use it for much... yet.) I'm also a fairly decent writer, if I do say so myself :P
I guess my plan for now is to write user stories, and also to play around with very basic touch input stuff on the iPad (totally different thing, but fascinating!).
To design a game you need to synthesize a theory of fun which you can use to gauge the value of a given mechanic. Outlined below are two popular schools of thought you can use as a starting point.
Luke Crane wrote that game design is mind control, and I wouldn't say he is that far off. Fundamentally, a game is an interactive experience which causes the player to do what the designer intended them to do and feel what the designer intended them to feel. Bottled emotion. The designer's role is to manipulate the player into behaving and feeling as they please. Under this paradigm, you are supposed to think of the experience you wish to convey and then shape mechanics that create that experience. Whenever you consider a mechanic, ask yourself whether it enforces the experience. Any mechanic that does not has no place in the game.
Sid Meier defines a good game as "A series of interesting decisions". This is the bottom-up alternative to the top-down take described above. Games differ from other forms of media by being interactive, and from toys by offering meaningful (often chained) choices beyond deciding what kind of fun you want to have now. Thus, if you wish to offer something that other forms of entertainment cannot, you must focus on choices. For a choice to be meaningful it must meet certain criteria. Firstly, a choice where one option is clearly better is no choice at all. For a choice to be engaging, several options must either be or appear to be as good to the player so that they can use their skill to try and determine which one is correct. Secondly, choices must have interesting consequences. A player must care about the result of a choice in order for them to want to pick the correct option. Ideally, choices should always alter further choices to create chains of possibilities in order to build on the player's previous engagement. Striving toward a single goal helps minimize the number of fronts on which you need to keep your player's interest. Finally, the player must be able to make an informed choice. If they have no way to guesstimate which option is superior, then it is, again, a non-choice. Whenever you consider a mechanic, ask yourself whether it offers the player an engaging choice and leads them to make other engaging choices. If it does not, ask whether making the player do something that is not itself interesting will make other choices in the future sufficiently more interesting as to justify its existence. Any mechanic that fits neither description is inelegant bloat.
I hope this helps a bit. My coverage of the subject is obviously extremely shallow, so if you find it interesting you should seek out a more formal source. You can find sources on the subject under the labels of Game Design, Psychology, and Ludology. Good luck!