Wednesday, 7 January 2015

Titanomachia: Parametric Design

It's confession time, and the confession I need to make today, my flock of mindless mutton, is that I can't stand GUI user interfaces when editing, and especially when doing layout and design. I would much rather write in what I want, and have the information squirted out as an attractive (and useful) layout. I rather wish that there was a game design program into which I could feed parameters, and out of which came a completed box game which I could then dump out like a demented game reviewer. But those don't exist, and the project remains incomplete because I haven't done the next best thing, which is to do the proper project planning that should be involved in developing something like this.

Firstly there's the hook, which is giant walking battleships, robots so big that they require crews to operate. It's essentially a ship/spaceship, but cooler. I get that giant robots aren't everyone's bag, and that it's an incredible stretch to make them anything less than a complete boondoggle, but then that's why I liked Adeptus Titanicus in the first place: Titans exist because the amount of technology going into them feasible is tantamount to holiness to people in religious awe of high technology.

But the key, and I think this is what the hook points towards, is momentum. In the original Epic: Adeptus Titanicus, and in Warhammer more generally, and in Epic: Space Marine/Titan Legions, a unit's state is defined at the beginning of the turn, affecting what decisions can be made later on, so units that move can't fire certain weapons, or do so at a penalty, where shooting always happens after moving. I think the trick is to break this open from the traditional 40k move/shoot/assault (and more anciently charge, advance, or first fire) but to ensure a lag between turns, or even between rounds of play.

Some notes:

How one plays a bad hand, one feels, should be more important than being dealt a bad hand. Being dealt a bad hand, or having to roll for something to get other things, is "random-input." Random-output means that you need to deal with good and bad results in the next choice. Random-output requires skill in contingency planning. Random-input plus random-output will be taken to equal "Randumb" or the colloquial phrase denoting what certain people consider 'bad' randomness.

This randomness can be contrasted with the combinations that players can otherwise milk out of resource-driven games. The issue I have with resource-driven games is that they're relatively easy to 'solve' though not in the complete sense, but in the sense that they tend to reduce to managing initial resources, and then having the patience to follow through. Games Workshop tries to ameliorate this somewhat by having players manage risk, but again it's easy enough to figure out the strategic parameters and select the optimum tactics for winning, and then blame the dice when they disagree with that win-path.

Part of the issue with this is the interpolation of elements that randomly contract or expand the live options available to players, and elements that randomly affect payoffs, resulting in randumb rather than risk-assessment. A game where one rolls 1D6 to select a threshold and then pays resources for a return on that threshold could be interesting. Likewise a game where one pays resources for 1D6 roll with a certain threshold (manifesting psychic powers in 7th edition 40k). A game where one rolls 1D6 to select a threshold that one must meet on another 1D6 roll is randumb, such as psychic power generation and psychic power manifestation. The issue is not individual mechanics so much as keeping track of how they line up end-to-end, side-by-side, and whatever intersections might crop up.

I think it would probably be best to do what in technical writing is called 'structured writing' where you define a layout, and slot content into that layout, and making sure I keep track of meta-data for each 'node' in the game tree explicated by iterating the resulting network. In a sense it's kind of like building a machine that generates a series of evenly weighted, but differently shaped, trees. Or a spirograph that makes fractals, if that makes any sense.

Finally, I'll point out that I've been generally fiddling with this on the back-burner until I could figure out what exactly I was doing wrong, and why my prototypes kept on blowing up in my face. The first problem was methodological: I needed to do parametric design, and track meta-data as well as the rules, and frankly that's the amount of work that I tend to balk at, preferring the old academic saw: "...that which has been left as an exercise for the student." So time to knuckle down and do work. The second problem was the hook, the thing that makes the game both stand out and makes it an exemplar of its time, which I think is required to make people both enjoy the game and encourage others to try it out, that it has to hook people with game-play that's user-friendly, delivers on expectations raised by the background-skin, and isn't found elsewhere in a more refined game.

Basically, if you're going to reinvent the wheel then it had better do everything a wheel can do in a different way, and easier way, and a way that responds to a need for something better than the wheel. Of course, the only thing that will reinvent the wheel will be cheap anti-gravity, because that will make it accessible, will do away with tires and axles and other wheel-associated stuff that's a hassle. In this case, I think, I want to see if the effect that turns spinning galaxies into spirals makes for an interesting game.

No comments:

Post a Comment

Looking forward to hearing from you!