Archive for May, 2009

Braindump: Risk MMO

I frequently get odd little ideas into my head that I know full well I’ll never follow though. Rather than let them fade away, I feel I should start writing them article writers needed down in case someone else might be interested.

A Risk-Like MMO

At one point there was a version of Risk written for the Google Maps API (which has since been shut down by Hasbro). I wasn’t a Risk player when it was around, but now that I am, it got me thinking about multiplayer Risk over the internet — and then about a massively multiplayer extension of the game rules…

Obviously it wouldn’t extend to thousands of players like WoW; more like 50 or so per game. And it couldn’t follow the original rules too closely, or it would be unmanageable. (Imagine waiting for your turn in a 50 player game!)

Here’s some rough ideas I’ve come up with so far:

  • First off, call it something other than Risk, or Hasbro will string you up!
  • The map is subdivided into real, contemporary territories. Larger countries are divided into their states or provinces. (Instead of 9 territories for North America, it consists of the 50 states of the USA and the 13 provinces & territories of Canada.)
  • Where this gets unwieldy (eg. USA), the states could be grouped into regions which roughly approximate the original territories. Controlling a region earns a small benefit (say +1 reinforcement), and the whole nation earns some additional benefit. At this point, controlling the entire continent may not need additional bonuses because of cumulative effects.
  • Players are assigned a rank each round, calculated first by territories, then regions, then units, and finally by a random number assigned each round. (All else being equal in the first round, rank is random.) Players can see each others’ ranks for the round, so they know where their biggest threats lie.
  • Each player takes their turn simultaneously. They have a fixed period in which to enter all their movements, then all battles get resolved in one batch. Battles are processed in rank order. The players are shown the results of the battles, then the next round begins.
  • Turn order is as follows:
  1. Fortify (except first turn) — this happens first instead of last, because you only find out the results of your battles at the start of your next turn.
  2. Reinforce — place units as normal
  3. Attack — you can only attack from territories you control in the current turn. For a territory with X units, you can allocate up to X-1 units to the attack. This many units are committed to the battle; all surviving units will move to the target territory. If all X are killed without a victory, the attack ends. One territory can attack multiple targets by splitting the unit count. (eg, for a 6-unit territory, 3 could attack one target, and 2 could attack another in a single turn.) Battles are processed in the order they are entered.
  4. The turn ends when the player is satisfied, or time runs out.
  • There will probably need to be more interconnections between territories. Perhaps certain key territories could hold airports, with permanent connections to other airports. If you control any 2 airports, you can also reinforce between them (even if they don’t otherwise share a connection).

I’m sure there’s a lot more to take into consideration too.

If you’ve got any thoughts, feel free to leave them in the comments!

    Share

    Comments (15,013)

    DataBeans in Groovy

    Okay, not many will be interested in this perhaps, but I thought I might put it up. I use a data objects framework called DataBeans which you can find as part of cialis soft tabs the sticker.jar file in the compare cialis prices Sticker instant messaging tool (http://tickertape.org/projects/sticker). DataBeans gives you a JavaBeans style interface to nested hashmaps, but it has an event mechanism, so you can listen at the root bean and hear changes inside (including path info to the change).

    Neat huh.

    Anyway, my supervisor said he’d be impressed if I could do some Groovy (http://groovy.codehaus.org) meta-programming to allow access to DataBean properties without having to use the typical getValue(String name) and setValue(String name, Object value).

    After a little looking around I wrote this program which adds a couple of methods to the DataBean’s meta-class (what supports most of Groovy’s dynamic behaviour). All you need is sticker.jar on the classpath and this will work without issue (oh, I’m using groovy 1.6.0 but I think it’s available in 1.5.x).

    import dsto.dfc.databeans.DataBean
    
    DataBean jdb = new DataBean()
    jdb.setValue("a", 1)
    jdb.setValue("b", true)
    
    DataBean jdb2 = new DataBean()
    jdb2.setValue("aa", 42.0)
    
    jdb.setValue("c", jdb2)
    
    println jdb
    
    DataBean.metaClass.propertyMissing = { String name ->
      value = delegate.getValue(name)
    // the commented code will allow statements like db.a.b = 'c' when a is undefined
    //  if (!value) {
    //    value = new DataBean()
    //    delegate.setValue(name, value)
    //  }
      return value
    }
    DataBean.metaClass.propertyMissing = { String name, value ->
      delegate.setValue(name, value)
    }
    
    println jdb.c.aa
    jdb.c.bb = 'hello'
    println jdb.c
    
    try {
      println jdb.d.dd = 3
    } catch (NullPointerException ex) {
      println "NPE on 'jdb.d.dd = 3': ${ex.getMessage()}"
    }
    println jdb

    Even if it’s of no use to you, hopefully it may intrigue you to look at Groovy or DataBeans (when there’s a link for that I’ll post it).

    Share

    Comments off