I'll start where I normally do, a milestone summery. Number two just raced by, so here's our hits and misses for the past month. I think I'll say a few words about the team and its structure too.

First up, a few points about the project at large, which are starting to become relevant. We intend the Phoenix Feather client to be playable on just about any system out there, this seems like a noble and worthwhile endeavor which will give us somewhere in the region of 30% more custom (note, the ratio of Windows machines V's all others is somewhere in the region of 10 to 1. But the people using 'other' machines are so desperate for decent games they are far more likely to check out a nicely presented indie title, thus my seemingly unreasonable user base guess (wow that was a long side note)). The intention is to market strongly to these minority interest groups with an aim of generating recognition from publications / journals / journalists that move in these circles. Where a decent indie game has to work very very hard to get recognized in PCgamer or similar mainstream publication, we will try to break the ice by pimping ourselves to the likes of Linux format and Mac review(?), still extremely notable and very difficult tasks, but also far greater chances. Anyway, thats a good way off yet, but it's worth writing down here.

So multi platform, launches from the web, optimized for a wide range of machine speeds, plans for translation. Indeed, we haven't even ruled out the possibility of future migration to palm/mobile phones. If there is a way to expand our potential market any more, it's illegal.

Our server is written in C++ and draws heavily on scripts for variables - GMscript (almost certainly). We have a custom built base network library (Tnet) which deals with the peculiarities of Java's byte order and takes care of multi platform functionality for the server. Most dynamic data is managed by the usual suspect, mySQL. Ok, on to business.

Client programming got bogged down this month, the issue was caused by a few factors jumping on top of each other to make an unsightly stack. The milestone targets were carefully considered and not particularly optimistic, but a few factors easily set us behind schedule.

Problem 1: Building editor...
We intend to use extremely compact files to store custom house designs in just a few kb's of data. This enables any architecture to be completely dynamic, buildings may be created, edited, moved and deleted without patching. Unfortunately me and the technical lead set ourselves up for a fall by not sitting down to fully design this format. As a result many hours went into development before we realized the system was seriously inefficient. Fortunately, by failing, we saw what NOT to do, and the developer had a stroke of genius which will lead us to a far more satisfying system.

Problem 2: Model format.
Another case of failed planning, we didn't sit down and discuss the requirements of the format as fully as we should have, fortunately this wasn't a huge blow because we caught the problem sooner. It was only after mentioning the progress of the format to a 3D artist that the problems became clear.

Problem 3: New developers...
Don't get me wrong, we're very pleased to have two new programmers joining the team, but there is a good deal of work that needs to be done to fully integrate new programmers (or I suspect any developer) into a current work flow. We had to do a lot of SVN shuffling and re-organizing (hopefully we won't have to repeat this in the future), re-assigning modules is far more difficult than it sounds, specially if some preliminary work HAS been done on them. There is a lot of discussion and explaining involved when you are first introducing a new person to current source code, methods are questioned and people generally 'don't get' whats already been done. It's clear how loosing a lead developer, or having to deal with constant departures and arrivals can kill a project if documentation and commenting isn't kept bang up to date, in any case, its a serious slow down.

Problem 4: Fun stuff...
Theres far more exciting things to be doing. Now that the server is functioning, we chat about newly implemented features each day and its very tempting to spend the entire time simply updating the client to test and play with with these new additions to the server code. Evenings which should have been spent developing the model format are (I won't say wasted, because it'll have to be done at some point) spent doing far less pressing things. This is something the team will have to come to terms with, sooner rather than later.

While these new developers (mentioned as problem 3) are initially a time sink, they are also the solution to our client development friction. The three major tasks, which have hung over our single client developer this last month, can now be spread out between three. I'm confident we can regain lost ground as a result. The next issue is, our client will begin to race ahead of server development [grin] fortunately the client devs all have some crossover skills, so we should be able to move between client/server as it becomes necessary.

Here, take a break and have a look at some lovely concept art :)



As I mentioned earlier, the server is coming along swimmingly. We can start up Phoenix Feather via a webstart link, login and chat away with other developers, which is well ahead of our milestone. Items and movement is being added as I speak. Thats all very exciting, especially so because we haven't used any external packages (raknet for example) [smile].

Perhaps its a little premature, but I went off on one a bit this evening and reviewed our hosting plans. I'm currently fairly sure that we will build a beefy 1u 'blade' of our own and use colocation hosting to get on a backbone. In the cases I looked at colocation cost roughly a tenth of the price of a comparable rented (dedicated hosting) package. The system I intend to build is near the upper echelons of the dedicated packages which cost $150 - $250 a month (depending on provider). With colocation I can build and ship the machine for under $1,000, I own it, and a slot in a data center is around $30 - $60. Bargain. In addition to this, owning the machine means we can reduce the chance of potentially expensive problems by doing 'burn in', compatibility and stress test simulations localy. I'd be particularly interested to hear peoples (_winterdyne_ *nudge nudge*) opinions on the most effective hardware configurations for single box servers dealing with hefty db's.

The next milestone targets aims to get us very comfortably into the realms of a multi user world. Walking, talking and drooping crap on the ground. I'll update again soon, congratulations if you read all the way to the end! I've got to sleep.