More Rainstorm Progress

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. 

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.

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.

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.

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

How to get high-res images in a low-res Air app

I thought about another way I might get partial HD graphics working.  The problem is that the resolution of the screen is 1024x600, and setting the application to that size (even without changing the assets) slows things down too far.  So I set it to 512x300 and then let Air scale it to full res to get reasonable performance.  This means everything is pixelated doubly.

After noticing that text and standard buttons render at full HD, I had the thought of loading a bitmap that's double the resolution that it needs to be, then scaling it down before letting Air render it.  This works for the one item I tested it on.  Some of my other objects use a different method for rendering, so those will take some work to HD-ify.  Here's what the code looks like:


// This image is double the size it needs to be
[Embed(source='rainStormTitleFinalHD.png')] public static var RainStormTitleImage:Class;

titleImage = new Image();
titleImage.setImage(new RainStormTitleImage);
titleImage.x = -30;
titleImage.y = 10;

// This part is where we scale it down.
titleImage.scaleX = 0.5;
titleImage.scaleY = 0.5;

addChild(titleImage);

The result of this is that when an Air app designed for 512x300 is upscaled to 1024x600, the above image is the perfect resolution (not pixelated).

Here is a comparison of a section of the screen.






First the original, pixelated image.










And here's the HD image.

So it's clearly working, and so far it doesn't affect the framerate noticeably.  But it's only the title screen that's setup this way.

Unfortunately, most of my game objects use BitmapData and copyPixels to an off-screen buffer which is eventually rendered in the normal Air way.  Before GPU acceleration in Air, this was a speedy way of drawing graphics that don't need to be scaled or rotated.  With GPU acceleration, this way is slower.  So I need to make everything a Sprite or some such and just do things with the "normal" Air method to get HD bitmaps in a low-res app.  And that's a fair bit of work.  But right now it's not my highest priority.

HD attempt and better controls

Summary:

• HD is too slow for now
• Repulsion control is lots more fun

A few days ago I converted the main resolution of the app to full HD on the playbook (1024x600), because the appworld version (1.0.1) is upscaling half that resolution (512x300).  I did this because I wasn't sure how smooth it would run on the actual device, and I'm glad I did, because at half resolution it runs at about 20fps.

Last night I tried running at full HD resolution, with the exception of the processor-hungry water ripple effect still at half rez.  Even with that, the framerate dropped to about 8fps.  Unplayable.  Rats.
So I'll have to wait until BlackBerry improves the performance of flash before I can really give HD.  I think the game still looks great without HD, and I'd definitely much rather play it with a higher framerate.

The other thing I tried last night was an improved control mechanic.  Version 1.0.1 uses only the water ripples to move the boat around.  I wanted it to be this way, but it ends up being too hard to control and just frustrating.  It was a good experiment, but it's just a poor way to control.

So version 1.0.2 adds a repulsion mechanic, so wherever you touch the tablet, the boat goes away from that point, sort of like if you were to blow air at that spot.  You still make waves, and the waves still affect the boat, but now the control is a lot more responsive and predictable.

Coming up next: multi-touch support, help page, movable leaves, multiple boats,
Coming up after-next: levels, intelligent enemies, online high scores, achievements, (maybe) upgrades.

A month of Playbook

It has been nearly a month since I received my BlackBerry PlayBook.  The Rainstorm plays alright on it, although the game isn't as tight and fun as I'd like it to be.  It's more frustrating to try to get the boat to move the way you want than anything.  So after playing with my new gadget for nearly a month, I'm finally getting back into updating the game and improving the gameplay.

Just tonight after an hour of work I was able to figure out how to transition half of the graphics to HD-quality, but the main water ripple effect is still half of the playbook's screen resolution.  It's scaled up to full-screen, but it's calculated at half that size.  It's an issue of performance.  The game runs at somewhere around 15-20fps on the playbook at half resolution.  I still need to check whether using the GPU helps, but I'm doubtful, since the ripple effect heavily relies on filters, which are not supported on the GPU with flash.  So what this means for now is that I'm likely stuck with nice HD-quality above-water graphics (boat, leaves, text), but anything below-water (coins, shadows) is half-size.

Near-term plans for improving the game are:

• HD graphics (except ripples)
• Smoother controls
• Move leaves with ripples
• High score list
• On-line high scores
• Help section

More distant plans:

• Multiple boats
• Moving enemies that you destroy by moving the leaves in their path
• Storyline, multiple levels, end game conditions
• Port to android, iOS

