Ultimatum

A pale, pink landscape against a black sky. A single missile arcs from the left side of the screen to the right, leaving a blue trail behind it.

Or: That Time My Card Game Accidentally Became an Auto-Battler

Ah, 2020. The year I graduated college – and a year where, famously, absolutely nothing went wrong whatsoever.

Earlier this week, I finally pulled the trigger on my new site, and cast my overpriced, crunch-born, collegiate portfolio back into the abyss – where it belongs. But, in preparing for the job search, I realized there might be some files on the old site whose originals were lost with my college email – so I downloaded everything, just in case.

A list of files in windows 10, with incomprehensible names like "1ce7tv2h8_804090".
Apparently, senior-year Andrew was way too busy to name the files properly. Understandable, but I hate it.

There’s a lot of stuff in there that’s nostalgic for me, but not really worthy of a proper page on my new portfolio. I was originally going to compile some of them into a blog post – a kind of tour of my college game design experience – but I got a bit caught up about one project in particular: Ultimatum.


Part 1: Local College Student Plays Too Many Card Games.

5 cards. A blue card, "Border Patrol: If this card would be destroyed while attacking, return it to its starting base." A green card, "Fission Reactor: Each adjacent base without any fuel gains +3." A yellow card, "Jet Fighters: This card attacks every enemy weapon or personnel card it passes." Lastly, a red card, "Nuclear Missile".
A collection of card designs.

Ultimatum was a head-to-head, strategic draft card game that I worked on for my senior-year Advanced Seminar in Game Design. At the time, I was in the depths of my tabletop gaming phase – Magic: the Gathering, Betrayal at House on the Hill, D&D, etc. – and I had a lot of ideas kicking around in my head. So, when I had to choose a systems project, I chose a genre that I was already immersed in on a daily basis. Or so I thought.

Diagram labelled "concepting". A black background, with a frame that shifts from light blue to red, left-to-right. Reads: "1: Players continually swap hands. 2: Play cards Face Down in Piles. 3: Reveal Cards and Respond".
A visual design document for ultimatum, showing the game’s basic play. Players would take turns passing around cards, and placing them on the board. At the end of each round, all of their cards would be revealed, and take effect.

At the time, I had been playing a handful of games that explored the idea of base-building with cards. Most notably were:

  • 7 Wonders, where each card was a building used to build out a city
  • Smash Up!, which was all about putting unit cards on bases
  • Magic, which really isn’t about base building – but I definitely tried with the number of land enchantments I was running

For a while, I had wanted to try my hand at a game that focused on preparation – something that blurred the lines between standard card game turn mechanics, and the sort of gradual, wave-by-wave buildup you get with a tower defense game. All these ideas came together in my head as a “base-defense” card game – where players would lay down base cards, load them with units, and – at the end of each round – flip them over to see whose board would be strongest.

A red card reading "Nuclear Missile."
Boom.

Now, if you’re any sort of game developer reading this right now, you might be thinking something like: “Hey. Did he just say he’s going to develop an entire draft card game as a side project? In his senior year of college? In one semester?”

To that, I would say “No! Of course not! This is just a prototype! I have to make it in Unity, too!”

Hah.

But in all seriousness: I knew going into it that this was far too large of a project for one semester. But this was a seminar class – it was more about learning than making a public-facing product. And that was my plan: fling myself headlong into card game design, and then into a digital adaptation, and then just… see what I can learn from the experience.


Part 2: “I’ll Make a Card Game!” he said. “It’ll Be Fun!” he said.

A dark blue game board, with one side for a light blue team and one for a magenta team. Top from left to right: A blue circle with 20/20 health, a blue deck of discarded cards, the word "ULTIMATUM", a magenta deck of discarded cards, and a magenta health bar, 20/20. The bottom half of the board contains a 12x2 grid of card-sized slots. In the top half of the grid, are numbers, 1-6 on each side, running towards the center of the board. On the bottom of the grid, a few spaces with cards.
A diagram assembled from the actual assets I made for the physical card game, depicting the gameplay of Ultimatum. Players would play base cards onto a slot on the grid, and then put units, weapons, etc. on top of them, face-down. The draw pile was passed back and forth between players each turn, so it was a game of figuring out what cards had gone missing, and where your opponent had placed them.

