Tag Archives: game design

design, devblog

Paint By Monsters DevLog 7 – Design Process Part 1 – High Level Design (So Far)

Leave a comment

Paint By Monsters started life, as with many of my original designs, as an attempt to subvert aspects of an existing popular design. In this case, it was the Horde Survival/Bullet Heaven microgenre, which has exploded in popularity since Vampire Survivors appeared on the scene.

This type of game is an attractive prospect for a dev – mechanically simple, technically and artistically feasible for a reasonably skilled development team, and with a reasonably short development cycle. If I had any sense, probably, I might have been content to simply create a much more direct version of the experience myself. But.

Originality in Replication?

I often take a contrarian stance in some aspect of a new design (witness the small squad sizes in Contension or the worst-of-both-worlds combination of cards and tiles in Mechanisms). I often end up thinking about how to “reverse” a particular a genre. In this case, I was thinking about “reverse horde survival”.

The obvious first step, for me, was inverting the relationship of player and entities onscreen. In Horde Survival, you are one against many, so obviously in the reversal you play many against one. This eventually became many against few rather than one, since there’s still action economy to consider, but the core idea remains the same – the player uses a horde of relatively weak minions to fend off a small band of powerful invaders.

This idea, on its own, is the same basic formula as Dungeon Keeper and its ilk. That’s not a bad thing – Dungeon Keeper was a lot of fun, after all – but one thing dungeon defense games don’t do all that well is the kind of continuous action that horde survival has perfected.

So how could we channel that feeling of “action” if mostly you’re just spawning hordes of autonomous creatures? Feature Demo 0.0.1 took a look at the simplest version: spawning minions in realtime. Nothing fancy, just skeletons appearing whenever and wherever you hold the mouse button down.

The next few feature demos built on top of this foundation – 0.0.2 added a little agency to the enemy, 0.0.4 added a win condition, 0.0.3, 0.05, and 0.0.6 added new enemy and minion types. The “minimum viable loop”, such as it was, seemed complete. And it felt…not great.

Player Experience

I knew why it didn’t feel great. Even with a bunch of minion types to switch between, even with limited numbers of each minion type, even with adventurers carefully tuned so you could just barely beat them if you did a good job with the resources available…you were just moving the mouse around with the button down. It didn’t feel intentional.

That’s when I starting thinking ahead, thinking about what the Player Experience should be. Player Experience is something that gets talked about a lot more in board game design than in video game design, in my (limited) experience, but it’s important in both.

It’s not really about the core loop, though that loop will inform it. It’s not really about the theme, though the player will form impressions based on the theme that will affect their experience. It’s not even really about the action economy itself.

Player Experience, at its very core, is the answer to “What do I want the player to feel while playing this game?” For Paint By Monsters, as it turns out, the answer to that question is: I want them to feel like an artist who uses their art to stand up against tyranny, the same way many artists I admire around the world have done throughout the ages.

Until this point, mind, I had no idea that was any part of what the game was about. I thought I was trying a new take on something that’s kept me creatively engaged for years. I wrote a book a while back set in a world where music and magic were the same thing. I was spending hours in that world nearly every day for 2 years, and at some point, I realized that in that world any art form should invoke magic.

Paint By Monsters was playing some of those same notes, and I kind of thought it was going in the same direction. But reading a story where some folks use art as magic, and actually playing the role of one of those folks, as it turns out, feels different. There’s a lot that comes out of that, but the big thing was clarity on a few different pieces of design:

  1. The Adventurers (who til now I’d sometimes been calling Heroes) were antagonists. There’s an easy perspective switch to make here – anyone with a little history in their head can appreciate how the crown and its servants might sometimes have dealt unkindly with common folk and upstarts in centuries gone by.
  2. The player should really feel like an artist while they play. Thus was born the notion of The Artist, the character represented by the player themself, and the Studio, the room in which they make their final stand in each life.
  3. Along with the Artist came Brush Strokes, which eventually became the basis of Feature Demo 0.0.10. It feels very different to just continuously spray minions into the arena, trying to surround and confound the enemy, versus using quick, precise strokes. It feels intentional.

These, then, are the cornerstones of the game’s core gameplay loop. We call it Room Painting.

Each new room is a new chance to try to stop the Adventurers from getting closer to the Studio. In each room, you channel creative energy to paint minions into the scene, and somewhere in the ensuing chaos one side or the other emerges victorious.

