Economics Doesn’t Believe in Magic
Games: , , , ,
1 comment

On a writing forum an author asked for users to think of what societies would do with the magic system he designed. Here’s a short rewrite of his setup:

Every person gets a magical talisman when they turn sixteen and visit the magical super-talisman granting object. The talismans can do any wonderful thing the person requests, but a powerful effect will be tempered by limitations on use and frequency. So Alice might get a talisman that can light a candle flame at any time, but Bob’s magic fireball might be only usable once a year after he sacrifice a chicken. Talismans can be bought, sold, or stolen, but they’ll eventually stop working when the person who requested them dies. The world’s technology is roughly contempraneous with the early rennaisance.

Later, the author talked about how he wanted to have “clockwork guilds” that powered their creations with magical ever-turning keys, etc.:

That being said, my intention to begin with was to make talismans mundane, even to the reader, to reflect the fact that they’re old hat for the people in the [world], and balance the system around making talismans more useful in the long run for everyday tasks rather than slaying monsters. The sense of “magic” would come finding information about the mysterious surrounding polities (which have their own talismans), and the origins of the [super talisman granting objects].

I didn’t think the world would turn out like that. At all. And it hangs on this:

Talismans can be bought, sold, or stolen

This makes talismans into commodities, subject to all the usual rules of economics. This applies to all kinds of settings where magical is at all reliable (though sometimes it looks like labor rather than magical items).

The common individual will never own a talisman, and the nobility will own millions. Individuals will be given very specific direction, on pain of death, as to what talisman they will be requesting and giving to the nobility. The age of granting is not 16, it is the youngest someone can reliably repeat their noble’s order for a talisman. It’s even younger in a failing state when the nobles get desperate.

The nobility will be incredibly powerful, because they’ll have a super-powerful once-per-decade talisman for each hour of the day. Nobility will be immortal, if the talismans can affect longevity at all, otherwise hereditary.

The talismans the nobility request, however, will be so trivial they can be tested instantly, probably a mood ring. Think of old monarchies making alliances: they’d either explicitly swap family members as hostages or implicitly by marrying them off. The sending family would keep the hostage’s talisman as a way to check in that that they’re alive and in good health (or maybe even spy a bit).

Nobles will live like dragons on hoards of talismans. There will be a lot done to ensure that their guards are loyal (eg. talismans to detect and punish theft). Because they’ll want use of more talismans than they can hold, they’ll rarely leave. But they might lend out a large part of their hoard to their armies to go seige another noble for their hoard. Perhaps offensive talismans will be more powerful than defensive talismans, much like nowadays artillery is more powerful than castles, so nobody builds them. But a hoard of talismans is so dang useful… well, the political situation hangs on the technological. If a defense outpowers offense, castles. If not, endless total war.

Fertility, reliable food, and maybe medicine (but not medical talismans used on peons) are important to the nobles because they keep the talismans working. They’ll have telegrams, too. It’s hard now to imagine life when major news moved at about 4 mph (see The Discovery of France for an exploration of this), but it took a lot of time for major news (death of the king, war, etc.) to pass by rider and minor news could take much longer. This society will just require some kids to get talismans that can be used as telegrams.

Actually, why not an assassination talisman? A noble orders a talisman that, when used, kills a specific named person to bump off a rival. Even if it’s only useful once ever, that’s fine, you get to kill that pesky rival without an invasion and then your guard puts the requestor to death. Why waste fifty years of grain on that peon when it could go to the peon who requested the talisman that keeps your fingernails manicured?

More of a crapsack world than the early rennaisance was, really.

The author argued that if requestors feared theft they could request talismans that only worked for them or when freely given, but I think that’s misapplying contemporary mores onto a very different world. The monarchy used to rule by the grace of god, and talismans let them go that one step further. When I say “noble”, don’t think “prince”, think “living deity”. Nobody would be told they can restrict their talisman to themself, or allowed to live if they tried it.

Story Time

