Friday, September 9, 2011

I really should stop doing this

My usual slapdash method when I feel like I'm on to something is to write out roughly what I think the function probably should look like, and then pepper it with statements like
print("This function won't work, dummy") 
at the no result ends of what I think are correctly formed functions. Invariably every one of them goes off when I run the code.
The solution is to set aside some time and really learn to use things like assert and try/catch, lua supposedly has a nice system for this sort of thing that will give me a lot of detail on where I'm wrong and improve my efficiency pretty severely. Sooo maybe soon. Maybe real soon. I don't know if I wrote this before or if somebody else did, but I'm calling it a Law: "You will learn something when the pain of not knowing it becomes greater than your perception of the pain of sitting down and figuring it out." The perception part is important, whenever I envision a task with more than a few steps I'm prone to suddenly feel like some poor prehistoric chump pulling a block in Giza. The fantasy of how dull this complex task you have to do will be is often plenty of motivation to continue doing whichever unproductive but however-marginally pleasure generating activity you are currently engaged in. More than a small part of the overwhelming effort that seems necessary to log out of the website, put down the crack pipe, finish the novel, refactor the code, etc. is to overcome that initial fantasy about how much ball-bustingly hard work is going to be involved in reaching the result. It's true, but we are really not good about estimating the future, as human beings, we get emotional and we're naturally clumsy with time and we have great imaginations, and yes, often some of the small, short-term, easily accomplished sub-tasks that need to be completed at any and every phase of the plan are actually kind of unpleasant and tedious, sure, of course, but it's a mistake to imagine every second is going to be like that!

Right, well . . the point is, if you can recognize that initial wave of resistance is going to come at you every time you try to self-motivate, you can at least brace yourself for it or try to . . dive under it . . surfing metaphor yeah . .  the imaginator's best friend is his worst enemy . .      

Thursday, September 8, 2011

Some Crude Planets And Some Cruder Math

Well, these aren't going necessarily going to catapult me into a sweet Art Director position anywhere, but they're good enough for Solar Trucker, says I. That wraps up the art section of this sprint (heh) unless I lose all remaining common sense and decide to implement that animated dotted line thing I was thinking about last night while I was falling asleep. That would truly be foolhardy. I have found as a rule of thumb I tend to resist a problem when I realize I'll have to create a test bed for it. I even have templates, it's not a pain at all, but something about it is not as much fun as hacking away at the main game, however fruitlessly.

I decided early on to try and make the game conform at least in the loosest possible manner to the actual distances between planets, so that players could do things like weigh the differences between a milk run to Venus for peanuts and a long, asteroid-fraught haul to Jupiter with a big paycheck at the end. I'm now wondering how much I should fudge the numbers.

For instance, if I decide that my basic Earth - Mars run (48.6 million miles) will be the gold standard of the amount of distance the player should cover over a "standard" arcade game level, let's say about two to three minutes. That seems like about as long as anyone would want to plink at asteroids before seeing another screen. So let's say if there were no obstacles, you could point the ship at Mars and dock in exactly two minutes. Seems reasonable. That's a basic speed of 24.3 million miles an hour.

If we want to keep everything roughly in scale, we'll have to plot the other trips with that top speed in mind. See where I'm going with this? The Earth-Jupiter run at top speed would take just about sixteen minutes, which is a Long Time to spend plinking asteroids, even with salvage and aliens and whatever else.

So, make the meta-game less "accurate" or make the core game more interesting. Time, Distance and Speed . . .

Edit: bonus old school dev tools screenshot

Tuesday, September 6, 2011

Where There's A Map


Here's a quick pic of the second between-missions screen for Solar Trucker, the route map. It doesn't have much logic hooked up to it yet so I haven't uploaded a build with it in place. This is one of those little humps where the basic idea is simple, but in order to implement it I have to do a ton of grunt coding. That is, I'll need gameplay art for each planet, plus calculation of distances, variable asteroid dangers, and of course the police and salvage features I haven't even begun on yet . . but once the basics of this are in you'll be able to travel to a planet, pick another destination, travel to that one, and on and on, which is dangerously close to what a real game might look like.

Every day of progress is still kind of agonizing because I'm still floating around unemployed, entirely unsure of which of a dozen possible skills is going to put me over the top during my next good interview. For instance, if I was spending this time on Python or ActionScript instead, I might be looking at a slightly broader swath of opportunities, but things are so fast and unpredictable right now that this is just speculation. At least I'm free from wondering whether I should be building Unreal or Source maps: my laptop won't run that stuff and I'm in no position to go buy a new dev rig.

I just keep reminding myself that the most impressive thing I could possibly have to show is a finished product, regardless of the specifics of that project. This game surely isn't going to be all that, but it is going to be done at some point, and the next one is going to be better, and the one after that is going to be better still . . .