Today we add a very important feature to the game. Some Android devices don’t come with a keyboard, so we must allow users of such devices to play the game using the touch screen. We’ll also add diagonal movement into the mix and make it so we can add solid walls into the map.

First step in the touchscreen process is to divide the screen into nine parts – four cardinal directions, diagonals, and center. Android comes with a really handy Rect object that stores a series of coordinates (like the Coord object from yesterday) that represent the top left and bottom right corners of a rectangle, and a Rect.contains(x,y) method that tells you if an X,Y point is contained in the rectangle. This is very easy stuff to do myself, but why reinvent the wheel, right? Right. We’ll make nine of these to store the nine regions of the screen, and We’ll test the X,Y touch point against each to figure out which direction Red should go.

Next we need to capture when the user taps on the screen. Android makes this easy for us by allowing us to override certain system calls; we can say “instead of doing what you normally do for screen taps, do this“. This, in this case, will be to move Red one square in the direction we tapped.

I should mention that TouchEventListener (aptly named, as it listens for when the user touches the screen then does what we want) listens for three events: TOUCH, MOVE, and RELEASE. Interestingly, the system ignores all RELEASE events unless we acknowledge a TOUCH event. This make sense because a RELEASE event should not be expected without a TOUCH event, but it’s annoying because we might not care to do anything when the user touches the screen, only releases, and we don’t want to have to take the extra step to acknowledge it. This doesn’t affect my game because I’m doing everything on TOUCH, for now.

Now we have our touch screen mapped to eight directions and a center (unused for now), and we have our previous movement code from the keyboard. We just copy it over and be done right? WRONG! Repeating code is generally bad – it’s sloppy and difficult to maintain. Let’s say we need to update our movement algorithm, so we update it in the touch screen but forget to update it in the keyboard. The game might act weird at best and catastrophically fail at worst. Instead, we’ll move the character movement code into the Character class, and call the Character’s movement functions from both the touch screen Listener and the keyboard Listener.

Current demo: Red can move diagonally using either the keypad or the touch screen. He is now trapped in a predefined map with corridors and rooms and walls.

Up to this point I’ve been hard-coding a lot of things in the game and not leaving a very much room for expansion. This is quick and good enough for testing things, but ultimately as the project gets bigger, it can get messy. Today we’ll do some code redesign so we can expand to add new map tiles and and character types – that means enemies! For today’s note, if you’re unfamiliar with Object Oriented programming and design, you might find yourself going a bit glossy-eyed. I’ll forgive you.

Our game uses a lot of X/Y coordinate pairs. It’s not a terrible inefficiency to have two variables here, but it looks a bit cluttery when declaring the two variables, and if we have to set both variables at the same time. A Coord object would do nicely to store both X and Y coordinates of anything – pixel coordinates, map tile locations, player locations, etc – so we can create and update both X and Y variables at the same time. Not necessarily more efficient, just cleans up the code a bit. We can also add some helper classes to this Coord object to check if it’s within a specified rectangle, or to check the distance between two of these types of coordinates easily. This will be handy later when we have characters interacting.

Next we’ll create a BitmapHelper object that initializes, processes, and stores all of the graphics files used by the game. Think of it like a librarian that knows exactly where all books are at all times. We can ask the librarian for any tile, creature image, or series of animation images and it’ll give them to us, ready to be drawn. Moving the graphics stuff into its own object is also nice if we want to use it in another app, we can just grab the object file instead of copying and pasting pieces of code from the Game object. We’ll also see benefit from this by not having to wade through game code to add another graphic, everything is neatly packed away in the graphics object.

Current demo: Aside the background changes, I added a walking animation so Red walks to adjacent tiles instead of jumps.

Please note for today’s writeup, all coordinates assume the very top-left is 0/0, increasing X as you go right and increasing Y as you go down. Also when I say map location, I mean the location on the entire map, grid or ‘visible map’ means the visible portion of the map on the screen, and pixel is each little dot on the screen. Now that we have that cleared up for the less technically savvy, on with the show.

Yesterday, we left the game drawing a subset of the map and Red traveling around the subset. Today We’ll make it so Red can travel around the entire map. To do this, we’ll need to come up with a way to represent movement around the whole map.

We could keep the visible portion on the same section of the map no matter what – even if Red is not on a visible tile. This is just silly, and I’m disappointed you would even suggest it.

Another option is to keep the view stationary until Red reaches the edge of the map, then adjust the visible portion of the map so we can still see where Red is going. This is better, but it still leaves some surprises if there’s an angry killer bunny right next to us on the next screen that we didn’t see (this is one of the things that bugged me about old Zelda games).

Yet another option is to keep Red in the center of the screen at all times, and move the grid around him. Essentially, adjust the visible portion of the map whenever Red moves to a new tile, so you always see the same range of tiles no matter where you are on the map. This is the method I’m going to use for this game.

This change will require another major overhaul to the drawing routine to figure out exactly how to choose which map tile to start drawing in the upper left, and how to nudge the map so Red appears in the middle of a tile (instead of standing between two tiles). I won’t go into details here to keep things simple, but you can ask if you want details.