I plan to keep the game at the same price for all of the near-term improvements, but once I get the "distant plans" implemented, I'll raise the price by some amount.


In case anyone is curious, my high score on the playbook is $2.35.  Good luck beating that!

It has been nearly a month since I received my BlackBerry PlayBook.  The Rainstorm plays alright on it, although the game isn't as tight and fun as I'd like it to be.  It's more frustrating to try to get the boat to move the way you want than anything.  So after playing with my new gadget for nearly a month, I'm finally getting back into updating the game and improving the gameplay.

Just tonight after an hour of work I was able to figure out how to transition half of the graphics to HD-quality, but the main water ripple effect is still half of the playbook's screen resolution.  It's scaled up to full-screen, but it's calculated at half that size.  It's an issue of performance.  The game runs at somewhere around 15-20fps on the playbook at half resolution.  I still need to check whether using the GPU helps, but I'm doubtful, since the ripple effect heavily relies on filters, which are not supported on the GPU with flash.  So what this means for now is that I'm likely stuck with nice HD-quality above-water graphics (boat, leaves, text), but anything below-water (coins, shadows) is half-size.

Near-term plans for improving the game are:

• HD graphics (except ripples)
• Smoother controls
• Move leaves with ripples
• High score list
• On-line high scores
• Help section

More distant plans:

• Multiple boats
• Moving enemies that you destroy by moving the leaves in their path
• Storyline, multiple levels, end game conditions
• Port to android, iOS

I plan to keep the game at the same price for all of the near-term improvements, but once I get the "distant plans" implemented, I'll raise the price by some amount.


In case anyone is curious, my high score on the playbook is $2.35.  Good luck beating that!

Busy Times

Whew, July has seemed like an unproductive month for Watcher. In reality, I think lots was done, but it's mostly about learning. I have spent lots of time reading a book on character and story design. I haven't done much of that, and I'm the one to do it for this game, so I decided to learn a little about it.

As for actual development, this week I managed to squeak in a targeting reticle that can tag multiple targets, and a missile launcher module complete with enemy-seeking missiles. It all actually works quite well. The targeting reticle may also be used for ship-ship communication.

A major design decision I am facing right now is how to make the cities structured. I plan to have communication happen between ships, and I would really like to make it so the only written story comes from those communications. I am realizing that I will probably need to have some story communication happen in the cities as well. So when you go to the market to buy commodities the merchant tells you something important, for example. It would be cool from an immersion standpoint to make the player actually walk around the city and talk to people and go to shops and stuff. For one thing, that adds a ton more artwork that I'm not going to have time to make, and for another thing I think it would take away from the game. The fun part of the game is going to be flying the ship and dogfighting with enormous capital ships while bombing bases and protecting allies.

A recent flash game I've been playing (another reason for my lack of major progress) called Caravaneer has an interesting idea for cities. They just drew an arbitrary map of each city in real real simple form, and landmarks are indicated with an icon. So there's a well at each city, and a shop, and a market, and a doctor, etc. Each city has a different layout, but they all have the important landmarks. Another thing Caravaneer did is a good dynamic economy. I once thought of doing this before, but threw it out because I didn't feel it would contribute to gameplay. Now that I've seen what can be done with it, I just might have to put it in. It's not just randomly dynamic... it's market driven. So if a shoe-making town runs out of leather, shoes run out of stock, and the demand for leather grows dramatically. If you keep making shipments of leather to the town, eventually the demand goes back to normal and you won't make much money off of it.

Anyway, I might try that method, and if there's some important person you need to talk to, they will have a landmark on the city map.

Another reason this month may have not been quite so productive for Watcher is ...


Lauren was born! She's a cute kid, and we're glad to have her. Sleep at night is a little more precious now, though. Luckily Jared doesn't wake up to her wailing very much. Like, I think he's woken up only once in the week that she's been home.

Infrastructure

This week was just more infrastructure. There is now a message window in the HUD to tell you stuff about your mission (like when you complete it, and when you pick up cargo, etc.) and a new dialog that shows you all of your current missions. So if you just sign up for all available missions and forget what they were, you can look them up. The bounty hunting missions isn't quite so hacked together, and both cargo and bounty missions are randomized a little now (instead of entirely scripted).

One of my friends also gave me a good idea for the "first chapter" of the storyline. Instead of telling you what it is, I might do a little demo release of the first chapter when it's done. The first chapter is basically my first milestone. The game won't be feature-complete at that point, but a good chunk will be done.

So many little things

