How do you code games?

Hello there Stencyl users. Today, I want to talk about your concepts of how you code a game, and make it function.

For me. I start off with a really rough codebase that's sloppy, but pretty much works every time. It can cause some bad lag from how horrid it is (I think everyone that has played my works know they have frame-rate issues) I like to call this "baby code". As it's slow like a child's brain, and is also barely developed in terms of mature game coding.

Once the game is 100% done and has been in it's final a play-able state. I start to re-code a ton all of the baby code, and along,  remove all the debugging tools and unused assets and such. In-order to optimize the game so that flash, or even a toaster can run it at 60 FPS (which can be a hard thing to do in actor-filled games that are also fast paced in general)
 
I know this may seem like a bad idea, since starting with proper code is a better idea to boot. But IMO, it's better to start of with something play-able, but laggy. Than having solid code that can  take months of creation after the deadline before having a play-able game.

As Said. Some games can run really smoothly due to insanely optimized code, but can take awhile to make and code around to get the same results on something that be coded easily, but slow on system.

An analogy for this would be making a pipe system that gets to the tap as fast as possible, but also needs to save up on budget limits. You need to plan ideas with very critical thinking at most.

Anyways, I hope you enjoyed the read!

 ~Filler. Whom is working hard in a game himself.

You are on the right path.

This sounds pretty reasonable to me. You could also call this the novel writer's approach, or Nanowrimo approach, since it follows the usual writers' advice of getting an initial manuscript down, then revising.

I can't argue that it's the ideal approach for larger projects, but you'll often find academics (theoretical computer scientists and applied mathematicians) doing something similar. One person thinks of an algorithm, publishes their results, and subsequent research is on improving the method.

My own approach is similar, but I go through more "hand-written" versions--working out the math, processes, etc. on paper. The result is psuedocode. Once I'm happy with it, I code it, then optimize the implementation as much as I can. Writing actual code is tedious, so working on the "baby code", as you call it, on paper first saves time.

If I did a good job planning, by the time the entire game is coded, I won't need to revise much of the actual programming. On the other hand, I may have killed a small forest.

There's a reason things like 1GAM exist: because people try to spit polish the car before its even put together, so to speak. Just write code, and in writing code, you get clearer ideas of what works, what doesn't, and what to do next time. So yeah, keep doing what you're doing.