You’re a young man growing up in the city not too far from the capital. Your whole society worships one god, Phil. Phil is a loving, wonderful god, not like the scummy, wretched gods of faraway states. Your parents worship Phil devoutly. They bring you up to love and respect Phil. They tell you stories of when Phil visited the local cathedral (I mean, Phil laid the capstone three hundred years ago, but his latest visit) and bestowed blessings on the people: Phil cured a blind child, gifted wonderful crafts, and righteously slew a murderer with magical fire. This visitation was one of the highest moments in their entire life.

You are looking forward to your talisman ceremony more than any kid has ever looked forward to a bar mitzvah or christening or thread ceremony because Phil is so obvious, so real. You can still see the scorch marks on the wall of the cathedral! It’s a few feet to the left of the gallows where they hang the wicked children who fail in their talisman ceremony and have to be ritually sacrificed lest the entire town be tainted by their curse.

The ceremony is a mystery – I mean, everyone knows that afterwards you’ll get your adult name and be of majority and you’ll go to heaven after you die (which won’t be for a while, Phil’s looking out for you). But what happens in the talisman ceremony? Nobody talks about it, but you know you and the other kids your age will go to the church where the priest (who performs minor miracles by the grace of Phil, peace be upon him) will lead the ceremony.

Finally the big day comes – for the first time you get to wear the robes all adults wear to church. Your father saved up months to buy the cloth and you’ve seen your mom working late into the night to sew them. They’re obviously not blessed yet, but you’re excited just to be wearing them – maybe you run down to the town’s mirror to admire yourself, careful not to get them dirty. But still, you arrive early to the cathedral, can’t be late for the big day. After the week’s usual ceremony you and your friends are all called up on stage and everyone makes a big fuss over you. Then you head downstairs, and the priest tells you that it’s time to make a special prayer to Phil.

Flavio, that annoyingly preachy devout kid, gets to go first (and the rest of you go in The Order of Asch, which just means most-devoted first, for some reason). He reads the words over a talisman and after the priest listens and receives the talisman, he bestows the blessing of Phil and Flavio glows with a miraculous, unearthly light! His robes are marked by the light, recording his blessing for all to see at church every week. Flavio is sent upstairs to be received by the congregation, who will see proof of his devotion to Phil – why, you can already hear their cheering!

Now it’s your turn, and you receive a scroll to read, asking for – I don’t know, something about manicuring fingernails? But you know it doesn’t matter what it says, it’s time to prove your devotion by reading it. Your whole life has been leading up to this moment and you’re about to become a man! What do you do for your god Phil?

Economics

Really, it’s silly that nobody built a wall around the super-talisman granter to charge admission. (Or even sat on the road to rob people on their way home.) A talisman is a valuable commodity. Pople want and take valuable things from each other – not just by trade but by trickery and force. It doesn’t matter that they’re powered by magic, this is how commodities work.

The society the author envisioned has talismans for practical tasks like lighting candles and turning clockwork, and it has mercantile guilds, and emerging democratic notions. It has clever clockpunk and spunky heroines and taverns bursting with quest hooks.

Phil the living god has five thousand soldiers willing to die for him, each carrying their own magic missile talisman. Phil also has magical artillery and magical supply lines.

How long, in days, does it take before Phil has conquers Questville? (Hint: it’s the number of days it takes to march from Phil’s castle.)

An Alternate Setup

Talismans are such a fun idea and we want magical clockpunk worlds that it’s easy to forget they’re a commodity. Let’s imagine another magical world:

Imagine a world in which every 16 year old is given $100,000 by visiting a super-talisman in a specific place. They can request the form it’ll take: maybe gold bullion, dollars, a check, a jewel, etc. There may be tradeoffs: maybe they end up getting $10,400 dollars once per year for ten years (or whatever, I’m not doing the Net Present Value calculation), or maybe their jewel is unpolished and needs finishing, whatever – the magical granter balances it so everyone gets exactly $100,000 worth of value. In other places with other super-talismans maybe you can only get specific money-related things like an +1 point on your checking account’s interest rate or -5% to your credit card’s rate. Through some magical handwavey process (capitalism), even these limited bonuses can be transferred to other people.

