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.