Citizen: How do you know so much about crimes?!

Parker: I… read… blogs?

A great moment from Leverage where Parker is forced to pretend she’s not a master thief.

I have to find a way to steal this for my RPG campaign. So many of my favorite roleplaying moments come from when a character is forced to go far outside their comfort zones. It’s hard because that oftentimes means taking actions that the characters are bad at.

The times I’ve done this around inexperienced or goal-focused rleplayers, I’ve nearly caused riots. (the time at GenCon where my character was offered any weapon in the modern world I could ask for and he picked a taser was a great example).

We’re doing a Netrunner draft at Braintree soon after the New Year. I wanted to send the new drafters a cheatsheet on their first draft. Since I couldn’t find any online, I wrote my own.

What follows is one person’s opinion on Netrunner drafting after having gone through a few drafts. I have yet to win a draft tournament so take with a grain of salt.

How does the Netrunner draft work?

When the draft starts, all players will pick up the first set of 10 cards in front of them. They will each pick one card and pass the rest of the cards to their right. This means that each player will now receive the 9 cards the person on their left didn’t pick. Each player will pick one card from that 9, and pass the remaining cards to the right again. This continues until you are passed one card. When you receive one card from the player on your left, you will keep that card automatically and this round of the draft is over.

We will do this 4 times for Corporation cards and 4 times for Runner cards. This means you will draft 40 cards for each side. When you add these to your starter pack, you’ll have about 50 cards total for each side. Of these you will put roughly 30 (for Runner) or 34 (for Corp) into your deck. You can make changes to your deck from this pool of 50 between games.

Corp-side Drafting Tips

There are three pillars to the Corp Draft - Agendas, ICE, and Econ. There are other powerful cards that you should consider grabbing but you’ll be in trouble if you don’t cover these bases.

Agendas

The corp is required to have a certain number of “agenda points” based on how many total cards you have in your deck including agendas. If you have 30-34 cards total in your deck, you must have agendas worth a total of 14-15 points. If you have 35-39 cards, you must have 16-17 points of agendas. Conventional wisdom is that you want as few agenda points as possible in your deck while having the most cards total (to minimize the odds of a runner stealing agendas), so shoot for a 34-card deck with 14-15 points of agendas.

Your starter pack will contain about 17 points of agendas, but this doesn’t mean you should avoid choosing agendas in the draft! A diverse set of agendas gives you many options in how and when you score, not to mention the effects of each agenda. 3/2 agendas (that is, agendas that require three advancements to score and are worth 2 points) and 2/1 agendas are particularly powerful weapons for the corp to sneak out quick advancements!

ICE

ICE should generally make up about 30-45% of the cards in your deck. Usually you’ll want at least half of that ICE to have an “End the Run” subroutine and you’ll want at least half to be less than 5 credits to rez (not necessarily the same half though). Doing this ensures you have ICE you can rez in the early game and that makes a good defense.

Assuming you have a 34 card deck, this means that you want 11-16 pieces of ICE in it with at least 6 “End the Run” ICE. This isn’t a hard rule, but it’s a good starting point.

Diversity is often the key to a great ICE lineup. You’ll want a good mixture of Sentry, Barrier, and Code Gate ICE to prevent one kind of icebreaker from ruining your game. The same goes for ICE strengths. A variety of strengths creates a variety of challenges to the runner - higher strength isn’t always better.

“End the Run” ICE can be surprisingly rare in the draft. It’s not wrong to take “boring” ICE like Wall of Static or Ice Wall as an early-round draft pick. Aside from that, draft what seems interesting to you while keeping your ICE diversity and card synergy in mind. it’s no good to have a ton of tag-the-runner ICE if you lack the other cards to capitalize on it.

Econ Cards

Great cards are only great when you can afford them. You’ll want a number of cards that generate credits in your deck. These cards can take a variety of forms - agendas like Geothermal Fracking or Hostile Takeover that provide credits when scored, assets like PAD Campaign or Adonis Campaign that provide a steady stream of credits each turn, or operations like Hedge Fund or Medical Fundraiser that provide an instant influx of cash.

Usually having 15-33% of your deck generate income is good, but this isn’t as hard a rule as with agendas and ICE. Your starter pack will contain some solid econ cards, but you’ll likely want more. If you have a 34-card deck, you’ll want about 6-11 econ cards.

One thing to keep in mind with these: the more your economic strategy relies on assets or scoring agendas, the more end-the-run ICE you’ll need to keep the runner out or else you run the risk of easily being credit-starved.

Everything Else

At this point you may have a deck that looks something like this:

• 7 Agendas
• 12 ICE
• 5 Assets
• 3 Operations
  

That leaves 9 cards to do with as you please, and this is where the flavor and strategy of your corp deck comes from. This depends entirely on what you see in the draft. Look for cards that seem powerful when combined with the assets/agendas/ICE you have already picked for the deck or that have a number of potential uses.

Runner Drafting

In general you want your Runner deck to be as small as possible so that you are more likely to get the cards you need. 30 is the minimum in the draft - you should probably plan on having about that many cards.

We draft the Runner second so you should already have some idea of the Corp cards you’ll be up against. In particular, when you see a bunch of ICE that has some specific strength of vulnerability then you can use that to your advantage as the Runner when drafting. Don’t go overboard though - as your draft group is larger, the likelihood that there are great Corp cards in the pool that you didn’t see increases.

Econ

At least 25-33% of your deck should be econ cards. In a 30 card deck, this means about 7-11 cards for econ. Like the corp, diversity is good. Resource cards are often powerful credit generators but can be destroyed by any tag-heavy Corp deck.

Icebreakers

The number of Icebreakers in a Runner deck varies wildly but you should consider having at least 6-7 in your deck and no more than 15-16. The runner starter kit will include some number of AI Icebreakers (icebreakers that apply to any kind of ICE) but you shouldn’t rely on these alone without a backup plan. Some ICE are particularly strong against AI icebreakers or even immune to them.

On the flipside, you may not need an icebreaker for every kind of ICE either. A strong set of universal/AI icebreakers combined with some powerful “niche” icebreakers like Ninja or Corroder is often sufficient for a draft runner deck. These niche icebreakers are usually the most credit-efficient way past ICE of their type.

Everything Else

There’s much more freedom in building a Runner deck than a Corp deck which means there’s less advice to provide. If you want to go program-heavy (say, a bunch of viruses or exotic utility programs like Sneakdoor Beta), make sure you have the memory unit cards to install them. Don’t underestimate events either - just one play of Maker’s Eye or Inside Job can swing a game in your favor.

Runners have an easier time of connecting combos in the draft than the corp does since they have more flexibility in card draw. Since you’re unlikely to get more than two copies of any great card, favor combo cards that can create many solid-to-good synergies rather than a single, powerful combination.

Card draw is generally more important for the Runner than the Corp. Cards like Test Run that let you search your stack for an icebreaker or program can be very powerful for the Runner - these cards mean you can find the right tool just as you need it. Other cards that provide a boost to card drawing like Diesel (event: draw three cards) provide similar benefits for the runner.

Go Forth and Draft!

One last tip: as soon as the drafting begins, a smart drafter is observing their opponents for any clues about the decks others are building. For instance, invariably people at the table will complain about seeing many copies of a few “underpowered” cards. This means that if you can think of a way to make that card work, it will be easy to draft 3+ copies of it. In our first such draft, everyone bemoaned the excess numbers of Underworld Contacts they were passed only for someone to steal a horde of them and make a monster econ, untraceable Runner deck with them.

If you have any feedback or tips from your own draft experiences, please get in touch and share them! Happy hacking!

SP

Unfortunately I didn’t have enough time this weekend to participate in this round of Ludum Dare so I’m sketching out what I would have attempted given the chance.

The theme is “Entire Game on One Screen.” I thought about screens for awhile and how they are just a simplified view of an underlying system, similar in nature to Plato’s allegory of the Cave. I wanted to make something that really exploited that and provided imperfect information to the player.

COMBINED ARMS is a two-player co-operative mini-RTS that simulates the ground invasion of a city supported by a fleet of ships in orbit.

The View from Space

One player is the Fleet Admiral and sees an interface like so:

This player can see the entire map and the current status of all objectives. A number of control points have to be held before the capital (large building in top left) can be taken by friendly troops. The orbital commander can also take various strategic actions on a time delay (simulating the delay between launching something from orbit and seeing its effects). These actions include:

• Getting a city-wide scan that indicates troop density
• Getting a smaller scan that indicates unit position and type
• Launching a number of different kinds of orbital strikes doing general area damage, targeting buildings, or targeting specific types of units
  

Except for the moments after a scan, the Fleet Admiral lives in fog of war. The player can see the theatre of battle but doesn’t really understand any specific situation on the ground except as relayed by the ground commander.

The View from the Ground

The other player is the Ground Commander. The ground commander has a more typical third-person view of a small squad of units.

The Ground Commander is massively outnumbered by hostile troops and must use the power of the orbital fleet to even the odds. The Ground Commander has an almost perfect understanding of their immediate surroundings, but no strategic view of the city or objectives.

The Commander controls 4-6 units at a time. As units are lost, the Admiral can send in replacements but they are slow to arrive, and the fleet is otherwise useless while preparing them.

The war on the ground is relatively simple - units come in three flavors: tanks, walkers, and fliers. Tanks are slow, strong, excellent versus walkers, and can slowly destroy buildings. Fliers are fast, frail, excellent versus tanks, and ignore all but the tallest buildings. Walkers are a middle-of-the-road choice which are excellent versus fliers and can slowly move through buildings.

---

The “game” of Combined Arms is as much a game of memory and communication as it is tactics and strategy. It blatantly steals some of my favorite bits of Wargame, World in Conflict, and Full Spectrum Warrior and I make no claim of it being original (indeed, you could say it’s just a strategy take on Clandestine).

While I don’t have time this LD to do much more than make fake screenshots, this might be an idea I visit in the future.

I’ve claimed to have several spirit animals in the past, but in reality it’s definitely Tim Gunn.

Now that I have a basic prototype that adheres to the plan outlined in Part I-A, it’s time to build a server to support this game.

A longstanding (and totally hilarious) joke of mine is that I’ll play any game with a “Next Turn” button. As such, I plan to build a server that can support not just Clans but any future turn-based strategy games I build. Ideally I’d even love to open-source the server portion and allow other, less technical developers to start making this kind of game so that I can start playing them. =)

As such, here are my design goals for this:

1. Support multiple different “Games”
2. Support multiple users
3. Support users having multiple “sessions” in multiple “games” (a session is basically an instance of a game. In other words, “Clans” would be the game while my 1v1 game against Gourmand would be a “session”)
4. Support asynchronous chat within a session

So then, architecture: I initially plan to build this out as a rails-api application that primarily exists to persist game and chat state. The server will authenticate users and apps via OAuth2 password grants with each game as a different client.

While I’d be tempted to store game states on disk, serializing them to Postgres is the easiest solution for now since I plan to deploy to Heroku. I reserve the right to introduce a more sensible document store down the road however.

I haven’t found a way to incorporate Redis into this solution yet so let’s fix that. I’ll probably use it to store in-game chats as sorted sets per-user. Initially chat will only be global within a session so chats per-user is overkill. Eventually I’d love to support user-to-user chat as well though. Even if this turns out to be YAGNI¹, it will be YAGNIBIIF?²

Next Time on the Making of “Clans”

This wraps up most of my planning materials. Once I have a Trello board for Clans, I’ll add a link to it here. (edit: here is that Trello board)

Next up, I’ll share what are becoming my current “best practices” for code organization in Unity. This has long been a sticking point for me as projects grow, but I’ve come across a style that seems to be the least painful.

Footnotes

1. You Ain’t Gonna Need It, http://en.wikipedia.org/wiki/You_aren’t_gonna_need_it (ignore anyone who says that stands for aren’t, by the way) ↩

2. You Ain’t Gonna Need It, But Isn’t It Fun? (citation needed) ↩

The nice thing about working with a bunch of friendly and clever folk at Braintree is that they are always willing to brainstorm on better ways of building software. “Clans” is no exception, and within 20 minutes of posting Part I we¹ had come up with a simpler way to build it.

In our last thrilling installment…

I left off in Part I talking about running Unity on the server. It consisted of two parts:

1. Clients (our players) submit orders to the server that represent what they wanted to do on their turn.
2. When the server has all orders for all players, it processes those orders on the server and sends back to clients the new game state that results from it.

Turns out that Step #2 is overkill². Instead, once we have all players’ orders, we just have to send back to each client that collection of all players’ orders and let each client simulate what happened. As long as the simulation is deterministic, clients should end up with the same game state that the server would have generated. This avoids any kind of Unity/Mono running on the server at all.

This introduces the possibility of clients accidentally generating different ideas of the “current state” of the game and getting out-of-sync from one another. This is hardly a novel problem or indeed solution. The original Warcraft used a similar scheme in multiplayer albeit to solve very different problems than what I’m solving. There is a fascinating analysis of the Warcraft out-of-sync problem and its solution by one of Warcraft’s creators, Patrick Wyatt.

My solution will be a slight variation on the first step above. When clients send the server their orders, they’ll also send their understanding of the current game state. Specifically, each client will serialize the current state of the game as they understand it and produce an MD5 sum of the result. If any client sends an MD5 sum that differs from the others, the game is out-of-sync and is dealt with³.

The New Plan ⁴

1. Clients (our players) submit orders to the server that represent what they want to do on their turn. In addition they submit an MD5 checksum of the current game state.
2. When the server has all orders for all players, it verifies all clients had the same game state. It then sends back to clients all other clients’ orders.
3. Each client verifies and simulates orders on their own to determine the next game state.

Next Time, on “Clans!”

Scott outlines how the server will work, something he promised to do in Part I! Enriquela discovers a terrible secret about sharks! Captain Boontz makes a decision that will change OMEGA GOGO SQUADRON forever.

TUNE IN NEXT TIME!

SP

Footnotes

1. Credit specifically goes to Michael Fairley who did the lion’s share of the critical thinking so I didn’t have to. ↩

2. The server-side simulation approach has a couple of advantages still. In particular, it’s rather hard to cheat in that scenario. While “Clans” won’t have much hidden information, it will have some. A technically skilled cheater could reverse-engineer the client to provide omniscience within the state of the game. If Clans is popular enough to have that problem, I will be only too happy to revisit this scheme to simulate the game server-side and send partial state to clients. ↩

3. “Dealt with” is a euphemism for “game over.” This won’t be a Civilization-style game where someone would lose 30 hours of gameplay if a game terminates. Additionally, this should be an extremely rare occurrence. You could send out the previous game state and keep the game “paused” until you get consistent states back from all clients, but I don’t care enough about this problem to bother. ↩

4. Until my clever coworkers come up with something else, that is. ↩

In my previous post on my next game project “Clans” I outlined the kind of asynchronous turn-based strategy game I want to make. I didn’t discuss the implementation details though.

An asynchronous game implies there are persistent servers available to coordinate game state between players. I want to leave the option of an offline mode available, and I also need to make this easy to develop without having to run a server locally.

I experimented with a few options but it came down to two: build my game logic in a separate assembly and reference that from Unity, or take the compiled DLLs Unity creates of my custom code and find a way to run them without most of Unity.

Option 1: Separate Project

While building my game logic as a separate assembly is more logical and definitely cleaner, I ran into a few issues. While I don’t need most of what Unity provides in classes like MonoBehavior for my game logic, the utility classes around math and vectors would be a big help. Furthermore, Unity periodically likes to rebuild your solution files which forces me to periodically re-add my GameLogic project.

Option 2: Headless Unity

When you build & run your Unity game, Unity compiles all of the custom code you’ve written for your game into a DLL named “Assembly-.dll” (in my case, Assembly-CSharp.dll). This won’t work on it’s own though - you’ll need to pull in a few additional DLLs from core Unity to make it work.

After I tracked down those DLLs though, I was able to make a simple command-line application that used those DLLs to process some simple game logic. I’ll have to be diligent in separating my logic code from anything that requires Unity’s “MonoBehavior” components as anything that references any of their event lifecycle hooks like Start() and Update() won’t work. This shouldn’t be a problem for turn-based strategy games, as they shouldn’t be making use of Unity’s game physics or other logical components for any important bits of game state.

In the next installment I’ll show how all of this is going to come together. I may even make a diagram! GET READY

After a period of game-making hibernation, today I found the time to get back into shape. Previously I had teased about a strategy game called MUTANT OVERLORDS. As my design doc hit the 4,500th word for that game, I realized that perhaps it was beyond the scope of my current skills. I’d like to tackle it someday, but it’s prudent to start on something less ambitious.

“Clans” (very much a working title) is a simple asynchronous turn-based strategy game of hidden information. Drawing inspiration from the board game Sekigahara, victory in “Clans” will be achieved by surprising your enemy by your unit composition and choosing the right time to play “tactics” cards that can change the nature of battles:

Armies are composed of stacks of units and used to take key parts of a point-to-point map. On your turn, you’ll queue up movement orders for your armies. When you opponent has done the same, the orders will be resolved simultaneously.

Choosing and ordering the individual units of an army is the key mechanic of “Clans.” While your opponent will see your armies and the number of units in them at all times, they won’t know the composition of your army. Perhaps you’ve filled it with a number of cheap, fast units to give the impression of strength where there is none. Perhaps you have an elite few heavy hitters. Perhaps you have a mix:

Each type of unit will have an ability it grants to its army when it is the topmost “lead” unit in the army. In the above screenshot, a “shield” unit is atop the army which makes it both harder to kill and harder to move.

I have some further ideas on how this mechanic will work to offset the obvious “kitchen sink” army composition strategy that this otherwise lends itself to. I don’t want to say too much more until I have more than a simple mockup though.

The New York Times is reporting this morning that a settlement is close in the class-action lawsuit brought against Google, Apple, Intel, and Adobe for their discriminatory and illegal no-hire, no-solicit agreements amongst one another.

For those who haven’t been watching this case, those four companies (and previously also Intuit, Lucasfilm, Pixar, and eBay, who have since settled for pittances) have been accused by potential employees as having an agreement not to hire employees from the other companies. The proceedings have already led to the discovery of numerous emails documenting the process

I’d be very sorry to see this settled rather than set a precedent. I am fanatic about retaining employee mobility as society transitions further towards employees as disposable, transient resources. With the high-profile companies involved, this was a fantastic opportunity to clearly make this an illegal act for others considering the same.

This isn’t just theoretical either - I was nearly the victim of such an agreement back in 2009. A number of CEOs from bootstrapped Chicago companies and consultancies formed a networking group. The cost to entry was, amongst other things, an agreement not to solicit employees from any of the members of this group. When I reached out to Obtiva to work there in 2009, I was unlucky enough to work for one of the other members of this group.

I may have been rejected outright if it weren’t for the fact I found out about this and had a very lively conversation with my soon-to-be former employer. I was one of the fortunate ones though - I learned this was happening. Usually this unfair labor practice manifests itself in the form rejection letter, the unanswered email, or the strangely reticent recruiter. This isn’t even to mention the other victims like the Google recruiter that Steve Jobs had fired for daring to do his job in the face of these illegal agreements.

I’ll be crossing my fingers that this article is inaccurate, but I suspect not with the number of other companies that have already settled similar claims. It’s a shame - when a case like this settles for such small amounts, the only legal precedent becomes “don’t get caught.”

(On a side note - The New York Times has been fantastic in covering this case - virtually every meaningful update has been on page one of either their National or Business section. If you care about these things too, you might consider throwing them a few nickels)

It pleases me immensely that GATTACA has aged like a fine wine.