Now let’s imagine how society incorporates this phoenomenon, and keep in mind that the value of these compounds: if I have ten people’s $100k, I can offer you more for your “$100k over 10 years” and have a tighter profit margin (or just hire more guys to take it from you).

What percentage of these 16 year olds have their $100k ten years later? A year later? A week later? The society will extract that from them, fast, whether it looks voluntary (“throw yourself an adulthood party!”, “buy your guild apprenticeship”, “make the down payment on your house”, “you get to pay off your childhood debt today”) or mandatory (“it’s a tribute to Phil”, “your money or your life”, “we’re going to borrow your kid for a week and take them to the super-talisman”). People don’t just leave valuable things in other people’s hands, especially not in the hands of inexperienced kids.

The talisman system has 90% the same problems as this setup (that 10% is the “it stops working when you’re dead”). Getting talismans compounds how easy it is to get more talismans. In a low-tech low-institutional-trust world, this looks like warfare, religion, theft. No matter what, institutions and norms appear to justify and encode these practices.

Extra credit version: in our world, every 16 year old is given this commodity in the form of their future labor as soon they are no longer considered restricted child labor. Explain how society has commodified and extracted this talisman with an eye towards our stunning inequality in wealth. Project textbooks: On The Wealth of Nations, Das Kapital, Samuelson’s Economics.

(If you’re super curious, here’s the original discussion.)

Ironwood, a Roguelike Game in 7 Days
Games: , , , ,
3 comments

Ironwood is a roguelike game developed for the 2014 7 Day Roguelike Challenge. “Roguelike” is a pretty poorly defined genre, but generally speaking it’s a turn-based game with generated environments, emergent gameplay from simulationism, and a steep learning curve. (For more, see an informal definition, a formal attempt, or a current take on its broad use.)

Updated 2014-04-07: You can play Ironwood in your browser right now! Big thanks to Snarky for the Javascript port: Ironwood

Continue this post

CTF Liveblog
Games:
2 comments

Friday

It’s on Friday afternoon and time to start working on Capture the Flag game. After chatting with friends I have some vague title/theme ideas. In the sprites there’s this row of pieces that look like a broken crest:

crest pieces

I’m not really sure what they’re supposed to be, but they prompted some theme ideas that fit with teams playing CTF over and over on random maps. Maybe there was a great evil sealed away that has broken free. It was defeated, but its wild magic broke the world into ever-changing pieces. Which is not so bad as things go, but it would be nice to put things back together again. There’s a bit of a tragedy of the commons, though – whoever is the one to reassemble the seal to fix the world will have the power to shape it, so rival groups (families? clans? guilds?) are trying to take the pieces away from each other and remake the world to their design.

Continue this post

Random The Flag
Games: , ,
6 comments

Oryx 16bit Fantasy Characters

I’m going to spend next Friday to Monday making a game. I was inspired by Oryx’s 16bit sprites, they’re a beautiful, cheap resource for game prototyping (the license is a bit confused for business purposes). I’ve been wanting to (and failing to) make games for years, so I’m going to ensure I succeed by defining the game by the time I spend rather than the infinitely long wish list plan I can invent.

Continue this post

FTL: Simulationism Lost
Games: , ,
3 comments

All weekend I’ve been captaining a series of (mostly doomed) Trek-like starships in FTL, a new indie game. The gameplay is mostly derived from time management and roguelike games (more on that later), as you juggle crew between tasks, shift power between systems (straight up “more power to the engines and target their shields!”), and balance exploring the galaxy with fleeing from an ever-advancing plot device that’s too boring to describe.

It feels intimidating to start, but despite a half-hearted tutorial it’s pretty easy to pick up if you’ve ever seen a battle on Star Trek. Most of the time you’re figuring out new strategies for dealing with emergencies like fires, boarders, robot boarders, and damaged systems and then juggling your well-limited resources to “make it so”.

As you progress you can upgrade and reconfigure your ship with found and bought parts. With 9 ships (each with a variant layout, though all but the first ship must be unlocked through hidden in-game quests) and a heavy-handed random number generator, most games are about quickly strategizing in dire circumstances, which is where the game shines.

