Tales of the Rampant Coyote

Adventures in Indie Gaming!

Programming, Gear-Shifting, and The Zone

Posted by Rampant Coyote on July 9, 2012

One of the things I need to get better at as an indie is shifting gears. Or, more correctly, task-switching.

As an indie, I don’t have the luxury of specialization, or concentrating on any one task for too long. I have to be agile. I have to wear lots of hats. It gets very, very easy to get comfortable in one task, especially one that takes several days (as a part-time indie who can only work a few hours at night, that describes a lot of my tasks, especially in the early-to-mid stages of a project). When working on Frayed Knights: The Skull of S’makh-Daon, I frequently had to switch between acting as a designer and acting as a programmer. The transition was jarring. I feel I can do an adequate job of both, but it feels like two completely different modes of thought for me.

I’m not sure why that is, though it may be something restricted to making a game like an RPG. I didn’t experience much of that problem in Void War or other past projects where I did contributed to the game design (which was most projects I worked on at SingleTrac). But in those games, much of the design was mathematical and problem solving. Balancing weapon and enemy stats is an easy job for programmer-Jay to handle. But dialogs, visual imagery, or storytelling stuff? I definitely have to shift gears to designer-Jay, and it’s not a trivial switch. Yet.

Even in programmer-Jay mode, it can be a little rough to task-switch. Many times, I’ll be working on a major task, and must spend several days getting it “right” – fixing bugs, making sure all the functionality works, etc. And then, suddenly, everything seems to be working right, and I’m… a little lost. What next? Switching tasks – especially choosing the next task – can be a little rough,  though it’s a critical skill for any software engineer. But I fight the temptation is to linger on the old task and spend some time silver-plating it.

Part of this is a side-effect of a good thing – as a programmer, there’s this magical place some of us call “The Zone” where highly efficient and productive coding exists. The deeper you get into the zone, the more amazing your work becomes. The code is cleaner, faster, and more maintainable. The minutes and hours fly past but you are on such a roll you barely notice it. This is the place you want to be as a programmer. It’s hard to get there, and once there you don’t want to leave. Shifting gears can force an exit from The Zone.

In the past, lists helped me overcome the latter problem. I keep a list of issues, tasks, suggestions, and ideas in a  simple text file that I keep updated with ideas as they come to me. Then, before I begin each night’s development in earnest, I prioritize the new tasks or re-prioritize some old ones, and move some tasks to the top of the list. Then when I’m down in “the zone” and coding away and find myself finished with a task, I don’t have to come up for air too much to jump to the next task, and the next one, on down the list as needed.

That helps when switching between programming tasks.  I need to adhere more firmly to that system, as it’s easy to get lazy about it, particularly in early and mid stages where a lot of what you are doing feels a bit like “tinkering.”

The solution to the former may not be too different – scheduling the tasks so that related ones occur in clusters that allow me to stay in the same “mode” and avoid gear-shifting too much in the course of a single session.  This at least limits the problem.  And I’ve been in the design / writing “zone” before too, although the experience is more rare to me, but arranging times in blocks and setting clear goals for those activities may help.

I wonder what other things I can do to help make that transition better. Maybe I can come up with a musical playlist for each transition, so I can help force some kind of Pavlovian response over time?  Work out some kind of self-hypnotic mantra or visualization exercise I repeat to center my focus?  I don’t know. Goofy as those may sound, something like that may work.

The bottom line is this: I have a lot of games in me that I want to make, so I need to be more efficient about making ’em.

Filed Under: Production, Programming - Comments: 5 Comments to Read

  • Albert1 said,

    This is why I’m a big proponent of level-based design! Not only levels give players a stronger sense of accomplishment, they also lend very well to iterative development. By the way, you tend to suffer creeping featurism, aren’t you?

  • Rampant Coyote said,

    Doesn’t everybody?

    From a code perspective, in order to get the programming done to make a single level 100% playable, you have to write about 80% of the code for the entire game. Unless you do a terrible job of it, I guess.

    The other problem with levels as an iterative process approach is that by the time you’ve completed the final levels of the game (not necessarily the last levels the player will encounter, just the last ones in the dev process), the earliest levels may look like crap by comparison. So iterative still means going back and re-doing what you’ve already done before. I don’t know that being level-based necessarily makes it easier.

  • Albert1 said,

    On 80% of the code I do not completely agree – I mean, I think it must be done anyway. This, in my opinion, is linked to the black triangle story you wrote years ago: so much code must be in place before you even start to make something that simple! You’re right on the crappy-early-levels problem – if the development lasts lot of time, the chances are that by the end you got extremely better at making levels, hence the first levels you made cannot be compared with the last ones. On creeping featurism: I tend to suffer the opposite problem – features are always too many…
    Well, maybe it’s just 1/(creeping featurism) 🙂

  • Anon said,

    The first levels *can* be simpler to provide a learning curve for the player.
    But they shouldn’t *look* bad compared to the rest of the game so that players won’t get discouraged or bored early on.
    IMHO designers should think long and hard about distribution of new stuff in games (level construction, different graphics, plot developments etc.) so that later parts of the game won’t look & feel the same.

  • Cuthalion said,

    Many times, I’ll be working on a major task, and must spend several days getting it “right” – fixing bugs, making sure all the functionality works, etc. And then, suddenly, everything seems to be working right, and I’m… a little lost.