Wow, there are a lot of little things that go into making a game. You would think that I would remember that, since I have shipped one game (a long time ago). And I do remember it, but it always amazes me how many little things go into making a fully polished game. Today I spent some time on a few of the little things, like showing the name of a city on the navigation screen when you mouse over it. They're little, but very important. I'm not even talking about the microscopic stuff yet...

Anyway, the player's ship now loads properly between levels... before it would leave some stuff behind, like what weapons they had, and their entire cargo... it was like some sort of greedy border customs. But now it's all good. I still don't have game saving/loading, as I re-ordered priorities since I had trouble motivating myself to do the load/save framework.

Instead I worked a little more on missions. Now missions can lead you to other levels, and there's a hacked-together bounty hunting mission. It's not too exciting yet, since the AI just stupidly hunts you all the time, and it's easy to outsmart it. But the enemy ship is spawned correctly, in the correct region. I did a little work on the "little things" for mission creation too, like showing the mission description.

Anyway, here's a concept sketch for the ones who just like to look at pictures.

Howl's Moving Castle

This week I managed quite a few small additions/changes. The first thing was the radar/compass widget. Take a look (the arrows around the border):



The green arrows are landing pads, and the red are enemy ships. It works quite well.

The next thing was changing the movement method from direct velocity to inertial control. This change made the game a LOT more interesting. Now there's actually a point to combat. This change also opens the door to a lot of physics weapons.

The last changes were more under the hood, but they are paving the road to allow game saving/loading, which I feel is important even this early in the game. (heh)

Now that we've got the game dev report out of the way, I saw a great movie last night. All of you have probably already seen it... Howl's Moving Castle. I had not even heard of it until yesterday, and I absolutely loved the movie. In a lot of ways, it's the art style that I would like to have for Watcher. Howl's was a little too old-fashioned for what I have in mind, but the point is that there are airships and airplanes and such that are steam powered. The art style I hope for is some kind of mix between the old fashioned and futuristic. So, not everything will be coal steam powered, but also nuclear/fusion steam powered. There will be laser weapons and computers alongside the mechanical steam stuff. Anyway, if you haven't seen Howl's moving castle, you should. The art is amazing, and the story is amazing, if not a little strange. The plot isn't necessarily amazing, it's the storytelling that is fantastic.

Navigation screen

Not much happened this week, although I did make a functional navigation screen. Check it out.



That screen shows where your ship is and where all jump gates and cities are. I tried several dumb things first to get it working, and then I remembered TGB's ability to draw the same thing in a different window. I still kept some of the dumb stuff, like creating a new object for each thing to be displayed, since actual size on that map is really really small. So I scaled each object up about 10x.

Warp 0.5

So my jump gates work! The solution was simple... at first I was trying to end the current level or empty out all the scenegraphs, but the end result is that you just have to load the next level, and all the rest is taken care of. The result is...



... another world!

There are still some funny bugs (or lacks of features) with jumping, like loading all the defaults for your ship (weapons, upgrades, cargo, etc.) I'll get around to fixing that kinda stuff eventually. Like probably a week before release date (ha!)

Another accomplishment for this last week was jumping from Idaho Falls, ID, back to Provo, UT. I worked in an internship at Idaho National Laboratory for 5 months, and now it's back to PhD fishing in school. Although only a 4 hour drive, the move is still happening, as I type amidst towers of unpacked boxes.

Back to the game, another accomplishment is getting the first draft of a design doc done. It's not so much a design doc as a "core vision" document, but that's my method of game design. I like to work out the details when they are ready to be implemented. This game is already going to be hard to balance, so I don't want to try to balance it on paper and do a poor job of it on paper.

So the next step is making a map/navigation gui to show you where all the cities and jump gates are in your current region. The same gui will be used to see how jump gates connect different regions on a planet. These features will make it possible to give some life to missions... I can describe what city to go to, and then the player can look up where it is on the nav gui.

Don't get lost!

Gate jumping

Not much happened in development this week. Some time was spent on the design document. I really don't want to work on the design document, though, so I spent some time also developing. The result is a solid TGB crash. Basically I'm trying to load a new level when the player hits a jump gate (shown below).



I'm starting to figure out what needs to happen to keep TGB happy, but it's not quite there yet. The good news is that once I figure it out, I will have accomplished another of my major milestones for prototyping.

Mission Accomplished

