Lesson Negative Infinity: "Always have a plan. Always."

The hippie "agile guru" professors you learned from weren't entirely wrong. But you need a plan. Be a Boy Scout. Be prepared.

I don't know if they still do this, but back when I was in school, around 2005 or so, "agile" was all the rage, and they absolutely shoved it in our faces. "Waterfall is evil!" they'd tell us. "You need to use an iterative design workflow!"

Well... they weren't actually wrong. They just left out one important part. Or at least left it for the last minute... You see, even if you're doing agile programming, you need a design document. Plan ahead everything you want in your game or your app or whatever. Doesn't need to be in excruciating detail, just give an outline of the major features and a summary of how you plan to implement each of them.

OK, good. Now you have a design document. Next thing is, you need to have it reviewed. If you worked on the doc with a few oher people, you can probably skip this step. The idea is, though, that you almost certainly missed something, because you have only one brain and you're not telepathic. Get it reviewed, take suggestions, and as the Bible says, "test everything, retain what is good". You never thought the Bible would have advice on software development, did you? ;) You may also wish to brainstorm "in what way could such and such feature go wrong, and what could I do to mitigate it?" for your most critical features.

Now you have a solid design document. You should be able to start development of your project now and have a much improved chance of success compared to if you didn't plan at all. But this doesn't have to be the waterfall method! Every so often, take a break. Review your principles. Are you keeping in line with them? Do they need to adapt to what you are discovering about the realities of working on this project? Edit your design document to reflect these discoveries. Then pick up again and start from where you left off.

Guess what? This is still agile! Agile development does not preclude having a plan. What makes it "agile" is willingness to adapt. Sadly this is not always taught right away, so students may get a mistaken impression of the philosophy.

Lesson 1: "When you start making up words like 'senates', you know you have a problem with an overcomplicated game design doc. Wait, is 'overcomplicated' even a word?"

So, "senates". It probably is a word, but if you're trying to cram it into a design document for an "elegant" 4X game... then you know you've gone too far.

Why did I even go that far? Well, I really liked the idea of having a galactic senate, but then I also thought it would be cool if there could be more than one of them. It always seemed unrealistic that communication could somehow occur between empires that had never even met each other! So I fleshed this idea out pretty well, just to see if it would be feasible, but it turned out that it was way too much for my game. At this point I scrapped the entire senate idea, deciding even a basic senate was too complicated as well.

Lesson 2: "When you're designing an 'elegant' 4X, you should not add game mechanics that belong in the next iteration of Crusader Kings."

This also comes from the "senates" debacle. How much time did I waste designing that mechanic?!

I was adding all sorts of insane stuff in there like charter rules and presidential ousters! I truly wanted to reinvent the completely broken "alliance" mechanic from SE5, but sadly this just isn't the game to put it in. That's why I've got the archive (linked below) - I might use it in some future game, or you may wish to do so yourself! (Just remember to credit whoever created the idea; we should be listing our names in there!)

Lesson 3: "If it doesn't add anything to the game besides some minor measure of realism, and requires a lot of mental and/or programming effort to implement, it’s almost certainly not worth it."

Units of measurement. Why do I always fall into that trap? I like realism, but does anyone really care?

So obviously ship masses are measured in tons, and sizes in meters, and galactic distances in lightyears, right? Simple enough.

But what if you want to start getting fancy with your units? Some units are based around grams, and others around kilograms, and I'm trying to base mine around tons... the prefixes are all wrong when you combine them! Kilo times kilo equals giga?! And what if you want to make up entirely new units for which there is no established standard? Say, stealth?

So what I finally decided to do, at the behest of my good friend Nick (Suicide Junkie), is simply drop all the units and refer to everything by raw numbers. After all, a lot of games do that, and who really cares? You add your own units mentally. They don't have to match 100%; a "year" is SE4 is made up of only 10 "months"! But it's close enough. Now this is not to say I won't be using k and M and G (or B?) and all those nice suffixes! They'll just not go with any units of measurement. So your ship's mass will be 25k, not 25kT. Simple convenience to avoid having to count a bunch of digits to get the magnitude. Like scientific notation but more human friendly!

Lesson 4: "When designing a game mechanic, keep in mind the design philosophy of all parts of that mechanic, and throw out any that don't match some common design philosophy you actually want to use."

That's a bit cryptic... what does it mean? Well, basically it means that your game mechanics must be internally consistent (philosophically speaking) and consistent with your game design as a whole.

So I had added a diminishing returns attribute to the construction mechanic. Shipyards build at some particular rate of "complexity". But the time to build something isn't simply its complexity divided by the queue's speed. Instead there are diminishing returns based on triangular numbers. For instance, anything less than or equal to the queue's speed builds in 1 turn. But then it takes 3 turns to build something twice as complex, and 6 turns for something 3 times as complex, and so on. (Naturally, you can get intermediate numbers too - you can build something that's 1.5x as complex as the queue's speed in 2 turns, for instance.)

All right, that's all well and good. (Though I might even scrap that mechanic for being too complex; who knows?) But then I wanted to add fractional build times, so you can build several really cheap things all at once. Why is this a bad idea with diminishing returns?

Well, the purpose of fractional build times is to avoid "magic thresholds" and minmaxing. But one of the primary effects of my diminishing returns mechanic is to add those very same magic thresholds! It's not ideal, but it works; I had other reasons for the diminishing returns. I briefly considered combining the two and having some sort of floating thresholds (i.e. formulas), but immediately dismissed it as way too confusing for players. And that's when it hit me... don't try to shoehorn in diametrically opposite components into a mechanic!