Second hand stores

I love going through second hand stores. I find all sorts of neat trinkets and toys from years ago. Most recently, I found a Skannerz toy, from sometime in 2000. Still works, and it even had batteries in it.

I got to playing with this, and I got to thinking... Nothing really similar has been done lately, to my knowledge. With smartphones booming, the majority of them including cameras, there's no reason you couldn't do everything this toy does and more with the hardware that people are already carrying around.

And so an idea was born. I love when this happens.

I know there's barcode reader apps out there for Android, and if I remember correctly, you can take advantage of those apps from other apps. So I don't even need to write the barcode reader side of things. That's a huge portion of the work gone, right there.

So now we need a way to get a monster out of an arbitrary barcode. The first thing that came to mind is just using the numbers in the barcode itself. But then I remembered that those barcode reader apps also do QR codes, and NFC tags are starting to become more common. So we need a way to do it from not just an arbitrary barcode, but an arbitrary string, of arbitrary length and content.

New plan. Hash whatever data we get, so we get a fixed length and a fixed set of characters, and then use that hash to do your monster generation. Easy enough. MD5 has a fixed length, and is hexadecimal, and has been around long enough that there's implementations is pretty much every programming language out there.

Now, we need a way to get a monster out of that hash. MD5 isn't collision proof, but for what we're doing, it might as well be. This means we can't just use the raw MD5 hash to say "hey, this is monster". We need a way to make collisions happen. So we start dividing up the hash.

The easiest way to do this is to just grab specific characters and look at those. But that still leaves us with way too much room to work with in some ways, and not enough in others. My current thinking is that I'll grab a few bytes(MD5 results in 16 bytes. I'm thinking groups of four.), add those bytes together, and modulo 256 that result. This gives us much smaller numbers, and gives us a few "fields".

I'm thinking the first field would be a "type" or "group"(Or "expansion set") thing, so you could have different groups of monsters, items, etc.. Second field would be which actual item/monster that one is. Third field could be a "variation"(Think shiny pokemon). Fourth field could be a seed for a random number generator, for battle stats and things like that. This gives you room for expansion, down the road.

The problem here is that same expandability, though. The way I see it, there's two options here. You either leave a good chunk of hashes useless at the start(If you managed to fill out 64 full groups, you're still only using a quarter of all possible hashes out there. That's a lot of failed scans.), or you start out "wrapping" the hashes, and when you expand it later, some of your previous scans no longer lead to the same thing...

I don't really like either of these options. The first one leads you to a lot of failed scans(That using 64 full groups example? That's 16,384 items/monsters.), and the second one leads to confusion when you release the expansions, 'cus all these barcodes people had found don't necessarily point to the same thing anymore.

