The Saturday Paper - Making Magic (Spells)

(Crossposted from Games By Angelina)

Depictions of character classes in The Elder Scrolls IV: Oblivion

If you've ever played a role-playing game, from Final Fantasy V to Skyrim, you'll know that the genre loves its tropes. From orcs and goblins to swords and sorcery, the same themes come up time and time again. Sometimes this is exactly what you want, but often - particularly when it comes to the classes players choose to be, and the skills they have available - we want to have something new to challenge us. This week The Saturday Paper is about getting the game itself to come up with new abilities and class ideas for RPGs, with a little guidance from the player.

More...

We're reading Alex Pantaleev's 2012 paper, In Search of Patterns: Disrupting RPG Classes through Procedural Content Generation. It describes a game he built for two players who fight each other in simple RPG-style battles. It's a prototype game in order to prove the idea's worth, so Alex's RPG system doesn't let the characters move (they can all reach each other, like a Final Fantasy fight) and has a really simple combat system that uses eight statistics - things like health points, armor, speed and so on. Each player controls a party of characters who take turns (according to their speed statistic) to fight until one party is defeated.

The experiment's RPG system reminds me a bit of Final Fantasy-style combat. In a good way!

Instead of picking a ready-made player class with its own skill tree, players begin by choosing abilities for each character from a list generated by the game. Each ability is defined by a few pieces of information - a negative effect (the cost of the ability) and a positive effect (the benefit). For instance, a magic spell might lower an enemy's health points while reducing an ally's magic points. This makes abilities very easy to represent and generate through code - you just need two statistics to target (like health and magic points) and two numbers to add or subtract from them. Abilities also have information like a duration (the number of turns they affect things for) and a cooldown (the number of turns you have to wait before using it again).

Of course, if the abilities were just randomly generated forever this wouldn't be much use. Instead, Alex's system tries to improve the abilities over time by using computational evolution. Like biological evolution, computational evolution is about combining good examples of something in the hope of making even better examples (in the same way that fit animals survive to reproduce and make fitter children). Computational evolution works in much the same way - if you're interested in reading more (and like baking analogies) I wrote a quick explanation of how computational evolution works in this post here.

A (very) simple example of how two abilities could be recombined. Alex's are a little bit more interesting, and detailed better in his paper.

 Recombining can be a tricky thing to define when you're making an evolutionary system, but it's easily experimented with over time. Maybe initially you create a child that takes the benefit from one ability and the cost from the other (like the illustrated example above). Or maybe you vary the values a bit. Maybe you swap the statistics over. Different methods will have different results - Alex uses a method where any number of elements (statistics or values) are chosen from one of two parent abilities, and included in their children.

Just like evolution in the real world, Alex's RPG abilities need a way of being sorted so only the fittest can reproduce. What do 'fit' abilities look like? His solution is elegant and simple - let the player decide. At the end of each battle, the abilities that were used the most by players are the ones that get chosen to recombine into the next set of abilities for players to choose from. The player might choose some, all or none of this new set - whatever happens, the process continues into the next battle.

Results

So, what do you think? Could such a simple system - giving a player random abilities and slowly mixing together the ones they like best - produce cool new ideas for RPGs? My favourite thing about this system is that it absolutely did, and I want to go over some of the interesting ideas that came out of this (very preliminary) experiment.

Remember that each ability has a cooldown and a duration of effect? In one game, a player evolved a set of abilities that had durations slightly longer than their cooldowns. These abilities were often not individually very powerful, because Alex's generation system tries to avoid generating abilities that have a high benefit and a low cost. Because they could be stacked multiple times, however, they could be used to create huge damage in very long battles.

Goblin Techies from DOTA

Another example had a player evolve highly damaging, long-duration abilities that also hugely damaged the person casting them. This meant that some party members could sacrifice themselves to inflict large amounts of damage on the enemy team. This is a really unusual ability - the only example that springs to mind is the weird Goblin Techies character in DOTA, whose ultimate abilities kills the player and deals huge damage around them.

Other interesting patterns emerged from unforeseen uses of game mechanics. If a player's magic points dropped to zero, any active spells they had cast immediately vanished. This led to abilities that attacked magic points and magic point generation as a way of stopping suicidal or long-term strategies like the ones above. It's interesting to see such variety coming from such a simple system - included alongside these more unusual examples were also the expected range of healing, damage and buff/debuff spells.

So What?

Where might this research apply to the games industry today? Even just considering its core idea - that there are more RPG classes out there than just Warrior, Mage and Thief - I think there's plenty to be excited about here. Ideas like this could be used in the development of a game - to explore new ideas that you might not have thought of yourself - or even built in as procedural generators to games for players to explore themselves.

It also has promise outside the boundaries of RPGs. What about a roguelike whose item drops were designed based on which ones the player picked up and which ones they threw away? What about an RTS where the tech tree redesigned itself each week based on what skills players were picking most or picking least? Perhaps a game like Minecraft could help players specialise and co-operate better by changing its crafting recipes or inventing new ones as players find things they want to do more of? Player-guided creation of content, that goes beyond the ordinary things that games try to generate, is an exciting prospect.

Where To Find More

I've been in touch with Alex since deciding to write about his paper, and he's very kindly put the PDF online for everyone to download and read. He was extremely friendly and excited about the idea of people finding out about his work:

I'm glad that the community is starting to look at the intersection between academia and industry, which has long been a pet peeve of mine. I'd be very happy to talk to indie game developers and other smart people with my goal, which is "make cool stuff that works and is useful".

Alex can be contacted via his academic site - please drop him an email if you liked the work or want to know more about it, I'm sure he'd be delighted to talk to interested developers and gamers! There are lots of details to be found in the paper that Alex can expand on that I didn't have time to go into here. Hopefully I've piqued your interest and you can find out more through the paper itself.

Don't forget to let me know what you thought of the column this week. I'm working on the format and I want to know what people want more of, less of, or just plain love/hate. Let me know by emailing me - [email protected] - or getting in touch @mtrc on Twitter. Thanks for reading!

With many thanks to Craig, Joel, Mark, Mike and Azalea for feedback and suggestions.