It's Time to Bring This Ship In To the Shore IN SPACE

OK, As of last night, around 11:30, I pushed what I considered the completed version of Interplanetary Space Courier. Two games in two months, I didn't go completely crazy, and I haven't lost my day job (yet).

What Have I Learned So Far?

 Oh, probably a great number of things, mostly little bits of techniques that I've used in previous games that I've adapted to new stuff. As I go, I'm building up a toolbox or library that I can go back to and loot from, which will make things easier on future projects.

So, the easy answer is that there's lots of little things I've learned how to do in JavaScript, like playing sounds, or drawing backgrounds.

I've also learned that JawsJS is a fine framework for my JavaScript games, but as I go forward, I'm leaning on it less and less - so I may end up abandoning it entirely and just use my own code. It's not bad, it's just not helping me as much as some other frameworks have done in the past. (I'm thinking primarily about PyGame, but PlayN and DirectX might be worth considering.) One thing that contributes to this feeling is that HTML5 with JavaScript is a pretty feature-rich platform to begin with, so I need less support to get my work done.

One great area of stuff I haven't learned is good Closure practices. I took on this challenge of One Game a Month in part to force me to write more JavaScript, and I chose JawsJS because it was friendly to the Google Closure toolkit, which is something I want to become fluent in.

I've learned that posting to this blog helps me maintain momentum - just journaling about stuff makes it feel different - talking about features I completed, or pieces I'm working on puts it in a different perspective than just seeing it on a TODO list.

On a meta-level, I've reminded myself that a game jam format (and One Game a Month is sort of like 12 month-long game jams stacked end to end) is a good way to provide a deadline, and a deadline provides focus, but it doesn't guarantee that you'll accomplish the things that aren't your top priority. I've seen so many people jump into a game jam, maybe a LudumDare 48 hour challenge, and say "Ok, I'm going to learn Python, and PyGame, and...". You know, more power to you, but finishing a game is hard, and learning a language isn't easy, and doing both is maybe biting off a lot.

So, about my challenge to myself to learn JavaScript and Closure and HTML5, and make 12 games...

Well, OK, so it's a little crazy, sure. But I'm not trying to learn the language in a weekend - I've already learned bits of it, enough to get by, most of the time. Closure, like I've said, I need to remind myself to incorporate that more into my workflow. Closure is a good tool in that you can integrate it into your existing project a little bit at a time. I just have started at the dependency management support and minification, and haven't incorporated a lot of other good Closure practices.

What's Next?

I want to do something that's tablet-friendly, and doesn't take a lot of time, to give me time to breathe a bit. It'll also give me time in case work goes crazy, like I fear it might.

My current thought is to make a Dots and Boxes game with a pretty straightforward alpha-beta pruned adaptive-depth game tree evaluator. I expect to cache evaluations, which should keep the tree evaluation under control. The one interesting bit is that a player may get to go again after their move, which is a small wrinkle in the implementation. Not hard, but important to get right.

I'm also thinking of making a Choose Your Own Adventure-inspired game book. I knew that going into this that I didn't want to just do computer games (and certainly not just browser games). So, a branching-path game book would be kind of fun. It'd require me to write English, instead of JavaScript. Hm, I could do both if I wanted to make a fancy app. Or, maybe not. I've looked a tiny bit into the EPub format, and have downloaded some Python code that makes EPub files, so there's some opportunity there.

Now, with more visible data. Also, bugs. IN SPAAACE.

Whew.

Coming up on the end of February, and things are mostly done.

Things What Are Working

Persistence

I transferred the persistence code from cookies to localStorage, which works just fine, and simplifies some of the code, because I just jam a bunch of data into an Object, which I use JSON.stringify() on, and I'm done. Similarly, JSON.parse() and I'm back up and running on the other side. No nasty parsing numbers in my own code.

Running out of Fuel

It's now possible to exhaust your fuel supply, which triggers a lose condition. There's no win condition, and I'm unsure if I'll get around to implementing achievements, which would have been sort of like win conditions.

More Data on Trading Menu 

On the buy/sell menus, I now display how many of an item the planet wants or wants to sell, as well as how many of the item you have. This makes navigating the planet menus a little less obnoxious.

Ship Inventory Dialog

You can press 'I' while inflight to see what you're carrying, as well as the price you paid, so that you can decide if you want to sell.

Things What Just Ain't Right

Persistence

At the title screen, there's a hacked-in option that allows you to discard the stored status. Something broke, and that no longer does anything.

Ship Inventory Dialog

If you leave the game with cargo in your holds, when you come back, the per-unit cost doesn't show up correctly in the inventory dialog.

Sounds

I've noticed that the cash register sound has been truncated recently - perhaps due to a refactoring that I did recently. I think I need to collect the sounds into a single place so that sounds don't go out of scope.

Positioning Large Ships on Landing

Some of the bigger ships look silly when they're positioned overlapping planets. It'd be easy to add in an offset to push them further out.

So, How Does It End?

I definitely feel like I've got a satisfying quantity of code written. I'm not entirely sure that it's balanced the way I'd like, and it feels a little sparse; this is a good part of a game, but it feels like you need some more conflict to make it worth the treadmill. Still, as a tech demo, it works. As an exercise in building a smallish (but larger than I had planned) chunk of code, I let a bunch of sloppy stuff in. I can't say that the sloppiness actually hurt me, but it makes me less eager to reuse that code, so it seems like it will hurt me down the road, or at least, benefit me less than I wanted.

More post-mortem-y-ness, I imagine, in a couple of days.

Buying, Selling Ships... IN SPACE.

The month's almost over, I'll be able to retire the "IN SPACE" suffix soon.

At 9am today, I pushed out a version that had buying and selling of 8 different ships. I was quick to call that "feature complete", which is perhaps a bit hasty. There's still plenty that I really want to get done by the end of February.

• Rewrite persistence system to use localStorage instead of cookies, and then use the new persistence system to store trade history, ship position, sector coordinates, what ship the player has purchased, and anything else I'm forgetting.
• Player loses when they run out of fuel. Permadeath is harsh, but it makes venturing out into the void a real risk. Not so much of a risk when you have a fast ship, but still.
• Have a player inventory screen to see what's in the hold and what price you paid (to remind you not to sell for too little).
• Warning klaxon when low on fuel.
• Experiment with inertial movement - this would really change all the ships' accelerations and top speeds to make them feel right. It will also require a slow "life support" cost to maintain the tension of getting from sector to sector.
• Achievement for getting a lot of money
• Achievement for exploring a lot of systems
• Achievement for limping in to a system with less than 1% fuel
• Achievement for reaching distant sectors

We'll see if inertia gets in. And achievements. At one point, I was thinking about having asteroid mining as a thing you could do. That's not getting in.

Even though I'm looking at a lot of features that'd be neat to see in the game, I can still look at what is in the half-full glass, and be fairly satisfied. I've wanted to make a game something like this since playing TradeWars on the old BBS systems I dialed into back in 1988. Yikes.

BigWorld, Economy, New Ship Art -- mostly IN SPACE

I took most of the weekend, and got a few big pieces working:

Sector to Sector

I had refactored the planet code to be contained in a Sector object, and procedurally generated based on the coordinates of the sector, which then made it possible to fly off the edge of Sector(0, 0) to Sector(0, 1) and see new planets, but then fly back to Sector(0, 0), and all your old ports of call are still there. Pretty easy to get working, no real surprises there. I toyed with the idea of having 4 sectors in memory at once to permit drawing planets at the corners, but that was more work than I wanted to do at the time, so I just used a single sector, which I figured would cause problems if there were planets right up at the edge of a sector - planets could blink in and out as the player crosses the boundary.

Well, I expect that's happening, but I haven't seen it, yet, and space is large, so I'm going to conjecture it's not a big problem, and I'll work on other stuff.

I'm pleased that flying from sector to sector is currently a tense activity; you don't know if you've got enough fuel to reach there (at least with current levels of fuel expenditure). If I tweak the physics, I'll want to make sure I keep this level of danger.

Buying and Selling

Oh, I've had buying and selling in before, but now, when you buy and sell, you deplete the quantity of goods for sale, or deplete the amount of goods wanted. This causes prices to rise and fall. (I have a hard time keeping straight which prices I'm talking about, so the code has functions like "computePricesForPlayerSelling", which is cumbersome, but unambiguous.)

