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.
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.
A couple summers ago, I made a new videogame.
This one has an interesting story about it.
I taught videogame development at Lorain County Community College for five years, and I kept in touch with some of my brightest students since then. In January, I built a strategy game “skeleton”, but wasn’t interested in continuing work on it, so I emailed it to these old students, asking if they would be interested. They were, but life quickly got in the way, and nothing ever came of it. This was frustrating to me, because I knew these young men. They were all underemployed (like millennials are), working at fast food or assembly jobs. They have so much potential, and it hurt to see such potential unfulfilled.
So I realized; I had set them up to fail. If I wanted them to learn and achieve, I’d need to flip this script. Instead of throwing code at them and walking away, I’d need to be there for them, working together intensely, shoulder-to-shoulder. We could use my C++ engine, and I’d be there to teach them how to use it. Perhaps a month of intense effort was called for.
I discussed it with my wife, and she was supportive. She even told me to clear out the basement, and use it as the common workplace. Since I’m a big fan of small game companies starting in humble places, I liked the idea too.
Then I discussed the idea with my former students. John, Hunter, and Donald told me they wanted to be part of the project. We had several lunch meetings in June, where we decided on making a hex-grid, turn-based strategy sci-fi game. We needed a team name, so someone found a heavy-metal band name generator webpage, and it gave us the silly name Gore Slayer.
So on July 20, the four of us started work on what we called Project GR-5LYR. We got Visual Studio, Discord, and Perforce set up on all our Windows machines. We made a run to OfficeMax for cheap task chairs and a whiteboard. We mounted my big monitor on the wall, so we could share our screens. Donald dragged in his Wacom tablet. We laid in snacks, and they cluttered my upstairs fridge with sodas.
We made a facebook page, https://www.facebook.com/ProjectGR5lyr/
We live-streamed our dev pit; https://www.twitch.tv/techbear1980/videos/all
Then these guys worked their tails off, giving me every hour of every weekend, plus every week-night (after their day jobs). Hunter slept in my basement four times. Every bad possibility was avoided. Nobody got sick, or ghosted. Nobody had family emergencies. As the leader, and the experienced indie game developer, I was there every day too.
Donald produced all the art. He was especially good at cranking out buildings and units. We joked that he was sending us unit images faster than we could put them into the data files. I don’t have a video player in my engine, so he used code and art assets to produce the opening, win, and lose cinematics.
Hunter took responsibility for the tactical battle mode. He quickly got units moving and attacking, but continued to hammer out the unit behavior and GUI throughout the project. He also had a hand in coding almost everything else.
John worked on the strategic map; the buildings, caravans, events, and missions. He designed and coded the mission objective system. He had a strong vision for how it would work, and doggedly implemented it.
And I mostly just helped and guided. Throughout the month I happily got out of the way; they never left something to me because “it was too hard” or they “didn’t have time”.
One month later, on August 20 (at 12:20am), we submitted our 1.0 build to Steam for approval. We’d created strategic and tactical map generators, 11 buildings, 22 units, dozens of attack effects, dozens of scripted and generated “missions”, over 200 art bitmaps, and thousands of lines of C++ code. I couldn’t be prouder of what they accomplished.
Donald, Hunter, and John all have ambitions going forward. I want to continue to try to nurture that. But now they have something they didn’t have a month ago; a complete, published videogame. They can proudly say, “I made this.”