Building Browsergames: a brief design document

One important but often neglected part of building a browsergame is planning it – what you will be building, and how you will be building it.

So far, we’ve built a login and registration system for a browsergame – but not much else. In order to plan a little more out for our game, here’s a small sketch of what we’ll build(at least to start off):

  • Town

  • There will be a town, where users can access all of the shops/etc. within the game. These shops are the bank(pays interest on each daily visit by the user), the armor shop, weapon shop, and healer(although there could be more shops later).

  • Forest

  • There will also be a forest area, where users can get into fights with creatures and search for items(very low chance to find items). Users will be able to search for monsters, visit the spring(random 2% chance to have something cool happen), or search for items/go back to town.

  • Monsters

  • To begin with, there will only be a few monsters. These are their names(they don’t have stats yet):

    • Crazy Eric
    • Psychotic Jeff
    • Laid back Nick
    • Lazy Russell
    • Hard Hitting Louis
  • Tracking

  • A count will be kept of how many of each particular monster a user has killed – eventually, this might be used for a quest or something.

  • Administrator Control Panel

  • It would be nice to build an administrator control panel, so that administrator users can easily add items/monsters/etc. to the game, without having to interact with(and potentially screw up) the database directly.

And that’s what will be in the browsergame that we’ve been building – if there’s anything else that you think should be in it(or you’d like to learn how to implement – we can add it in), just send an e-mail to

Wish there was more?

I'm considering writing an ebook - click here.


Luke is the primary editor of Building Browsergames, and has written a large portion of the articles that you read here. He generally has no idea what to say when asked to write about himself in the third person.

Thursday, May 22nd, 2008 buildingbrowsergames, design
  • Jacob Santos


    Keeping presentation separate from business logic is the foundation for good development, however, PHP is already a templating system. Using an abstraction on top of something that already does a good job at abstracting code is not a good idea.

    Many languages do not have the luxury of combining code with HTML, which forces them to keep it separate and building the abstractions into their business logic. This creates complexities that are not needed. The primary focus should be building a solution as quickly, but as professional as possible.

    Smarty goes against this by forcing both the designers and programmers to learn the language of Smarty. You then have to hope that the next project also uses Smarty and not some other convoluted custom system. I've seen many custom templating systems and I have to say that not many projects use Smarty.

    Another issue from the developer's point-of-view is extensibility, which is difficult for Smarty, because while it has its own API for it, not every custom templating system will. The API for Smarty (when I last checked) was not as simple as it should be.

    When I write a template system for a project, I think of WordPress, because they do it as easy as possible for both developers and designers ("Just plug this code in to your code and it just works"... "In most cases."). As opposed to spending two or three weeks learning how to use Smarty and other two or three weeks trying to learn how to extend Smarty with custom tags.

    I can do everything Smarty does using just (X)HTML and PHP, which Smarty abstracts from the developer and designer. If you ask me, PHP is far easier to use than the syntax Smarty forces you to use.

  • While PHP *does* have enough built into it to freely intermingle your
    business logic and presentation code(and even seems to encourage you to),
    I'm wary of writing code that does that. Frequently for my own projects they
    have begun with a sole developer(me), and then as they have gone on the team
    has grown - all too often, a designer who knows nothing of PHP and has no
    desire to learn it is the one who will be doing the final design for the
    game. In those situations, being able to give them a list of the variables
    available to them in the template and the Smarty documentation has proven
    extremely useful to allow me to keep focusing on features, while someone
    else focuses on making things look nice.

    While embedding PHP directly into your files is an option, it is a bit of a
    messy one - and it makes it far too easy for someone who doesn't know enough
    PHP to have a firm grasp on what they're doing to break something that they

    To be clear, I am certainly not saying that Smarty is the *best* or *only* way to develop. I'm simply saying that your code *should* be abstracted from your presentation, and using a templating engine like Smarty or something else is a better way of doing that(in my opinion) than relying on someone copying and pasting code without understanding what it does.

  • Warlords

    is it possible to have a example whitout Smarty??
    If u have a link to something u can mail me.


  • I am afraid that the tutorials have been written with Smarty in mind; using
    a templating system lets you keep design and code separate from each other.
    There is no Smarty-less version of the tutorials.

  • I wish successes in your building. I will watch updatings.

blog comments powered by Disqus


Building Browsergames is a blog about browsergames(also known as PBBG's). It's geared towards the beginner to intermediate developer who has an interest in building their own browsergame.


Got Something to Say?

Send an e-mail to, or get in touch through Twitter at