Early on, I settled on a Missile Command and DEFCON-inspired cold war theme – which I thought fit the buildup concept quite well. However, I started the real development on Ultimatum by looking at the gameplay of tower defense games.

The thing that really interested me about tower defense (as far as Ultimatum went) was the ways in which games of that genre handled wave-based progression – centered around a buildup of stationary structures. Classic tower defense games tend to place the player on a map, with a simple inflow of resources that they can spend on building and upgrading defenses. As waves progress, players naturally layer more and more defenses onto the map, to meet the rising strength of their opponent – resulting in an escalation on both sides.

A dark blue game board, with one side for a light blue team and one for a magenta team. Top from left to right: A blue circle with the word "Life", a blue discard area, the word "ULTIMATUM", a magenta deck space, and a magenta circle labelled "Life". The bottom half of the board contains a 12x2 grid of card-sized slots. In the top half of the grid, are numbers, 1-6 on each side, running towards the center of the board. On the bottom of the grid, a few empty spaces that would hold cards.
The play space for Ultimatum was constructed (in my head, at least) as an adversarial set of tower defense tracks. Players lay down buildings on the six slots on their side, units that will attack the opponent on those buildings.

That play pattern was what I attempted to adapt into a card game with Ultimatum. Players would start each game with a few tiles containing “Fuel” – which would allow them to play cards on those spaces, or set up cards that would provide fuel for other spaces in subsequent rounds.

Ultimatum document labelled "Systems" with a picture of the card Mobilized Legion, and notes breaking down different parts of the card. Going counterclockwise from top left: "Card Name". "Fuel Cost - All bases have limited fuel. You can only play cards you have fuel for." "Card Type - Facilities provide static effects - Defenses stop attackers - Personnel attack bases - Weapons attack opponents." "Combat power - the number of times a card can attack per round." "Initiative." "Icon."
A sample of a card design. All cards were color-coded by the stage of the game they were introduced.

The cards themselves came in four different types: Facilities, Defenses, Personnel, and Weapons.

“Facilities” was just my fancy word for “cards that had buildings on them” – which were played face up on a space. It’s hard to hide an entire building.

Defenses were, as the name implies, tower-defense-style defenses.

Personnel and Weapons were the two types of “units”. All played face-down on the board, and revealed at the end of the round. Each card moved towards the opponent’s base in order of initiative (a system which was neat but not worth explaining here), and any personnel that survived would stay to the next round. Weapons did not, because missiles don’t tend to be multi-use.

Ultimatum design doc labelled "Through-Lines". On the top row of the document are 5 spy cards, in sequence from stages 5-2. On the bottom row are two Defense cards, one in stage 5 and one in stage 3.
There were several “archetypes” of cards in the game, which had similar functionalities and visual motifs. The more powerful versions were introduced as the game progressed.

For that feeling of progression between rounds, I divided the game into 5 separate decks – one each for stages 5-1. Players would start out drawing and playing cards from Stage 5, then shuffle in 4, and 3, and so-on as the deck got low on cards.

Diagram labelled "Iteration". Top shows 5 sets of cards, labelled "The game is divided into five stages." The left shows a set of cards laid out, with arrows pointing towards slots where cards were placed, labelled "1) Players take turns drafting cards." On the right, the same cards, now face up, with the label "2) At the end of each round, all cards are revealed."
Some revisions were made. Notably, I decided to take a cue from Go Fish, and leave all the cards face-up in the center of the table. Not that constantly passing five whole decks around wasn’t fun or anything.

The physical version of the game underwent a couple big iterations – largely in service of figuring out how to make things flow smoothly. I was actually a bit smart about the workflow, though; most of the iconography and assets I made were designed to work across both cards and game UI, meaning they were Unity-ready.

