Tag Archive: game programming


Menu System is an important part of a game, no matter which platform you want to target. Same is the case with Android and I found the platform flexible enough to facilitate any such requirement. While developing my first game, i too got into multiple approaches while i was searching for the best (and of-course ‘easier’ ;)) way to develop a menu system for my game. I found some ways on different forums that involve making an activity for each menu screen. This has some advantages but I personally didn’t like this approach. Finally I found a way, through some experimentation, that was more understandable (for an indie PC game developer, like me) and is described below:

1. Create a layout file (.xml) for your menu screen just like you do to create any other screen and place some controls on it. You can add as many screens as you want using this way.

2. Now you have to modify your game activity class to initialize these layouts using View objects. You can either keep separate variables for each view or you can declare and array of views and initialize them all.

image

3. The currentView variable is an index that determines the view that should be passed on to the activity to show on the screen.

4. Now initialize your view depending on its type. You must use the LayoutInflator class to get the view object that you want to store.

image

This is a simple utility function that takes a layout resource id and returns the required view object.

5. Write event handlers for your controls in each layout in your activity class and use the currentView variable to determine the next view to show.

6. Now you can use the setContentView(View) function in your event handlers to switch to the next screen by using currentView index and using it in allViews array. Look at the sample call below:

image 

7. Optionally, you can pass parameters among these views by utilizing the view.setTag(object) function and passing it a custom parameter class instance.

This way, you can think of your whole game as a single activity (just like a PC game) and switching between screens as required. I don’t assume that this approach is the best one out there and i look forward for some positive feedback on this.

Advertisements

The starting point of any game project is writing a game loop. This is one of the most integral and crucial part of any game, whether small or large. So it must be given due attention and one should choose the most appropriate and optimized way of doing it.

The Android game programming is no exception and there are several ways of managing and writing this game loop. Here I’ll discuss some approaches that I found in SDK samples and other resources (excluding OpenGL part). There are some basic steps to follow before writing these game loops.

The first step is to create your own View or Layout by extending an existing Layout or View (like LinearLayout or SurfaceView). Then override its onDraw method to control the rendering over this surface. The general concept is, that you call some update function that calculates the dynamics of the new frame and then post an invalidate command that ultimately forces the View to draw itself, hence creating a simple basis for drawing and refreshing the objects on this surface.

1. Using TimerTask and Timer

One way of creating this loop is to extend the LinearLayout class and override its onDraw function. Then add a Timer object in the child class. Look at the code chunk below:

image

You then need to write some functions to start/stop this timer. They should look something like below:

image

The schedule function of the timer object takes a TimerTask object and the time after which the Timer task is run. Here the UpdateTask is a custom class that extends the TimerTask and overrides its run function.

image 

The postInvalidate function forces the View to redraw itself and the update function is a local function that you have to write yourself (you can name it anything) to calculate game’s next frame.

2. Creating a Custom Handler

This scheme is used in the Snake game that comes with the SDK’s samples. In this approach, you create a custom class by extending the Handler class and overriding its handleMessage function. The custom handle should be written inside you game view so that it can access the update and invalidate functions of your view. The child handler class should look like this:

image

Now you need to create an instance of this class in your game view class and then call its sleep function from your method that you will use to update your game’s frame. In the code snippet above, the sleep method calls some internal message handlers to make sure that the message is sent and handled appropriately. To find out more details about this approach, refer to the Snake game that comes with SDK samples.

3. Using SurfaceView, SurfaceHolder and a Custom Thread

This approach is considered more appropriate if one wants to write a game that is more real-time. Some SDK samples like LunarLander and JetBoy also implement this technique.

This method use the SurfaceView class to create its main game view class. The game view class in turn needs to handle the SurfaceHolder call back and then use it to get the underlying canvas which can be used to carryout the required drawing routines.

All the core game logic is written in the custom thread that uses it’s overridden ‘run’ method to update the game objects and redraw the view. This method contains a while(true) type of loop that repeatedly calls the drawing and updating routines. To draw the game objects, the method uses the SurfaceHolder’s lockCanvas method to get the underlying canvas object and then uses that object to do the drawings.

This approach doesn’t use the view or layout’s onDraw method and hence doesn’t require calling the invalidate method as the other two approaches do. Instead it clears the screen itself by calling the Canvas object’s drawBackground or drawColor routines.

Since there’s no delay or wait time mechanism in this approach, therefore, it allows the system to do the update and draw processing as fast as it possible increasing the refresh time of the game’s frames.

This wraps up the post here. I hope it is helpful for those seeking out to develop games on the Android platform.

Here’s a quick post that will guide you through a few very simple ways through which you can make you application run in a full screen i.e. without title and the notification bar of the Android OS.

1. You can add the following piece of code to your OnCreate function of your activity to make it run in full screen mode:

requestWindowFeature(Window.FEATURE_NO_TITLE);

getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN, WindowManager.LayoutParams.FLAG_FULLSCREEN); 

Note that the first call to requestWindowFeature function might be optional for you in case you want to run the application in full screen but you also need to show the title.

2. The second method, which is more preferred in my opinion, is to use the AndroidManifest.xml file and add following attribute to your activity (in your <activity> tag, of-course):

android:theme="@android:style/Theme.NoTitleBar.Fullscreen"

The main difference between these two methods is that the first one will be called a bit late and you will see the notification bar appearing and then going in the background. The second method however avoids this behavior and make your application run in full screen straight away.