My quest to avoid making an art pipeline continues. I couldn't sleep last night so I replaced the landing targets with little guys that wave their arms.
These are made out of five capsules (which can have different radii at the two endpoints) and one circle (for the head). I'm still working out the relative scale of the guys to the rocket.
Next up is to make ramps that fold down from the rocket, and have the guys move aboard. They probably won't animate much yet (if any) while they move.
Thursday, August 26, 2010
Friday, August 20, 2010
A Couple of YA Novels
I like young adult novels because they tend to be short. There's been a discussion recently amongst independent game developers about how long people expect games to be relative to their price. One of the mistaken points I've seen made a few times is that it's only games consumers that judge their media by its length. I'm pretty sure there's a pressure in the adult fantasy/sci-fi genre for novels to be bloated, poorly edited messes. A book needs a map in the front, “Part One of the Demon Kingdoms Saga” on the back cover, and seven or eight hundred pages of typo-laden prose in between. Fortunately you can go to the young adult field and find tightly-plotted, well-characterized books that won't waste your time. Here are two:
Ship Breaker by Paolo Bacigalupi. An oil-less near future on the flooded Mississippi coast. Nailer, a child laborer (the eponymous ship breaker) falls in with a shipwrecked princess on the run. The characters are vividly drawn, the drama is intense, and the plot comes together well. Nailer's abusive father is a particularly strong villain. Not a cheery book but the atmosphere is thick and novel. Impossible to put down once started. Bacigalupi has also written a (much longer) adult novel in similar vein, The Windup Girl.
Leviathan by Scott Westerfeld. Westerfeld, already a prolific and accomplished YA writer, tries his hand at this newfangled steampunk thing. It works out pretty well, and has a sequel coming out in a couple of months. It's an alternate history version of World War I where the British have got genetic engineering down pat (with which they create the requisite steampunk dirigibles) and the Germans have gigantic walking fighting machines (because really, what universe should not have these?) Deryn, a young girl, hides her sex to enlist on a dirigible, shipwrecks and falls in with a prince on the run. Similarly un-put-downable.
Ship Breaker by Paolo Bacigalupi. An oil-less near future on the flooded Mississippi coast. Nailer, a child laborer (the eponymous ship breaker) falls in with a shipwrecked princess on the run. The characters are vividly drawn, the drama is intense, and the plot comes together well. Nailer's abusive father is a particularly strong villain. Not a cheery book but the atmosphere is thick and novel. Impossible to put down once started. Bacigalupi has also written a (much longer) adult novel in similar vein, The Windup Girl.
Leviathan by Scott Westerfeld. Westerfeld, already a prolific and accomplished YA writer, tries his hand at this newfangled steampunk thing. It works out pretty well, and has a sequel coming out in a couple of months. It's an alternate history version of World War I where the British have got genetic engineering down pat (with which they create the requisite steampunk dirigibles) and the Germans have gigantic walking fighting machines (because really, what universe should not have these?) Deryn, a young girl, hides her sex to enlist on a dirigible, shipwrecks and falls in with a prince on the run. Similarly un-put-downable.
Relative neighborhood graph
I've been trying out various things to improve camera control, but nothing good has turned up yet.
Currently the camera frames the player's rocket and the nearest objective. This can introduce a big discontinuity when a new objective becomes the nearest. The camera controller smooths its motion so it's not horrible but I think I'd like it to anticipate the transfer better. I've been trying out things in a testbed; if you'd like to try it you can get it here. It's a Windows application. Click or drag the mouse to move around; press the space bar to generate a new point set.
A screenshot appears above. The light-colored circle represents the current framing algorithm. The larger circle is an alternate method. What I really want is for it to interpolate between those two solutions so it frames things tighter when it's close to only one target, and then expand so there is a smooth transfer to the next objective.
I've also learned about some cool graphs. The application displays the relative neighborhood graph of the points. I'm not sure if it'll be useful here but I threw it in to see what it was like. It's a subset of the Delaunay triangulation that only contains an edge if there is no third point that is closer to both of that edge's endpoints.
Long, long ago I made a prototype for a game that was ultimately canceled. The idea for the game was that you'd have a map full of towns and villages and you'd help one or the other of a trio of warring factions to conquer all the territory. You'd do this in typical third-person action game format. (It was basically Dynasty Warriors Empires, but about five or six years earlier.) In my prototype I sprinkled towns randomly on the map and then made a Delaunay triangulation to determine which towns were neighbors; the mission generator would use this to generate sortie missions from one to another across the current borders. The problem with the Delaunay triangulation is that you have all these really long edges connecting vertices around the outer perimeter, which wasn't at all what I wanted. This relative neighborhood graph turns out to be exactly what I wanted back then.
Currently the camera frames the player's rocket and the nearest objective. This can introduce a big discontinuity when a new objective becomes the nearest. The camera controller smooths its motion so it's not horrible but I think I'd like it to anticipate the transfer better. I've been trying out things in a testbed; if you'd like to try it you can get it here. It's a Windows application. Click or drag the mouse to move around; press the space bar to generate a new point set.
A screenshot appears above. The light-colored circle represents the current framing algorithm. The larger circle is an alternate method. What I really want is for it to interpolate between those two solutions so it frames things tighter when it's close to only one target, and then expand so there is a smooth transfer to the next objective.
I've also learned about some cool graphs. The application displays the relative neighborhood graph of the points. I'm not sure if it'll be useful here but I threw it in to see what it was like. It's a subset of the Delaunay triangulation that only contains an edge if there is no third point that is closer to both of that edge's endpoints.
Long, long ago I made a prototype for a game that was ultimately canceled. The idea for the game was that you'd have a map full of towns and villages and you'd help one or the other of a trio of warring factions to conquer all the territory. You'd do this in typical third-person action game format. (It was basically Dynasty Warriors Empires, but about five or six years earlier.) In my prototype I sprinkled towns randomly on the map and then made a Delaunay triangulation to determine which towns were neighbors; the mission generator would use this to generate sortie missions from one to another across the current borders. The problem with the Delaunay triangulation is that you have all these really long edges connecting vertices around the outer perimeter, which wasn't at all what I wanted. This relative neighborhood graph turns out to be exactly what I wanted back then.
Monday, August 9, 2010
Turret aiming
Progress has been slow. I've been working on making the turrets aim:
After experimenting with projectiles that are influenced by gravity I'm now experimenting with ones that aren't. The goal of the turret is to find a spot along the rocket's projected trajectory where a bullet would arrive at the same time as the rocket. The turrets in the picture are assuming that the rocket undergoes constant acceleration. They use the sum of the rocket's current thrust acceleration vector and the gravity vector at the midpoint between the rocket and the turret. This gets them pretty close in the picture shown (the endpoints of the white lines) but often it's a lot worse. There are two reasons for this: the main one is that the gravity vector's strength changes with altitude and its direction changes as you go around the planet. A second inaccuracy is that when the player is thrusting without steering, the thrust vector is automatically rotated slightly as the rocket goes around the planet. (This essentially makes the thrust direction view-relative, since the view rotates in this way.)
I'm currently replumbing things so that the turrets can examine the plotted rocket trajectory instead. It is built using forward integration (albeit with a much larger time step than the game update) so it predicts where the rocket will go almost exactly. This should allow them to aim very accurately. In the past when I've worked on aimy-shooty things I've found that it's best to make them perfectly accurate and then work from there toward something that is inaccurate in a fun way.
The exact role of the turrets is not yet clear. It's no fun when you get shot with no time to react, so they need to be ineffective at close range. Probably they will avoid shooting at all at very close range (due to fear of unwanted splash damage, let's say). Making them turn slowly, and need to sync up to tracking the rocket's trajectory before firing, should also help.
I think I will plot the intercepts of all flying projectiles with your projected trajectory, although I don't yet know exactly what that ought to look like. Ideally it would give you an idea of the best evasive directions. It's possible that having all these trajectory plots will rob the game of any required skill, but my hope is that it will instead allow players to play a much denser game. I've noticed with the trajectory plots that I fly more aggressively than I ever would without them, and I feel much more in control as a result. Without plots I fly defensively and do a lot of waiting.
Ultimately you'd be able to destroy turrets to make things easier for yourself. (There'd probably be a bombing trajectory plot as well!) I've also been thinking about having turrets drop in from space over the course of the mission; maybe key the drops to astronaut pickups so that the difficulty ratchets up as you go.
After experimenting with projectiles that are influenced by gravity I'm now experimenting with ones that aren't. The goal of the turret is to find a spot along the rocket's projected trajectory where a bullet would arrive at the same time as the rocket. The turrets in the picture are assuming that the rocket undergoes constant acceleration. They use the sum of the rocket's current thrust acceleration vector and the gravity vector at the midpoint between the rocket and the turret. This gets them pretty close in the picture shown (the endpoints of the white lines) but often it's a lot worse. There are two reasons for this: the main one is that the gravity vector's strength changes with altitude and its direction changes as you go around the planet. A second inaccuracy is that when the player is thrusting without steering, the thrust vector is automatically rotated slightly as the rocket goes around the planet. (This essentially makes the thrust direction view-relative, since the view rotates in this way.)
I'm currently replumbing things so that the turrets can examine the plotted rocket trajectory instead. It is built using forward integration (albeit with a much larger time step than the game update) so it predicts where the rocket will go almost exactly. This should allow them to aim very accurately. In the past when I've worked on aimy-shooty things I've found that it's best to make them perfectly accurate and then work from there toward something that is inaccurate in a fun way.
The exact role of the turrets is not yet clear. It's no fun when you get shot with no time to react, so they need to be ineffective at close range. Probably they will avoid shooting at all at very close range (due to fear of unwanted splash damage, let's say). Making them turn slowly, and need to sync up to tracking the rocket's trajectory before firing, should also help.
I think I will plot the intercepts of all flying projectiles with your projected trajectory, although I don't yet know exactly what that ought to look like. Ideally it would give you an idea of the best evasive directions. It's possible that having all these trajectory plots will rob the game of any required skill, but my hope is that it will instead allow players to play a much denser game. I've noticed with the trajectory plots that I fly more aggressively than I ever would without them, and I feel much more in control as a result. Without plots I fly defensively and do a lot of waiting.
Ultimately you'd be able to destroy turrets to make things easier for yourself. (There'd probably be a bombing trajectory plot as well!) I've also been thinking about having turrets drop in from space over the course of the mission; maybe key the drops to astronaut pickups so that the difficulty ratchets up as you go.
Subscribe to:
Posts (Atom)