I've spent some time over the past couple weeks working on The Rainstorm again, and it's getting pretty close to an update. There's one minor bug to fix, and I want to add a pause menu. After that I'll release a new version.
Tonight I created some graphics for the menu buttons, instead of the rather unattractive QNX buttons.
I also changed the font, which turned out to take lots longer than I thought.
Recently I also added a help screen and tweaked the gameplay speed to make it a little less boring. I still want to radically alter the gameplay, but I might have to wait until the NDK comes out so I can code it up in C++ and OpenGL to get the raw horsepower for the visual effects.
Monday, July 11, 2011
Saturday, June 18, 2011
HD Progress
The Rainstorm has now been converted to HD foreground graphics, with low-res water effects and background. With the water effect as such low resolution (1/4 size) as it is to get good framerates, it looks pretty awful compared to what it was (1/2 size).
I decided that it's better to have a crummy visual effect with better gameplay than the opposite. The only way I think I can get good performance out of this game (mostly the water effect) is to convert to C++/OpenGL once the PlayBook native SDK is released. And I do want to do that. One of my coworkers today had a great idea to make the game more fun, but it will be a lot of work. I might just have to save the idea until I port it to C++/OpenGL. Of course, there are other games I want to do in 3D...
I previously mentioned how I got high-quality foreground graphics with low-quality background, and yesterday I thought of a much simpler and probably faster way to do it, so refactoring was much less of a headache. In short, the app now runs at full resolution, including all of the foreground bitmaps and such (no scaling down), and the background is rendered at low resolution and upscaled. That way only one thing needs to be scaled, rather than a whole bunch of things.
I decided that it's better to have a crummy visual effect with better gameplay than the opposite. The only way I think I can get good performance out of this game (mostly the water effect) is to convert to C++/OpenGL once the PlayBook native SDK is released. And I do want to do that. One of my coworkers today had a great idea to make the game more fun, but it will be a lot of work. I might just have to save the idea until I port it to C++/OpenGL. Of course, there are other games I want to do in 3D...
I previously mentioned how I got high-quality foreground graphics with low-quality background, and yesterday I thought of a much simpler and probably faster way to do it, so refactoring was much less of a headache. In short, the app now runs at full resolution, including all of the foreground bitmaps and such (no scaling down), and the background is rendered at low resolution and upscaled. That way only one thing needs to be scaled, rather than a whole bunch of things.
Thursday, June 09, 2011
Rainstorm performance analysis
I added a display for frames/second (fps), and discovered that my multi-touch version runs at about 13fps, so lower than I guessed by eye. That means the HD version must be at about 5fps. I decided to do some subjective profiling by turning on and off various features (such as drawing only the ripples, turning off sound, etc.) to find out what the performance hog is. Of course it's the ripple effect. Nothing else makes a huge difference, basically everything else drops the rate by about 3fps total.
So I tried changing the resolution to 256x150 (1/4 screen res), and poof, we got 30fps. The ripple effect is a little grainy, but I think with everything else at full res it might not look too bad. I'd rather have a smooth, fun game than a choppy, nice-looking game any day. If RIM ever decides to improve the performance of the flash runtime I can bump the resolution back up. I also tried 384x225, but that was about 20fps. And I tried changing the resolution of just the ripple map (behind-the-scenes calculations) and that helped, but the 256x150 combo was the only setting that got 30fps.
So now I'll be updating all the graphics to work well at this new resolution.
So I tried changing the resolution to 256x150 (1/4 screen res), and poof, we got 30fps. The ripple effect is a little grainy, but I think with everything else at full res it might not look too bad. I'd rather have a smooth, fun game than a choppy, nice-looking game any day. If RIM ever decides to improve the performance of the flash runtime I can bump the resolution back up. I also tried 384x225, but that was about 20fps. And I tried changing the resolution of just the ripple map (behind-the-scenes calculations) and that helped, but the 256x150 combo was the only setting that got 30fps.
So now I'll be updating all the graphics to work well at this new resolution.
Wednesday, June 08, 2011
How to control the boat
As I watch people play my game (friends and family), I've noticed that everybody tries to control the paper boat as if it were a real boat in the water. They start with their finger on the boat, then drag it where they want it to go. With real water, I see two ways of making the boat move without touching the boat, and without blowing.
One, you can put your hand behind the boat and make a wave that moves the boat. Two, you can put your hand in front of the boat, then push water away from the boat to make a sort of slipstream. People seem to use a combination of both, especially with the new control scheme which acts like blowing the boat. So for really intuitive control, I need to make a sort of slipstream control.
Here's what I have in mind: when the user is just touching (not dragging), make a repulsion force at the touch point. When the user is dragging, make a time-decaying slipstream. Time-decaying means it's strong when they first make it, but over time it weakens and goes away completely. I envision the slipstream only lasting maybe 3 seconds total, but only really giving a good push for 1 second. If you drag along right in front of the boat and kind of lead it along, it will follow your finger, and if you make a quick curvy swipe it will follow the path for about 2 seconds and then continue with its own inertia.
One thing I like about this idea is it's a small-scale "fire and forget" type interaction, where you tell the boat (or leaves) where to move in the near future, and then you can do something else while they're moving. Of course, you only get a few seconds in between each move, but that's good for a game.
I'll code this up soon and let you know how it goes.
One, you can put your hand behind the boat and make a wave that moves the boat. Two, you can put your hand in front of the boat, then push water away from the boat to make a sort of slipstream. People seem to use a combination of both, especially with the new control scheme which acts like blowing the boat. So for really intuitive control, I need to make a sort of slipstream control.
Here's what I have in mind: when the user is just touching (not dragging), make a repulsion force at the touch point. When the user is dragging, make a time-decaying slipstream. Time-decaying means it's strong when they first make it, but over time it weakens and goes away completely. I envision the slipstream only lasting maybe 3 seconds total, but only really giving a good push for 1 second. If you drag along right in front of the boat and kind of lead it along, it will follow your finger, and if you make a quick curvy swipe it will follow the path for about 2 seconds and then continue with its own inertia.
One thing I like about this idea is it's a small-scale "fire and forget" type interaction, where you tell the boat (or leaves) where to move in the near future, and then you can do something else while they're moving. Of course, you only get a few seconds in between each move, but that's good for a game.
I'll code this up soon and let you know how it goes.
Tuesday, June 07, 2011
The Rainstorm now supports multi-touch
After just 40 minutes of work, The Rainstorm now supports multi-touch, and it's pretty sweet. The Air documentation is very good, with the examples especially. The one downside is that I don't get mouse events now, so I need to figure out how to bring those back (while also keeping multi-touch) so I can continue to develop without having to test on the physical device every time.
For the developers here, this is the Air documentation page that is most useful:
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/events/TouchEvent.html
For the developers here, this is the Air documentation page that is most useful:
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/events/TouchEvent.html
Subscribe to:
Posts (Atom)