Simulationism

The buzz is that FTL is a roguelike, though I’ve only seen one good review explore what that means. The one thing missing from this writeup is “simulationism”. As you fight through the unending hordes of enemies in a roguelike, those hordes are part of the same simulation you are: they use the same hit point system, the same weapons, the same options available to you, and suffer the same pains you do. If your character can get frozen and have an arm broken off and soldier on partially dismembered, so can your enemies (the ones that have arms, anyways).

Roguelikes allow deep strategies by simulating complex systems (there are, of course, other ways to get deep games). Dying (and oh, can you have some fun getting the ship blown out from under you) is teaching you new ways to destroy the enemy starships that you can see run on the same rules you are. You could build up shields and let environmental hazards destroy your enemies; or send over a boarding crew; try to burn out their crew or space them; use automated drones to harrass; bring overwhelming firepower to their defenses — and these are just some of the core strategies.

It feels like there’s a ton to do and try, and there is, but your choices are badly constrained by a flaw I’ll discuss under the spoiler heading below.

Complaints

Cruising the galaxy isn’t all the fun it could be. In each game you’ll pass through 8 sectors of ~25 stars (though you only have time to explore around half of those). A narrow majority of systems have an enemy to fight, the rest of the time you’ll have Trek-like events where you have to negotiate with aliens, investigate an anomaly, or react to some peril. After two or three games, you’ll have exhausted most of the events the game has to offer, which is boring because they’re all simple dialogue/action choices that only occasionally care what kind of crew or equipment you have.

Not only do they get boring, they’re very random with harsh consequences. You find a derelict freighter, do you want to investigate? Maybe you get a little bit of scrap, or maybe you get a game-changing weapon, or maybe one of your 3-8 crewmembers dies outright. There’s no way to assess or influence the odds, and (painfully for such a Trek-inspired game) you can’t even send a redshirt to do the deed. In one event a mine attaches to your hull, flip a coin to learn if you lose a vital, painstakingly leveled-up crewmember.

There’s also heavy randomness in what’s available to you. Because the plot device keeps you from exploring too much, you may see few of the ~16 stores per game and never see one you can buy vital upgrades from. FTL’s randomness is great for generating new circumstances of encounters and new strategies, but the wide variance can make games impossible to win, however well you may be playing. (As a quick example: instead of selecting store type completely at random, fill a deck of cards with a distribution of store types and draw from it as the player arrives. Random generation with reduced variance.) Nethack has a lot of randomness and I almost always die thinking “Oh, I should have…” Even after I’ve learned most everything about FTL I’m sometimes left feeling “Yeah, I couldn’t have done any different, it was out of my hands”.

Aside from these major problems there are a few nits to pick in the UI: it’s hard to see crew health (especially enemies), you can’t rename crew in the middle of the game or carry names between games, you can’t direct crew to open or close doors if your control is down, and if your sensors are down (due to damage or being in a nebula) the only indication that an unoccupied compartment is on fire or leaking air is easily missed. The big UI frustrations are that there are few keyboard shortcuts and after almost every combat you’ll have to do 20 seconds to three minutes of routine, totally safe clicking to repair and reorganize back to peak form.

Summary

On the whole, the game feels unpolished and flawed. It has some great moments and emergent gameplay undermined by too much variance, UI, and big bad design decision (to be discussed below).

If you’ve been waiting to command your own Trek-style starship, really like lasers that go pewpew, or sorely miss the subsim genre, you should absolutely buy FTL.

If you’re at all on the fence, though, I’d say wait. It has some rough edges and the endgame is a mistake. There will be a great game coming in a few months, or maybe in a year or two. I don’t know if it’ll be a DLC, a sequel, a fan mod, or a clone that gets it right, but someone will polish this rough gem into a classic.


Simulation Lost (Here Be Spoilers)

In talking about variance I touched on fairness. Roguelikes, as brutally difficult and unforgiving as they may be, feel fundamentally fair because of simulationism. The same hazards that are your bane as you learn can be turned into weapons against your enemies. This breaks down in FTL and leaves the game feeling seriously unfair.

