Sprinting to the finish line...

I'd like to briefly share this concept that's come up time and time again in development for me.

When I first got into game development 12 years ago in my teen years, I had wanted to be a professional composer, so much so that I had this ambition to be the greatest composer that had ever lived. I wanted to create music that would deeply effect a great number of people basically.

As I took on projects, RPG Maker 2000 projects at the time, I realized this trend that the creators of the games wouldn't take their projects seriously enough, and they certainly wouldn't care about creating music that influenced the project. My solution became at the time, that if I wanted to compose music for the projects of my dreams, I would have to create those projects myself from the ground up.

As I started on the journey of creating my own projects, though, I came across another problem. Creators would almost always come to a state of about 90% completion and then after that never release their work. They would have workable demos, trailers, all of that, but they would never be released.

Now there are a couple obvious ideas that crop up as to why this is, like losing interest or inspiration or fear of releasing, or just that not enough people would play it as the creator would want in the first place, but I'd like to talk about one of the reasons in my own experience that I've come across, and that is: underestimating scope, and then going into a sprint, burning oneself out and thusly burning out their inspiration because they feel that the finish line is closer than it actually is.

Sprinting (or 'crunching), and the fact that underestimating the time it takes will make you believe you're near the finish line, so you have this tendency to then set your gears into a sprint to try to reach it as soon as possible.

This has been a very rough thing for me to learn...because I have one of those high energy do or die personalities in where if I'm at the finish line I'll want to put myself into a mode of insanely fast 20 hour days and rush to reach it asap for that feeling of having something that's complete, that sigh of relief "aaahhh, finally!" feeling that's had after you hit a big checkpoint. My first choice before being a programmer or composer, when I was 13, was to be a professional tennis player, and this kind of do or die mindset actually helped out quite a lot at the time, and maybe I brought this same intensity to my life sitting at a computer.

For people like myself, this is extremely discouraging when you're first learning what debugging is actually like. What's debugging a big project like? Basically you grab a list of bugs, you say to yourself "Hey, if I just crunch these ones, I'll move on to the next phase and have basically either a finished product, or very close to it!". So, you end up doing just that, and then when all of those bugs are crunched down, guess what happens? Another list, just as big as the last one crops up, if not bigger. So, you repeat the process and say the same thing to yourself, looking for that sigh of relief, but those sighs of relief are short lived as you just hit the next round of bugs...and you wonder why these days with the higher and faster demand of consumers these companies are using early access tactics.

I've learned that this is why experience is extremely important in working on projects. Designing a video game is designing a piece of software, and since it falls into the category of 'entertainment' I think so many of us get caught off guard at just how different it is than to for example making a movie. A lot of amateur developers get into designing their dream projects without understanding that a computer wasn't originally designed in and of itself to do what we're getting it to do, so in a sense it's like trying to get this animal to cooperate that doesn't want to do what you want it to do. It sounds cruel, but there's a sense of restraining it and taming it to do what you want it to do, and this all takes quite a lot more time than you would first suppose.

You're going to have tons and tons of bugs, and debugging can take a very very very very long time, WAY longer than you will think.

Being inexperienced, when you get to this phase you're going to look at your project and think to yourself that it's inadequate, you may even want to start over in this phase of development, which is a huge mistake. You're going to have something where characters turn all jagged, where their animations don't do what you want them to do, where they fall through floors or go halfway through walls, you're going to have (this is a huge one) transition problems from one scene to the next, you're going to have data problems in where two values aren't appropriately named, you're going to have problems in where events aren't triggered off that are supposed to be triggered off, you're going to have problems in where there's just this itsy bitsy little blink of a flash or stuttering and you can't figure out what's causing it for hours on end, all kinds of things that you have to deal with either head on or (hopefully not needing to) finding workarounds.

This is where you absolutely need to not get discouraged, but sometimes kick it into lower gear and absolutely not sprint. Just treat development at this stage like it's business as usual, go about your design just like you would any other day, and as rough as it is, when you find a bug that breaks your project, it will test your confidence in yourself.

With debugging there's a problem of perception. You will see software that you think is fairly complete and yet more bugs will crop up, and some of them will be extremely technical and require you to re-think how you wrote and/or organized large portions of your code.

You have to have a mindset that you're far from complete, even when the field of landmines looks like you could just cross easily from one side to the next. It seems like it's close, and yet it's so much farther than you think.

For anyone reading this that is using games also as a means of telling stories, I would highly highly recommend to just use one of the tools out there to make narrated visual novels like RPG Maker, or Ren'Py or use a fully finished Unity project if you can find one and work from there.

 

Yes, I think your analysis is pretty much correct. But there's an even deeper level of truth here.

Software artifacts (i.e. games and other programs), in terms of the number of unique parts, are the most complex artifacts ever created by mankind. A building may have hundreds of thousands of parts, but mostly it's a much smaller number of parts used over and over. There are only a couple kinds of nails used, one kind of 2x4 (parameterized to different lengths), etc. But a software program has hundreds of thousands of unique lines of code; if they weren't unique, we would have factored them into a method (per the Don't Repeat Yourself) principle.

All that is to say, software's complex. Bugs happen.

But here's the real kicker. When an experienced developer goes to fix a bug, very often they make things worse. Their understanding of the bug (or the rest of the software) is incomplete, or their unit tests are inadequate so they're afraid to refactor when they should, so they add code to patch around the problem. (Indeed this is a common pattern — junior developers fix bugs by adding code; experienced developers more often fix bugs by removing code.) But now the software is even more complex and brittle than it was before, so the next bug is that much harder to fix. It's a slow boil, but the end result is, big software projects written by inexperienced developers usually become more and more of a mess. The quality goes down over time instead of up. Eventually they can't fix anything without literally introducing more bugs than they just fixed, and the project collapses under its own weight.

This isn't the junior developer's fault. This stuff is hard, and doing it well takes years of experience. But I think many people don't fully understand that. I wouldn't expect to watch a few videos on playing the violin, practice a couple weeks, and then create the beautiful music of my dreams. Yet many people think they can do exactly that when it comes to writing software.

On the other hand, just like creating music, creating clean, elegant, maintainable code is a form of art that is deeply satisfying. And just because you may never be Mozart doesn't mean you shouldn't plunk around on a piano. Do it! You will get better with every failure, and build a skill you will treasure your entire life.

On the other hand, if you just have a story to tell, and there is an off-the-shelf package that lets you tell it — then I agree, that's almost certainly the most efficient and reliable way to get the job done.

 

Great write up. Solid advice.

I know it's true, even though I'm no programmer, because I can tell the same story from other fields. That's when you know there is some universal nugget of truth there.

For me, the big take away is humility. After you sprint your ass off only to realize this wild effort has only got you deeper into a pit of kaka, without a shred of hope or dignity left, that's when the real adventure begins. And real adventures always go on much, much longer than you ever want. And they aren't fun. They suck -- big time.

I think you hit the nail on the head about the need to NOT sprint. Keep the emotions in check, put the head down and just grind on in low gear. "This is just my life," is a mantra that got me through times when I otherwise just wanted to sit down and die. It's not about fighting against all odds, it's about submitting to the way things are.

When you come out at last, probably just by luck and determination, you know that the key to doing things right is avoiding getting lost like that in the first place. Which means planning with your own ignorance as the chief obstacle to be avoided.

Really appreciate you taking the time to share this. I dunno if stuff like this ever really saves the newcomer any trouble, but at least by seeing it once, then when they come to the same place it may help them sort things out, or realize, "oh, I'm not a fool. Other people have been here before me."

 

I agree with every sentiment here.

There was a time when I had very ambitious ideas. I still have them to some extent but with my partners and I's new project I've realized that it is very important to reign in the scope of your project.

A clear and focused well executed project is much better than one that tries to do every feature the devs dream up, and fails at the entire process.

Dreams and ambition have their place. Yet game dev is a business in many cases. You cannot tie all your hopes and dreams into one project, because when you inevitably fail or give up it will hurt at a deep level.

Play the long game.

 

The problem is that many people dont actually rush at the end but through the whole developing cycle:
"I fix this bug later - first i want to progress the game and do this feature"
This results into "ton of bugs" at the end.
I actually think that every bug which affects the core gameplay and technical side should be fixed immediately.
Bugs which only affects for example visible aspects like a shader looking strange or character head flying above bodies (Fallout 3;-) can be perhaps postponed. Also in Witcher wild hunt there where many bugs affecting the horse but not really affecting the core gameplay (Who cares if the horse stands on a roof)...

So by not rushing i would say take your time to fix the bugs not only at the end but everyday your working on a game!

 

They are not actually at 90% though. Polishing a rough but good looking and playable game can easily take as long as all the work put into it so far, and without much progress seen for the efforts. Building your attack mechanic feels like you got a lot done, but it can take just as much effort to clean up several UI pages with no change in functionality. So it feels like progress slows down a lot in the last 90%. But that is because you're not at 90%, you're at 50%.

 

I think what astracat may have been getting at is a certain phenomena of the emotions which happens when you have worked on something a long time, put a lot of effort into, and it very much a reflection of your personality; and when it comes time to release, fear takes hold and starts springing up all kinds of excuses to protect you from failure and judgement.

"Oh, I just need to polish this" "It's not good enough yet," "Nobody's gonna like this," "I just need more time/money...."

I say, if you do not have a proven track record of finishing tough jobs -- enough to trust yourself beyond a shadow of a doubt, first order of business is building that trust. This means finishing is highest priority. Higher than quality, higher htan artistic vision, higher than fear of making a fool of oneself....

Imagine you are a primitive person. You got to hunt to feed your family. You go out for a moose. Seven days in the bush and you find no moose. Only a den of squirrels. You gonna go back with nothing and starve your kids, or deliver some stinkin squirrels? What would be more shameful? People will make fun of the mighty squirrel hunter, for sure, but you can grab them by the throat and growl, "don't bite the hand that feeds, beeeeeyoootch."

There is times to bail out for sure... but it's a very dangerous habit that shouldn't be practiced by anyone who doesn't fully understand the value of determination.