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.

Games: , , ,

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: , , , , , , ,

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
    render :action => play_sym and return
  def pocket
    pocket_sym = "pocket_#{@card}".intern
  end # PH: no explicit render here? Feels like a paste error
  # plays
  def play_roland
    # Play the game to see what happens when you play the Roland card!
  def play_water
    # Play the game to see what happens when you play the Water card!
  # pockets
  def pocket_roland
    # Play the game to see what happens when you pocket the Roland card!
  def pocket_water
    # Play the game to see what happens when you pocket the Water card!

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
  def pocket
  def load_card
    @name = params[:card]
    @card = "card/#{@name}".camelize.constantize
  def default_render_card
    render :template => "cards/#{request.action}/#{@name}" unless performed?
# add in config/application.rb:
module Oaqn
  class Application < Rails::Application
    config.autoload_paths += %W(#{config.root}/app/cards)
# and then create app/cards/roland.rb:
module Card
  module Roland
    def pocket
      # code for pocketing
    def play
      # code for playing

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.

Small Steps
Games: ,

In Week 5 of So Play We All, things were pretty quiet. I bugfixed and laid groundwork. Luke… uh… did something. I read his post and it sounds like he added some helpers but otherwise mostly just rewrote his story. It’s more enjoyable now (seriously, play it), but it doesn’t really feel structurally any different. There’s no added mechanics that I can see. I’m curious where he’s going, though.

Meanwhile, Jim is apparently suffering from Python poisoning, because he’s naming events __LIKE_THIS__. He’s swirling into madness:

Once Version 1 is stable, I’ll compile a list of “official” Events that developers can utilize in their own projects.

No, I didn’t make that up. Not only is he thinking about a framework for multiple games, he’s thinking about a published framework for multiple games. Not, you know, his game. I see why Luke earlier used the phrase architecture astronauts. Jim, you are a great many abstractions away from writing a game, and I think the air is getting thin.

More encouragingly, Jim’s been writing about some of the deities in his game world: Dani, Rhegar, Nuri, Shisane, and Kesok. I understand the setting is largely based on long-gone-by D&D campaigns. It’s great to see some player-facing information.

Now Featuring Monsters
Code: , , , ,

The So Play We All theme this week was “core game objects” and the time budget was 3 hours. I did did well for myself, time to review the others’ work — both of which included monsters.

Luke did well this week as he started to build out his combat system, including party members who (unless he’s hacked it in, but it doesn’t look that way) respond to locations and enemies. It’s a start at gameplay, though your choices are pretty limited so far. I like the idea in the blog post about having party members you can configure but not directly control, it reminds me of Ogre Battle.

Also, he’s started the storyline, including “the fact that the bear can’t seem to find you is important”. When you play, the bear enemy appears to be completely incapable of attacking you. Just for wild-ass guessing’s sake, I’m going to guess the player starts as some kind of ghost. We’ll see how I did when the storyline takes shape.

Jim… continued to work on the controllers for his web framework, as he did last week. I felt like this:

> Application creates CommandRouter and TemplateDisplay instances

I’m very happy for it.

> Application retrieves Events from the CommandRouter for the current Post data (usually none)

So, it’s like how PHP populates $_GET and $_POST for you before invoking a script, but redundant.

> Application retrieves Events from the CommandRouter for the current URI

Events are sounding awfully general purpose. Wasn’t this a game? I feel faint.

> Application loops through the current events (events can be added while processing other events) and calls the CommandRouter->ProcessEvent() method for each one

It’s a generic message queueing system. The world is going dim…

> CommandRouter creates any necessary controller and sub-display instance for the event and passes all data to any module event handlers registered for the current event

It is pitch black. You are likely to be eaten by a grue.

> Created controllers determine models to use which add their data to the relevant Display objects (which are further applied to the TemplateDisplay instance)

No, really, a grue. It eats developers who don’t finish games.

> Application renders the TemplateDisplay

The grue dies of boredom.

Jim mentioned he liked the Mortal Kombat drawing last week. I guess he didn’t click on it. It’s a link to a great article, which includes:


There are pros and cons to writing your own engine. But ask yourself, do you
really have to? Is what you want to do impossible to do with what’s already out
there or would you be reinventing the wheel? Of course, if you write your own
engine you can make it just perfect the way you like it. But be honest, how
often do you ever get past the engine to the game itself? Do you find yourself
making game engines more often than you do games?

Bring the thunder, Jim.

SPWA Week 1 Response: Code Hassles and Kittens
Games: , , ,

This week in So Play We All our topic was “Signup” and our budget was 4 hours. I originally pushed for more time, but I ended up glad that it was short as I hacked things out on the last day. I don’t need to belabor that, let’s look at how Luke and Jim did with their games.


Jim wrote about a lot of
technical progress
, but unfortunately it all falls into the category of
invisible infrastructure, there’s nothing for a player to see. It really
reminded me what a huge boost Heroku is for
hosting: not only is initial deployment about 5 minutes, it prevents you from
spending time tinkering with your server setup for only minimal gains. (I don’t
know how he got more votes than me, I suspect sympathy from similarly
frustrated PHP coders.)

In all, it’s been a difficult 4 hours… but well worth the effort, in my opinion. I believe the extra headaches I’m taking now will allow me better flexibility in the long-term.

The bulk of his post seems to be about improving his own ORM and site infrastructure. Ouch. It sounds like he’s written some nice code, but this contest is about building one game, not building the next ten games.

Maybe the Real Ultimate Power of Drupal will make it a breeze to drop in community features like a forum and a chat, but right now he has nothing to see and he’s falling behind.

Fantasy Adventure

I’m glad to hear Luke’s stepping up his game after his brief blog posts for week 0. Not that I don’t mind easy competition, but I don’t want people to think I rigged the contest by setting myself up against a sucker. :)

In seriousness, Luke did great this week, he got my vote in the poll. We both used Devise for registration, but he got his basic install much faster and then streamlined it to make it easier for people to get into his game.

Yes, into his game! I’m not sure if it’s just static text or he created a basic player object with a few attributes, but he threw together a decent template and you could click around to move between different locations. Currently there’s just a bit of cute story to read, but that’s enough for the player’s imagination to start filling in gaps and imaging a world. (Also, bonus points for using delightful PlaceKittens, I’ve bookmarked that as a resource.)

That ability to fire the imagination is a great sign for Luke’s prospects. Time for me to go step up my game in response.

SPWA Week 0 Response: A Strong Start
Games: , , , ,

As mentioned in the rules for So Play We All, we’re required to respond to each other’s progress update. I’m going to be doing the Oaqn progress updates on that blog but the feedback here, mostly to keep that blog focused.

Showing off his superior time management skills, Jim quickly posted about Allabrilyn. It sounds like a collectible card game (or maybe LCG). That the collectible elements are units for a tactical game is… awfully familiar.

I dropped Athenge as a project because I realized I love the genre, but it’s actually really uncommon. Tactical wargames have a hardcore fanbase (a blessing and a curse), but it’s certainly not a big one. And building a game around PVP that’s mostly based on the player’s skill progression means there’s going to be a lot of dissatisfied bad players who don’t want to participate. So I think it’s great that Jim is building my kind of game, but I worry about his market. (And Jim – don’t just sell random packs, add a premium currency that players can use to auction/sell cards between themselves with so that you don’t create a secondary market that gives you support hassles but not income.)

Next up, Luke explained Fantasy Adventure Game. I loved this post (though of course, not so much that I voted for it over myself). He’s immediately willing to be imperfect in public by beginning with a terrible working title. It’s a great sign for getting over embarrassment to develop something great. I’m terribly jealous that he included financial info from the start; I’d wanted to but it slipped my mind. More guts!

As for the game itself, it leaves me a little flat. I’ve seen too many games default to fantasy; I hope he finds ways to turn his ignorance into interesting genre redefinition rather than middle-of-the-road generictown. It really sounds like it’s a single-player RPG (having not played KOL), so I think he’s going to have problems with producing content (items, quests, skills, etc.). Multiplayer interaction, competitive or cooperative, is wonderful content because you can set up systems that players fill up with content. It takes a fraction of the time to code a PVP game like chess than it does to write a text adventure like Adventure, and chess is probably fun for far longer because it becomes about other people, and people are interested in people.

I also have one criticism to level at both games: there’s nothing for the player to identify with. In Oaqn, the player controls a single caravan, that’s them in the world. (And I very likely will add some kind of human player avatar to play dress-up with eventually, because that’s even better.) In Allabrilyn and FA, the player controls a collection of characters, so there’s nothing for them to feel represented by or invest in the well-being of. This is why RPGs (and many other games) have a heroic mime character leading the party, so the player has an empty template to fill up with their personality. It’s much harder to do that with a deck of cards or a small troupe, and it’s a powerful motivator for casual online games.

My lengthy braindump rocked this week’s poll, with 6 votes for me, 1 for FA, and 0 for Jim (who I guess is not even active enough on the forums anymore to even vote for himself). I’m happy for that, but I think I’m going to face stiff competition that’s constantly thinking of things I’ve missed. So all I can do is plan to steal those things like revenue details for next week, muahaha! (Speaking of which, I’d better go put in my hours before I wind up owing these guys money.)

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