A minor example of this (“minor” because the player is less likely to notice a flaw that works in their favor, not because I’m going to be terse) ship engines are upgraded and powered both to improve how likely a ship is to dodge incoming fire and how quickly they offer the option to flee combat. When you are in battle, your FTL is continuously charging; when full you can click to jump away instantly. Charging takes about 30-60s (which is often too late to avoid crippling damage).

Enemy ships will only occasionally try this (even though in-plot every enemy without overpowering superiority should flee at the first opportunity) and you’ll get a pop-up to warn you. Which is odd, because if their FTL works like yours, it should already be powered up when you’ve jumped into their system – or at worst it should be powering up all through combat just like yours. Because it would be frustrating to have enemies constantly jumping away with no warning, the devs added an explicit notification that the enemy crew is selecting that strategy. Fixing this inside the game system would mean a lot of rebalancing: maybe engines aren’t used for evasion and so are not powered up except to charge for FTL, or maybe there’s an entirely different system of FTL that’s less Battlestar and more Trek. This one doesn’t have an easy answer, but the game has rough spots because issues like this got a band-aid instead of a redesign.

The real problem, and the big spoiler, is that the last sector isn’t about exploring but hunting and fighting a boss ship that is far more powerful than any previous ship. It has huge shields, tons of weapons, strong crew defense, and you’ll have to defeat it three times.

Because of its unprecedentedly powerful equipment, the boss battle is gear check. You lose if you don’t have one of the couple weapons powerful enough to break down its super-shield. And because it has more weapons than anything before, you lose if you don’t either have the single piece of equipment that can fix hull damage (hull repair drone) or you get really lucky with the three disappearing, probably-not-close-enough repair ships or you lose. It’s that stark.

You can play your best but go an entire run without once seeing the items required for the boss. You had lots of fun strategies available for attacking previous ships, like using boarding parties and special weapons to target the enemy crew. In the boss battle, the devs decided that those strategies were simply wrong, and even if you succeed over the record-large crew and its unprecedented defenses, the game tells you “no” and, like being told the enemy wants to escape, you’re told an AI takes over for the crew. If you didn’t build your ship around a handful of strategies, you can’t win.

It’s deeply unsatisfying for every game to end with a simulation-breaking fight with an opponent that is roughly twice as strong in every single aspect than the best of any enemy you’ve seen before. I’ve seen a lot of complaints from people about the random number generator, and I think this is what’s at the core of that. Either you get lucky enough to get the equipment for the viable boss strategies or you lose. All the deep gameplay earlier is swept away.

The worst part is it’s probably easier to fix than the engines. Instead of one boss that’s overpowered in every way, create a dozen ships that are overpowered at one or two of the strategies, then require the player to face down three or four in succession. Then the endgame isn’t a lottery the player has happened to win, it’s a test of whether the player has built and commanded an all-around capable starship, with a bit of luck that you don’t get a bad matchup.

So this is why I think FTL is a fun but flawed game. I’ve enjoyed playing it and I’ll play some more, but it’s not the game that people will remember for delivering on the promise of this setup.

Added Sep 28: found another good response (dead link: archive.org version) that makes an important point about positive feedback loops in FTL’s power curve.

Timing
Games: , , ,
1 comment

Luke, who writes backwards like DaVinci did some more game design with help from #bbg (on irc.freenode.net – anyone’s welcome to drop by to talk browser game development, it’s a great place). Reading his note photo, it looks like he’s breaking cards down into Settings, Characters, and Monsters. There’s not a lot more info, just that he’s spending his hours planning out his game.

Speaking of hours, I missed responding to something in his previous update:

Eventually, I’m going to create web interfaces for a lot of this stuff, but for now I’ll have to do any settings and etc. by hand in the database. By the way, the interface work isn’t strictly game-related and can be handled outside of So Play We All hours.