Diagram titled "Translating to Digital", showing 4 different versions of a game UI for ultimatum. Mostly the same as the physical board in layout, but with a variety of small tweaks to test different versions of the UI.
Game UI tests. Some assets were in-game, most mock-ups.

The gameplay HUD was by far my biggest snag when it came to making a digital version. This wasn’t really an issue with the cards themselves – but rather a consequence of my desire to represent things on an actual battlefield, rather than just digitizing the game board. Would the latter have been easier in retrospect? Absolutely. But this was a student-era side project, and I felt like challenging myself to come up with some sort of solution.

Picture of a later demo build of Ultimatum. The top of the screen displays two player health bars. The stage is overlayed on each side by a transparent row of card slots,6 for each team. A pop up shows the current cards on the leftmost base.
The UI setup for the final demo build of Ultimatum.

I ended up settling on an overlay UI close in design to the original board’s, and using the battlefield as the combat display at the end of each round. At that point in the year I was pretty pressed for time, so the UI was a bit dense for my liking – but I did manage to get something I thought looked fairly decent, and could be refined into something better.


Part 3: Conclusion?

A pale, pink landscape against a black sky. A single missile arcs from the left side of the screen to the right, leaving a blue trail behind it.
An early mockup for Ultimatum – a deck-builder and accidental auto-battler I created in college.

In the end, Ultimatum was a project that suffered from a number of design and planning problems – hence it not having its own slot on the portfolio site at the moment. The digital version was more a proof-of-concept than anything else – a quickly-assembled demo that was more for the sake of my own learning than having a polished product.

The physical version holds up a fair bit better in my opinion, with a fairly solid bit of visual design (for the amount of time put into it) and some fun and interesting card interactions. The main issue it suffered from was over-complexity; not that the rules themselves were particularly complex, as-written, but that there was, I think, too much information to keep track of for a smooth gameplay flow. There were resource costs, stats, individual card abilities, an initiative system, drawing/playing rules, different rules for types of cards, discard/graveyard mechanics, a life system, and more – 75% of which came into play in secret, and then all had to be activated and calculated out at once. For a game with a more traditional sort of turn structure, where cards were openly played onto a field one-by-one, everything would probably work just fine. But, in testing, I had a definite feeling that the mental load might be too much for… well, anyone who hadn’t spent the three previous weeks creating the thing, I suppose.

Still, all of that said, there are a number of things I really, genuinely love about my work on Ultimatum. I still hold that a lot of the core mechanics/ideas are sound – and with some simplification, would be a good little card game. They just needed some more time, and a bit less overhead complexity.

Diagram showing progression of two card archetypes. On the top, a borderland patrol agent is visible in the art of other units with similar functions down the line. On the bottom, a spy is visible on several cards, from conscription , to a sabotage mission, to an escape, to running a message. Both the spy and border patrol agent are visible, conversing in a late game card called "Mobilized Legion".
The borderland patrol agent and conscripted spy both appear repeatedly. This was originally to signify card functionality, but ended up telling a little story about their respective journeys.

The visual design, for both the documentation and game assets, remains some of my personal best, and includes some of my favorite work I have ever done. That’s not to imply that these visuals weren’t lapped by the art on most of my bigger projects – but there’s a lot of communication and storytelling that I managed to cram into these card designs, without terribly cluttering things. From the repeating “characters” in cards of similar function, to the styling of the card type indicators – I’m really happy with what I was able to do in the time I had for them.

I really like a lot of the ideas in Ultimatum, and – to this day – find myself thinking about returning to them. There’s something about the way that the game plays that really stuck in my brain, from the semi-random unit pool, to the teambuilding, to the… placement…

…the placement of units. In a line. And the way they all move forward and fight each other at the… end of the turn..

Hey, wait a sec-


Part 4: Wait A Second! Did I Just Make An Auto-Battler???

Super Auto Pets, developed by Team Wood Games, is a quintessential entry in the auto-battler genre of video games. It’s also been my personal procrastinatory obsession of choice for the past several months.