This week I made good progress on Watcher. Bombs are now part of the standard weapon framework, which means you have to buy a bomb launcher, then equip the launcher on your ship to drop bombs. Bomb explosions now have a radius that diminishes in power as it gets farther from the center of the explosion. Buildings and decorations on the ground now have hitpoints, so one standard bomb isn't enough to destroy them... the guard tower currently takes 6 direct hits to destroy (a fairly difficult task!) although those kinds of statistics will change lots through the course of development.

The most exciting new feature to me this week is the missions (quests) system. Only one mission is available so far, but I think the system is flexible enough to add new mission types with fairly small effort. The one mission is to take 10 units of wheat cargo from the southwest city to the northwest city. When you accept the mission, you first have to fly to the first city to pick up the cargo (it's automatically loaded onto your ship, if you have space). Then you fly to the destination where the cargo is automatically dropped off and you are automatically paid. The system will allow multiple-stage cargo missions too... you could have to deliver cargo to multiple cities or pick up cargo from multiple cities. Right now I don't know if such a cargo mission would be fun or a good idea, but the point is that I can have such a mission if I want.

This morning I made some in-game menus. Now when you land at a landing pad, a city menu pops up so you can choose what you want to do at that city. When you choose the "missions" option, the missions dialog pops up where you can look at available missions and choose from them. Take a look at the new menus:



Yeah yeah, I know the game looks like more of a business application right now, but I'm forcing myself not to do any real artwork until more of the basis is put together. The game is getting to be fun... I need to add a few more cities and then the missions will be more exciting. Fun First! Pretty Later!

In other news, I decided earlier this week to learn a new keyboard layout. It's called Colemak, and it was invented just over a year ago. Check the website: http://www.colemak.com/ and here's an image:



Several years ago, I learned the Dvorak layout, and I liked it for typing emails and general text, but it was an absolute nightmare for programming and any sort of non-text development. The important shortcut keys just moved around too much, and the symbol locations just didn't make sense for programming. Colemak, in my opinion, fixes quite a few of those problems. It leaves many keys in the same place as Qwerty, but moves the most common English letters to saner places on the keyboard. So far the learning is a little slow, but faster than learning Dvorak. I'm up to probably 20-25 wpm. Unfortunately, I'm a sinner because I didn't type this whole blog post using the layout... I'm just in too much of a hurry. Speaking of... I'm taking off.

TorquEDIT

A month or so ago I found a nifty eclipse plugin called TorquEDIT. It was fairly basic, but it had some nice things going for it. I noticed that the code was open source, so I took a look. The code looked fairly well-written, and it looked like it would be relatively easy to add some functionality. So I did. Last night along with kruxgames I released another version that has a ton more functionality than before. This is now the editor I use for making scripts. The code completion really helps, and it serves as a form of documentation, since you can see what methods a particular class has, as well as what parameters the functions take. Right now it's mostly tuned for TGB, although it should work with TGE and TGEA quite nicely too. There's only a few little things that are geared to TGB. Check it out at http://opensource.kruxgames.com/torquedit/



This week I decided to install Ubuntu linux. The only purpose for this was to be able to use the music editor RoseGarden. After a few hours of following tutorials and general mucking around, I finally got it up and running. It's not the easiest thing to setup, but it's not too bad by linux standards. RoseGarden is what I will use for the music in Watcher. I probably won't start on the music for several weeks or months, but I had time to get it all setup now, so I did.

Just a few minutes ago I finished splitting all objects into proper collision groups. So now bombs affect everything they should, bullets affect everything they should, etc. The bombs also behave more like bombs... before if the bomb hit anything in its path (before it landed) it would still blow it up. Now the bomb lands, and blows up anything it's touching. Nothing eye-popping this week in Watcher, but TorquEDIT is pretty sweet.

Weapons Energized

Today I made it possible to purchase weapons at a store, and equip them in the ship equipment screen. There was a lot of under the hood work to be done to make all that possible. Now it will be rather easy to make new weapons, as long as they are the straight-flying projectile type.


Screenshot showing different weapons



Plasma gun art (temporary, obviously)


Guard tower (not yet functional)

The next major step is getting the guard towers to shoot at you, and being able to bomb them. That really won't take all that long, but I don't very often get big blocks of time to work on this.

A few concept sketches

Here are some very rough, very raw concept drawings for some
airplanes/airships. Just scanned 'em in, adjusted levels slightly,
and uploaded.


"The Seagull"


"Glider"


"Big Ship"


"Big Prop"

My favorite so far is "Big Prop." Hopefully by the end of this I'll
have a couple dozen ships that I like as much as "Big Prop."