One side-effect of this is that you can take a profitable route and make it unprofitable, even before you account for fuel. So, pay attention, buying and selling technology starts out being quick cash in your pocket, but there's nothing keeping you from going broke buying high and selling low.

Ship Art

The first ship sprite I had in the game was a pretty simple geometric shape, reminiscent of old vector space games. I had a copy of "Bill Budge's Space Album" back in the day, and one of the games on that was a pair of spaceships flying around a planet. Not exactly SpaceWar, but along the same lines.

I've been planning to add an ability to buy new ships (to have something to do with all that cash, for one thing), and that means additional sprites. I had doodled some 30 different recognizable ships in a notebook, but that was a lot. I decided to narrow down things to three variables; speed, range, and cargo capacity. Each ship would either have a high or low value of each of these three variables. That makes 8 ships, which is a reasonable place to start.

I set out to draw sprites in GIMP, which isn't a terrible tool for the job. I don't know if some of my frustrations could be addressed by adopting better habits, or installing special plugins, but I'm able to get my work done. I'm shooting for a 16-bit color palette, which gives me structure for picking colors. I want yellow, and there's only a few of them, so I don't paralyzed with too many choices.

I started out making all my ships fit into a 32x32 pixel square, and then I realized that some of my ships would have to be a lot bigger, so that meant going back and redrawing some of my ships. Along the way, I used some photographic references, which led me away from the stylized, clean, look I was using elsewhere, so I went back and redrew some of my ships.

