We're about to do something scary. We (me and my company that is) are taking the step of playtesting the core of our game to see if it's fun. Like any game in development there comes a time when the designs all fall away and good intentions are left by the roadside, and all that remains is what you have. Is it any good, is it not?

The main difference is we're doing our playtesting in public.

Simple Lifeforms is a social game company. We make games that work on the web through a social network like Facebook or Myspace. We primarily develop in web technologies like PHP or MySQL, and our game is hosted like any other web site or application.

For some developers that choice of platform is incredibly limiting as PHP and Flash are not exactly swish as game engines go. Maybe not. On the other hand, for us it's incredibly liberating.

As a social game designer, I can do something that most developers really can't: I can get my game in front of players today, hear their opinions today and fix their problems today. Obviously not for all cases in all instances, but that's the principle. Change game rules, add a virtual good, fix a market, balance a spell, I can do it all today. And they in turn can tell me what's wrong. Today.

So my game may not be a Halo killer but it is also not stuck in the mire of retail-politik. It's not crunching endlessly for milestone after milestone with only internal subjective quality assurance for guidance. It's not doomed to the artificial half-light of focus groups. I can just ask my customers what they think and then can quickly respond. What that really means is that I can build the game from the ground up.

This has been a surprisingly hard lesson to learn. I came up with a full design for Spell Souls in February. I wrote a wiki, wireframed schematics, created spreadsheets with various quantities and attributes like a regular designer might, but we quickly realised somewhere around mid-April that this was a big mistake. Details were not read, feature confusion crept in quickly, wireframes were not fully played, and nobody understood the game but me.

The reason this was (and is) a mistake is I was thinking in terms of design-develop-tweak. Design the game, make the prototype and content, and then tweak. That's how it worked on every game I've worked on in the last 8 years, but oh so wrong.  That's how retail games work in the old release-and-patch model. We realised that Spell Souls is not a retail game, it's a service game, and that makes the whole approach different. I read a lot of good advice, from blogs such as Startup Lessons Learned, and we talked about the importance of getting the game in front of players as fast as possible. Spell Souls is attempting something a bit unusual, so how can we know that the core game mechanic works?

We certainly can't afford to just sit on it for 9 months and continually prototype. So I worked to scale things back. And then I did it again. And again. Scope revision is normally a final activity and though a team tells itself that cut levels, enemies or content will go back into the game if there's time, it very rarely ever happens. Gone is usually gone. With Spell Souls, I could cut to get at the core of the game to playtest it, but gone is not gone.

My game does not have to be fixed for features like a retail game. I'm not selling something in a box or a downloadable game on Xbox Live. I have no long lead times to worry about, not approvals and no corporate structure requiring buy-in. Web applications tend to settle on their core functionality after some iteration but they can always change. Facebook recently changed its whole front page interface and features to focus on new priorities, so why can't I change Spell Souls to do likewise? The only reason is if customers don't want that.

So a lot of our expanded features are sitting on a roadmap while we try and get the core right first. This is something we can not only afford to do, it is something that we should do. After all, what if the core of the game sucks? What if it's great but players like it for a different reason than we assume? What if it's partially good but there's one very obvious thing missing? All of these are huge questions that any developer has to, at some point, ask of themselves.

The main difference for us is we get to ask you too, and I'm pretty sure that you'll be much more brutally honest than we would ever be with ourselves. As I say, it's scary stuff.

If you want to join the Spell Souls playtest, join the Group on Facebook.

(@tadhgk)