I've been playing Age of Wonders Planetfall. Like all the other Age of Wonder games, it's a copy of Civilization. So it's very pretty, and has lots of content, but I've played this game already (it was called Civilization). However, AoW Planetfall has done something sneaky. Its battle system is closer to X-Com. It's turn-based, grid-based, squad-level combat. And that always grabs me.
Now, I've been thinking very hard about game design (as I do). I've been thinking about the game I most like to play (X-Com comes closest), and about the game systems I can develop. And I generally thought I had turn-based, grid-based, squad-level combat figured out. - a grid, implemented as an array (even if it's hexes), with a CanGo() function and A* pathfinding helper functions - a list of units, all the units that exist in the battle - an Action system (and base class) , from which unit actions can be derived - the Move and the Attack Actions, which all units can generate But here's the deal. For a lot of these games, the Move and Basic Attack anims aren't very exciting. For many of these games, the Super Attack (or alt-fire mode, or racial special, or whatever you call it) is the big draw, cause it's so powerful and flashy. Ever see a game called Super Robot Taisen? It's nothing but robots doing super attacks in a turn-based, grid-based, squad-level combat game. When I first saw the breadth of such Super Attacks (implemented in Final Fantasy 7), I naturally assumed that the developer had about 100 artists laboriously make all those attack animations. And that's simply not a resource an indie game dev has. So I've muddled through in the code that I've written, doing the best that I can while understanding that these Super Attacks are time consuming and fiddly to implement. But. What if they weren't? What if there was a different way of thinking about these Super Attacks? What if we just have to see the problem from a different angle? What if we had a Super Attack system, so that we can build the presentation in discreet pieces (the laser beam, the explosion, the lightning crackle, etc), and the system automatically falls into place around these pieces, while combining them in new and interesting ways? Yes, what if. I don't have such a system now. Sorry to get yer hopes up. But I feel it's just out of reach. I can see a lot of pieces lying around, and I bet I can assemble them into a working giant robot. metaphorically. It's not just the presentation, either. Any attack can cause status effects (burning, freezing, charm), hit multiple targets, push targets around (knockback), modify the terrain (smoke cloud), and do other things that are more than just cosmetic. And that code is just as custom and fiddly as the presentation is. I've lately been building a list of status effects, then using that list as a checklist, while I run around the code, implementing the status effects in 10 different places in the code. It feels ad-hoc and dirty. And if I flip the script, making the laser beam presentation, and then letting the rest of the game pick it up and use it, then how can I ensure that the text name of the attack isn't "Slow Missile"? Clearly this isn't a simple idea. It's possible that I'm the one looking at the problem through the wrong lens. In 1997, I went to work on Guardians: Agents of Justice for Microprose/SimTex. They immediately had me working on the game's Super Attacks. They had normal attack Actions, but Steve Barcia was pumping out design docs describing all these different Super Attacks, while blaming others for busting the schedule. So I worked to implement those Super Attacks, while trying to deconstruct them (and find common elements) so each new Super Attack wasn't all new code and art. The work was ultimately quixotic and disappointing, but I tried. And possibly I learned bad lessons from that experience. I don't know. But if I can do this (create a Super Attack meta-system), it will open a big door wide. I've made lots of games that use Super Attacks, and I think I'll continue to do so.
1 Comment
|
Archives |