I now have 7 of the 8 ship sprites at a minimally shippable level of quality. I could go back and tweak them with all the time I have left, but I have to walk away from the art so I can get other stuff done.

Only a few days left. Buying new ships is an important piece of gameplay that still needs to be written, and then it's revisiting and improving stuff that's basically working now. This project's grown a lot from where I started it, but I'm pleased with where it's going.

Randomness Leaves Town, Randomness Comes to Town, IN SPACE

As I've mentioned earlier, I've got several chunks of code that I want to work on over the next week. Almost all of them have a few properties:

• Supporting another piece of the code - if I change this bit, that other piece is going to need to change. Part of this is sloppy coding, which I admit to, and know I can do better. But most of it is just tight coupling of what the systems do - if I change the way that ships move, that changes the way that planets need to be laid out. And those connections are usually two-way links; the "birthday cake" diagrams I drew in class about abstraction layers aren't helping me here. Or, you know, maybe they would, if I thought through the problem better. But there's no time for thinking!
• Perched on a refactoring cliff - the work that I need to do involves taking working code and putting it into a state of not-working before getting it to work again. I should really set up a local Git repository to take some of the risk out of changes like this (also, to lessen my exposure to catastrophic machine failure). I usually like to have lots of incremental work that can go in without destabilizing the game. These changes aren't that.
• Not well-suited to screenshots - working on economic systems is important, but how do you take a picture of them? I could have a dashboard, demonstrating that the systems are working, but that's not what the user would see. Maybe I should do it, anyway, to prove that it's working to myself. I'm sure to have printf-debugging log file output, perhaps that's sufficient.
• Self-directed - this isn't a big deal, but some of the stuff on my TODO list has come about from external feedback. Some are requests for features that I've wanted to do anyway, some are other people's ideas of how they'd like to play the game. I need to remind myself that these are all good, and I need to consider them all, and decide what gets in and what doesn't. February 28th is coming up fast, so not everything I want will get in, and not everything that friends suggested will, either. But I'm happy when I get to tell a buddy that his feature is in and working. Most of the big stuff I'm working on is on my personal must-have list, so there's nobody to brag to but myself.

