Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
October 25, 2014
arrowPress Releases
October 25, 2014
PR Newswire
View All
View All     Submit Event





If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
Time, Perspective, Value, Creativity.
by James Hofmann on 11/01/09 05:48:00 pm   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

I've spent about six months now working on an indie game project, all by myself. It is a fairly large scoped game for an individual, and I am trying very hard not to "cheat" on any aspect of its quality. This is the longest I've spent doing a solo effort, and I estimate another two months, at least, from here to something shippable.

Here are my observations:

  • I am never bottlenecked by myself. But at the same time, I'm always bottlenecked by myself! This means that the parts of my process that I optimize are very different from those of a team, because it's no longer as important to minimize bottlenecks across the board. The total time/quality measure is the only thing that matters.
  • I work when motivated. The amount of time I spend "making product" every day is 4-6 hours. Time beyond that usually gets spent "meeting" with myself, writing and fussing with overall concepts. I have rare episodes of crunch, but they are determined mostly by "learning something cool" or "oh, this task is just a mechanical process now (repeat, repeat, repeat)"  and not by scheduling. But as far as production of creative, non-repetitious, intellectually original value goes, I can't force myself beyond those numbers without some external factor driving me.
  • Programming has taken by far the majority of my time thus far. I've done approximately a month of work on story/concept art/assets, vs. five months of code work. If I had made some technical tradeoffs early on, I could have gotten away with some less work on the code, but three major elements were more important in blowing up this number:
  • First, the real schedule of this game is determined by personal finances. Thus, since I estimated that I could go well past the end of the year without trouble, I'm pretty sure I subconsciously planned to let things stay at an early stage longer than I "really" intended - I would write up plans like "oh, I'll have the tools done in July, and then I'll spend X hours per scene in September and I'll ship by November." And I didn't go through with that at all - besides having interesting code tasks to solve, I was still uncertain about what I would put in each scene. So I didn't have any pressure to deliver, on a specific time or date, some set of features to start building content on, because the content was still indeterminate.
  • Second, saying to myself, "this architecture isn't going to do what I want in production, it'll have too many bugs, it'll be too hard to iterate the design with, and I have this great idea that will shrink the amount of code I'm writing by another 5%." If I had to rewrite the engine and tools now, it'd take under six weeks, because I was learning new things and developing the concepts the rest of the time I coded. Another factor was that I was deathly afraid of building up some untamable software monster - I wanted to get things right before going past pre-production data. (Very different mindset from the "game in a day/game in a week" attitude I've used previously in solo work, where things can be slapdash because you know in advance that you won't build anything particularly complex on top of it. Also different from "the publisher expects a build at the end of the week and it must have these I's dotted and T's crossed," which, at least from the designer-side viewpoint I've seen that from, means stretching out my workday into a massive crunch so that I can push through the sheer uncertainty of how to proceed. )
  • Third, organizing the tools and pipeline so that design data is flexible. The designer-side experience flows from these elements: a bad tool, or inflexible means of accessing and changing data, can result in hours of soul-crushing repetition and lessened will to make interesting layouts and interactions. I made three major iterations over this process because the previous two had terrifying aspects to them(terrifying as in, I could easily end up in the soul-crush situation if I made a mistake, and I wouldn't know it until after I had generated tons of data.) The specific data model I ended up with was based on a Python-native embedded database, buzhug. My previous attempts involved ad-hoc data formats(downside: no introspection outside of the tool) and JSON-based formats(downside: difficult to describe relationships in) The database approach gives me some key features for data flexibility - queries, relational data, serialization. One thing that has gone missing is tight engine integration, but overall, I don't value that as much as the flexible data.

Now, while I did all this work on the code side, I was still keeping my eye on the game and how to make it a better game, and I did these things:

  • Wrote the story and rewrote and rewrote it, in bits and pieces. Each time I started "from scratch," not looking at my old work, just remembering the good parts from the last time. With each retelling I incorporated a different idea, so over time my conception of how the story flowed got more detailed and nuanced, and the characters got more multi-dimensional and believable.
  • Iterated over approaches to art and did some tests. From the beginning I knew that the gameplay sprites would use 3D prerenders, and character art(which only appears during in-game dialogues) would use 2D vector drawings traced over 3D mannequins. I'm fortunately doing a vehicle-oriented game, so character animation is limited to rotating my ships a little bit. But I was concerned about keeping things easy to iterate over, and the 3D, at least, seems to work well for that - I can mix-and-match materials, lighting, models, and compositing so that look and feel remains consistent even when one part changes. The 2D I haven't completely tested yet, but the preliminary attempts make me guess that it'll work adequately for my level of drawing skill. I keep coming up with more detailed ideas for the look of the characters - palettes and costuming and all that. They might even be overworked at this point. In any case, I was able to bring my art concepts from vague "this ship is the player's ship" platitudes to more specific ones about shape, color, styling and theming.
  • Thought of increasingly detailed design ideas. Coming into this, I already had some prototypes to work from, but the difference between prototype/demo content and "polished" content is a subtle one; a game under schedule pressure will employ assembly-line level design, finding a handful of level features that work for a demo or vertical slice, and then repeating them everywhere. Taking things to the next level and giving the gameplay itself a progression over a multi-hour experience, and not just the look of the environments, takes a hell of a lot more work. I ultimately decided to split up the game into three episodes - partially because I really wanted to ship something now and not in another six months, but also to combat the mental fog that came with trying to envision this sort of broad variation - instead of six "chapters" that are vastly different, I could focus my attention on two chapters at a time, stick to a few common elements for the two chapters, and iterate fractally over the design from there, concieving of it in smaller and smaller chunks. By this time my story had become detailed enough to support such a split, which was a concern when I first considered going episodic - I didn't want to spread things thin.
In conclusion, the net result of these six months is that I've been able to fill in a lot of blanks that, had I been "building to ship" from day one, would have gone unaddressed or filled by generic placeholders...and I think the game is going to be a lot better as a result. This wouldn't have happened in the same way working with more people - more people would have been able to bring more ideas to the table at any one meeting, but the key to my own progress was in being able to continuously reevaluate the whole game every day and say "Today I am interested in ----" with a different thought of what I'm interested in each time. And at the end of those evaluations I could make sweeping changes that would have blown away a schedule based on task parallelization; the changes affected things that hadn't been built yet or had only been experimented with a little bit, so the cost of change was low at every step.

The main downside, I think, is that this is a very lonely work process. That can really eat at you after a while, and if you aren't careful it lets you get lost in the details of something that won't ever deliver value. I'm sure I've wasted a lot of time, too!

Related Jobs

Forio
Forio — San Francisco, California, United States
[10.24.14]

Project Manager / Producer (Games)
Yoh
Yoh — Vancouver, British Columbia, Canada
[10.24.14]

Build & Test Engineer
Infinity Ward / Activision
Infinity Ward / Activision — Woodland Hills, California, United States
[10.23.14]

Senior Sound Designer - Infinity Ward
Treyarch / Activision
Treyarch / Activision — Santa Monica, California, United States
[10.23.14]

Multiplayer Level Designer - Treyarch






Comments


Alexander Bruce
profile image
This was an interesting read, mainly because I've been going through the same thing for months (and shall continue doing for several more months until release now). Ultimately, as you say, working by yourself is indeed a lonely process, and the only roadblock is yourself. If you can't work something out, it doesn't get done until you can.



It does allow for creative freedom, and I certainly wouldn't have the same kind of game at all if I had someone else working with me telling me I was crazy, but there are certainly many times spent thinking about whether or not you get someone else on board, because it's also a huge learning effort. Anything that you don't know, you have to learn.

Harold Myles
profile image
I enjoyed this post.



I think its wise to abandon the 'game in day/week' mentality. If you get into the mindset of writing reusable, maintainable code, then hopefully you will, and all the time you've 'wasted' will spill over to future projects. Of course it has to be balanced, and in the end its better to actually get something complete rather than fuss about code design, but I think its worth it. Especially working solo, due to the high chance of not completing the project, if you at least wrote some code that would be usable and understandable in a years time on a different project, then at you've accomplished something.



Anyway, thanks for the post and good luck.

Glenn Storm
profile image
Thank you, James. This touches on many aspects of development in a very personal way. Having been both an independent contractor and a member of teams (big, small and in-between), I can affirm the solo work is lonely, and the dangers you describe are real; even the ones you didn't specifically call out as dangers, like alternating between being mired in technical aspects and creative aspects; shifting gears, sometimes sans clutch. A one-man-band is interesting to watch, incredibly difficult to pull off. That's not to say that one shouldn't try, not at all. I believe that the solo developer is able to overcome some of the hardest aspects of development as compared to a team; namely effective communication, clear goals/vision and trust.



What keeps me leaning toward group efforts is the idea (or ideal) that when assembled properly, when utilized effectively, groups can be something like a well-orchestrated one-man-band ensemble; where each individual is tackling a range of tasks according to interest and motivation, but where the group as a whole moves as a single entity, toward a unified goal and with grace. Groups have the potential to do much more than the sum of its individual's efforts; i.e. Great Groups, but here again, this is difficult to pull off. My current studies are aimed at making this easier.



This account of your experience is being filed away for use later. Thanks again, James. :)

Edward Williams
profile image
What a great article. Tell me, what was your motivation behind taking on a project of such scale on your own? I have to admire that; I'm a newbie in software development (still in school), and I can't even begin to imagine having to oversee every aspect of creating a game completely on your own. Kudos!



E.A.W.


none
 
Comment: