Time, Perspective, Value, Creativity.

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.

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.