Overview

As a programmer, I have a bad habit of reinventing the wheel. I've devoted vast energies over the years to algorithms and data structures that I could easily have sourced from elsewhere, had I not been so neurotic about "bloating" my projects with "unnecessary" libraries. My fascination with implementation details produced some pretty groovy stuff, like a Java thread pool years before Java's standard library offered thread pools. But it didn't produce very many complete apps. I rationalized that coding was just a hobby that I enjoyed for its own sake — that it wasn't a means to an end, but an end in itself.

Well, I'm over it.

I've been working on this project for a little over a month now. I was surprised how quickly it started coming together once I decided to use existing libraries whenever I could. Instead of spending months writing my own persistence API, I spent two weeks comparing the options and studying the one I settled on, JPA2. Then I spent day or two each on Apache Commons Configuration and Apache log4j. I even pulled in Apache Commons Codec for the sake of one little hash function. I'm not writing anything I don't have to!

That said, after experimenting with several alternatives, I decided to roll my own client-server protocol. That decision cost me two weeks, but I'm very happy with it. The details will be the subject of my next post.

One of my top-level design goals was to make everything modular and scalable — a modern MMO, writ small. For the sake of simplicity, I chose not to create separate services for authentication or inter-client messaging. Both of these will be part of the game server. But in the unlikely event that I ever need to run clusters of game servers to handle thousands of clients, they will be relatively easy to refactor.

There are five major components:

• the game logic, contained in a Java application


• the game data, stored in a relational database


• a Web interface for account management and scoreboards


• a client-server protocol, implemented as a Java library


• a simple reference client, also written in Java

I'm calling the reference client a "telnet bridge" because it will function either as a stand-alone client, or as middleware to provide a text interface for traditionalists and casual players. I want people to be able to check out the game without installing anything.

I should probably count this blog as the sixth component, as much time as it takes to write. But I enjoy it; it helps me put things in perspective. Programming is a hobby I can easily get sucked into at the expense of all else good in my life. I'm pacing myself by aiming for one milestone worthy of writing about each week.