One option is to reduce your expandability, so there's less failed scans. This is probably a good idea, 'cus I really don't think you're going to use 65k item/monster slots(Even pokemon hasn't gotten that far yet). But there's still the problem of not maintaining a consistent successful scan rate, or causing confusion when all your barcodes change meaning with new expansions...

This is where I'm at at the moment. I'll need to think on this more.

Game Design Log - Entry #14 - Final

Got the highscore stuff done. When you land successfully, if you beat the best time, it says "New highscore!". If you didn't, it shows you what the best time is. Either way, it shows you your time.

This isn't exactly fair, though, as the random terrain generation lets you just keep going until you get one that's straight down and not very far from your starting point. But, it'll work.

The code is at http://code.meldaire.net/lunarlander. I don't have the current version up at the moment, but when I get home, I'll make sure and push it up there.

Game Design Log - Entry #13

Whoops. Forgot about this again...

The game is functional now. It generates a random landscape(Which is guaranteed to have a flat section on it), starts you in the top center of the screen, and lets you have at it. When it sees that the ground is within a 1-pixel boundary of your lander, it runs a bunch of checks to see if you can land successfully at that moment. If yes, you win. If no, it changes the lander graphic to an explosion, plays an explosion sound, and you lose.

The only requirement I haven't met is disk access. I'm not familiar enough with C# to do things the way I want to, and I haven't had the time this last week to familiarize myself with the bits I need. Or think I need, anyways.

Attached is a scan of the explosion graphic.

Game Design Log - Entry #12

The last few weeks have been crazy. I've started work on several projects in addition to what I'm doing for school, and a lot of stuff has been going on besides that... But, things are still progressing with the game, and I think I'm in the home stretch now.

The current state of the game is that most of the "required" things are there. The controls work, there's enough feedback from the HUD to be able to finish the game(As soon as the game can be finished, anyways), and I've got a working way to detect when I hit the ground.

All that's left(I think) is to do the game logic for when I hit the ground, a few graphics tweaks(Have it show something when the engine is firing, an explosion when you crash), some kind of options thing when you start it up, so you can change difficulty stuff... And I think that's it.

Of those, the only one that seems even remotely difficult at the moment is the options thing. Mostly because I have no idea how to work with multiple forms. We'll see if that happens.

Game Design Log - Entry #11

Today, so far, has been spent playing with GraphicsPaths. I've got my Lander designed, and all the points plotted, and put into an array of points, which then gets added to a GraphicsPath. I can draw this path, and as far as I can tell looks correct. The only problem is, it's tiny. Oh, and I haven't figured out how to move it around the screen yet.

There's functions of the GraphicsPath class that lets you apply transformations to the path, but I haven't quite figured out how they work yet. Once I get that going, I should be able to resize it to be more easily visible. It might also let me move it around the screen.

Attached is a scan of me sketching the lander, and plotting out the path to draw it.

Game Design Log - Entry #10

Right, supposed to be doing a log thing...

So, motion is pretty much done now. I've got gravity as you'd have on the moon, and the lander itself is using numbers from the Apollo lander for it's mass and engine power. The only thing I don't have is limited fuel, because I couldn't wrap my head around that particular equation...

Using the numbers from the Apollo is interesting, because the engine is throttle-able to a point where(at least as I'm using it), you're at 40% throttle before you can even push the mass of the lander. I'm not sure if this is something I'm doing wrong or if that's actually how it's supposed to be, but I need to work on other things. It's workable, and as long as I include something on the HUD to show the the amount of thrust you'll actually be producing, it should be fine...

Speaking of HUDs! I realized that I can just draw strings on top of the game, and it'll work. I'm actually using this for debug purposes, currently showing the lander's rotation, throttle level, and potential delta-V with the throttle at that level.

Next up is graphics. I've taken to calling this "rocketbox" for now, as that's basically what it is. I'm just drawing a box on the screen showing where the rocket is at the moment. Doesn't rotate or anything(Hence why I have the rotation shown in the debug HUD)... So yeah. That's what I'm looking into at the moment. Currently looking into an array of points, and what can be done with that... If my thinking's right, I can do vector-like graphics, and get graphics and collisions with the same array of points. We'll see how that goes.

Game Design Log - Entry #9

AHAHAHAHAHA! SUCCESS!

I took a break from Thrust calculations for the last day or two, and skipped ahead a bit to actually adjusting the trajectory with the results from the thrust calculations... Kinda backwards, but I wasn't getting anywhere with the thrust stuff.

After spending a day and a half going in circles trying to figure out what I was doing wrong(Believe it or not, all the references I could find online were wrong in some way...), I finally asked a friend, and we found two problems. One, I had the wrong operation in one place(I needed ArcTan/Atan/Tan-1, and I had Tan), and two, I was putting it into my calculator wrong.

In my LanderMotion structure, which contains just about everything relating to the motion of my Lander(How about that name, eh?), I'm storing things as polar coordinates. I didn't know that they were polar coordinates when I was setting up my structure, but now I do and that's what they are. Now, I had never worked with polar coordinates before, just cartesian. Polar coordinates, to me, seem better suited for things like this, as you're applying force in specific directions and amounts, which is exactly what polar coordinates are, direction and magnitude.

The fun part came when I got to adding multiples of these forces together. There's three forces acting on the course of the lander -- momentum, gravity, and the engine. Gravity is always in the same direction, down, and for this game will stay constant through one "game". The engine is variable -- You can change your rotation, and the throttle of the engine. Momentum is variable -- It's the result of your previous motion, and is also what the result of your trajectory calculation is calculating.

Now, to get the net result of these forces, you simply add them together. "Simply". Anyways, to add these vectors together, you have to convert each one to cartesian coordinates, add all the cartesian coordinates together, and then convert it back to polar coordinates. Converting polar coordinates to rectangular coordinates is easy, and I had actually already been doing it in my ballistic trajectory stuff(Which I just realized is horrible misnamed in my game as it stands... It's not gravity at all...). Let's walk through it real quick.

For a given vector, there's two components to the polar coordinates for it, the radius and the polar angle. The vector we're going to work with has a radius of 15 and a polar angle of 180. To convert this to Cartesian coordinates takes two calculations, one for each the X and Y axis.
To calculate the X axis, take the cosine of your polar angle, and multiply it by the radius.
To calculate the Y axis, take the sine of your polar angle, and multiple it by the radius.

Easy, no? The part I had problems with was going the other way, cartesian to polar. This is more difficult, and the best way that I can think of to show it is to link to the code that I ended up with.

See here, starting at line 69.

Rtheta is the polar angle, Rmag is the radius, Rx is the cartesian X coordinate of the rectangular coordinates you're converting, and Ry is the cartesian Y coordinate.

Quite a bit more complicated, no? After I got help and figured out what was going wrong with my calculations, this got cranked out in less than half an hour, but I spent just about two days going 'round in circles on the 'net.


So things are moving along. Next up's back to thrust calculations. Also, I should have mentioned before now... My code's being put in a Git repository, accessible at http://code.meldaire.net/lunarlander. Not much to look at yet, but it's very much a work in progress.

Game Design Log - Entry #8

I spent a lot of time today beating my head up against a wall, trying to figure out the equation for delta-V. Turns out I had been missing the unit on one of the sub-equations the entire time, and was misinterpreting "ln"(loge) for "1n"... Now that I've got that figured out, I think I'm almost done with the "motion" part... Hopefully.

Game Design Log - Entry #7

So I finally felt comfortable enough with how it would work in my head to actually start programming it, and I found out that I was missing quite a few pieces of the math involved.

I think I've got it mostly figured out again, but I've spent a lot of time just reading through all this stuff making sure I'm not missing any other big pieces. Little progress has been made on actually writing code, so far.

Game Design Log - Entry #6

I've spent the last week arguing with myself over how to lay out my classes... I've got a good idea of how things should work in the end, but C# doesn't seem to let me lay things out the way I want.

For collision detection, I want to be able to get everything as close as possible as far as function calls for checking whether things collide. I have a feeling there's a way to do what I want, I just don't know how to do it. With C++, I could do this with multiple inheritance, and have a "Lander" class inherit both my "sprite" and "gravityObject" classes. C# doesn't have multiple inheritance, though. I don't want to have objects of the "sprite" and "gravityObject" classes inside my "Lander" object, 'cus then I'd have to do lander.sprite.rect.intersectsWith(), which would be different from all the other calls to intersectsWith()...

Maybe I'm just being too picky.

Game Design Log - Entry #5

I've been doing some more looking into what I can get to with C#. The display's DPI doesn't seem to be one of them, so I can't set my scale that way. If I can't do it that way, that leaves me two options that I can think of.

The first option is to set a static scale. For example, 1 pixel equaling 1 meter. This makes sprites rather difficult, though. The Apollo's lander module was 5.5 meters tall. That'd put a similar sprite at 5.5 pixels tall. 1 pixel = 0.5 meter would get me an even 11 pixels, but that's still a tiny sprite. The next "easy" step is 1 pixel = 0.1 meter... 55 pixels tall. 7% of the height of my screen(1366x768). Acceptable, I think.

Assuming a 1024x768 screen, this gives us 102.4m(252 feet) vertically and 76.8m(336 feet) horizontally to work with. More than enough, I think.

I need to actually start implementing this, now, I think. I've got enough that I can start laying out my functions, even if I can't completely fill them in yet.

Game Design Log - Entry #4

All about Gravity

For the purposes of this game, gravity is a constant force pulling you down at a given speed. This will affect both your trajectory and your velocity. If your trajectory is anything but straight up and down, gravity will alter your trajectory until it's straight down. If your trajectory is taking you "down", gravity will increase your velocity, until you reach terminal velocity. If your trajectory is taking you "up", gravity will subtract from your velocity until it is 0, or your trajectory is taking you "down".

Earth's gravity pulls you down at 9.81m/s^2. To gain any altitude, you need to supply enough thrust to be able to push more than your craft's mass straight up. Should be as simple as calculating the force of gravity pulling you down(9.8m/s^2 * mass?), and subtracting it from the force of the rocket upwards(Which will either be a static number or scale based on how long it's been on). Fairly simple for straight up and down.

The tricky part comes when you add in horizontal movement... I believe you'll only need four 'major' variables, though. If I'm correct, you'll need to track the rotation of your craft, the force provided by your rocket, your current heading, and your current velocity. From your current heading and velocity, assuming no intervention of the player firing of the rocket, you should be able to calculate where you would move in the next game tick. THIS should be sufficient, I think...

If the player /does/ fire the rocket, though, things get more interesting... I'm not sure of the math involved, but you'll be altering the current heading and velocity based on that math and the ship's rotation and rocket's thrust.

Still have a lot of reading to do to get a complete understanding of this, but it's getting closer...

Game Design Log - Entry #3

I've been trying to sleep for the past hour, but things keep coming to mind... Figure I should write them down before I lose them.

Physics is the name of the game for the Lunar Lander game I'm making. It needs to work well, and (to my mind) it needs to be accurate. This is going to take at least a few things, that I can think of.

First up, I want/need it to have a consistent scale. I remember seeing something about DPI while poking around in C# earlier. If I can get the DPI of the screen the program is running on, I can set a scale(Say 1 inch = 10 meters), and have it generate the movement offsets based on that to always have 1 inch be 10 meters. So long as I have a consistent way to get to this, it should work without too much trouble.

Next up, ballistic trajectories and thrust. This is going to be the difficult one. With my rudimentary knowledge of physics, getting this right is going to be interesting. I'll need to set a mass for my ship, and the amount of thrust that my thrusters will provide(Possibly factoring in a "spool up" time to get up to full thrust), and do all sorts of math that I'll have to research based on those to be able to get my trajectory for which direction to move and how far in a given timeframe. So long as I set a framerate that it can keep up with, and base my math on that framerate, this should be doable. So far my experiments have been running at ~58 FPS, which means I'll need to set up my trajectory math to come out with meters per second divided by 58. Ideally I'd figure out how to set up the framerate so that it works out what that particular computer can handle dynamically, but I doubt I'll get to that.

I'll need to keep track of what angle I'm moving at(degrees) and what speed I'm moving at(m/s, probably), as well as which direction the ship is facing(degrees). If I do a spool-up time for the thruster, I'll also need to keep track of how long the thruster has been on(Probably in ticks, not seconds).

These are the major things that have been going through my head as I try to sleep tonight. Now that I've got it written down, I'm going to go try to sleep again...

Game Design Log - Entry #2

Over the weekend, I've mostly been reading through some of the example C# code, familiarizing myself with the language.

The Lunar Lander/Solar Jetman game is still the "major" idea in my head. Depending on how difficult it ends up being to have my player-controlled sprite collide with a dynamically generated line, I think I've mostly got randomly generated levels figured out... I'll have to do some math/experimenting and figure out ranges for everything, but I think it's doable.

As for everything else in the game...

Graphics shouldn't be too hard. Since I'm wanting to do randomly generated levels, I'm probably going to go with a wireframe look for most of it. That'll make drawing the ground easy.

Music... I'll need to play around with it, see if I can come up with something fitting. Chiptunes, if I can manage it. Thinking along the lines of VVVVVV for music.

There'll only be a few sound effects, that I can think of. Your engine firing, your ship exploding, opening/closing the airlock, and an "item get" sound...

Gravity's going to be fun. If I'm doing randomly generated levels, I might be able to have the gravity randomly generated, too. I'd need a HUD to display the amount of gravity, so that it didn't seem "odd" that the controls were different every time you loaded it up... I'll need it for fuel anyways, though. Maybe score, too.

I'm not sure what to do in the way of disk access. A high-score leaderboard is all I can really think of, if I can figure out a way to score it...

Mostly thinking out loud again, but I think I'm getting closer to nailing it down.

Game Design Log - Entry #1

Hope nobody minds -- I'm gonna take a sidestep on this blog for a while. I'm taking a "Game Programming/Design" class at the local college this quarter, and part of it is keeping a log of what I'm doing for the game we're supposed to be making. I figure my blog's as good a place as any, and people might comment on it and help refine some ideas.

The assignment for the first week is to come up with some ideas for the game we'd like to make. So far, I've got two ideas. The first is a platformer of some sort. Been done to death, but it does cover a good deal of the "basics" of designing a game. This particular idea hasn't been fleshed out much.

The other idea I've got is a mix of "Lunar Lander" and a little bit of a platformer. You have to land your ship on the "moon", then get out of the ship and go gather a few things(Artifacts that have been located on the moon, ship parts... Something.), then return to your ship and take off again. Kinda like Pikmin, only without the pikmin.

This second idea is the one that keeps coming back to me, and is probably the one I'm going to end up going with. It needs some more work(What is it you're retrieving, and why... Where are you going when you take off again(Which brings with it, what happens after you take off again)... I know there's other questions that need to be answered, but those are the ones that immediately come to mind.), but I think it could make for a decent project.

It would need gravity(Landing/taking off, jumping), collision detection(Landing/crashing, collecting items, possibly spikes or something after you've left the ship...), might be able to work in a random number generator for level creation(Probably not for the "surface" segment, but for the landing segment it's definitely possible)...

This is mostly just thinking "out loud". This will become more and more detailed as I go on, probably.

Anyways. This is Entry #1, on 4/4/2012, right around noon.