Solving Problems & Making Games

Solving a problem (especially, I’ve found, in code) goes (or should go) something like this:

1. What is the problem? The problem is X.

2. More importantly, what is the goal? The goal is Y. I find that too often this is missed — a problem exists and everyone wants to solve it, but if you don’t know what the end result will be, how will you know how to get there?

(3.) Do I know how to reach the goal? (‘Do I know how to solve the problem, theoretically?’) If 2. is skipped, this step most often is too. If the answer is ‘no’ then you have two options (neither of which is ‘proceed blindly’):
a. Break the problem into multiple problems that are smaller. Repeat from step 1 for each.
b. Seek new information from any sources you may have at your disposal. If successful, proceed to 4.

4. Go about solving the problem.

This is the way I approach programming, but not most other things. Art and music, to me, are vastly different in that I never, ever know exactly what I want the end result to be, and it bothers the hell out of me. It’s the reason I feel more comfortable coding than I do doing art or music.

But games are the same way, and I absolutely love making them.

Very often, I find that artistic endeavours are not so much driven by being solutions to problems… because they aren’t. Art, music, and games all fall under this umbrella of things that can’t exactly be planned out ahead of time.

Well, okay, games can — at their heart, they’re just programs with a pretty shell. I can’t do things that way, and I can’t make games with makeshift, temporary programmer art (rectangles, boxes). It’s got to come together all together for me and it’s terrible but it’s the only way I can do things.

… is this the dividing line for ‘games as art’? I doubt it, but it’s an interesting thought.

Right. So, I’ve found that anyone who comes at programming without utilizing the above steps is generally very amateur in their approach (blindly writing code, ‘hey hey will this work? yessss (or more frequently noooooo)’) — but maybe I’m mistaken about these creative, artistic things not being able to use these steps at all.

How do you approach ‘logical’ code-like problems? Is it different from the way you approach creative ideas (more applicable if you have, in fact, taken such things to completion, I guess — or have at least started and done a decent amount)?


When coming at any of these things, the process I generally use is

1. What do I want to make? Kind of? (Sometimes I even skip this step.)

2. Make it. Or make something.

3. Does it feel good? Look good? Sound good? Play good? If yes, keep it and maybe advance to 4. If not, go back one or two steps or just give up and wait until the next time I feel like doing something.

4. Elaborate.


About Droqen

Droqen is a game designer/developer/creator/etc. from Toronto, Ontario. View all posts by Droqen

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: