[ Return to The Short Circuit - Research Bunker ]

Bits - Cards - Actions Ratios

By Leonard D. Blado

BLADOLE@HSDWL.UTC.COM


Theory

One of the problems confronting both deck design and play of Netrunner is the evaluation of different methods of generating the three primary resources in Netrunner, namely Bits, Cards, and Actions. Amongst cards that fundamentally act in the same manner (Score and Livewire's Contacts, for example), we can easily state that one is "more efficient" than another. However, between cards that use these three resources to differing extents, the issue becomes muddled.

The easiest method seems to be to assign a ratio between the value of these three primary resources, and to use that ratio to reduce the question to one of comparing two identically scaled numbers, rather than weighing three different variables. While this method lacks accuracy, and the ratios themselves must be presumed rather than calculated, it can provide a vital tool for analysis.

The rules clearly establish a correspondance of 1-1-1 between Bits, Cards and Actions, but this is slightly misleading. Since this correspondance is directed- ie: Cards and Bits cannot be converted into either each other or Actions- this serves to place a minimum boundary on the value of Actions. Irrelevant of cards in play, it is a fact that at Action is always worth at least 1 Bit or 1 Card.

Furthermore, an examination of the cards shows that, in a continuous sense (ignoring cards that provide an immediate boost with long term drawbacks), the maximum limit on the value of an Action can be placed at 4 bits (Score!/Accounts Receivable), or 5 cards (MIT West Tier/Bodyweight Synthetic Blood/AI Chief Financial Officer). In reality, optimal values fall somewhere in between- these maximum values are clearly unattainable in an absolute sense.

Using this theory, we then establish a Bits - Cards - Actions Ratio (or BCA Ratio), which, while differing for each deck, will not substantially differ from an optimal BCA for the set of cards as a whole. That is, while some decks will generate more cards than bits, the intrinsic limitations of the card set will confine the efficiency of any given deck to the limits described above. Thus, while conceding some inaccuracy, and, indeed, rendering the method inapplicable to certain bizarre deck designs, we can establish a set of numbers which will clearly describe a range of efficiency- any sequence of effects which exceeds this range of efficiency can be labeled "effective", and any sequence of effects which is below this range of efficiency can be labeled "ineffective".

In order to simplify the mathematics involved, we must adopt two premises that are obviously false, but should not be significant enough in the majority of decks to severely skew the results:

  1. Rather than having 6 separate directed ratios, we will presume that the designers of the game, either consciously or unconsciously, restricted themselves to certain "ideal" ratios. Thus, while there is no card in Netrunner that produces Actions directly from Bits without the consumption of cards, if there were, in order to maintain game balance, it's cost for use would not be less than a certain value. And since there are cards that produce Bits from Actions without any consumption of cards, we can calculate this minimum value. This leads us to a estimation of an "ideal" ratio between Bits and Actions. Likewise, this process can be extended for Cards - Bits, and Actions - Cards. Note that this point emphasizes that, by the nature of the game, translation from Actions - Bits is inherantly cheaper than Bits - Actions, and that translation from Actions - Cards - Bits is inherantly more expensive than translation directly from Actions - Bits, but by ignoring this, we can simplify the mathematics considerably.
  2. In the majority of decks, the optimal BCA Ratio can be achieved fairly early within the game, due to the cost of cards and the ability to develop intrinsic in the game. While this effectively renders use of the method ineffective in the initial game, it does lend a clue to in what manner the playfield should be developed.

In addition, it is a certainty that, due, to the different cards sets available for Corp and 'Runner, that different optimal ratios will exist for the two sides.

Method

While calculation of a precise BCA ratio for the set of all existing Netrunner cards is beyond the scope of this document, we can presume from observation a "sample" BCA Ratio to aid in our understanding of the use of this tool. Suppose we decide to compare the value of two cards in how effective they are in gaining bits, using a sample BCA Ratio of 4-5-2.

Example:

Short-Term Contract has an installation cost of 1, and returns 2 bits/action for a maximum of 6 actions. Thus, if we were to gain the maximum benefit from Short-Term Contract, we would use:
Bits = -1 (for installation) - 12 (gain from Contract) = 11
Cards = -1 (for the card itself) = -1
Actions = -1 (for installation) - 6 (for actions to retrieve bits) = -7
Reducing to bits, we get:
cards to bits = -1 * 4/5 = -.8
actions to bits = -7 * 4/2 = -14
Adding with our original bits, we get:
final cost in bits = 11 - 14 + -.8 = -3.8 bits
Note that this should not be interpreted as "losing money", as this figure is taken in isolation.

Now examine Score!- which has a cost of 5 bits, and returns 9 bits:
Bits = -5 (to use) + 9 (gain from Score!) = 4
Cards = -1 (for the card itself) = -1
Actions = -1
Reducing to bits we get:
cards to bits = -1 * 4/5 = -.8
actions to bits = -1 * 4/2 = -2
Adding with our original bits we get:
final cost in bits = 4 - 2 - .8 = 1.2 bits
Clearly, using a BCA ratio of 4-5-2, Score! is a better play to gain money than Short-Term Contract.

This does not, however, indicate that Score! is fundamentally better than Short-Term Contract. First of all, the ratio 4-5-2 was "invented"- while it is likely that any optimal BCA Ratio for the 'Runner is "near" this ratio, these figures were not arrived at through analysis of either a specific deck or the card set as a whole.

One point we do know with certainty, however, is that the only way in which to make Short-Term Contract more "efficient" than Score! is to change the ratio between Bits and Actions, since there are an identical number of cards spent. And we know with certainty that an Action can never be less than 1 bit in value. Recalculating using a BCA Ratio of 4-5-4, we see that:

Short-Term Contract = 3.2 bits
Score! = 2.2 bits
In other words, in the worst possible case, Short-Term Contract is better than Score!, in an arbitrary median case, Short-Term Contract is worse, and in the best possible case, Short-Term Contract is horrendously worse than Score!

More enlightening still is comparing Short-Term Contract to the "no card" scenario. If you had to gain net 11 bits without a card, you would have to invest 11 Actions to do so. Using the original BCA Ratio, we see than this would result in -11 Bits (-11 Actions * 4/2 = -22 + 11 bits gained = -11), clearly far worse than the Short-Term Contract would provide.

Time

Many cards in Netrunner require an initial outlay of Actions, Bits, and Cards to relentlessly produce some sort of resource. A common example would be the Floating Runner BBS, which, for an initial outlay of 1 Action, 6 Bits, and 1 Card, provides 1 bit/turn for the remainder of the game.

It would be useful to know how much a "turn" is worth in this situation, so we may compare it against more standard cards for it's efficiency. The simple answer would be that 1 turn = 4 actions (for the 'Runner) and 1 turn = 3 actions (for the 'Corp). While this method can be used, it is deceptive, since these cards do not "consume" actions, but rather require that they be consumed by some other source for that sources' benefit. A more reasonable approach is to regard such cards in regards to the amount of time it takes to repay their initial investment, adjusted by a small amount to compensate for the inconvienience of not having funds on hand, but, inside, receiving them at some future time (interest).

The Floating Runner BBS, using a BCA 4-5-2, would "cost" approximately 9 bits. This means that 9 turns must pass before any bits are actually "created" by the Floating Runner BBS. Once those turns have passed, the Floating Runner BBS starts to actually generate bits. If we assume that 10% "interest" is the penalty for the delay of the usefulness of those bits, it would actually be closer to 10 turns. From experience, this is easily half the average Netrunner game. In other words, use of the Floating Runner BBS indicates that the deck is willing to spend half of the game in a cash-deficit state in order to spend the remainder of the game in a cash-bonus state.

While the above example may not be precise in the particulars, it should serve as a guide to thinking about the relative value of time dependant cards.

MU

MU is another resource that does not precisely fit into our BCA definitions. By the existing definition, most programs are definitively better than most hardware/resources that they duplicate the functionality of. The reason these cards are balanced is because they consume MU.

In order to analyze the cost of such a program, we must retreat to the specific deck we plan to use it in- a general rule will not suffice. The simplest method is to evaluate the deck's MU needs- that is, how many MU will the deck require to perform optimally? If this number of MU is 4 or less, then we will not need to incorporate any additional boosters to MU, and such programs are vastly more efficient than their hardware/resource counterparts. However, if the number of MU is greater than 4, then we must add enhancements to compensate for this greater MU usage. Since these enhancements cost bits, cards, and actions, we can easily express the value of a program in terms of not only the bits, cards and actions required to install and use it, but also the bits, cards, and actions required to install the upgrade to permit it's MU consumption.

Installation Cost

Earlier, we mentioned that Score! was easily identifiable as more "efficient" than Livewire's Contacts, since for the same consumption of cards and actions, it generated a greater number of bits. However, further examination reveals that this is not always the case.

For example, if the 'Runner has no bits in their pool, drawing a Score! is next to useless- it would take 5 actions (in a naked environment) to gain enough bits to play it. In other words, it would take 6 actions and 1 card to generate 4 bits. This is clearly not a very efficient use of resources. Drawing a Livewire's Contacts in the same situation, however, would retain it's efficiency of 1 card - 1 action - 3 bits.

Last Words

Despite the somewhat mathematical nature of the various methods above, this document does not purport to set forth an absolute system for the comparison of decks and individual cards in Netrunner, but rather a series of systems that can be used as tools for examining the issue. None of these tools is particularly accurate, and all are highly dependant on the individual player's selection of certain constant criteria which are not easily deduceable from the existing card set, but they still can have a positive influence on design and play if used properly.

The guiding revelation here is that the effects of cards cannot be looked at in isolation- the consumption of ALL resources involved with the use of a card or combination of cards must be evaluated before it can be declared effective or ineffective in accomplishing a goal.

Lastly, it should be remembered that the guidelines above ignore the vast majority of the cards in the game, concentrating instead on the development of crucial resources. However, in general, by assigning some range of values, generally expressed in bits, to each effect in the game, usually a comparison between two similar effects can be made.

In conclusion, none of the above should supersede experience and judgement on the part of the good player. Many cards and combinations have effects too complex for such simplistic analysis, and should not be discarded because of unfavorable mathematics behind them.


Created on: August 1, 1998
Last updated on: August 1, 1998
Created by: Scott Dickie <codeslinger@mail.com>