About five years ago, I was watching an F1 parade and I had a Grand Idea. I would build a game based on the idea of being an F1 manager, only with more interesting things, like alien technology. The USP would be that on a saturday the people in your league would race, and you would be able to make decisions on the fly as to your strategy and tactics. I did some diagrams and thoughts around this, build up a prototype, plugged some numbers in, rewrote it all in OO PHP, buried it in soft peat for a couple of years, realised I wasn’t interested enough in F1 to make a game about it, even with alien technology. It was called Racr, and it would have had a new name before release. The codename before Racr was “Escape” because it’s close to F1.

Three years ago, I was signing up to a webhost in order to take advantage of their “100GB Web Space!” promotion to solve my backup problem. My backup problem – at the time – being the reasonably traditional “I don’t have any backups”. Part of the package was a domain, which I needed to choose on the spot. By this method, I bought the domain PiracyInc.com, and my mind started to whirr a bit.

I took some of the files from Racr, filed the serial numbers off, plugged in some pirates and monkeys, and had a better idea. Piracy Inc. Now, mentioning projects on here has been a death knell for them for a while, but with any luck this will stop here. Having written a couple of abstract scripts and some ideas, I started coding it about three years ago in Django, because it was New and Cool. Unfortunatly, the webhost I was with for the domain didn’t support Django very well, and I spent most of my development time dealling with differences between my local environment and the live one, Cpanal funtimes, reasons why fcgi had broken today and, on top of this, learning a brand new envrironment which was rapidly drifting towards 1.0 and kept on rendering the foundations of what I was trying to learn obsolete. I could have stuck with a single version, but a) I was trying to learn how to do this, and learning the Wrong Way to do it was a waste of time, and b) I was trying to build For The Ages, and doing it in a way I *knew* I would have to rewrite quite soon was pointless too. A lot of this was because development tended to be in bursts of a few days every month or so, but in the end I spent more time fighting the development environment than coding things, and gave up.

At the end of January last year I sat down and Did Stuff. I wanted to write this thing, and what I know how to write is PHP web applications. I’ve used most of the PHP frameworks, and I’ve got major problems with most of them. Zend pulls things out of thin air too often, Code Igniter has a Mahoosive God Object problem (They do not, obviously, see it as such), and all the others tend to have a 4mb footprint before you can write “Hello World”, so I decided to do this freestyle, building an MVC framework as I went. Obviously, for a full professional project, I’d highly recommend using an existing framework and staying within it, because the flexibility and things you may lose by doing this are ofset by the fact that multiple people have to work on it and understand it. However, I also believe that it’s important to understand where the problems with writing a framework are, and the line between a design decision and a pile of crap. Actually trying to do it all yourself gives you a far better perspective of why you wouldn’t want to.

Within six hours of starting the new version, I had decided to split out the framework into a different project, which is called Plank (Because it’s what a game about Pirates is built on). It’s designed to be light, flexible, and include the ability to use almost any Zend Framework plugin. I suggest you don’t even think about using it, it’s not even close to stable or ready.

Anyway, so I’ve been working on that, and some of it has been fun and interesting. A couple of weeks ago I had a problem with suicidal ex-captains shooting themselves in the head, and yesterday I attempted to rebuild an economy from scratch.