After the first week we said hours had to be budgeted towards code, but not marketing and blogging. It’s vague here, Jim, what are you referring to working on? If “interface” means HTML frontend, that’s code that’s gotta get counted, Luke and I both did a bunch of template work on budget.

Anyways, this week Jim’s got some nice top-to-bottom functionality done in his rendering engine. It felt a bit like my update about finishing off code from last week. He’s rendering a basic page:

We do not have DisplayRegions yet, so I am just some simple text. However, this page is now valid XHTML and not simple plain-text!

Congrats on the milestone, Jim.

Breakdowns
Games: , , ,
2 comments

When Jim asked me how many hours I could put to So Play We All this week, I said “Negative three”. That turned out to be pretty accurate, as I managed to drop on the floor all but the three most important things for my week. Unfortunately, Oaqn didn’t make that top three so I sent $20 each to Jim and Luke. So, let’s look at what I funded this week.

Luke had writer’s block, so there’s not a lot to say there. I’m a bit puzzled that he doesn’t say “coder’s blocK” because the hours are budgeted towards that, but I can see how it’d be easy to open a code editor and then stare at it.

I’ve chatted with Luke a bit about his game design and thought it was pretty solid, similar to stuff I’d seen on Three Hundred Mechanics . This really sounds like he’s trying to see the entire design up-front and getting overwhelmed by it. His big questions are all certainly important ones, but maybe it’s worth figuring out if there’s a way to take smaller bites.

Jim’s got his first progress that doesn’t sound to me like he’s reinventing a wheel. The template for a page is broken down into DisplayRegions, each of which has a Controller (“Component”) responsible for loading the right data.

It’s an interesting PHP-styled take on MVC. The top-level code that handles each request isn’t a controller action, it’s basically a template split into code/settings (“DisplayEngine”) and markup (“PageTemplate”). The template then lists what controllers and actions should be invoked to handle the request, which is a not how I’ve ever seen any web MVC work before. It feels pretty stereotypical of PHP to have a template running the show, and I wonder how much logic is going to leak into them as a result. A common pattern is that a section of a page with links to register and sign in — or, if there’s a user logged-in, to edit account settings and log out. Jim, in your system, where does that if (logged_in()) { [settings/logout template] } else { [register/login template] } live?

Keeping Jim Busy
Games: ,
1 comment

Oops, got totally distracted by flying back to Chicago and forgot to write my So Play We All response post on time, so there’s $10 each to Luke and Jim. Late but not lost, here’s that response. (Luke didn’t post an update this week, so I’m only responding to Jim.)

This week, Jim had a brief but significant update, writing:

Well, after so many weeks of being seriously far behind, I’ll finally be making the progress towards being able to render a complete HTML page.

He’s written his Page, Session, and Form classes to the point that he’s only held back by not being able to template pages from displaying real pages. I’m a little surprised he got votes in this week’s poll without anything to demo, but it’s nice to hear things are coming together for him.

Actually, maybe I should be worried that he’s going to start displaying a game sometime soon. So let me mention a great Rails feature you should spend time reimplementing, Jim. The pending release of Rails 3.1 includes HTTP streaming, basically the ability to send parts of the page while still working on generating the page.

This is how PHP’s page-as-script model works out-of-the-box, but it often leads to bugs when state changes during the page rendering. I’ve seen a lot of browser based games with a bug where a page says you have 100 minerals in the header and then, lower in the page, say that you only have 50 because loading this page performed an action that spent 50 minerals. Having an explicit stage that builds and renders a page usually prevents these bugs at the cost of being able to send enough information for the client to get working at downloading page assets while the server is still performing work. Continuing to support that may cost Jim enough time in gold-plating to keep me comfortably ahead.

(But just in case it doesn’t the 3.1 announcement also mentions an asset pipeline that compiles and compresses CSS and JS for faster pageloads. Have fun, Jim.)

Rewriting My Competitors
Games: , , , , , , ,
7 comments

It’s really clear that the polls So Play We All are measuring progress. When we have a quiet week, there’s a lot fewer votes. This week, there were 4, evenly split between Luke and I. The SPWA site doesn’t have code to handle ties so it highligted me as winning, which I guess means the bugfix is not my problem. :)

