Latest Entries »

Late to the Dance

Been busy with another startup and some contract work. Need to get back to Dungeon Adventures. It’s so close.

My Mom’s on Facebook?

Interesting demographics information: My Mom’s on Facebook?.

ARPU (average revenue per user)

Looks like RPGs are doing well. Good news for us. Numbers are all over the place but $0.2 – $0.12 seems possible with RPGs at the high end.

See: What is the average ARPU (average revenue per user) for a social game these days? Today?

I just finished Raph Koster’s A Theory of Fun for Game Design.

Overall I’d rate it as good with reservations (four stars).

It’s a bit too philosophical, repetitive and  self-reflective for my tastes. I was hoping for something more formal and rigorous. I found myself wanting to skim over text in search of substance. The book is really short, maybe a couple hours at best. Every other page is a crude drawing and many of the pages with text don’t use the full page. I think the intent is to reinforce the games are art premise. It reminded me of Scott McCloud’s Understanding Comics: The Invisible Art. Similar tone and feel, but I think it falls short whereas McCloud’s work delivers. Maybe Koster should have written a game to convene his message. After all one of the bigger points he’s trying to make is that games teach.

The good news is that every so often there’s a brilliant and incredibly insightful tidbit. I had a couple ah-ha moments when I suddenly saw game design in a different perspective. The book has altered my own game’s design. For $16 and a couple hours this is a bargain. So in the context of Pac-Man: you might have to eat a lot of dots to find the rare power pellets, but they are there and probably worth the effort.

Concept Art

Our art director sent over some concept art. Possibly for a splash screen or the town map.


Dungeon: Skull Entrance

Dungeon: Mausoleum Entrance

At the risk of starting a language war, let me state that the language you choose for a project matters.

My first program was written in Integer Basic on an Apple II in the late seventies. I think it was a graphical screen saver that displayed randomly generated geometric shapes in beautiful 8-bit color. Since then, in approximate order, I’ve used: Commodore Basic, MS Basic, C, REXX, Pascal, Modula-2, Oberon, LISP, C++, SH, KSH, BASH, LPC, X86 Assembler, Prolog, SPARC Assembler, Perl, Java, SQL, PHP, Python, Ruby, Erlang and Google’s Go. These days I’m most familiar with Perl, Java and C.

For this project I prototyped the backend of our first game in Python. For the production implementation I wanted to look at options. Successful Facebook games get a lot of traffic so I wanted whatever we built to quickly scale. For servers, I can increase the memory and CPU on the fly with my RackSpace server. If I outgrow a single server I can provision new ones in five minutes. Now I believe with the proper architecture you can scale any language, but some scale easier and more efficiently than others. For Java, you have a large memory foot print. For Perl, Python and Ruby you need to figure out threads vs. fork/exec vs. third party framework vs. some kind of resident interpreter as none of those languages were really designed for multi-processors or multi-cores. With C you have the power to do pretty much anything you want, but it tends to be tedious to do it. This is something Google’s Go language might mitigate, but I didn’t think Go was production ready.

So my thought process went like this:

C: Powerful, but really slow and painful to implement. A few years ago I wrote the streaming software for Live365 in C. It gave us a couple orders magnitude more scalability over our previous third-party solution. But it was easy to shoot yourself in the foot and introduce a memory leak, a deadlock condition or core dump. Lots of debugging required.

Java: Powerful. Easy to find developers. Rich features set. Proliferation of resources and frameworks. Handles all the tedious parts of programming like memory management. The problem is that every time I write Java I feel like I’m running on a sandy beach. I’m working hard, but making slow progress. The language is too verbose and I think the bloated language features and gazillion frameworks only slow developers down.  Bruce Tate talks about this in “From Java to Ruby” and I live this daily as I’m surrounded by bloated and buggy Java code that’s prone to memory leaks. It also seems to take months to implement the simplest of our projects.  With the right environment I’m sure things would improve, but it’s kind of a lowest common denominator effect. As a language becomes more popular the average quality of the developer that uses it goes down. I think there would be a significant difference between ten randomly selected Erlang or Python developers verses ten randomly selected Java developers. I’m digressing. I’m firmly in the Bruce Tate camp: Java takes about three times the effort to get anything done compared to Ruby or Python.

Perl: Perl has been really good to me, but I didn’t want to use it for a large project.

Erlang: Erlang is an amazing language and perfect for highly-available and scalable software. After reading Richard Jones’ “A Million-user Comet Application with Mochiweb” I was pretty excited.  One big hurdle is that Erlang in a functional language and you have to change your mind set to use it. I did that years ago when I used Prolog and it’s not always easy after years of living in a functional world. Ultimately this was the main reason I passed on Erlang. I was worried that it would impede my ability to bring others onto the project.  I did look at Scala briefly, but it’s not nearly as robust as Erlang and carries a lot of Java baggage.

Go: Google’s Go holds the promise of an easy to use system language. Main issues were the lack of third-party support. I didn’t want to be fighting with immature drivers or have to implement them myself.

Python:  My favorite language. Not perfect, but incredibly productive. I still find myself blown away by how much I can get done in a few hours of work. What annoys me is the lack of multi-processor and multi-core support. It’s something you need to understand and architect around in any project that needs to scale. There are a lot of options like Stackless or Twisted, but in the end gevent looked like the best approach to handling large numbers of network connections. Python supported all the drivers and third-party libraries that I needed.

So basically the language choice boiled down to: can is reasonably scale, is it accessible to others, does it easily support my third-party needs and is it productive. I give Python an A for being productive which is why I tend to think of it as a secret weapon. As a tiny company, we need to use technology to our advantage. Programmer efficiency is critical.

Random Dungeons

Our game has dungeons. They are small and randomly generated. As this is a Facebook game we tend to think of them as flowcharts and try to keep them simple.

To help us get a feel for how our random dungeon generator works, we create PNGs of  each. This is just a visual representation of what we store in the database minus all the fun details like doors, traps, monsters, stairs, etc…

Currently we pregenerate many thousands of them and store them in our MongoDB database. This gives us a chance to check the quality and offloads resources that would be needed to create them on the fly. For a quick QA check I can display 264 at a time on my monitor. Checking a few thousand goes surprisingly fast and I just delete the ones that I don’t like before loading them into the database. Note that each white box is a room.

Dungeon 82:

Dungeon 82

Dungeon 348:

Dungeon 348

Dungeon 11:

Dungeon 11

As you can see they are basic, but we think they’ll work fine for our game. The algorithm could use some fine tuning as I think they tend to cluster more than I like such as with Dungeon 155:

Dungeon 155

and Dungeon 234:

Dungeon 234

Anyhow they are good enough for now and we have other features that need more attention.


Time to get busy!

We’ve been working on our roguelike inspired Facebook game and making steady progress. Our focus has been on the server and database which is built around Python/gevent/MongoDB. So far it’s working out well, but we’re still flushing out the framework and APIs. Once it’s ready I’ll implement a testing framework to beat up the interfaces and look at the overall performance. I’d like the backend to be solid before doing getting too deep into the client.

Eric’s also be cutting his teeth on a basic company website. Our background is mainly server-side as opposed to presentation so it’s been a learning experience. Gives us a greater appreciation for great web designers.


Hello world!

~Hello adventure!~

Thus begins the odyssey of MithrilSoft and the journey’s that await.