So, that's the knot that I'm going to try to unravel over the next weekend.

I'm happy to say that I put in a little bit of time into the BigWorld procedural universe generation refactoring task, and it's going well. I've moved the planets (aside: I'd like to call these things "systems", as that feels more astrophysically plausible, but it's also more awkward, and the code says "planets") into a new class called Sector. I also have a SectorMgr which provides Sectors to the rest of the game. Is it a factory? A cache? I think that's getting underneath the abstraction - it serves up Sectors based on sector coordinates, and the illusion to the player is that the universe is huge and unchanging (at least, on the level of what planet systems are where). Carve away a little bit at it, and the Sectors are coming in and out of memory, but they'll be there when you need them.

So, right now, the SectorMgr is serving up a single Sector, and that Sector is procedurally (ish) generated from a seeded random number generator. Which is just about indistinguishable from the way the game had been working up until now.

The bit that is noticeable is that I keep reusing the same seed ([0,0]), so restarting the game no longer gives you a new layout of systems. You get a random layout, but it's always the same random layout each time.

One of the next things to do is to allow the player to fly off the edge of a sector and give them a new sector to fly onto. This isn't hard, just a little bit of changing some of the references high up.

Once this gets working, players may notice that they've seen all 1570+ of the hardcoded planet names I've accumulated. This will bring me to another procedural exercise: generating system names. A pretty simple Markov chain generator should get me most of the way. I have some ideas of ways to make it better, including working from both ends; names have interesting suffixes that I want my name generator to produce. We'll see if I'm still that ambitious as I write the code.

Once all that's up and running, the next huge system is the dynamic economic model.

Haven't I seen you before? IN SPACE?

Ah, if it isn't me old friend [username]. Hail, and well met.

Home is where you wear your hat.

I spent a few hours last night/this morning working on getting persistence working in the Space Courier game. I'd seen about 12 lines of code in several places for reading and writing cookies, and I figured I'd be able to put it in and be able to have fuel and money persist from session to session.

The first problem I ran into was that Chrome doesn't like the idea of cookies if the page you're viewing is using the file:// protocol instead of http://. Well, it doesn't mind you trying to read or write them, it just silently fails. I'm OK with Chrome making fairly aggressive security policy, that's what I want it to do. (How are those popunders working?)

Somehow, I had the insight that running off of the local machine's filesystem might have caused problems (I knew that cookies have to have connected domains, and maybe the leap of inspiration wasn't so far), so I was able to push a version out to my webserver, which worked, but it wasn't as fast as I'd like for rapid iteration on features. Maybe this is an exceptional case where I can get some wobbly structure in place that works sufficiently for webserver-based players, and I don't need to worry about it for filesystem-based play. (I want to say 'online' and 'offline', but that gets confusing; if you use the "navigator.onLine" property, that seems to be true, even for filesystem-based pages, which doesn't make a lot of sense to me.)

I think the next step here is to use the localStorage API (see WebStorage, DOMStorage, and sessionStorage), which gives me what I'll need to keep working. It'd be kind of nice to have a uniform API that works well across all browsers, under both http and filesystem use, but I really shouldn't be trying to solve problems I don't have right now.

Ok, so cookies are problematic, but I have some workarounds. Good.

Saturday morning serialization.

Another problem I bumped into, which was probably a little bit of my own confusion, had to do with implicit and/or explicit conversion of strings to numbers or vice versa. As I shift over to using localStorage, I know that the documented behavior is that the keys are strings and the data is strings. If I want to store numbers, I can turn them into strings (probably implicitly, which is OK), but then to read them back, I'll want to turn them back into numbers. JavaScript isn't picky about integers versus "real" numbers (floating point isn't really a data type, it's a representation choice).

What I am doing right now is reading a string out of the cookie for the money value, then converting it to an int, using
moneyVal = moneyString.parseInt();

And, similarly, for fuel:
fuelVal = fuelString.parseFloat();

Again, this is adequate to my requirements (for now), but I might want to have a more flexible data description object, saying that fuel is a float, and money is an int, and you know how to serialize and deserialize ints, so when I start talking about how much ore the player is carrying around, we don't have to go through all that again.

There's only seven days left in the month, so I'm reminding myself at every step that I need to do what makes my job easier in the short term, and defer working on stuff that might make my job easier sometime that's not right now. Or, at least, this week.

Interdependent Day

There are still several meaty pieces of code that I want to write this weekend, and it seems like three of them are all fairly tied together.

1. "BigWorld" procedural generation of planet placement. This is probably the one that I need to start on, but it's also the one that has the most work to be done, risks breaking the most code, and will have the least visible result. The idea is that I'll generate data for a small number of planets on a small "sector", and as the player moves off of that sector to another sector, I generate new data. If the player returns to the first sector, I regenerate the data in the same way, and everything looks the same to the player. This will be cool to me, once I get it working. But it breaks a bunch of other stuff, like knowing about all planets the player might visit, or have visited. That data just isn't around anymore, so I have to be satisfied with notes like "planet 6 in sector (0,3)", and when the player gets back to sector (0, 3), then I can actually look at planet 6.
2. Dynamic planet economies. I could do this now, but if I did the BigWorld feature afterwards, I'd have to redo the economy feature. So this probably goes second. As players go around the world, it'll feel more "alive" if their trades have an effect; if I bought a lot of ore yesterday on Ares, and sold it today on Ganymede, the next time I went to Ares, the selling price of ore might be a little higher (moving on the supply/demand graph), and the next time I went to Ganymede, the buying price might be a little lower. This will have interesting effects (I hope), pushing the player to explore more space to keep getting good profits.
3. Upgrading ships. This doesn't seem super connected to the other features, but it's got some dependencies back and forth with the BigWorld implementation. I've thought about a bunch of different ways to upgrade your ships, and what I think I might do for now is just have a catalog of different ship types. But maybe you can't buy all ships at all planets. So that's a BigWorld connection there - how do I make sure that ships are available? Flipping it around, if I don't have a lot of ships to explore space with today, how will I properly balance the sector size and system density? That's a soft back dependency - I'll just wing it for now, and then adjust the constants to tune things later.

And then, there's polish to work on, including making planets prettier, making the menu UX clearer (why can't I buy any more Organics? Oh, I've got a full hold of Ore), and switching to using a more physically realistic inertial movement implementation (more balancing and tuning tied up in that).

A buddy has been bugging me for varying planet sizes, which I could totally do, maybe I'll toss a 0.8 - 1.2 randomization in when I do the procedural sector population. But again, it's a polish thing, and not something I want to do before I get the big three, above, complete. And, I'd want it to feel right with the upgraded ships, which might have different sizes, themselves.

Space Courier: Now with buying and selling IN SPACE

It occurred to me over the weekend that I'm not really making a courier game so much as a cargo hauling and exploration game. Still, I'm sticking with "Space Courier". I want my own font. Somebody should get on that.

I intended to put a lot of work into the game over the long President's Day weekend, and I did spend several hours on Monday, so I should be satisfied with that. Part of time management is being honest about what time you really have available to your project.

I added in a dialog box with a menu tree of different activities (buying and selling goods, buying fuel). In projects past, I've done this sort of thing as a stack of more or less uniform items, so that exiting out of a part of the tree is just popping a thing off the stack. This time, though, I did some gross hardcoding; there's three levels of the menu tree - a toplevel menu where you pick buy / sell / fuel / leave, a second level where you pick what good you want to buy or sell (ore / organics / technology), and a third where you confirm the actual price being offered. I'm not really pleased with the design, but it's working for now, and as I'm rushing to get stuff into the game, I'm sacrificing code quality.

Which makes me reflect - is that really what I want to be doing? One of my goals is to make a game a month, and I seem to be on track to keep up with that. But another goal is to incorporate good JavaScript / Closure design habits, and I think that's being thrown under the bus. Perhaps my next month's game will allow me to rebalance, doing a less technically challenging game, but giving me time to refactor some of the code I've been carrying forward.

One half-joke I've made several times is that a game engine is whatever you carry forward into your second game. I've been dragging around a little bit of code from one project to the next, and have some ideas of ways that I want stuff to work, but it's not packaged nicely. Really, that's OK, because my goal isn't to have a fancy engine at the end of 2013, it's to have good practices and (at least) 12 games playable.

Next up:

• saving game state to a cookie in the browser
• dynamic pricing, so that planets supply or demand can be depleted by player actions
• "big world" system placement, using procedural naming and sector-based system distribution. This will be a huge change, as I won't be able to think about the player visiting all of the planets, or having known systems to refer to.

There are several user requests that have come in already that are on my list:

• make it easier to understand what the player has in his ship, which will make it more clear why a system might not want to buy or sell anything.
• frictionless / inertial / Asteroids spaceflight model
• vary the sizes of planets

They're all good ideas. Some are more good than others. If and when I get to them, I'll get to them.

Space Courier: Now with more Anaxides

I just made that name up.

The space courier "game" now populates the galaxy with a sampling of 100 planets, drawn from a list of... I forget now, something around 1570 potential systems. There's one big file that associates a name with a planet color - I had been thinking that I might want to have a lot more specific information about a planet, but I think just saying that Tattooine is a yellow planet, and Barsoom is red is sufficient. Given that, I should probably just make a big list of yellow planets, red planets, and so on.

I borrowed some names from familiar fiction, which feels like light trespass, but I'm not investing a lot of gameplay in the fact that planet #90 is named, let's say, Gelidus. If somebody wanted to send me a cease-and-desist, I'd be OK with renaming it. Gallidous, maybe.

But, to thin out the use of potentially legally uncomfortable use of trademarked names, I looked for other proper nouns - I recalled hearing about a difficult to pronounce name applied to a planetary body outside Pluto's orbit. That sketchy description didn't immediately yield to my Google search attempts, but with persistence, I found that the name I was looking for was "Quaoar". Oh, and starting there, "Sedna" is also a perfectly good name. Hm, so is "Palomar", though it doesn't sound so entirely other-worldly. But cultures name stuff after scientists, so, sure.

And, from there, it was a short leap to looking at the names of Greek gods on Wikipedia, and I had a list of over 1500 planet names before I clicked on the link to see also "List of minor Greek deities".

Every now and then, I'd insert a name that came from my own imagination, often a variation on a name I was taking from Greek myth. "Chicocrates", for example, came to mind when I was entering "Hippocrates". And, from there, "Harpocrates" and "Grouchocrates". Humor is hard.

So, if you play the game today, you can fly in a galaxy of 100 planets, pulled from my list of 1500 names. It seems like I ought to be able to be smarter and populate sectors of space from my list of planets in such a way that the player can fly from sector to sector, and only have a few sectors in memory (one most of the time, but up to four near a corner) at a time. Maybe, if I get procedural name generation working, the player could fly for very long distances (limited by the precision of an IEEE floating point number) without running out of universe. That'd be something.

Brainstorming Feature Level 1 (1500+ planets):
Shuffle the list of planets, based on a random number seed. Partition the planets into sublists of 100 each, which will be used to populate "sectors". Within a sector, position the 100 planets based on a seeded value. Place the sector tiles together in an easily-reconstructed fashion (a square grid would be easy, or maybe a hex grid, if I was feeling fancy). With care, it would be possible to create a single sector without building any of its neighbors, thus keeping memory use low.

