In some ways, I'm a pretty experienced BYOND programmer. In other ways, as is made clear from time to time, I'm an incredible newbie.

After wracking my brains to produce something simple since Wednesday, I've decided that my trouble is actually this: I've been trying to experiment within the confines of BYOND and a text document. Why is that trouble? Because it's an incredibly inefficient method that ultimately serves only to sap one's motivation and kill the project.

While you can just dabble with BYOND and see what you come up with, and maybe be pleasantly surprised with the result, it's better to look at programming as just explaining what you want to the computer. The reason why having a completed design first is necessary is because if you don't know what you really want, you won't know what you're explaining to the computer.

Remember this screenshot? My current development focus is coming back here. If I do what I'm saying here, I've genuinely got a shot to make it happen.

If you don't sweat the details, sooner or later you'll hit a snag where you have to figure them out. Every single game I have failed to produce so far has failed because I hit these "snags." Not knowing what I really want results in a lot of wasted time, perpetually changing my mind, and repeatedly discovering (too late) that what I spent the last few days coding is not going to work. Enough of that, the futility of the endeavor overwhelms me, I give up, and this shouldn't surprise anyone.

I improved upon my earlier process by having what's essentially an open design document. A simple text file that I append to each day in development to order my thoughts. This was an improvement in that it's a whole lot less work to change an idea on the scratch pad than it is in a program in progress. However, this was not enough, it may even have been a complete red herring, partly because it took too long to do all that typing and reviewing, but mostly because I still had not decided what I really wanted.

BYOND is not a scratch pad for ideas, and not even a text document performing the role of a scratch pad is efficient enough, so what is? As of today, I've decided that any and all experimentation is best conducted in the mind. One's brain is an immediately more accessible computer where the realization and testing of ideas can be done relatively instantly compared to any other medium. At most, maybe write down a few mnemonic remainders if I think I'll forget something later, but in the past I've found this can be dangerous. If I run off on a wild tangent based off of some awesome thought that occurred to me before fleshing out the details, as I have in the past, then I am doomed.

"The GUI is the game," as they say, and figuring out exactly how your game looks and how the elements work is one approach towards reaching a complete design. If you can't make it work on paper, it won't be any easier to get it to work on the computer

If you can't touch your keyboard at this phase, what can do you? You're using your brain, so do wherever you need to do to perform your best thinking. I often do my best thinking laying down, which seems awfully lazy, so I'll get up to work on the computer instead. This was a mistake. I need to keep mulling things over until I feel confident that I can mentally play through the game from beginning to end in my head.

At that point, I'm ready to begin trying to frame it in a design document. During the design phase, I will uncover details I missed in my head, and these details are worked out here. If I discover a vital problem here that prevents the project from moving forward, that's excellent: I just saved a ton of time that I would have spent when I hit this snag when coding. Once I've run out of snags, I've just saved the game from an early demise. If I've run into too many snags, I wasn't ready for this phase, go back to the conceptual phase.

When the design document seems finished enough, test it, do a full run through, see if the design works. Only then, after I've set down exactly what I need to do, I've tested it, and (most importantly) I still like it, then I'm ready to make a decision. I have truly decided what I want to do. What I have in my design document should be considered a contract, set in stone, that I know exactly what I am doing and so I'm ready to explain it to the computer.

It's really hard to bring myself to do this, I want to start getting BYOND to realize my games immediately, but I now know that this is a must if I plan to see an epic project through to the end. Simpler projects will fare better without, but even they have their share of mandatory details to work out.

While this was pretty cool at the time, it was also the problem of what happens when you don't incorporate enough abstraction.

"Look, ma, I made me a digital ant farm!"
"That's nice, dear, now how close are you to finishing the game?"
"... further than ever."
The lesson: have a playable game first, then flesh out the details like this.

Having said this, just because you need to realize your game in its finest detail to create it doesn't mean that your game needs to be incredibly detailed.

For example, a lot of my designs call for working power systems that power devices and perform crafting automatically, then put it up to where the players can buy it. That's too detailed - the more elaborate of realization I'm shooting for, the more dragged out the design gets.

Consequently, I need to be willing to start off with an abstraction. To create an abstraction of previous example, simply generate the item spontaneously from a shop. We rarely sweat the details of how the items in the shop came to be.

This doesn't automatically kill what's cool about the game because abstractions are always something that can be fleshed out later. Abstractions are just something that lacks further details, and often the players' imaginations are more than happy to fill in the gap. Once you have a game that can be played from start to end, details can be added wherever you feel appropriate.

It's a fine line: what details do you do now versus what do you save until later? The answer, I currently believe (and reinforced from what other members of the BYOND community are telling me) is you need to have a playable game. If there's something you can't figure out, or that seems too complicated, and it is preventing you from finishing the game, then streamline it into an abstraction. These kinds of details are always something you can build upon later.

I'm probably repeating myself at this point, I suspect I said as much time and time again. However, it's been a few months, I've got 3 weeks off coming up after finals week, and it's a good thing to remember now.