How Do You Go About Your Game Design?

Here are some questions to help get the ball rolling:

How about telling us how you answer those? (To get the ball rolling faster.)

Here are some questions to help get the ball rolling:

How about telling us how you answer those? (To get the ball rolling faster.)

Much better idea :)

Disclaimer: I'm a 21 year old Computer Science major with a minor in physics at a university in southern California. The extent of my game development experience is limited to 2 games that I designed and made in C# - a text adventure and a block breaker style game. This was about 9 months ago before i had to focus on C++ application - i did not stop designing however.

My process is day in and day out - whether i'm at work, school or at home my mind is always running on what I can do and how can I do it better this time. I have a notebook i use exclusively for all of my game concepts - story ideas - game mechanics. I'm not much of a drawer so I leave that until its time to hit the computer. I will typically watch movies or listen to a type of music that aligns with the general mood and idea that i'm after. For example, i'm working on a concept for a sci-fi rpg - i'll listen to the martian soundtrack, or eve-online -etc. When i think about game design i always have one thought in mind: go big or go home (i know, i need to work out of this). It leads to a lot of crazy ideas that are always out of reach for me in all reality. I'm not very good myself at going about improving a game mechanic from the design standpoint - I don't feel very innovative. I'm hoping some of your answers will be able to help me with that. But typically i go about it via a tree, i have the mechanic in the middle and I try to break down every aspect of that mechanic, then put subsequent ideas about improving the aspects of the mechanic versus the mechanic itself. I like to go to the core of whats going on and look there. I've definitely worked on something for 12 hours and scrapped it all because i didn't like the direction it was taking. I think this is a big aspect of my design process that holds me back a bit, but also allows me to improve upon the design. Although, if you're always scraping and improving and never finishing a final product, whats the point, right? :cool:

Two weeks ago, I had a dream about a game. It lasted like... 10 seconds. I got really hyped.

I wrote a quick GDD to organize my ideas and... programmed 5k lines of code in 10 days (2k in the first two days).

I created my own procedural map generation algorithm and started doing some pixel art (I never ever worked with art before).

In the end, my subconscious mind was not very good at game design. My game developer friend told me it was not fun to play. I took his opinion as the only opinion in the world and stopped doing it.

I do not recommend this game design approach. xD

Oh, it was a Tiled-Biomes-RPG-RogueLike-Survival game. Here's a picture.

[spoiler][attachment=32685:Game.png][/spoiler]

For me, most of my "game design" goes on in my head, typically while I'm just going about my day (I tend to be relatively busy). If I think of something particularly useful, I jot it down in the Notes app on my iPhone. When I do get a chance to just work on it, I whip out my laptop, throw up Vim (my preferred note-taking software), and start fleshing out my ideas. I'll generally listen to music as I go (either electric/instrumental or in a foreign language, anything so long as I can't understand any lyrics that would distract me). Frequently, as I type things out, I'll reach a brief stopping point where I need to actually flesh out an idea rather than jot it down. At this point, I'll get up out of my seat and start pacing. And I'll pace and pace until I've fully and completely fleshed out the idea. Or until I'm interrupted. And this can potentially go on for hours. Sometimes I run out of time and have to postpone my thinking until later, so I'll jot down a quick summary of how far I got and write down the things left that I still needed to consider.

Generally this all goes on for several weeks / months before I feel that I've got enough material to start working on a project "for real".Then I go to town in Unreal 4, programming something. Granted, I myself am only 23 and graduated college back in May, so I only have 1 "real" game that I worked on for 4 months consecutively with a team (everything else was school projects or game jams of 2 weeks or less, pure prototypes). But I've had about 5 games that I've come up with over the years that I feel are of sufficient enough quality to devote any actual time to and the first of those constitutes my current project, codenamed Spectral. You can look it up on cartrdge.

Part of my "process" is considering not just the gameplay potential of the game idea, but also the marketability of it. If I can't think of way that a game of "this sort" would have a concrete place in the marketplace, both in terms of an existing player base and the current trends in the industry, then I don't really see a reason to continue devoting time to working on its design, let alone programming anything with it.

Not sure what you mean about your "solid concept improvement" question. When I feel that an idea is lacking, I'll usually notice either during my original thought process or during the prototyping stage. In those cases, I can usually see what it is the player is wanting to be able to do (occasionally by getting random friends/relatives/associates to do a quick playtest), see HOW the current design is failing to properly achieve that, and then understand what things need to be fixed to achieve that. Then it's just a matter of brainstorming / prototyping different features to see if they are a good fit for creating the feeling in the player that I am seeking. A nice combination of intuitiveness, autonomy, and functionality.

I don't "go back to the drawing board" as often as some of the other students I've worked with before since I tend to spend a lot more time developing designs and code that emphasize robustness, so my stuff will generally "work" longer than my cohorts' before my team and I come to see the weaknesses in it. I'm actually currently on my 3rd iteration of a robust skill system (first on a project as a Junior, then again on a project as a Senior, and then now). Each time, I've come to recognize key problems in the previous versions and have begun making alterations to the design. It also helps that I've grown in general as a programmer with each year.

I have material that I created in the past about various tropes, characters, gameplay elements, etc. that caught my interest in the past. To start a new game design project I need a focus - some inspiration or a request from a collaborator. When I have that focus it's kind of like building a mobile - the focus is the center-point, and I have to find balanced things to hang on it to make the whole thing spin interestingly and have harmonious colors. So I brainstorm to see if that focus gives me any new ideas, and I also brows through my old material to see what seems compatible or like the two ideas might strike interesting sparks off each other. I try to imagine playing the game (or reading the story, if I'm designing a story rather than a game).

