Monday, June 18, 2012
Tuesday, June 12, 2012
All The Things I Did Wrong
I'm entering a new paradigm now. I'm going to work differently, I'm going to work better.
This post's service is twofold: First, to publicly reflect on my past mistakes, with the hope of benefiting others in some way, Second, to solidify my transition.
1. I worked ambiguously
Instead of planning things out solidly, I would rush in sloppily, basing my work on an ambiguous idea, aided only by fragments of ideas nilly-willy stitched together by my vague memories of past enjoyments. I would work and become frustrated at my piecemeal results and try to redo things, getting out my tape and glue to try to force things to be cohesive. It just didn't work.
2. Overdesign
This was a direct result of problem #1. Prodded on by cautious notions, I completely overdesigned everything--I set out to program such broad, expansive, extensive systems that I could cram any possible mechanic or feature that I *might* have wanted into the game. I didn't design my programmatic needs beforehand, so I overdesigned to compensate. The result of this was an incredibly bulky, painful architecture to work with every time. This was almost always the one ultimate demotivator that lead to the death of my projects. Developing my game and implementing new content became such a chore that I just wouldn't be able to take it any more.
3. No focus
Remarkably similar to my previous points and often a result of them, my design thematics and mythos often had no focus. There was nothing to unify or solidify them in aesthetic, narrative, or anything else style-wise. The lack of unity made the game feel messy, uninspired, empty, and quite frankly amateur.
4. Lazy, sluggish, negligence
Rather than tackling big things head on, working intelligently and pragmatically, overcoming the learning hurdles in front of me, and so on, I would all too often half-ass a problem and continue with a defunct solution. As only one instance of many, instead of making tools to aid my workflow I would just "tough it out" and go the long way because making tools felt boring and cumbersome. No longer, though. It's a necessary part of the process, and now I'm of a mindset that "it's all gravy".
5. I held myself to relative standards
Instead of considering my work in the broader scope, I would often goad myself by comparing it to my own previous works and to those of my associates as what I believe was a form of desperate self-validation. But by holding myself to lower standards I achieved far lower and limited my vision.
Cheers to a fresh approach.
P.S.
I was only able to make myself jump this cusp after watching "Indie Game: The Movie"--That was an incredible, eye-opening experience for me.
This post's service is twofold: First, to publicly reflect on my past mistakes, with the hope of benefiting others in some way, Second, to solidify my transition.
1. I worked ambiguously
Instead of planning things out solidly, I would rush in sloppily, basing my work on an ambiguous idea, aided only by fragments of ideas nilly-willy stitched together by my vague memories of past enjoyments. I would work and become frustrated at my piecemeal results and try to redo things, getting out my tape and glue to try to force things to be cohesive. It just didn't work.
2. Overdesign
This was a direct result of problem #1. Prodded on by cautious notions, I completely overdesigned everything--I set out to program such broad, expansive, extensive systems that I could cram any possible mechanic or feature that I *might* have wanted into the game. I didn't design my programmatic needs beforehand, so I overdesigned to compensate. The result of this was an incredibly bulky, painful architecture to work with every time. This was almost always the one ultimate demotivator that lead to the death of my projects. Developing my game and implementing new content became such a chore that I just wouldn't be able to take it any more.
3. No focus
Remarkably similar to my previous points and often a result of them, my design thematics and mythos often had no focus. There was nothing to unify or solidify them in aesthetic, narrative, or anything else style-wise. The lack of unity made the game feel messy, uninspired, empty, and quite frankly amateur.
4. Lazy, sluggish, negligence
Rather than tackling big things head on, working intelligently and pragmatically, overcoming the learning hurdles in front of me, and so on, I would all too often half-ass a problem and continue with a defunct solution. As only one instance of many, instead of making tools to aid my workflow I would just "tough it out" and go the long way because making tools felt boring and cumbersome. No longer, though. It's a necessary part of the process, and now I'm of a mindset that "it's all gravy".
5. I held myself to relative standards
Instead of considering my work in the broader scope, I would often goad myself by comparing it to my own previous works and to those of my associates as what I believe was a form of desperate self-validation. But by holding myself to lower standards I achieved far lower and limited my vision.
Cheers to a fresh approach.
P.S.
I was only able to make myself jump this cusp after watching "Indie Game: The Movie"--That was an incredible, eye-opening experience for me.
Monday, June 11, 2012
Monday, May 28, 2012
Game Design: Pacing
Pacing is something we all understand very intuitively, it's the rhythm by which we snap our fingers and tap our feet to the beat, jostling in our seats. It goes deeper though, and today I want to ponderously explore what that is and what it means. I'm going to approach this with an emphasis on interaction design, taking feedback loops and whatnot into consideration.
The first element of analysis is to consider rhythm. With rhythm, you expect the recurrence of a pattern in consistent intervals. So in other words, pacing is defined by "what you expect to come next".
In concrete terms, let's consider a typical puzzle game flow. You begin a level and are introduced a new mechanic. The puzzle with this mechanic is simple and flexible. The level is short. In the next level, the difficulty ramps up a bit, continuing until the pattern repeats and another mechanic is introduced. A sense of pace and flow is created by the repetition of the pattern by which new mechanics are introduced to the player. What if the third mechanic was introduced without any easing in of difficulty, and the player simply couldn't solve the puzzle?
The first element of analysis is to consider rhythm. With rhythm, you expect the recurrence of a pattern in consistent intervals. So in other words, pacing is defined by "what you expect to come next".
In concrete terms, let's consider a typical puzzle game flow. You begin a level and are introduced a new mechanic. The puzzle with this mechanic is simple and flexible. The level is short. In the next level, the difficulty ramps up a bit, continuing until the pattern repeats and another mechanic is introduced. A sense of pace and flow is created by the repetition of the pattern by which new mechanics are introduced to the player. What if the third mechanic was introduced without any easing in of difficulty, and the player simply couldn't solve the puzzle?
Thursday, May 17, 2012
Hive? Some logo design
 |
| Click to lightbox this! |
Also, my box art commission was completed last friday, I might post it later on. Yay.
So am I a game designer or a graphic designer? The correct answer is "neither"! Why limit myself to a single designation? Muahaha!
Subscribe to:
Posts (Atom)