Game development analysis-paralysis

[milon]

Experts, noobs, fellow novices, lend me your --ears-- eyes!

I finally figured out why I keep getting stalled on game development: analysis-paralysis of code layout

I come up with a great idea for a game, I start coding it, and all goes well. Until I'm a few systems/mechanisms/etc in, and I start running into ambiguous scenarios. "Hmm, this function draws a bunch of calculated data to the screen. It's kind of a graphics function, and kind of a data function. Where do I put it? How do I organize this?" And either there's no clear place for the function, or no non-hacky way for the function to get all the data it needs to operate. And every time I try to work on it, it feels incredibly awkward and clunky. And so I shelve it until I can mentally reorganize it.

Either I never solve the problem, or I reorganize so many times I'm sick of the project. Or maybe I solve it (hooray!) and immediately hit the same problem in the next chunk of code. There are either too many possibilities or none at all, and I get stuck and can't proceed.

As an aside, I realize that the ambiguity points to poor overall design, but I'm not sure how to correct that either.

How do YOU avoid such analysis-paralysis problems?

[ReFreezed]

Whenever I notice that what I'm writing is a bit sloppy or maybe belongs elsewhere, instead of fixing that issue right away I just add a "cleanup" comment and continue along. Sometimes I even intentionally write sloppy code with the intention of coming back later when I have a better understanding of the problem I'm solving. It's possible I'll remove the code altogether later, or there may not even be a need to change it, even though it's sloppy, so there's no good reason to spend too much time or thought into it when writing it.

It's important not to get too sidetracked when working on something or nothing will ever get done. The way you get better at design and initially constructing a better "code layout" is by getting experience, which you get by doing design and writing code. Or in other words, you have to first make the mistakes to know that they are indeed mistakes. The real problem is that motivation is a (time) limited resource that needs to be refilled, and getting things done sooner, even sloppily, is more motivating than never having anything that works. (And when you have things that work it's easier to go back and fix the "cleanup" places, when you feel like it's time to do so. And if things go poorly you can always return to the working state and still feel ok.)

As an aside, this is one reason I don't like class based languages/code bases as they imply everything related to some functionality belongs in the same class. I literally generally have a file called functions.lua in my projects for miscellaneous functions I don't know where to put (yet, or ever).

So, to summarize: defer any cleanup tasks to later, and don't worry too much about whether what you're writing is good enough at the point of writing it.

[togFox]

I have a functions.lua as well!

I'm extremely results driven and 'player experience' driven. If the code brings something to the player then it's good enough.

If I come back and refactor it later or move it to some other module is a different question and sometimes the answer is 'no - not a good use of my time'.

[milon]

Thanks for the replies!

... in other words, you have to first make the mistakes to know that they are indeed mistakes.

You said a lot of really good things, but for me this was the best part. I have to remind myself that making mistakes is part of the process, and even good (as a learning experience, etc).

[togFox]

I reckon coding is actually about 75% debugging!

[Nikki]

Basically its a rehash of whats been said in this thread already,
What really was pleasant for me to watch was some live streams or youtube videos from Jon Blow (creator of a few very good games)

Its a case of :

- writing simple code that does what you want to happen
- maybe write some --todo comments about cleanup ideas
- sometimes, maybe months or years later, have another look at said code
- then rewrite the function with the new knowledge you now have.
- stay away from class organization stuff

eventually you will learn things you know that will need some kind of architected solution anyway,
some structural things might really bother you and you want to investigate and solve them

but the end goal is the simplest way of achieving what you want, which -in a way- is the best organization too, but focussing on organization does not help you that much from the get go, you need a lot of code to organize not just ideas.

And just to keep it practical; don't worry about some random files that have a few 1000's lines of code, it's no big deal.

[ReFreezed]

What really was pleasant for me to watch was some live streams or youtube videos from Jon Blow

Funny how you mention Jon. He has probably influenced me more than anyone else when it comes to the way I program and think about programming.