I think design is a basically iterative process, so something like The Snowflake Method is a good starting point if anyone isn't familiar with iterative design yet.

I would like to start the game design. Do you have programs that you recommend?

• What setting do you try and put yourself in? (listen to Music? Watch Movies? TV? etc?)

I design in any setting that it occurs in, for example, if I'm stuck waiting somewhere, I start to refine Game Design ideas I already had to type or write later.

• What do you physically do while you're designing? (Are you in front of the computer typing? Draw something? Write?)

I could be in front of the computer typing it out in a document or drawing out the ideas.

• How do you go about thinking when designing a game? (Game mechanics can be different than your storyline)

I go about thinking "How will I make this system work?" or to be more specific, I would think about how a game would translate specific mechanics, such how moves have different properties depending on the user or how to approach a concept and turn it into a functioning game mechanic that meshes well with other mechanics.

• When you have a solid game mechanic or design aspect in mind, whats your steps to improving upon them?

Testing it out on paper or even in a prototype if there is time for it. If the latter, repeatedly testing it to make sure it functions and behaves the way you envisioned it{or as close as possible to it}. Seeing a mechanic go from an envisioned thought to actual gameplay is very awesome.

For example, because I was a novice to game engine/programming, I couldn't get a mechanic I envisioned to act the way it did, I gave up on it, came back to it a year later, and managed to get it to look exactly as I saw it in mind. You can see it being used in the first two seconds of this trailer from a game I worked on in my free time for 2 years. Even added a "rocket breaking the sound barrier" sound effect if you manage to hit a specific speed threshhold.

• How often do you go back to the drawing board after laying our a certain tree of mechanics and design aspects?

There is a certain game I've been adding to and re-designing for the past 12 years, haven't made a prototype of it yet. I would rather tackle it with an actual team someday due to some aspects of it being too complex for a single person to tackle{my skills are divided between art and game engine skills, I would prefer an actual programmer or game engine master for this kind of game}. After laying a tree of mechanics, I find myself elaborating more on them until they make "sense" and synch really well within the game's design.

I typically start with mundane technicalities like genre, if it's single player or cooperative, platform, how long the average game session will last, etc. Then I go for a central concept (like "no micromanagement", "you are the Emperor of the Galaxy", "asymmetric gameplay", "historical accuracy of medieval world") and a theme. Then I check if it makes sense market wise and if I can manage it promotion wise (where it will be sold, what the price wil be, what kind of player will play it).

A very important part is the decision what will be NOT in the game (like tactics vs strategy, never both). What will be sacrifaced to make the rest of the gameplay solid. Actually it's far more important than what will be in the game.

Next I try to post about it on some forums. Because I need to persuade people the game will be great I need to write certain things, what I wrote/promised adjusts the game and let me know what's needed to make this game appealing (for example in one game I added "saving princess and slaying dragons" because it sounded cool on the game's description :D). These improved the game.

Oh yes, and the most important thing, I set the deadline :) Without it nothing works :)

Choose the game format (big, medium, small), delivery platform(web, downloadable, physical), think of game mechanics and theme of your game, think of the potential buyers i.e. target audience. Get your idea done in some basic form, get feedback, adjust. Iterate, till you get mainly positive feedback. Publish, sell, build community around it. Be happy. :-)

Two weeks ago, I had a dream about a game. It lasted like... 10 seconds. I got really hyped.

I wrote a quick GDD to organize my ideas and... programmed 5k lines of code in 10 days (2k in the first two days).

I created my own procedural map generation algorithm and started doing some pixel art (I never ever worked with art before).

In the end, my subconscious mind was not very good at game design. My game developer friend told me it was not fun to play. I took his opinion as the only opinion in the world and stopped doing it.

I do not recommend this game design approach. xD

Oh, it was a Tiled-Biomes-RPG-RogueLike-Survival game. Here's a picture.

[spoiler]Game.png[/spoiler]

I had a similar experience. In my dream the idea seamed amazing, but after 2 days of work i finished the game "Path to glory", and no one wants to play it. It seamed so promising in my dream... it realy did.

The objective of the game is to go from point A to point B. But there's a catch: you can't see anything except the room you are on. When you move there are two possibilities: (1) you can move or (2) you can't move. When you can't move you have to start all over. So the trick is to trial and error until the end memorizing all your options.

So my take on this is that dreams are important but it might be important to think about it more indepth before start programming. Thankfully i only lost 2 days. In this case i could easily make a paper simulation for example and show it to a group of people. Asking for their opinions, ask if they were having fun and if they could play it more than once.

The game for reference:

https://play.google.com/store/apps/details?id=com.rjfcastro.a12

I would like to start the game design. Do you have programs that you recommend?

Try some of this tools. https://mobilegamegraphics.com/tools/ I just come up when i was started working on game design. So i just compile it for some reason that maybe someone would try to ask some of the game design builder. Hope you can find a better one from there.

When I go about designing anything in my games I always consider how I want the player to feel. I research colours, sounds, and reactions. I try to predict how players would react in all aspects.

I've noticed there is a lot of discussion about designer's end results and how it effects their current game-play. It's great, however I feel we are missing out on some very important discussions about game design as a whole. The process of how you get there is just as important as your final decisions on design. I myself have my own style of going about things, but It leads to roughly the same outcomes. Sometimes even a change in the way you go about designing and the thought processes behind it can lead to things you never knew you could come up with. So, what is your design process like?

I believe there are 3 core things to game design:

1 - Ideation

2 - Organization/Streamlining

3 - Macro-level

I generally tend to do them in whichever order fits the project I'm currently in (knowing fully that am constantly revisiting all 3 until the design is entirely completed and most likely, the project is done).

1 - Ideation, to me, is a lot about finding new ideas for mechanics or content of areas (objectives and functions) I've identified during another phase of design (generally in 3 - Macro-Level).

