Monday, April 30, 2012
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.
Thursday, April 26, 2012
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.
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.
Sunday, April 22, 2012
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.
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.
Sunday, April 15, 2012
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.
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.
Saturday, April 14, 2012
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...
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...
Wednesday, April 11, 2012
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...
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...
Monday, April 9, 2012
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.
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.
Wednesday, April 4, 2012
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.
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.
Subscribe to:
Posts (Atom)