I don’t know why, but I was struck with a bit of inspiration while kicking back and doing absolutely nothing yesterday afternoon (literally: I was at my desk, feet up, contemplating a nap). As you might know, I have been semi-obsessed (semi meaning completely) with the idea of a space-based trading game. I have started down that road several times, but most every time I had approached it from exactly the same point of view: you are a singular pilot, and you are hands-on in-charge of being where you need to be in order to pick up and drop off your goods. My epiphany this weekend was that maybe the player should be the Louie De Palma of their own shipping and logistics service, and not have direct control of a space ship or a fleet of ships.

In this new version, the player wouldn’t be anywhere except behind a screen, pushing fleets of cargo ships and their security escorts around the universe to pick up and deliver raw and refined materials, and finished and luxury goods. By taking the “character” out of the equation, I figure that I don’t have to worry about making players unique entities or applying that uniqueness to situations, and can instead create base statistics in little packages — the types of cargo ships or escort ships available, the commodities being traded whose prices are affected by regional concerns as well as supply and demand, and so on. This normalizes the data and would make the player’s decisions be the driving factor. Everyone can move the same goods, but the “game” of it is maximizing profits and minimizing loss, and undercutting your competition in “soft”, market-based PvP.

That paragraph was hard to write because I am only about 2 hours into this version of the concept and obviously have no complete idea. Instead, I decided to start by figuring out what a “cargoship” is, what an “escortship” is, and what a “commodity” is, and how those are to be represented in code structure. Then, once I had a first draft, how those data objects work together. In my past design and development attempts I’d often get tripped up between design and implementation because my pipeline would be that I’d rough out a data design and then immediately try and apply it to a coded system, only to find that my data design had painted me into an illogical corner which required refactoring to the point where my notes — which I absolutely need in order to keep my thoughts in order — no longer represent the code I’ve written. Eventually things get out of control and I have no way of understanding how this web I’ve tangled myself up in is meant to work, and the whole project goes into the “maybe someday” bin once again.

I’m finding that not jumping directly from design to code is pretty relaxing, actually. I have been creating data objects and have run one prototype method just so I could validate that my data design would perform the way I would need it to (it does!), but aside from that I’m only codifying data design after I’ve written out a plan for how it’s to be used. Sometimes throwing out scenarios or mocking up a UI can make me think of something I hadn’t considered when drafting the data objects. I am a very visual person, and I often think of the final product first and work my way back from that point, deconstructing what I think I might need in order to get back to square one. Often times, this doesn’t go as planned…shocker, I know!

Of course, this is the curse of the independent developer of any kind: knowing your tools is one thing, but knowing your own mind is something that can take a back-seat to enthusiasm when we assume we’ve got a handle on our own desires.