There are a lot of fun bits and pieces that have emerged from this core concept, and I’m looking forward to talking about those in future articles, but the emergence of these three key ideas, and particularly the Brush Strokes mechanic, was the first time I felt like I was headed for a good understanding of the Player Experience.

Art, Artists, Art Directors, and Beast-Headed Men

Somewhere around this time, I started talking to artists. I eventually landed on the incomparable Curtis Rioux and his merry band at Stellar Boar Studios. At first we talked solely about the studio doing art for the game, but as I went through the application process for CMF, I realized that games have many kinds of design intermingling, and art was an area where I really didn’t have the right skills or sensibility.

Happily, Curtis does have such a sensibility, and furthermore, when I sat down with him to talk about his ideas as Art Director for the game, he was already moving at the speed of thought. He brought a bunch of medieval mythical creatures to my attention, the best of which we chose for our starting lineup. I can’t wait for him to tell you all about the process of bringing those to life.

This new input set fire to my brain. I’d had a vague notion of what the world map might look like before, but adding these unusual creatures to the mix, along with a bunch of HEMA nerdery (check out Tod’s Workshop and Shadiversity in particular), gave me a strong sense of the tone of the game. There’s a playfulness here that wasn’t immediately apparent with the generic royalty-free assets I’d been using initially.

How can you not laugh at this guy?
Why is he wearing a padlock as a jaw strap?

I recognized, looking at these strange artifacts of ancient imaginations, that we’d do well to hold our tongues in our cheeks now and then.

Take Me to Your Action Heroes Murder Hobos

Maybe because of that new sense of levity, I also recognized that the game feels a bit like an Action RPG, and also that dudes who just run around with swords are Bo Ring. We needed a little flavour. A little flare. A little Michael Bay, if you will.

At this point I’d already worked on 0.0.7 & 0.0.8 (heavily informed by the excellent upgrade system in Brotato) and 0.0.9 (Dungeon Keeper, obv), and those informed my ideas about where we might inject some Action Hero notes. I also drew these:

This isn’t actually how it will go, but it inspired something all the same.
An early concept showing the Dandy swinging on a chandelier like Errol Flynn. Somehow, despite the diagonal lines, I thought I was making “pixel art” with this.

Just messing around with these sketches let me think in more concrete terms about what kinds of action might matter – interacting with the environment (particularly the addons from 0.0.9), the room, and the Minion horde. And that set me down the path to thinking about archetypes and Murder Hobos.

Murder Hobos is an idea in tabletop RPG circles that the group of characters in a typical D&D game is sometimes indistinguishable from a band of drifter serial killers whose sole purpose in life is to destroy life and steal property.

These days a lot of RPG players recognize that maybe this isn’t the healthiest model within which to run a roleplaying game, but for Paint By Monsters it fits perfectly.

The Adventurers are, after all the antagonists. It’s fine if they’re despicable. Better than fine – it drives home that whole thing about opposing tyranny.

And if the Adventurers are the expression of tyranny, then the ultimate realization of that is the crown itself. I’d already been thinking about including a traditional roguelike world map (sometimes called an FTL map), and putting Studio and Castle in opposition to one another fit very neatly into that setup.

This became the second loop of the game, which we’re calling Gauntlet Building. The player adds rooms to their magical gauntlet, trying to head off incoming Adventurers, and each time an adventuring party finds a room, they invade the gauntlet in search of treasure and glory, kicking off another iteration of the inner (Room) Loop (the one with the painterly gameplay).

There are, as with everything else, lots of fine details that have spun off from these seeds, and we’ll tell you more about those as development proceeds.

Roguelike? More Like Roguetolerate

The final piece of our puzzle is meta-progression. Folks often say this was the real secret to Vampire Survivors’ success, and it’s hard to disagree. The game makes you feel like you’re adding stacks on stacks on stacks on NUCULAR WEPPONS.

This is the second place in the design where my inner contrarian raised his head. Most roguelike games keep the the meta-progression elements behind very simple interfaces. A few have played with expectations a bit, or used more traditional unlock systems where completing specific in-game goals will open up new and exciting possibilities. But we already had such an interesting, unique world taking shape that tacking on the merest mechanical necessities felt really unsatisfying.

I started thinking about Evil Overlords and the tropes around them. Think about the villains in Lord of the Rings or Wheel of Time, for example – a dark lord is defeated, an epoch passes, a dark lord rises once again, ad infinitum.

Epochs

As a word nerd, any chance to use the word “epoch” is a chance worth taking, and so we came up with the Epochal Loop. The Artist may not be a dark lord, but they do rise and fall in the same age-old cycle.

Curtis (remember Curtis?) suggested that maybe in these sections of the game, the player is travelling between worlds, exploring an infinite universe of possibilities, and I thought that was just the best thing, for lots of different reasons.

Among those reasons is how it explains why the world we’re on is always in roughly the same technological period. Sure, civilizations rise and fall, but these days folks like to say History doesn’t repeat, but it rhymes.

We could say the roguelike elements of a game like ours – procedural worlds and progression, unlocked pools of randomly awarded abilities, cycles within cycles – fit this idea, but on some level it just feels better to say that maybe The Artist’s very soul is attuned to the medieval, and so when, in their travels, they happen across worlds upon which the people are just getting around to forging steel and fight senseless battles that will nonetheless inspire great art, they feel drawn to those worlds.

At least, that’s the backstory.

In Paint By Monsters, we call the place where the soul goes seeking its next home the Spirit World, and we’re building some unique gameplay around it. It will be a dark, mysterious place that lets you move at a slower pace – a good place to reset your mind and stretch your legs – and we’re still working out some of the details, but we’re aiming for a distinct identity that feels rewarding on its own rather than feeling like the player is wasting time away from the “good parts” of the game.

And not for nothing, it fits nicely with the Perfect Minute Games ethos – we make short, beautiful games for smart, busy people.

If You’ve Read This Far, Thank You!

So that’s where we’re at as far as the high notes go. I’d like to talk sometime soon about the other end of the design process – the nitty-gritty details of planning each thing in a way that will lead to a reasonably well-defined end goal – but for now I’ll leave you with this teaser for our forthcoming art devlog.

Meet the Paint By Monsters Demo Full Cast!

Left to Right: Barber Surgeon, Dandy, JuggerKnight, Giovannia aka The Artist, Blemmyae, Nucklavee, and Monopod

Featured Image

19th century engraving of The Trusty Servant, from the 1579 painting by John Hoskins (public domain).

devblog, Games, Prototypes

Paint By Monsters: DevLog 4 + Feature Video 0.0.10 – Brush Strokes!

1 Comment

I’m gonna talk about all the faffery in a minute, but if you want the TL;DR, I invite you to take a look at feature video 0.0.10 – Brush Strokes;

Why “Brush Strokes”, Cousin?

One of the folks in my local gamedev community, the incredible artist rsvpasap, asked me a while back what kind of “painting” there was in Paint By Monsters, and at the time I didn’t have any kind of sensible answer for them.

Well, now I do, at least in the first-proof-of-concept sense. The Brush Strokes feature was directly inspired by that conversation, and I hope Angie would be proud to have sent me down this road.

On Assets, Asset Markets, and General Faffery

I’ve been mostly buying assets for PBM from itch.io artists, but there’s only so much content you can find there. I’ve looked at a bunch of new spots, particularly ArtStation and the Unity Asset Store, and in the latter I happened across the Gesture Recognizer asset.

This asset, on its face, is exactly what I wanted for Brush Strokes – a clean, simple asset focused specifically on recognizing a range of gestures, with good editor integration and the ability to create new gestures without a lot of faffing about. So, you know. Good job Raphael Marques on that front.

Unfortunately, Gesture Recognizer has a few problems out of the box that make it less than ideal to work with as of this writing. Maybe the creator will update it sometime, but in the meantime let’s talk about how I approached the issues that I encountered.

Fixing Gesture Recognizer

The first problem – and really, this is as much an indictment of Unity as a vetting agent as it is of the asset creator – is that unless you’re starting with the example level included with Gesture Recognizer, creating a new Gesture and trying to fill in the ID field causes a whole boatload of exceptions to show up in the Console Log. These will lead you back to the GesturePatternEditor.OnInspectorGUI method, and in particular to this line of code:

var closedLineProp = gestures.GetArrayElementAtIndex(currentGestureIndex).FindPropertyRelative("closedLine");

There are two exceptionally unfortunate things about this line of code. The first is that nowhere does the editor code check to see whether currentGestureIndex is a valid index for the gestures array. The second is that it is only really required in a small subset of gestures, because closedLine is only a concern when you’re closing a gesture that contains a closed loop of some kind.

My solution to this issue was relatively simple. I put an if statement around the entire editor block containing this piece of code:

if (gestures.arraySize > 0)
{
    //do stuff, including the array access
}

This fixed the editor errors, at least for the cases I care about.

I ran into some issues with the OnRecognize event that the asset uses, but I can’t 100% rule out PEBKAC for those, so I’ll just state for the record that Dynamic Events are tricksy, and you should look for them at the very top of the event list for the handler object.

I don’t really want to admit how long it took me to find that entry, but…it was a long time.

The Other Problem With OnRecognize

The really tricky bit with this event, however, is that the parameter for the event, RecognitionResult, only includes the points from the recognized gesture. The asset seems to be focused on some kind of cleaned-up vector drawing use case, so I’m sure that works great in that circumstance where you’re doing the scaling and whatnot in another component (for the record, you probably need to inherit from DrawDetector to do that properly).

But if you’re more interested in the gestures themselves – place, size, all that kind of stuff, and if you want to keep things nice and centralized to boot – you’re going to want the points as measured at the time of input.

Now, I’m not proud of my solution to this one, but I will say that it serves the purpose, and that’s enough for the kind of rapid feature iteration I’m doing on PBM. What I did was this: I changed the array of points that define the input being examined – which is a member variable in the object that invokes OnRecognize (that is to say, DrawDetector) – from private to internal. 

internal List<UILineRenderer> lines;

This lets me do the following in my event handler:

var cam = FindObjectOfType<Camera>();
var dd = transform.GetComponentInParent<DrawDetector>();
var lines = dd.data.lines;
var line = lines[lines.Count - 1];
var point1 = cam.ScreenToWorldPoint(line.points[0]);
var point2 = cam.ScreenToWorldPoint(line.points[line.points.Count - 1]);
Vector3 gestureVec = point2 - point1;
Vector3 gesturePos = ((point1 + point2) / 2.0f);

This works for basically any straight-ish line, and gives me the two primary things I care about:

  1. The position of the gesture in world space
  2. The orientation of the gesture in world space

I expect to have to do more complex analysis for future specializations, but these two vectors allowed me to specify

  1. Where my brush stroke effects appear
  2. How big they are
  3. What their orientation is.

Of course, then I had to figure out how particle system shapes work and how they interact with the Position, Rotation, and Scale of their host GameObject…but more on that next time.

devblog, Games, Prototypes

Paint By Monsters: Devlog 2 – Work To Date

Leave a comment

I promised some local tech folks I’d do a weekly summary of my progress on Paint By Monsters, and I figured since I was doing that anyway, I’d expand on it over here for anyone who’s not in that very specific community.

First of all, I’m happy to report that PBM feels kind of like a game now
https://www.youtube.com/watch?v=_LGMChMhVFk

Things of note in that video include:

  1. Programmer art new logo!
  2. FTL-style “Progression” screen – as I understand it, these are required by law for roguelike and roguelite games
  3. Upgrades – each time you defeat a hero, you get an upgrade for your monsters. I’ll be expanding on these over time, and probably playing with other possibilities.

There are lots of smaller details, too, but I’m mostly just happy to be well on the way to something that’s game-ish in form.

I’ve got lots of plans and ambitions in mind for the game in the weeks and months to come, so I hope you’ll stay tuned for those. Some of the high notes include:

  1. Lair Building v1 – add balconies, traps, chandeliers, and more
  2. More progression stuff
  3. More monsters
  4. Acrobatic maneuvers

I mentioned some of those in my first Devlog over on Itch.io. Which reminds me – if you’re wondering how I’ll be working Devlogs going forward, I’m planning to alternate between itch and this site, with links going both ways. I’m hoping you’ll stick with me on that. I tend to prefer to keep things on this site, but it’s nice to have a more well-known presence as well, especially since between the game page on itch.io and the ko-fi page for Perfect Minute Games I’ve moved from “fun pastime” to “thing I’m both spending and soliciting money for”.

That’s always a bit of a hard rubicon to cross, from hobby to serious, but I’m trying to take the lowest, informal-est approach possible right now so I can keep my focus squarely on making the game itself as fun as I can. At some point I’d like to expand my ambitions to include custom art, animation, and music, but I’m not in a rush for now.

Having said that, if you’re an artist or composer who might be interested in partnering up, my email is always open:

mgb (at) perfectminutegames (dot) com

I can’t tell you how much I appreciate the interest folks have expressed in Paint By Monsters thus far. I’m excited to work on my own game design again, of course, but you never know how well it translates to anyone else. So getting feedback and even financial support has been incredibly encouraging.

Hope yer well.

design, Prototypes, tabletop

Meet Mechanisms!

1 Comment

I’ve been designing a tabletop game for a while now, and with Protospiel Online coming up (https://protospiel.online/prototype-games/april-2022/mechanisms-entry-1921/ ), I’ve been focused on making sure I have ways to play the game.

Tonight marks one of the big ones – I’ve started to get a few requests for a way to play the game in person. I tried out The Game Crafter and Print and Play Studio, but for a one-off printing both spots want over $150CAD, which I’ll be ok with – it’s my baby after all – but I don’t want to suggest it as an option to friends and family.

Enter the Print and Play – this is an option that many games use prior to publishing, whether it be licensed or crowdfunded. And, of course, I had to try it myself…

My first print and play!

So that’s it. If you’re interested in trying it out, feel free to send me an email or message me on Twitter.

design, devblog

Boardgame Research: Thornwatch

Leave a comment

My regular tabletop gaming group kindly agreed to try Thornwatch during our last session. I read through the rules when I received the game earlier this month, but this was the first time trying it out at the table.

I hadn’t punched out any of the pieces, so the first several minutes were spent just getting those out and sorted. There’s not a ton of information about how to use those until you’ve read through the rules, and when you do, there’s a fair bit of jumping back and forth to do. I don’t expect that’s usually a problem, as the rulebook is quite short, but I was using a PDF on my phone, so this was not ideal. I suspect we missed several important aspects of the game, so keep that in mind as you read this discussion.

The game board, enemies, and setup are dictated by the scene. The opening scene is usually chosen by the Judge – that was me, in this case – but I threw the options out to the table. We decided to play through May He Die in the Forest, which, for the uninitiated, is one of the suggested starting scenarios from the base set.

We had three players, and the group composition proved to be critical to party success. The players chose Greenheart (healer/support/melee), Sage (support/ranged), and Blade (melee/ranged). This seems to have been a spectacularly effective combination.

Setup is focused on the board. The scene dictates which tiles to use and how to put them together, which is a neat mechanic, but it isn’t the best gameplay experience. The art on the board tiles is blurry and complex, so it’s hard to match against the board setup as it’s shown on the scene card. It also means the board feels muddled. Sideways stairs and weird crystal columns beside a cozy hut in the woods give the whole thing a dreamy “unplace” feel. Maybe that’s your thing! Not mine, though.

There are also a lot of symbols to figure out, and we missed at least a couple of steps. This is also the point where the Judge role kicks in in earnest, which was unfortunate for me, as I hadn’t fully absorbed the gameplay yet. I didn’t know what to do with my pool of Ebb or how to decide where monsters should go.

In general the Judge role feels quite odd, at least in this kind of mechanics-heavy playtest. Your resources are tightly constrained, and there isn’t so much play space that you can make much happen with good tactical play. I’m not sure if there should be more options or if we missed something important in setup/gameplay, or if the Judge is just meant to be a lighter role than I’m used to.

The primary thing that the Judge has access to beyond the monsters themselves are the momentum track and the damage mechanics. There are two parts to this equation, the NPC damage mechanic and the player wounds mechanic. 

The momentum track acts as both initiative and NPC damage. It’s an interesting system that can suffer badly when players aren’t rolling well, as it can be straight-up impossible to kill the bad guys for extended periods. There are other options for handling this situation – the Sage’s board control powers, for example – but success still frequently hinges critically on making the bad guys go away somehow.

The wound mechanic, on the other hand, seems badly under-tuned. There are 10 wound cards for each player, and the scene is lost when this collection is exhausted. If the party has a Greenheart, however, it’s hard to see how this could possibly pose an issue, as the Greenheart’s healing abilities are extremely potent. If you don’t kill the party in the first couple of turns, the Greenheart has a good chance of simply preventing any meaningful threat from wounds.

Speaking of under-tuned mechanics, the Judge’s ebb supply also feels a bit wanting. Player dice that show the @ (ebb) symbol supply one point of ebb, and deck reshuffles supply two. Perhaps my players were simply amazing from the get-go, but I was having trouble maintaining my supply, and that meant my monsters often lacked the Ebb-infused trait, which meant they were kind of pathetic, inflicting very little damage and succumbing quickly to focused attacks.

As you can tell, we focused on the mechanics over the roleplaying for this test. We did use Traits, but didn’t get a lot of value out of them in this session. They’re an interesting mechanic, but it eventually became clear that they make a lot more sense if you’re treating the game as much more of an RPG and much less of a boardgame.

That feels a little in opposition to how the game is actually built, as much of the focus is on the board, tokens, and mechanics, but the trait mechanic is  simple enough that it doesn’t interfere with normal play, and it does encourage a small degree of roleplaying even in a mechanics test.

Overall, Thornwatch is an interesting game, and one I’d like to give a second go with more involved roleplaying at the table, but also one I currently feel is going to need some house rules to really “finish” the play experience. I hope to stand corrected on that at some point.

design, Prototypes

Design Prototyping: Card RPG

Leave a comment

Perfect Minute Games is primarily focused on video games, but one of the fun secrets about game design is that paper is always an option for prototyping mechanics. And if you can prototype on paper, you can implement the whole thing on paper.

(Well, sort of. I found out quickly that there are hard limits on how much paper prototyping you can do with a game like Contension without also building the dynamic experience in code!)

The new project, then: It’s a card game. Specifically, it’s a card game taking design notes from RPG-adjacent boardgames like Gloomhaven, Pathfinder Adventures, and Descent; from light RPGs like Fiasco and Thornwatch; from heavier but non-traditional RPGs like Fantasy Flight Games’ excellent Star Wars and Genesys systems and from the Fate RPG; and, finally, from some really interesting indie RPGs like Phoenix: Dawn Command, Ten Candles, and Tavern Tales.

The initial iteration of the game is focused on simple, purely card-driven mechanics and is playable as a regular game akin to Munchkin and other Expandable Card Games. I have, in parallel, been fleshing out an expansion that adds roleplaying elements.

As I’m not an artist, it all looks pretty terrible right now, especially given that there’s no built-in “setting” or “theme”. Please keep that in mind(!) when I’m a little further along and post some shots of the game and “cards” in action.

I haven’t decided whether I’ll establish a theme or setting to “ship” with the core game. At the moment, as with most of my initial designs, it’s mechanics-driven, and I think I can create something compelling without the need to tie it to a single setting.

I’d much rather have expansions (or “splats”, as some folks call ’em) that contribute their own unique mechanics and style sitting on top of the core game. But a lot of the interesting work for projects like this comes down to creating the worlds that players inhabit. So we’ll see.

thought experiments

Theorycrafting a fully-integrated Eve MMOFPS

Leave a comment

I’ve been doing a lot of game design of late, both for Beat Farmer and for other projects I’ve had in the back of my mind for a while. Having stumbled over Eve and its FPS tie-in ambitions again today, I kind of want to figure out what my approach to this might look like.

First, some background.

Eve Online is a massively multiplayer game with starship combat and player-driven economics and “geographic” (topological?) control. It is famous for, among other things, its difficulty curve:

Can’t find an author – if it’s you, HMU

Many moons ago now, CCP Games released Dust 514, a first person shooter aimed at giving new players an “in” to the Eve universe, as well as expanding the existing player base’s available experience.

Dust 514 was shuttered, and CCP has gone through a couple of stabs at a design for a successor. The first was Project Legion, which, judging by the name alone, may have contained some of the ideas I’m going to talk about below. The second will be Project Nova, which sounds like it will be a much more straight-FPS first. After looking at GunJack videos, that’s probably the right decision. Eve was never a game for the nice-UX crowd.

Integrated Game Worlds and Design

As fascinating as it is to read about Eve’s many born-in-real-life treacheries, the universe itself isn’t that compelling. The compelling part of Eve has always been its large-scale gameplay, where massive alliances conduct battles so fierce that time literally slows down within the game so that the servers (and, no doubt, the clients) can run the necessary calculations.

That seems like a great place to start for a planetary conflict FPS. Fleets need to bring their troop transports to bear because ground forces are the only forces that can take territory. That’s interesting from a space combat standpoint because at that point you need to have well-protected transport ships.

Luckily, Eve already has these gigantic transports, and shipping is its own deep specialization within the game. But.

Blowing Things Up With Smaller Guns

The thing about Eve is this: the whole idea is to make spaceships shoot at each other. Every piece of the player-driven economic system is, in the end, a way to let both hardcores and casuals put together ships and fleets and super-fleets and massive starships and starbases oh my. These heavy things necessarily dominate the gameplay, and there’s no reason to imagine that a planetary assault wouldn’t come down to who has the better fleet in every case.

So you’d have to introduce gameplay restrictions in order for this to work.

You could, for example, add planetary defence systems that are able to  blow a Titan out of the sky in short order but, in keeping with the game’s oeuvre, can’t hit anything smaller than a supercapital. This could get even more interesting if planets can throw off their governance once in a while, leading to both sides having to dodge space flak.

(Side note: There are almost certainly Eve players who would enjoy an associated game wherein their only job was to manage the governance of planets, quashing rebellions and maximizing productivity. There could be a tie-in between this game and the FPS players as well, where FPS players lead rebellions and security forces in conflict with one another.

There could even be a competitive aspect to the management game, with “sleeper” agents embedded in the game exercising various levels of mismanagement to mess with the managers. I don’t know whether the management types would like this element, but I digress…)

Another, possibly complementary, approach would be to  introduce the idea of orbital pollution, where intense spaceborne warfare in proximity to a planetary body would reduce the effective value of the planet while the orbit was “cleaned up”. You could still see skirmishes and raids with smaller ships to try to disrupt or destroy orbiting transports, but the heaviest ships would have to concentrate on controlling the supply line rather directly participating in orbital dominance.

To my mind, it seems like introducing these limiting factors would allow the optimization of the play experience in each game for its intended players.

Ground Assaults, Economics, and Availability

As to the transports themselves, I feel like the Dust approach, which limited itself to orbital bombardments, was a poor solution. It would be much more Eve-ish, to my mind at least, to integrate the transports themselves into a resource equation for a particular planetary war. Eve players and FPS players would have to negotiate how many clones, resources, and buildings to supply to the war effort. FPS players could see – possibly depending on their rank – exactly what is left available on the planet and in orbit, which would raise the stakes on their individual and team performances.

From a technical standpoint, one of the harder things to get right about this situation would be matchmaking. I think there’s room here, too, for improvement.

The first thing would be ensuring the conflict doesn’t pause because FPS players go to bed. Bots could be brought in as part of the supply drop, ensuring that FPS and space gameplay are not over-reliant on one another. FPS players might face AI-controlled bots for a while, then see a gradual increase in clone troopers, who would be controlled by other players.

For those unfamiliar with the Eve Universe, there are grades of clones, which brings a whole different question into play – when FPS players field their top-tier clones, and why? What payment do they require? How do they handle the collapse (or retreat; betrayal is a key part of the game, after all!) of their space-based support lines?

This appeals to me as a former Eve player. Judging exactly how many clones might available for an assault and for how long would become a critical part of the supply line equation. Balancing different bot types – Titanfall comes to mind – would come into play. And it’s possible to tie in economic incentives by offering clone trooper contracts on a cross-game marketplace to improve your assault’s chances.

Negotiation

Allowing cross-game discussion and negotiation in some form would be critical, even if it’s more like email than Messenger in design. Eve players and FPS players probably have some crossover, but I would expect that in most cases you’d see two separate entities (Eve Corp/FPS Mercenaries)  discussing terms via this system. From a community and design standpoint, this could be a great place to gather data about how players are actually doing what they do and how to improve the experience.

Conclusion

That’s kind of what I see being the best version of the tie-in idea. It’s obviously weighted towards Eve-first. That’s the starting point, and it’s also the only CCP game I’ve played. That also means there’s a recognizable and not necessarily positive bias in the design here, and I’m not sure I’ve solved the issues perfectly.

Regardless, I’ll be interested to see how CCP deal with Project Nova and to what extent they implement gameplay that melds these different genres in interesting ways.

-mgb