It is important to me that the very last thing I did before going to bed the day before is anchor that question to my mind, without any expectation (my short-term memory assimilates the problem, and through sleep, I'm able to turn that short-term memory understanding into a mid-term memory grasp).

On the following day, after taking care of whatever else, I reserve some time to do a specific activity that is not intrinsically productive, but that allows me to bring along a piece of paper and a pen. I allow myself to do what it is I do, focusing on it as needed, but I also allow myself to "have ideas" and I let them run their course. Sometimes, this will turn up an idea for whatever I'm trying to achieve. I'll write it down, as a bullet point, not trying to go any further than this (the bullet point should be enough for me to conjure up the idea later when I need to). More often than not, I end up with a piece of paper that lists some questions I'm trying to find an answer to, and a number of lines leading to bullet points on how to solve it (half of which are mere qualifiers, and the other half which are likely questions in the form of "Could this fit here?" or "Would this mechanic solve this sub-problem?"

Watching a new movie or TV series tends to work well here, because it forces me to look at various themes. I tend to make sure that whatever I end up watching has nothing to do with what I'm doing (not watching a space sci-fi tv series if I'm making a space game for example, I'd rather see a serial murderer drama to make sure ideas clash). Some things will stand out and can lead to a lot of "ignitions" in my brain. Preferably, I'll watch this from the living room, not on my computer screen, just so I can get a change of scenery (changing context is a good way to make one's brain creative).

I find that putting my brain in a context of "listening" instead of "thinking" is a good way to relax and let it naturally heal its creative juices. Because of my (human?) nature however, it doesn't take long before thoughts flow in organically.

2 - Organization/Streamlining

This is actually the best part of the work for me. When I know I'll be able to work for an hour uninterrupted, I sit down in front of my monitor, put earphones on and start looking at all these pages of ideation I've been producing. I pick them apart and slowly make a writeup of everything, as organized as possible. If I start to get a bigger idea of how these elements fit together, I draft up this idea, include these elements, and scratch them off the individual sheets.

I do this until I have a document that has a few pages, and nothing left to transcribe from these pages.

Then I start eliminating elements I feel are out of place, not necessary, are good ideas but don't answer one of the objectives, etc.

Oftentimes, the end result looks a lot like a new feature or two that I could implement, or a revised flow or control scheme for example.

This is screen-time at its most epic.

3 - Macro-Level

Once in a while, I gather up all of these streamlined feature documents, and I find a way to integrate them in the greater documentation of the project (GDD, or FDD). I do this perhaps once a week, and flush everything to a new iteration of that GDD (passing from v 1.3 to 1.4 for example). I ask myself a lot of questions, end up killing a lot of features, and generally feel very satisfied by the end result, no matter how much of the information I actually end up using: I like to think of it as a moment where I've killed a lot of questions regardless, and feel that much closer to the end product by doing so.

I tend to do Macro-Level on paper first, by looking at the individual documents I've produced (I print them, and I feel bad about the forest everytime, but it does work better) and once I have laid things out, then I go about making the actual edits directly in the GDD (most likely with a few annotated documents in hands).

I've obviously left out the "laying out the original skeleton" part, but I'll admit I'm not sure how this happens. When I was younger, I've been thinking about so many games that, for the past 10 years, everything has basically been a re-thinking of something I once wanted to do even when the concept doesn't come from me.

I do however have a steady progress towards a finished product. I don't tend to get stuck in the "doubt your creation" loop too long. I do challenge previous ideas when new ideas come in, but most of the time, it ends up with tweaks, not re-design. I'm open to let the idea flow of its own to make sure everything fits, but I'm also very specific about the components I'm missing and this provides me with clearer guidelines for design (and I feel more constraints makes it easier to be creative than the other way around) which limits my ability to go too far off the original intent.

Besides, there's only so much I'm willing to leave up to theoretical design itself, and I value gameplay programming and iterative development too much to spend too much time in design. Once I have a good idea of the general game concept and mechanics, we get to work and see, and tweak. I do my playtests in two different ways:

- Play on my own (at my home if possible, while everything is quiet and I can replicate my gamer experience setup)

- Watch people play (AFTER I've played myself, as I will have questions in mind I need answers to) - This can happen virtually anywhere there's a potential playtester.

(Note: I don't get a lot of free time to program and make assets, so when I actually do something I have to go hard on an idea that's relatively concrete. So the following reflects that process.)

Physically:

I tend to work in plaintext documents, and keep a large backlog of ideas. One thing that's been helpful is having this folder in Dropbox and having a Dropbox-enabled plaintext editor on my phone, because I can add an idea while I'm walking, doing errands, at work, etc.

Setting:

I don't have music or TV on, and I don't tend to get good design ideas (by my definition) while gaming, although I keep an eye out for principles and questions to refine the refining process.

Idea generation:

I try to treat it like this. Abstractly, there's a set of games that I want to exist, but don't. The first task is narrowing down what sort of set that is -- what properties do they have and how do they differ from games that do exist? (For me, I now know that set.) The second task is finding the subset of those games that I, personally, can achieve with my current skillset. Finally, which one of those games maximizes my return on investment?

I tend to think of these games as ones that already exist (in some parallel universe where my games are the norm rather than the exception) and treat the idea generation process as if I'm slowly finding out about those games.

Refining:

Once I have about a page of GDD, I then do tests to try to identify whether the idea is really a rich enough spawning ground of subideas, or whether I'm just fantasizing about a game I want to exist but can't personally think up enough ideas to populate. I have a pretty detailed list of questions I have to ask myself about the game. Coming up with answers to them is what usually deepens, broadens, or sharpens the game, and if I don't have a solid answer, it means the idea is still half-baked and/or I don't really know what game I'm making yet. Like:

• What gives the player the feeling that they're making progress?
• Would the basic actions still be fun if the in-game rewards were taken away?
• What can entice the player to take risks that are outside of their comfort zone?
• Why would anyone want to be the player character? Are they someone interesting, doing something interesting, or going somewhere interesting?
• For each source of randomness in the game, what choices does the player have to offset its effects?

(These questions come from lots of places, but the influence of the Book of Lenses should be obvious.) Questions like that, until I'm satisfied that with the answers. Usually, I'm not, so it's shelved, and then:

and I also browse through my old material to see what seems compatible or like the two ideas might strike interesting sparks off each other.

My school was very different than the one most reading this went too. In my day "game design" was simply thought of as the entertainment side of simulation design, and that you couldn't really do "game design" correctly without understanding real simulation design, which included many disciplines including what was known somewhat vaguely as "scientific modeling". At least this was the philosophy of the "hard core game" type of designers such as those found at Avalon Hill, Task Force Games, and a half-dozen or so other companies of the 1970s-80's. Of course, the majority were not making games that this applied too, so we were always a minority even among our own generation.

The fundamental basis of how we did this was "representing reality". All game and simulation is about representing things within your simulation. And anything can be represented in a simulation. Anything at all. So you can base a simulation, or game, on anything at all. Representation is an aspect of "game design" that is not really a consideration in modern games. Instead you have established ways of representing various common elements that essentially every game re-uses. And because they were never really represented in any sensible way to begin with, you wind up with very a very "flat" dynamic and little variation between wildly different things. Combat systems for land, air, and sea that work identically... even within the same game where they sit side-by-side screaming out "I'm not finished yet, we all work like tanks!!!".

This is far too big of a subject for me to get into while spending almost every spare moment writing for the last 3 weeks, so I will give you a couple of classic exercises from the book that Will Wright read and based his games on. I don't have the book anymore, but I have these simple old exercises memorized. These were scientific modeling exercises intended for you to practice representing the same thing in different ways. So the whole point is actually to see how many different versions of the same thing you can come up with. The basis for doing this is the Needs, Wants, & Desires system that you know from Will Wright's games. So you can think in those terms, or just do this your own way based on your experience and knowledge of how games work.

1: Self Sustenance Village. Recognize this one yet? No? This is Sim City. Design a self sustenance level village. The people need food, water, and shelter. They desire entertainment, religious ceremony, and tradition. The people also want peace, expansion, and protection from outsiders. Base the simulation on the Needs, Wants, & Desires of the people of the village.

2. City Water System. Water must be collected by various means... catch rain, lake/aquifer, reclamation. It must be purified no matter what source it comes from, and then must flow through a single, unbroken pipe system that ends back into the lake. There are 16 city blocks that must be supplied with water through the single snaking pipe system and each block will always take all the water it needs, so the blocks at the end with starve if your system is not working efficiently.

The point is to make the most interesting and dynamic "games" that you can out of this mundane subject matter. The lesson is that story should be irrelevant too you, and that you should know a wide array of ways of representing anything. The more uniquely different versions of these exercises you are able to create through detailed representation, the more you will have learned in the end.

i start with an idea of something that ,might make a cool game. such as a game where you can:

"make a stone knife and take on a sabertooth"

"be the captain of a starship"

"fly a space fighter"

"be a character in a fantasy RPG world"

"be a pirate"

then i determine what mechanics will be required to model the game world in question.

the design doc is typically a one page list of basic game features. the list of basic features leads to a "todo" list - which then drives the entire project. put it on the "todo" list - do it, move it to the "done" list. then on to the next feature.

i typically shy away from story based games - preferring open world simulation and emergent behavior from combos of basic game mechanics. forcing the player to follow a storyline places artificial barriers around them in what could otherwise be an open world simulation. but its ok to place a storyline over a open world simulation. if they stray off the storyline they don't hit any artificial barriers, because the whole world is modeled, not just the bits related to the story.