Image of a battle in Super Auto Pets. The left team, "The Pouting Ghosts", consists of a crab, a secretary bird, a songbird, a dodo, and a salamander. The right team, "The Flying Icecubes", consists of a porcupine, a door-head ant, an elephant, an emu, a guineafowl, and a saiga antelope.
An image taken of my friend/teammate, Annika, playing Super Auto Pets as I was writing this post. She doesn’t know that I put this image here. It’s a surprise. Hello Annika. Thanks for saving me the effort of getting my own screenshot.

SAP, and many auto-battlers like it, are team-building strategy games. Each turn, players spend resources to purchase units and equipment, which they place on a battlefield. At the end of each turn, the player’s team goes up against another team of similar standing, and – as the turns progress – stronger and stronger units become unlocked. Players must try to build a team that can last to the end of the game.

You may be seeing some similarities here.

The realization that Ultimatum was, mechanically, just a… “manual” auto-battler hit me while I was playing SAP a few months ago – like a vision from the past.

Or a brick to the head. From the past.

When I set out to make Ultimatum, I had no experience with auto-battlers as a genre, whatsoever. I had no real knowledge of the genre’s existence, even. I was trying to adapt some mechanics from CCGs and board games that I liked into a tower-defense, card game, genre-hybrid thing. Somehow, the solution I came to was the same as an auto-battler – except I was making the players do all the math.

A dark blue game board, with one side for a light blue team and one for a magenta team. Top from left to right: A blue circle with 20/20 health, a blue deck of discarded cards, the word "ULTIMATUM", a magenta deck of discarded cards, and a magenta health bar, 20/20. The bottom half of the board contains a 12x2 grid of card-sized slots. In the top half of the grid, are numbers, 1-6 on each side, running towards the center of the board. On the bottom of the grid, a few spaces with cards.

The visual and structural similarities are obvious at a glance, from the games’ systems to the layout of the UI. There were even cut mechanics – separate attack and health stats, upgradable units – that are auto-battler genre staples.

Again, I had no knowledge of the genre. My point of reference was my dormitory’s Magic: the Gathering game night. And the old flash version of Clan Wars. Yet, somehow, I still managed to stumble into the same genre as Super Auto Pets. More than anything, I just find that kind of funny.


Part 5: Conclusion (the Real One)

This is, of course, not me being clairvoyant – it’s just how game design is sometimes. While there’s something deeply funny to me about arriving at Super Auto Pets by way of “tower defense Magic: the Gathering“, what strikes me the most about this is the ways that other auto-battlers avoid some of the pitfalls I faced with Ultimatum.

As I said way back at the start of this post, Ultimatum was predominantly inspired by card games – and, as such, always focused on card-like elements. The main theme of a cold-war-esque buildup is represented by literally stacking decks – where the threat from your opponent is the massive pile of face-down cards waiting on one of their bases.

I still think that that concept is cool. However, in the heat of gameplay, the fact that players are juggling so many units, so many positions, and so many secrets, begins to bog down the flow of the game. Where, in something like Super Auto Pets, you can have 5 units with abilities and items, in Ultimatum, you can have 6 bases – each of which can have several units. That is a lot to deal with for a player – and not necessarily the best way to create strategic complexity.

If I were ever to return to a project like this, I think my big takeaway would be to tamp down the complexity of the board state itself. Something like having the last card placed on a base be the one that determines that base’s ability for the round – so that there’s still a sort of strategy to jockeying for the cards you need. There’s something fun at the heart of this project – it just has a bit more it can learn from the games around it.

As do I, it seems.


Oh, wow. This ended up being way longer than I intended. Sorry about that.

If you made it this far – thanks so much for reading! You’re helping me untangle years of game design thoughts formed under the extreme pressure of college. It’s hard to pick out which ideas I had then were good or not, and I if I hadn’t written this… I might have started working on yet another game project that I do not have time for.

Anyways… thanks!

Leave a comment