Luke laid down code for cards. I know I’m helping the enemy, but I’ve got to tweak it. His code is:

class CardController < ApplicationController
  def play
    play_sym = "play_#{@card}".intern # PH: this should be .to_sym
    self.send(play_sym)
    render :action => play_sym and return
  end
 
  def pocket
    pocket_sym = "pocket_#{@card}".intern
    self.send(pocket_sym)
  end # PH: no explicit render here? Feels like a paste error
 
  protected
 
  # plays
  def play_roland
    # Play the game to see what happens when you play the Roland card!
  end
 
  def play_water
    # Play the game to see what happens when you play the Water card!
  end
 
  # pockets
  def pocket_roland
    # Play the game to see what happens when you pocket the Roland card!
  end
 
  def pocket_water
    # Play the game to see what happens when you pocket the Water card!
  end
 
end

I’d write this code as:

class CardController < ApplicationController
  # I'm guessing from usage above @card is just the name for a card as a string
  # and that it's loaded from the url by a filter, note that I use it differently.
  before_filter :load_card
  after_filter :default_render_card
 
  def play
    @card.play
  end
 
  def pocket
    @card.pocket
  end
 
  protected
 
  def load_card
    @name = params[:card]
    @card = "card/#{@name}".camelize.constantize
  end
 
  def default_render_card
    render :template => "cards/#{request.action}/#{@name}" unless performed?
  end
end
 
# add in config/application.rb:
module Oaqn
  class Application < Rails::Application
    config.autoload_paths += %W(#{config.root}/app/cards)
  end
end
 
# and then create app/cards/roland.rb:
module Card
  module Roland
    def pocket
      # code for pocketing
    end
 
    def play
      # code for playing
    end
  end
end

So now the cards each get a source file to themselves, templates have their own per-action dirs (better swapped to per-card dirs, if there are more actions), there’s less duplicated code, and it’s far easier to test these smaller pieces. The only thing missing from this example is the fact that Luke may have to pass some game state into the methods. As long as there’s not too much it’s probably worth being explicit about.

2011-07-09: Luke actually used this code and found it didn’t work as written. I found an explanation; either add ‘app’ to autoload_paths instead of ‘app/cards’, or drop the Card wrapper.

Meanwhile, in the past, Jim wrote some PHP, and I’m not touching that language.

No, in seriousness, Jim talked about why he has some identifiers surrounded by __ (which I’d called python poisoning). I haven’t dug into his code (again, PHP), but it looks like it might be an InBandSignal to reuse Events as framework steps.

And then he talks about session fixation attacks, which are have been protected against out-of-the-box on PHP with the session.use_only_cookies setting for a while. I was a bit confused, I’m pretty sure he’s actually describing session capture attacks. Oh, and there was some other stuff about writing code to store sessions in the database. If you’re curious, Jim, here’s the code for a Rails app to do that, which appears commented-out in the stock config file for your editing convenience:

  Oaqn::Application.config.session_store :active_record_store

It includes support out of the box for keeping sessions in cookies (encrypted, of course), your SQL database via ActiveRecord, or Memcached. I’m curious, how much of your budget did you spend storing sessions?

Two Turnarounds
Games: , ,
1 comment

I was really impressed by Luke in week five of So Play We All. He built a playtestable game fast and, more importantly, he learned from it. He’s decided to completely rework his gameplay. Player interaction wasn’t what he wanted and he realized it would be a huge amount of work to write. It’s not easy to decide you’ve spent time building the wrong thing, and that maturity impressed me.

And, you know, I’m a huge fan of card games, so it’s nice to see another one in development.

As great as that is, Jim got my vote in this week’s poll.

In a post titled Deity Development he responds to some criticism and then links to the documentation for the abstract work I was hassling him about doing the last few weeks. I’m glad to tangibly see his progress, and it looks like he’s got a solid core built now.


Fatal error: Call to undefined function twentyseventeen_get_svg() in /home/malaprop/push.cx/wp-content/themes/pushcx/archive.php on line 45