I haven't made any changes to Ahab's Revenge in a while, but I had a breakthrough idea that was so easy to implement and obvious that I've been kicking myself for not thinking of it sooner.
The awkward, incongruous "3 strikes, you're out" system is gone. Ahab doesn't have "lives" anymore. What you have instead is a slowly decreasing oxygen supply. This makes sense thematically, since Ahab is underwater. When you're in the coral, your oxygen supply decreases much more rapidly, because it's...er... smothering you, or something. Okay, it doesn't make 100% sense, but this is fantasy, and I think this approach is a lot more intuitive than having the coral steal a life.
The scoring now makes more sense. You can't just camp out on the first level and destroy coral for eternity to get the high score, since you're now on a timer, and your score after killing Moby is now bigger depending on how much oxygen you had left when you finished.
And finally, a new power-up has been added. It, rather predictably, gives you a small oxygen boost.
Try it out:
AHAB'S REVENGE: OXYGEN EDITION
As usual, tell me what you think. Really, do not hesitate to leave a comment if you feel that there are balance issues; it's always incredibly helpful. Another question: do you think it would be too frustrating to lose a bit of oxygen when a whale hits Ahab?
nathan
Monday, November 8, 2010
Saturday, November 6, 2010
Tuesday, August 17, 2010
New Banner!
Hey! Look at my fancy new banner! Go ahead, click it!
As you can see, I've been working on the look of the blog. I'm not sure how my "aesthetic" sensibilities go over with the general populace, so if the color scheme assaults your eyes, just tell me and I'll try to accrue some taste.
As far as projects go, I'll soon be working with Kevin Chen of geakStudios on expanding "Stealth Robot Programmer." Namely, we want to make a level editor for it. So, that should be cool.
For a while, I was really eager to keep blasting through projects really quickly, but in the grand scheme of things I haven't been working on Ahab's Revenge for very long, and it wouldn't hurt to flesh it out a bit. What I really want to do is demonstrate level variety -- several people have pointed out that the constant upward climb can get a little monotonous. And with full 360-degree firing range and the mobility of a side-scrolling platformer, why not take advantage of the flexibility?
At the moment, there are two primary level concepts that I want to try out. The first, and most obvious one, is to take this in the direction of a platformer. Ahab jumps around dodging and shooting enemies while moving horizontally toward the end goal, with the destructible blocks thrown in as obstacles along the way. It's pretty simple, but with enough interesting elements added in, it could be fun.
The second concept would lead Ahab's Revenge in a more purist puzzle-game direction. In the "painter" levels, Ahab is in a single room with a solid block of corals in the center, and a fixed number of whales strewn about the stage. The corals are not moving, and the aim of the level in this case is not to destroy all the corals, but to destroy the right corals to make them form a specific pattern. As if you're chiseling out a sculpture. The tricky part is that the colors of the coral are not initially set so that it is possible to achieve your goal; instead you must use a fixed arsenal of "paintbrush harpoons." These are fired from your back like regular harpoons, but are giant paintbrushes that will change one or more of the corals to whatever color it is equipped with. Once you have the colors set up, right, you can switch back to normal harpoons and start clearing the correct corals by hitting them with whales.
If developing Ahab's Revenge has taught me one thing, it's that nobody has any idea what I'm talking about. So here's an example of what such a level might look like:
And you would be given an objective at the beginning of the level to use the right combination of paintbrushes and whales to carve the chunk of corals into, say, an "H" shape.
Anyway, give feedback! Tell me if this is an interesting path to follow, or offer your own ideas.
nathan
As you can see, I've been working on the look of the blog. I'm not sure how my "aesthetic" sensibilities go over with the general populace, so if the color scheme assaults your eyes, just tell me and I'll try to accrue some taste.
As far as projects go, I'll soon be working with Kevin Chen of geakStudios on expanding "Stealth Robot Programmer." Namely, we want to make a level editor for it. So, that should be cool.
For a while, I was really eager to keep blasting through projects really quickly, but in the grand scheme of things I haven't been working on Ahab's Revenge for very long, and it wouldn't hurt to flesh it out a bit. What I really want to do is demonstrate level variety -- several people have pointed out that the constant upward climb can get a little monotonous. And with full 360-degree firing range and the mobility of a side-scrolling platformer, why not take advantage of the flexibility?
At the moment, there are two primary level concepts that I want to try out. The first, and most obvious one, is to take this in the direction of a platformer. Ahab jumps around dodging and shooting enemies while moving horizontally toward the end goal, with the destructible blocks thrown in as obstacles along the way. It's pretty simple, but with enough interesting elements added in, it could be fun.
The second concept would lead Ahab's Revenge in a more purist puzzle-game direction. In the "painter" levels, Ahab is in a single room with a solid block of corals in the center, and a fixed number of whales strewn about the stage. The corals are not moving, and the aim of the level in this case is not to destroy all the corals, but to destroy the right corals to make them form a specific pattern. As if you're chiseling out a sculpture. The tricky part is that the colors of the coral are not initially set so that it is possible to achieve your goal; instead you must use a fixed arsenal of "paintbrush harpoons." These are fired from your back like regular harpoons, but are giant paintbrushes that will change one or more of the corals to whatever color it is equipped with. Once you have the colors set up, right, you can switch back to normal harpoons and start clearing the correct corals by hitting them with whales.
If developing Ahab's Revenge has taught me one thing, it's that nobody has any idea what I'm talking about. So here's an example of what such a level might look like:
And you would be given an objective at the beginning of the level to use the right combination of paintbrushes and whales to carve the chunk of corals into, say, an "H" shape.
Anyway, give feedback! Tell me if this is an interesting path to follow, or offer your own ideas.
nathan
Sunday, August 15, 2010
Taking Care of Business
NOTICE: All of my games have officially been moved! They are now neatly categorized in the "GAMES" tab that you see above.
A new game level that I made is up on geakStudios! It's called "Stealth Robot Programmer." The level itself sucks and is boring, but try to concentrate on the core mechanic: you get to sneak up on robots and reprogram them to do whatever you want (within reason)! The game itself is not my idea, but one formed before I even started collaborating with geakStudios. However, I sincerely think that it's one of the coolest ideas for a puzzle game imaginable.
I know I've posted this link about five times, but you can play the demo here at the geakStudios site. Make sure to read the instructions!
nathan
A new game level that I made is up on geakStudios! It's called "Stealth Robot Programmer." The level itself sucks and is boring, but try to concentrate on the core mechanic: you get to sneak up on robots and reprogram them to do whatever you want (within reason)! The game itself is not my idea, but one formed before I even started collaborating with geakStudios. However, I sincerely think that it's one of the coolest ideas for a puzzle game imaginable.
I know I've posted this link about five times, but you can play the demo here at the geakStudios site. Make sure to read the instructions!
nathan
Wednesday, August 11, 2010
This will be the next "Robot Unicorn Attack," I guarantee it.
[SORRY! The game has been moved here: Ahab's Revenge]
In case the start-screen instructions aren't explicit enough, A is left, D is right, W is jump (hold it longer to jump higher), and S makes you drop a level if possible. Oh, also ENTER pauses the game. I accidentally left that out.
It's finally here! My first game coded from scratch, Ahab's Revenge. There are definitely some things I can change up in the future -- I want to improve the scoring system, add some cool scenery underneath the coral, and make the boss a bit more interesting -- but it's finally reached a point where I feel like I can call it a "complete" game. Of course, feel free to leave me feedback. Particularly if it has to do with the speeds of all the game elements or their hit-boxes, since those are things I'm still experimenting with in order to tweak the difficulty.
In case anybody is curious, the background music is "Heiße Lippen" by Cluster. The rest of the audio I made with a combination of my mouth and Audacity.
You may have noticed that the name of the blog changed once again. Aside from choosing to make the title more gaming-related, I also had to decide whether to make it a Bowie or an ABBA reference. Yes, it was stressful. Next order of business: make the blog not look awful.
EDIT: Do you like game prototypes, but hate my taste in music? Then go play Ahab's Revenge at the geakStudios site, where they've been kind enough to publish the game minus the copyright infringement-tastic soundtrack.
nathan
In case the start-screen instructions aren't explicit enough, A is left, D is right, W is jump (hold it longer to jump higher), and S makes you drop a level if possible. Oh, also ENTER pauses the game. I accidentally left that out.
It's finally here! My first game coded from scratch, Ahab's Revenge. There are definitely some things I can change up in the future -- I want to improve the scoring system, add some cool scenery underneath the coral, and make the boss a bit more interesting -- but it's finally reached a point where I feel like I can call it a "complete" game. Of course, feel free to leave me feedback. Particularly if it has to do with the speeds of all the game elements or their hit-boxes, since those are things I'm still experimenting with in order to tweak the difficulty.
In case anybody is curious, the background music is "Heiße Lippen" by Cluster. The rest of the audio I made with a combination of my mouth and Audacity.
You may have noticed that the name of the blog changed once again. Aside from choosing to make the title more gaming-related, I also had to decide whether to make it a Bowie or an ABBA reference. Yes, it was stressful. Next order of business: make the blog not look awful.
EDIT: Do you like game prototypes, but hate my taste in music? Then go play Ahab's Revenge at the geakStudios site, where they've been kind enough to publish the game minus the copyright infringement-tastic soundtrack.
nathan
Friday, August 6, 2010
New Projects
Well, it looks like after a week or so of pretty intensive work on the whale-shooter, I'm going to put that on hold for a bit. Don't worry! It will be finished! It's very much my baby, and I will not toss it aside that easily. But, I feel as though I've reached a point where I can take a break for a while and still come back with a good idea of where I left off, and I've got other projects on my plate right now. Some of these projects are for my friend's fledgling game company, and they are not particularly fond of babies:
geakStudios
geakStudios is all about "fail-fast" game design, that is, they release a lot of simple, under-produced core gaming prototypes to the community, and continue development on what sticks. So with any luck, I'll soon be producing bucket-loads of total crap for you to enjoy! Go look at the website and enjoy the alpha releases of "Quicktime Coma" and "RTS Tuttle." I didn't have a hand in either, but when I start developing stuff, maybe I'll give some behind-the-scenes looks at the development process as I have for the whale-shooter, depending on how much geakStudios insider information I'm allowed to reveal.
As far as other personal projects go, my mom has asked me to make a game for her yoga studio's website, so my first idea was "Yoga Yoga Revolution," in which a raga plays in the background and you have to press certain button combinations to perform the correct pose. Also, I've been hoping to collaborate with a couple of my more artistically-inclined Vassar friends, including the curator of this site: Patootchy and Mallow & Koff. She's a computer science major, too! Yay!
That's where we are now. And I'm moving up to New York in about a month! So exciting. Later, folks.
nathan
geakStudios
geakStudios is all about "fail-fast" game design, that is, they release a lot of simple, under-produced core gaming prototypes to the community, and continue development on what sticks. So with any luck, I'll soon be producing bucket-loads of total crap for you to enjoy! Go look at the website and enjoy the alpha releases of "Quicktime Coma" and "RTS Tuttle." I didn't have a hand in either, but when I start developing stuff, maybe I'll give some behind-the-scenes looks at the development process as I have for the whale-shooter, depending on how much geakStudios insider information I'm allowed to reveal.
As far as other personal projects go, my mom has asked me to make a game for her yoga studio's website, so my first idea was "Yoga Yoga Revolution," in which a raga plays in the background and you have to press certain button combinations to perform the correct pose. Also, I've been hoping to collaborate with a couple of my more artistically-inclined Vassar friends, including the curator of this site: Patootchy and Mallow & Koff. She's a computer science major, too! Yay!
That's where we are now. And I'm moving up to New York in about a month! So exciting. Later, folks.
nathan
Wednesday, August 4, 2010
In Dark Trees
Okay, Flash got me this time. I didn't get much programming done today because I'm still trying to wrap my head around the coral problem. I've got some sort of algorithm for collisions involving the giant bitmap, but I'm not sure how well it's actually going to perform in practice, just in terms of accuracy. Also, a new layer of confusion has just been added. I tried storing each individual coral piece as its own bitmap and updating the position of each bitmap every frame, just out of curiosity.
And... it turns out that I really underestimated how fast bitmapping is compared to spriting. There is NO noticeable slowdown in the game-play, and I made about 45 rows of them! Oddly, though there's no lagging in player controls or whale movement, the bitmaps get spaced incorrectly as you get higher up, which may indicate that Flash is having more trouble iterating through the giant array storing all the bitmaps than copying the pixels. Of course, this is just me guessing, and I could probably get around the problem by dynamically slicing off pieces of the coral array and sticking them back on when they're needed again. since the position of the coral relative to the rest of the coral is always the same, there's no point in updating the position of coral that's off-screen every frame when I can just stick it back on again if it's needed.
So, I'm torn. The large bitmap approach seems undeniably more efficient, but I only have moderate faith in my algorithm. The small bitmap approach makes collisions a lot simpler for me, but possibly a lot more tedious for Flash, and I'm wondering if there's a way to do this that wouldn't result in too much overhead code. I could really use a personal Flash guru right now. If anybody has any suggestions, they are totally welcome. For now, I think I'm gonna take a break for tonight and get the rest I am sorely lacking.
Here's a rushed implementation of the small bitmap method. There's some unfinished code, so it might glitch out a little if you shoot the whales!
Log Entry #1, 8/5/2010: The coral is sort of working! Not very well, but sometimes when you shoot whales at coral of the same color, it disappears! The game's not giving me any errors. Basically I just have to refine the algorithm, which will be a lot of work, but it's still reassuring.
nathan
[EDIT:Moved it again.]
And... it turns out that I really underestimated how fast bitmapping is compared to spriting. There is NO noticeable slowdown in the game-play, and I made about 45 rows of them! Oddly, though there's no lagging in player controls or whale movement, the bitmaps get spaced incorrectly as you get higher up, which may indicate that Flash is having more trouble iterating through the giant array storing all the bitmaps than copying the pixels. Of course, this is just me guessing, and I could probably get around the problem by dynamically slicing off pieces of the coral array and sticking them back on when they're needed again. since the position of the coral relative to the rest of the coral is always the same, there's no point in updating the position of coral that's off-screen every frame when I can just stick it back on again if it's needed.
So, I'm torn. The large bitmap approach seems undeniably more efficient, but I only have moderate faith in my algorithm. The small bitmap approach makes collisions a lot simpler for me, but possibly a lot more tedious for Flash, and I'm wondering if there's a way to do this that wouldn't result in too much overhead code. I could really use a personal Flash guru right now. If anybody has any suggestions, they are totally welcome. For now, I think I'm gonna take a break for tonight and get the rest I am sorely lacking.
Here's a rushed implementation of the small bitmap method. There's some unfinished code, so it might glitch out a little if you shoot the whales!
Log Entry #1, 8/5/2010: The coral is sort of working! Not very well, but sometimes when you shoot whales at coral of the same color, it disappears! The game's not giving me any errors. Basically I just have to refine the algorithm, which will be a lot of work, but it's still reassuring.
nathan
[EDIT:Moved it again.]
Monday, August 2, 2010
Moment of Truth
The game is reaching a crucial point in its development, and I thought this was worthy of its own post. Basically, everything's running pretty smoothly; there's some mostly trivial collision stuff that I want to add at the end, but the last main obstacle is the barrage of "bubbles" that are supposed to descend from the heavens. As I mentioned two posts ago, Flash doesn't seem to be very good at rendering large numbers of moving sprites. So, I finally decided that it was time to stop re-inventing the wheel and go do some online research. What I came across was this:
Arrow Test
To quote that guy from The Wire, sheeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeet. That's a lot of sprites.
Well, actually it's not. The test came from one Mike Grundvig's blog, and it seems to be a clever use of the BitmapData Object type's copyPixel function. A fast way to move non-animated sprites across the screen? Could it be my salvation? Could it be?! Well, I'm certainly going to try it. In the mean time, here's the game as it stands. Steer with the WASD keys, point and click to shoot. you can drop down levels by pressing down (S). Bon appetit.
Log Update #1, 8/3/2010: Today is performance day! Performance, performance, performance! The results aren't immediately noticeable, but I've made the game better at cleaning up stuff that's off-screen, so now it's never updating more than 8 whale objects at a time. I've also been goofing around with bitmaps, so hopefully my bitmap-bubble plan will pan out by the end of the day.
Log Update #2, 8/3/2010: Unmitigated success! Well, so far. I initialized my block of bubbles (which are more akin to cubes of coral now), made it creep down the stage, and there was no noticeable slowing. I didn't explain it so well earlier in this post because I hadn't tried it and I didn't know exactly what I was talking about, so here's a better explanation for anybody interested:
When you make game sprites from Flash's built in drawing engine, to move these sprites in the game it literally has to redraw them in a different position every frame. In an earlier post, I mentioned getting around this by making it into one giant sprite, but this apparently doesn't help because Flash still has to redraw the damn thing every time. I opted out of Flash's vector drawing entirely by just copying everything to a giant bitmap image in memory, and for reasons that are not entirely clear to me, moving this giant bitmap is much easier for Flash than moving a ton of sprite information. Now when the screen scrolls up, I can make a bigger bitmap, copy all the pixels from the old bitmap to its bottom half, and fill out the rest.So, let's get going with that.
Log Update #3, 8/3/2010: Wheeee! Gigantic bitmap resizing is working surprisingly well. Of course, now I have to program collisions with it, which may prove difficult. In other news, look how trippy the game is right now! Sadly, it can't stay that way. :^(
Log Update #4, 8/4/2010: Here's what's on the agenda for today, just so I can stay focused: first I'm going to fix the level-scrolling glitch that I discovered last night, which should be easy, and then I'm going to try one method of collision detection between speared whales and coral cubes. Basically, I use ActionScript's built in hit-test function to see if the whale is intersecting with any part of the bitmap. Then I use another built in function to convert the stage coordinates of the Whale's center to its coordinates relative to the bitmap. At any given time one whale should not be intersecting with more than four sectors of the bitmap, so I'll cycle through them in order of closest to the Whale's center to the farthest, and if any of them are non-empty, the pieces of the collision will react accordingly. The awesome thing about this is that it's insanely efficient; instead of iterating through a giant list of corals and testing collisions on each, I just grab one by its grid coordinates. The problem is that I have to do math. Sigh...
nathan
[EDIT: Game has been moved to next post.]
Arrow Test
To quote that guy from The Wire, sheeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeet. That's a lot of sprites.
Well, actually it's not. The test came from one Mike Grundvig's blog, and it seems to be a clever use of the BitmapData Object type's copyPixel function. A fast way to move non-animated sprites across the screen? Could it be my salvation? Could it be?! Well, I'm certainly going to try it. In the mean time, here's the game as it stands. Steer with the WASD keys, point and click to shoot. you can drop down levels by pressing down (S). Bon appetit.
Log Update #1, 8/3/2010: Today is performance day! Performance, performance, performance! The results aren't immediately noticeable, but I've made the game better at cleaning up stuff that's off-screen, so now it's never updating more than 8 whale objects at a time. I've also been goofing around with bitmaps, so hopefully my bitmap-bubble plan will pan out by the end of the day.
Log Update #2, 8/3/2010: Unmitigated success! Well, so far. I initialized my block of bubbles (which are more akin to cubes of coral now), made it creep down the stage, and there was no noticeable slowing. I didn't explain it so well earlier in this post because I hadn't tried it and I didn't know exactly what I was talking about, so here's a better explanation for anybody interested:
When you make game sprites from Flash's built in drawing engine, to move these sprites in the game it literally has to redraw them in a different position every frame. In an earlier post, I mentioned getting around this by making it into one giant sprite, but this apparently doesn't help because Flash still has to redraw the damn thing every time. I opted out of Flash's vector drawing entirely by just copying everything to a giant bitmap image in memory, and for reasons that are not entirely clear to me, moving this giant bitmap is much easier for Flash than moving a ton of sprite information. Now when the screen scrolls up, I can make a bigger bitmap, copy all the pixels from the old bitmap to its bottom half, and fill out the rest.So, let's get going with that.
Log Update #3, 8/3/2010: Wheeee! Gigantic bitmap resizing is working surprisingly well. Of course, now I have to program collisions with it, which may prove difficult. In other news, look how trippy the game is right now! Sadly, it can't stay that way. :^(
Log Update #4, 8/4/2010: Here's what's on the agenda for today, just so I can stay focused: first I'm going to fix the level-scrolling glitch that I discovered last night, which should be easy, and then I'm going to try one method of collision detection between speared whales and coral cubes. Basically, I use ActionScript's built in hit-test function to see if the whale is intersecting with any part of the bitmap. Then I use another built in function to convert the stage coordinates of the Whale's center to its coordinates relative to the bitmap. At any given time one whale should not be intersecting with more than four sectors of the bitmap, so I'll cycle through them in order of closest to the Whale's center to the farthest, and if any of them are non-empty, the pieces of the collision will react accordingly. The awesome thing about this is that it's insanely efficient; instead of iterating through a giant list of corals and testing collisions on each, I just grab one by its grid coordinates. The problem is that I have to do math. Sigh...
nathan
[EDIT: Game has been moved to next post.]
Friday, July 30, 2010
Work in Progress
Alright, this is pretty much what's already happening so I might as well save myself the trouble and play along with it. I've been using the blog to test out the new game I'm working on, as mentioned in the previous post, and instead of taking it down and re-upping it constantly, I'm just going to leave it up and let all who care to see check out the game in its developing stages. Check back every couple of hours and see if I've accomplished anything, if you like. Maybe I'll even post some updates on how the code is coming. I know, soooo exciting.
Update Log Entry #1, 7/31/2010: OH MY GOD, I HATE TRIG SO HARD RIGHT NOW
Update Log Entry #2, 7/31/2010: Rotational shooting is working. I don't know why, but I'm not gonna touch it.
Update Log Entry #3, 8/1/2010: Well, I basically rewrote the harpoon and little whale classes and all their movement and collision handlers about three times from scratch. I think my current implementation is a keeper, but the whales aren't moving correctly when they get hit. Why do I have the feeling that the solution involves more trig?
Update Log Entry #4, 8/1/2010: Nope! No trig! Turns out I'm just retarded, which is a mixed blessing in this case. Time to graft the Thumb-Man controls onto this game to get the player moving...
Update Log Entry #5, 8/1/2010: Yahoo! WASD controls now functional. Just don't fire a harpoon while you're facing left until I get that ironed out...
Update Log Entry #6, 8/1/2010: Wall collisions, quick-jumps, and level-dropping is all implemented, and I fixed the aiming system! Things are going smooth right now, time to call it a night.
Update Log Entry #7, 8/2/2010: I wasn't looking forward to transferring the game to a 550x530 window (as opposed to 550x1800) but it was surprisingly painless. The only thing that didn't transition so well is -- surprise, surprise -- the rotational aiming. Just need to patch that up, then I'm on to implementing the "bubble" functionality, and then the game is almost done!
nathan
[EDIT: Removed the game. It's now in a later post.]
Update Log Entry #1, 7/31/2010: OH MY GOD, I HATE TRIG SO HARD RIGHT NOW
Update Log Entry #2, 7/31/2010: Rotational shooting is working. I don't know why, but I'm not gonna touch it.
Update Log Entry #3, 8/1/2010: Well, I basically rewrote the harpoon and little whale classes and all their movement and collision handlers about three times from scratch. I think my current implementation is a keeper, but the whales aren't moving correctly when they get hit. Why do I have the feeling that the solution involves more trig?
Update Log Entry #4, 8/1/2010: Nope! No trig! Turns out I'm just retarded, which is a mixed blessing in this case. Time to graft the Thumb-Man controls onto this game to get the player moving...
Update Log Entry #5, 8/1/2010: Yahoo! WASD controls now functional. Just don't fire a harpoon while you're facing left until I get that ironed out...
Update Log Entry #6, 8/1/2010: Wall collisions, quick-jumps, and level-dropping is all implemented, and I fixed the aiming system! Things are going smooth right now, time to call it a night.
Update Log Entry #7, 8/2/2010: I wasn't looking forward to transferring the game to a 550x530 window (as opposed to 550x1800) but it was surprisingly painless. The only thing that didn't transition so well is -- surprise, surprise -- the rotational aiming. Just need to patch that up, then I'm on to implementing the "bubble" functionality, and then the game is almost done!
nathan
[EDIT: Removed the game. It's now in a later post.]
Intermission
Ugh. Must... program...harder......
For my next programming project I've tackled something way more ambitious than that last "game", and I'm starting to feel like I bit off more than I can chew. I don't want to give away too much, but I'm essentially making a Bust-a-Move (aka Snood) variant. one of the things that is different is that the screen is really tall, to the extent that you'd have to scroll up the page in which the game is embedded while you're playing to keep up with your progression. I thought this would be a funny format for the blog, but some issues are coming up that seem to illustrate why nobody makes games in this way.
Let's just put it this way: your browser's Flash player is not exactly a PS3. There's a limit to the number of sprites that can be moving or even displayed on the screen each frame without massive slow-down. This is a problem because the way I'd designed it, the game started with a 37 by 14 array of bubbles to be busted, which the game has to iterate through and move each individual bubble for every frame of the animation. Right now, I see three possible fixes for this:
And since I feel obligated to post content, here's the first game I designed in my class at Vassar. It makes the last thing I posted look like less of an achievement, but this one was made using a Flash game designing add on rather than from scratch. Some of it won't make sense outside of the context of the class, so sorry about that. The point of the game is that you can't beat it without "cheating." I'm not telling you how, though. That's the game part.
[Sorry! The game has been moved here: Wallhacker]
CONTROLS: Arrow keys to move, space bar to shoot.
Featuring music by artists including Big Black, Microdisney, Thinking Fellers Union Local 282, and Earth Wind and Fire. Enjoy!
nathan
For my next programming project I've tackled something way more ambitious than that last "game", and I'm starting to feel like I bit off more than I can chew. I don't want to give away too much, but I'm essentially making a Bust-a-Move (aka Snood) variant. one of the things that is different is that the screen is really tall, to the extent that you'd have to scroll up the page in which the game is embedded while you're playing to keep up with your progression. I thought this would be a funny format for the blog, but some issues are coming up that seem to illustrate why nobody makes games in this way.
Let's just put it this way: your browser's Flash player is not exactly a PS3. There's a limit to the number of sprites that can be moving or even displayed on the screen each frame without massive slow-down. This is a problem because the way I'd designed it, the game started with a 37 by 14 array of bubbles to be busted, which the game has to iterate through and move each individual bubble for every frame of the animation. Right now, I see three possible fixes for this:
- Instead of moving all the bubbles every frame, I can make a timer and move them down a row every couple of seconds. This is how it works in Bust-a-Move and Snood anyway. I'm afraid that this won't fix the lag problem, though, because the game will still have to display a ton of bubbles.
- I can give up the dream and decrease the height of the game window, so that new content generates and disappears as you scroll up. D'oh.
- I can try to make the cluster of bubbles one glacially moving monolithic sprite, and then use my two-dimensional array to store information about each part of the grid rather than storing an actual Object. This feels like the best solution to me, but also sounds like the hardest to implement.
And since I feel obligated to post content, here's the first game I designed in my class at Vassar. It makes the last thing I posted look like less of an achievement, but this one was made using a Flash game designing add on rather than from scratch. Some of it won't make sense outside of the context of the class, so sorry about that. The point of the game is that you can't beat it without "cheating." I'm not telling you how, though. That's the game part.
[Sorry! The game has been moved here: Wallhacker]
CONTROLS: Arrow keys to move, space bar to shoot.
Featuring music by artists including Big Black, Microdisney, Thinking Fellers Union Local 282, and Earth Wind and Fire. Enjoy!
nathan
Wednesday, July 28, 2010
The Physical Adventures of Thumb-Man In Sunshine Land
Woohoo! Above you will find the first fruits of my attempts at videogaming. Alright, it's modest. And the graphics are pretty rushed. And there isn't really an objective. In fact, it's really just a platformer physics engine, and even then the controls are kinda sluggish. But here's the cool part! You can click those little arrows in the upper-right corner to change the physics constants: gravity, land speed, jump speed, and the coefficients of friction in the air and on land. Just use the arrow keys to move the little dumpy thumb-guy. It's pretty self-explanatory.
AWESOME FEATURES!
- The height of your jump depends on the duration you hold down the "up" button. Whoah, cool!
- Real simulated physics includes a vague semblance of momentum! Ga-roovy!
- Crouching increases your friction with the ground, sacrificing speed but increasing control. Duuuuuude!
Some technical notes of varying nerdliness:
- Sorry about the arrow button controls. It would obviously be easier to just have a text entry field for each variable, but for some reason I didn't realize this until I had written an entire Class for the arrow buttons with a bunch of neat little bells and whistles, and now I'm too attached to it. I guess I can go back and change it if it's that bad... also, if you think one of the variables increments too much or too little with each click, message me and I'll fix the code.
- Just to clarify, the friction values are coefficients for the character's speed, so lower number = more friction. The other values work the opposite. Bigger number = more gravity, etc.
- Okay, this one's really nerdy: ActionScript is weird. For some reason, when I fed a global Number variable of the game's main class to an instance of the Up/Down Button class, it copied the variable's value and left the original unchanged. Okay, normal. But when I did the same with a TextField variable, it actually went and updated the original. So yeah, I'm not really sure how pointers work in this language. There is still much to learn.
nathan
Subscribe to:
Posts (Atom)
