JayIsGames Contest: I am So In
Yeah, I had posted earlier that I would be participating in the JayIsGames IF contest (over here), but it’s taken all that time for me to come up with a good idea. Yeah, a one-room contest with the theme of escape is not as easy to do as I thought, but I prevailed and will unleash my game! Mhu hah hah! I also came up with some other cool ideas that had a small number of rooms but didn’t really fit the theme, and at least one really cool idea that fit the number of rooms requirement, but wouldn’t hit the T rating. Think lots of blood, not perviness.
And oh, the name of the game? Zegrothenus. Repeat the word slowly over and over, as in sentences like this one: Zegrothenus will totally destroy in ’10! Zegrothenus owns your free time. Zegrothenus…well, you get the idea.
And why did I decide to enter a contest, given my feelings on contests? Two answers: this contest features real prizes and it’s not held by the insular IF community. The former is nice to have, and the latter makes all the difference in the world.
I am SO in.
Collapsing Complexity
I’ve been pondering something lately, as to how complex designs tend to resolve into simpler forms over time. While the human mind does have an upper limit on the amount of complexity it can accept, it’s not that I’m getting stupider as I work on Seasons. It’s not that I’m getting lazier, either; it’s that looking at the code, I can see not only that some functionality just is not necessary (see here), but that what needs to be done can be done in a less convoluted fashion.
The complexity of any coding project generally follows the life-cycle of a star. As a star is born, grows into a red giant, and then collapses into a dwarf star, so a project’s complexity starts low, rises to high, and then abates to some degree or another. I think many programmers do not spend enough time on their projects, and release them before the final stage is reached. As a result bugs and worldview inconsistencies abound.
If you look at many commercial projects, you’ll find the programmers figuratively out of breath and celebrating as they cross the finish line: the code has been delivered by the deadline! Yes, the project works (mostly), the date has been hit (so management gets their bonuses), but the application is simply not as good as it could be; it is still a red giant. When you have to patch or extend the code, or support the project, you end up spending an inordinate amount of time making it work or explaining it because it is still overly complex.
In IF, the support staff is usually the author, so what happens? Either the game is a buggy junk pile and further releases must be created to fix problems, or the author abandons the game and decides not to fix the problems at all. The end result is a game that’s not as good as it could be.
The only thing that allows us to reach that final stage is the passage of time. Apparently the mind needs enough time to analyze the deeper patterns in something fashioned, or repeated exposure yields up the glaring complexities; most likely it is both. Both writing and IF design must be “edited cold” or otherwise they are not mature. I think of the stage of maturation as an aged wine; you can drink wines before their time, but you miss the experience of a good wine. Incidentally, this is why Speed IF almost always produces a horrible game.
So in short, a good motto for IF designers (and programmers as a whole) would be to release no project before its time. Let it reach full bloom and then unfold that beauty to the world.
Failing By Over-design
I’ve since forgotten where, but I read an article about designing electronic gadgets that plumbed Apple’s design methodology. What they concluded was profound: most electronic gadgets are over-designed. They have too many features and as a result instead of doing one thing (or a few) things well, they do many things with brilliant mediocrity. This state of woe is not exclusive to such gear, of course; for years, mid-fi has suffered from what my dad once termed “buttonitis” — a superabundance of buttons, whose nature tried to convince potential buyers of its functionality, instead of playing music well. With overdesigned products, quality suffers, complexity increases, customer satisfaction goes out the window, and customer loyalty is nonexistent.
IF is the same way. You can create a huge stinking mess of fail by over-designing your game. Take for instance, Seasons. In one of the seasons, there is a barn populated by barn cats. These cats are not critical to the plot, but are just present to add to the realism of the game. Despite that, I was determined to create a class Cat that could automatically create cats as needed, make each cat have a unique description (well, uniquely-selected from an array of descriptions), have the cats do different things every so often, move them around, and so forth. I was even working on a way to have the cats referred to as “a/an” if more than one cat was in a room at the same time; otherwise, the cat would be referred to as “the” cat. Overdesigned? Whoo yeah.
It’s more important to have minor things do their job well as minor things than to spend days of work making them nearly simulationist. Audiences will appreciate nice accents of color (which is what the cats really are supposed to be) but won’t be impressed if scenery can do interesting things when the rest of the game works half-well. When you think about it, you only have so much time to make a game, create the help, distribute it, and gin up interest in it. Do you really want your game to be years late to the market because you had to code an imp statue that could act out lines from every play of Shakespeare’s?