Brainstorming Feature Level 2 ( many, many, more planets):
As above, but use procedural name generation (also here) so that the planet names aren't limited to my imagination (or my ability to crawl Wikipedia). Populate a sector with planets seeded by the coordinates of the sector and a single universe constant.

In any case, my notes for keeping track of trades and economic data seem like they're sufficient to provide "local history", to give the player's actions an impact on the world (if you do a tight trading loop between adjacent systems, you'll quickly expend the goods available for trading).

Having a vast universe to explore is interesting, but before long, I'll need to actually allow the player to buy and sell stuff. That's next.

Space Courier: Now We're Movin'

I should really get into the habit of writing these when I have easy access to the screenshots.

Small improvements to the game today:
http://bigdicegames.com/SpaceCourier/courier.html

• Planets - I put simple sprites (32px circles) in last night, including what may appear to a casual observer to be a small moon.
• Ship "animation" - when you hold the up arrow key, I increase a throttle variable. At certain points as that variable goes from 0 to 1, I switch from no rocket thrust to small thrust to full thrust. Likewise if you take your finger off the key.
• Ship movement - the ship was turning, and now it's moving. Well, the galaxy is moving. That is, I'm tracking "world" positions for the planets and the ship, and then I'm subtracting the ship position from the planet position to get the location of the various planets from where the ship is, and then I'm adding in some window coordinates to make everything centered in the viewport. Pretty straightforward stuff, and it'd be slightly less confusing if I had a better term for "world" coordinates when I also have "planet position", which may be in any coordinate frame.

To Do:

• Text rendering - gotta do this sooner or later, and almost all of the important gameplay features remaining require this. I kind of want to have labels on planets, but that might be distracting. Or maybe awesome. We'll see.
• Sounds - the optional OneGameAMonth theme is "sound". And I downloaded a few samples from freesound.org. In space, no one can hear you argue that rocket sound effects are out of place.
• Docking with planets
• Ship inventory
• Ship upgrades
• "Deck of Worlds" - right now, the planets have no identity - they have positions and sprites, but that's all. I'm thinking that I'll author a collection of defined planets (Aaalderoid is a peaceful, blue planet that produces 100 food, 10 fuel, and 10 ore a year). Initializing the galaxy map would consist of drawing cards from the deck, and then placing them somewhere in my navigation graph. This may lead to more custom planet art.
• Navigation graph - right now, the planets just cluster around the origin, more or less. I want to stretch them out so that no two planets are closer than roughly one screen height, and some are much further away. You know, for better exploring.

One Game a Month, part 2 - Electric Boogaloo

One day, I'm really going to have to watch Breakin' and Breakin' 2.

Having squeezed "Switch 2013" into a vaguely playable condition in January, now it's time to start the process over again for February. February's about 10% shorter than January, I'm starting late, and there are fewer holiday weekends... so it seems like it's a perfect time to increase the scope.

See also "Second System Syndrome".

Still, I've chosen a direction for the next game: Interplanetary Courier Missions. There are a bunch of places to go with this, and I certainly played enough TradeWars 2000 and Star Trek at a formative age that the obvious stuff is begging to be implemented.

I'd like to try to avoid pouring every possible space game activity into the game - maybe this game has no combat at all (what?!), which would seriously limit the scope, and keep me from diving into full-on 4X territory (Explore, Expand, Exploit, Exterminate). Maybe the first three, but that has problematic abbreviation problems.

So far, I have a ship that renders onscreen, and turns left and right when you press the arrow keys.

http://bigdicegames.com/SpaceCourier/courier.html

Nothing exciting yet, I'll admit.

Some other features that I'll want to add:

• text rendering
• fuel consumption
• saving state from session to session in cookies
• docking with planets / space stations
• randomized galaxy map
• randomized economic profiles
• ship upgrades

That's plenty, really. Not much of a game, but you know, good for February.