Current demo: Red stays stationary in the middle of the screen and the grid is drawn around him. As Red moves, the grid is adjusted so you always see the same range of tiles around Red at all times.

Today’s goal is to change the screen drawing method to use the second method described yesterday, and implement a tile-based map that Red could be drawn on and move around.

Taking a look at the sample code is overwhelming. It’s important to take code like this and poke with it, intentionally break things to see how they break, and just have fun. The debugger that comes with the Android Dev Kit is really nice and works well to see what’s going on in the sample. Once we’re done messing around, we’ll take the code and clean it up to its most basic elements: the game setup, the keyboard movement routine, and the drawing routine.

The map for the game is a grid of tiles, with each tile being a wall tile, floor tile, trap tile, switch tile, etc.

The first experiment was to draw the entire map on the screen at one time – even the tiles that weren’t drawn on the screen would be run through the drawing routine and put into memory. The map held 40,000 tiles (200×200) where each tile is 400 pixels (20×20). That means the routine would process and draw sixteen MILLION pixels with each time the screen would redraw. This resulted in a very poor frame rate -  4 frames per second – and would probably kill the battery dead in no time.

We should probably optimize this to calculate the number of visible tiles on the screen based on the device’s screen resolution (more on this later), and only draw those tiles for each frame. On the emulator, the screen fit a 23×17 section of the map, so we really only need to draw approximately 156,000 pixels each frame. This will improve the frame rate to faster than the LCD is physically able to draw, with time to spare for the inevitable extra logic in the game for enemies’ artificial intelligence and such. Reaching a hardware limitation is a very good thing.

As an added note, this graphic routine should automatically resize the visible map based on the hardware configuration of the device you’re using. If we were to configure the game based on the screen resolution of the lower resolution G1, the game would look like crap on the higher resolution Droid. Taking the resolution and screen size into consideration early will save a huge headache later when testing on multiple devices.

Current demo: Red is displayed with a two frame animation on a grid map. Pressing a direction will move him to a new grid location and update the direction he’s facing.

Today’s goal was to put some research into drawing graphics onto the screen. Basically, with the Android, there are three general methods to put stuff on the screen.

First, and simplest, is with the predefined Android view classes. This method allows us to put icons on the screen, and give the icons simple animations. This is good if we want to add some graphic flare to an otherwise boring app, but doesn’t allow much interaction.

In the second method, we override the onDraw() routine to fine-tune where things are placed on the screen, and call invalidate() method when we want to refresh the screen. This is good because you can tell the screen to refresh when WE want it to (like when you press a key to move a character) – it doesn’t take up much processing power, and we’re able to have more interaction with where things are on the screen. The downfall is the simple animations that are accessible in the predefined static screens aren’t available here. Since we’re updating the screen ourselves, we’ll need to control which image in a frame animation or which frame of a “tween” animation – translate, scale, pivot, etc – is shown. It’s a bit more work, but the trade off in interactivity is worth it.

The third method of screen drawing is the most processor intensive. It involves spawning a new processor thread that will handle screen drawing, while the original thread handles input and game logic. The “graphics thread” draws to a separate canvas based on data fed from the “logic thread” then it displays that canvas immediately when the drawing is finished, then starts drawing the next frame on a new canvas. This method produces a screen that is constantly being updated, so we can have very smooth animations for more graphically intensive games. The downfall with this is it is constantly drawing to the screen, so it’s more processor intensive and drains the battery faster. Also the same animation gotcha applies from above.

I played with all three of these before deciding that the second one would be best for my game.

Current demo: Using the third method above (though I ultimately decided to use the second after the demo was created), I defined my onDraw() routine to draw the image of a guy, we’ll call him Red, on a white screen at a specific location. The direction pad updated the location, which would be reflected when the screen redrew itself.

So basically a guy moves around a screen.

Finally, an excuse to update the site!

Lately I’ve been tinkering around with the development kit for my new phone. It’s an Android phone, if you didn’t deduce that from the title of this post. In the past few days I’ve just done some very basic form stuff, learning about layouts, XML view definitions, creating custom views, and interactions between “activities” which are basically sub-applications within an application package you’d download off the Marketplace, or what have you.

My first application, which will be on the Marketplace when I get around to signing up for a developer’s key, is a Dungeons and Dragons style dice rolling app, where you can type in a dice roll string (e.g. 2d10+4d6) and it will show you the rolls. I’m aware that this has “been done” and it’s not the most complex app, but I made it to learn, and it served its purpose.

My next project, which will be the new focus of this blog, will be much more interesting. Not the blog posts – those will be mostly nerdy stuff, but the final application should be fun. It’ll be a top down dungeon crawler – a roguelike, if you’re familiar with the genre. If you’re unfamiliar, think a simplified Zelda with randomized maps and items to provide infinite replayability.

As a side note, I will be cutting back on WoW to work on this more. Frankly, it’s more fun.