The Phaser

EDIT: Added a short video showcasing the gameplay.

If you have been following me on twitter you may already know I have been working since the past month on a retro shoot’em up with hand crafted pixel art. Main target platforms are PC/MAC and iOS/Android. I’m still thinking if I should go first on mobile platforms or not.

Do you want more bullets?

Do you want more bullets?

 

Regarding Twitter, I currently use the hashtag #ThePhaserGame following the name of the main ship in the game, but this probably with change soon (with a more catchy name!).

You are death

You are death…

The gameplay focuses on intense action with massive bullets and explosions with a mix of fast-paced areas and slower areas where you need to concentrate on enemy patterns and bullet avoidance.

Go run!

Go run!

I have a huge list of user-stories that need to be implemented, from in-game cutscenes to final bosses, probably enough to hire a designed and a programmer, but unfortunately I don’t have the resources (a.k.a money) to do so. This is a one-man strong project 😉 Technologically speaking, the whole game is written in C++11 and uses Cocos2d-x as the 2d engine to run everything (with minor tweaks from my side 😉

Fast paced action in a confined spaced!

Fast paced action in a confined space!

If you like the screenshots above, follow me on twitter and spread the word! If you have any ideas (on weapons, enemies or whatever) drop me a message here or using twitter.

Fly safe!

Android Game Development Tips&Tricks

Kill the bugs

Kill the bugs

It has been several months since I first thought I should post here some of basic tips and tricks on android development, specifically game development. Sadly I have almost no free nowadays. But here it is, a new blog entry I hope I can expand into a little series. Everything posted here comes from my own experience developing ShadingZen, an open source 3D Engine for Android

This is all about java, dalvik and you. We well talk about java development and what little tricks you can do to make your game shine (ok maybe not shine, that depends on your graphics people, but to go faster and avoid slow downs). If you follow me on twitter you may recall me saying dalvik GC is slow…oh well, I was wrong, it is not dalvik but the mobile environment what is slow. If you don’t believe me, create a jni example and put a delete inside a loop, then profile.

Lastest versions of dalvik have done a huge leap towards a good-performance-all-around-vm. For gaming it was critical to release a non blocking garbage collector, prior to version 2.3 (Gingerbread) used to pause the whole application for more than 10ms. Let’s do some simple math: for a 30fps animation you need to rendering one frame in 33ms aprox. If the garbage collectors hits in, your animation will suffer.

Ok, so the garbage collector works as intended. so why do still need to use tricks and put more thoughts on the whole thing? Well….it is a mobile, all those Hires bitmaps need to be deleted and created during your application, if you do this very often, it is going to be slow, no matter what. This leads us to the number one tip, don’t allocate memory if you don’t need to.

1. Measure

A claim that something is slow need some proof. You need to start benchmarking your gameloop from day 0 of development and be sure nothing breaks your desired frame rate. A good resource for benchmarking is Caliper.

2. Avoid Allocating Memory

This tip may look like too simple, but it is true, you don’t have many spare memory, don’t allocate objects that you really don’t or have a more basic counterpart that would do the job.

3. Don’t release memory

– What?! – Yes, don’t release memory, it is slow, and furthermore, you will probably need to use it again, or a partial copy of it. Avoid having a huge for lop with hundred of iterations where you code creates and discards objects, that’s going to hurt you later, when the GC starts collecting that memory.

There is a very smart way to condense tip 2 and tip 3 into just one big idea, object factories. This will be may next tip, for the second part of this blog entries series. I will post some code for you all (although you can go right now to ShadingZen repository at GitHub and start taking a look!).

Resources

– There is great talk by Google’s Advocate Chris Pruett on some basic ideas, take a look at them: Writting Real-Time Games for Android

– Caliper. A benchmarking tool.

Towards ShadingZen 1.0beta2

Development of ShadingZen is approaching version 1.0 beta 2 and a new minor update has been rolled out and ready to be cloned/forked by you at ShadingZen’s GitHub repository.

The primary goal for this milestone (v1.0 beta 2) is to provide better documentation, ranging from API documentation to useful examples for the wiki.

Secondary goals are to improve performance, mainly in areas where we can use object pools to avoid garbage collection frame rate drops. In fact, RenderTasks have been refactored and now use a global shared pool manager which creates and reuses RenderTask objects. This gives a performance boost but increases memory usage.

ShadingZen is a 2D/3D Engine for Android OpenGL ES 2.0 and is open source under the MIT License.

Android realtime performance tips

Embedding programming has never been easier after the introduction of modern mobile APIs like Android SDK and iOS SDK. Nevertheless for realtime applications new areas for potential bottlenecks may arise as those extra layers add more complexity to your application.

A clear example may happen with the Dalvik GC (Garbage Collector), which coupled with a realtime 2D/3D Engine generating many objects for each frame, will (for sure) showcase frame drops when the GC hits in. This is hard to solve as Java makes really easy to create new objects that encapsulate your required functionality but hides from you how and when the memory will be collected. Hey! it creates objects everywhere, for iterators, enums, sorting alogrithms…I personally think Dalvik needs some improvement in memory management areas but meanwhile we just need to avoid those problems and minimize them as possible.

Dont create objects! No, seriously, don’t create new objects in your game loop. Use object pools as much as possible. This is an area ShadingZen engine is improving and is one of the reasons you should always create new actors using the “spawn” method.

Don’t call your own methods, use the objects properties within the objects code and use methods to access functionality from outside. Also avoid using getters and setters, but pack functionality in just one method call instead of using the getted property from outside. For example if you want to make an actor explode you may need to compute explosion velocity and actor final destination from outside. Instead create a “makeExplode” method for that and compute everything within the object code. Dalvik makes calling methods slow.

If you are using OpenGL ES avoid changing states, pack drawing calls sharing the same state and run them at once.

DDMS is your friend. I know how much you hate its awkward interface but you need it, profile often!

Check this paper as it contains basic guidelines to avoid performance bottlenecks in your realtime applications: http://dl.google.com/io/2009/pres/WritingRealTimeGamesforAndroid.pdf

Performance is an area the next version 1.0-beta2 of ShadingZen is receiving much love.

ShadingZen 3D Engine open sourced!

I’m showing you the code!

I have decided to open source my 2D/3D engine for Android and it is currently available at GitHub under the MIT License [put random reason here].

https://github.com/TraxNet/ShadingZen

The goals behind ShadingZen is to offer a simple framework on which you can build mobile games easily, but without leaving behind performance reasons like stressing out multicore mobile CPUs found in modern phones/tablets. I have borrowed some ideas found at Cocos2D that I just find really useful, like Actions and Transitions.

Go clone it!

I’m using my spare time to create some HOWTOs and examples. I would also like to write down some core concepts of the engine. For more info keep an eye to future changes at the GitHub wiki here.

Some notes I’m preparing for future documentation sections.

Development of Kids 3D Cube

I’m happy to announce that I have release my newest creation, Kids 3D Cube for Android:

https://play.google.com/store/apps/details?id=org.traxnet.kidscube

For this game a new 2D/3D engine optimized for multi core phones was created, targeting OpenGL ES 2.0, so It won’t run on old Android versions (below 3.2.).

A few interesting things about the 3d engine: It employs an smart task scheduler to parallelize work among all cores. It also has a lazy resource loader and few other interesting functionalities that I believe are a good starting point for upcoming titles.

I have to confess that mobiles GPUs are challenging for the limited set of resources, but high rewarding when your little phone starts showing up your glorious shaders on screen! 😉 A tip: minimize bandwidth usage, keep us much on GPU side and reuse it as much as possible. This is a big win on low-end phones.

I’m actively working on solving a few issues and adding new content to the game, stay tunned!

You can visit Kids 3D Cube fan page at Facebook here: http://www.facebook.com/Kids3dCube

Android MediaRecorder with Camera

Our animated gif and stopmotion maker application (Gifagram) relays heavily on the Android camera support. Two good starting points for Camera and Video recording on android are:

http://developer.android.com/reference/android/media/MediaRecorder.html
http://www.codesend.com/view/73d3edc51302c0e6a2fa3075db6fa1ab/

The first link is the Android SDK MediaRecorder class and the second one is a lengthy example.

Unfortunelly SDK information on camera and video is poor, and hidden behavior is quite undocumented.

For instance, MediaRecorder.setProfile(‘HIGH’) sets an invalid video size in Samsung Galaxy SII (1080 height, instead of 1088 as hardware requires). The same code on HTC Wildfire throws an exception although on other HTC phones, everything works great. This is heavily hardware dependent which can run you crazy.

Video recording using a Camera object

The following code snipplet setups the camera:

boolean setupVideoRecording(int use_profile){
    	boolean ret = true;
    	try{
    		if(recorder != null){
    			recorder.release();
    			recorder = null;
    		}

    		if(camera != null){
    			camera.reconnect();
    		} else{
    			camera = Camera.open();
        		//camera.lock();

    		}

    		CamcorderProfile profile;
    		if(use_profile == 0){
    			profile = CamcorderProfile.get(CamcorderProfile.QUALITY_LOW);  			
    		}else{	
    			profile = CamcorderProfile.get(CamcorderProfile.QUALITY_HIGH);
    		}

			Camera.Parameters params = camera.getParameters();
			List sizes = params.getSupportedPreviewSizes();

			//List formats = params.getSupportedPreviewFormats();
			Size optimalSize;
			optimalSize = getOptimalPreviewSize(sizes, profile.videoFrameWidth, profile.videoFrameHeight);

			params.setPreviewSize(optimalSize.width, optimalSize.height);
			params.setPreviewFrameRate(profile.videoFrameRate);

			params.setColorEffect(filter);
			camera.setParameters(params);
			setCameraDisplayOrientation((Activity)context, 0, camera);

			camera.setPreviewDisplay(holder);
			camera.startPreview();	
			camera.unlock();

			recorder = new MediaRecorder();
			recorder.setCamera(camera);

			recorder.setAudioSource(MediaRecorder.AudioSource.MIC);
			recorder.setVideoSource(MediaRecorder.VideoSource.CAMERA);

			if(use_profile == 2){
				recorder.setOutputFormat(profile.fileFormat);
				recorder.setVideoSize(optimalSize.width, optimalSize.height);
				//recorder.setVideoSize(profile.videoFrameWidth, profile.videoFrameHeight);
				recorder.setVideoEncoder(profile.videoCodec);
				recorder.setAudioEncoder(profile.audioCodec);
			} else{
				recorder.setProfile(profile);
			}

    	} catch(Exception e){
    		String message = e.getMessage();
	    	e.printStackTrace();
	    	ret = false;
    	}

    	return ret;
    }

We pass a use_profile integer to choose some hardware dependent code. But for almost everything the use_profile == 2 is the right one for you.

And the following prepares the media recorder. Both functions can be called one after the other to completely setup the camera for video recording.

boolean initializeMediaRecorder(){
    	try{
    		recorder.setOutputFile(captureFile);
			recorder.setPreviewDisplay(holder.getSurface());
			recorder.prepare();
			return true;
    	} catch(Exception e){
    		String message = e.getMessage();
	    	return false;
    	}
    }

This code is quite simple but I hope it can be the foundation of something more elaborated for someone. Please feel free to leave a comment if you have a tip that you would like to share with everyone.

Android development tips – Gifagram project

For the past months I have been reading the Android SDK, trying out it’s OpenGL ES 2.0 capabilities (check my Github project ShadingZen) and was really impressed with the overall API quality. It’s easy to get things done, and its integration with Eclipse helps too. Current top devices are computing crunchers!

I went thinking I could play a bit higher by developing some application for Android, and that’s how we came with the idea of Gifagram app.

Gifagram.com promo image

The idea behind it is to enable the user to create stop-motion or animated GIFs directly from her Android device. GIFs are easy to share, doesn’t take much bandwidth and some very creative people manage to communicate really stunning stories in this format.

Not everything was easy tho. The camera API in android is really quite undocumented and its behaviour relies completely on the underlying hardware implementation. Retrieving useful information from the beta-tester devices was also cumbersome (to the point that was much easier to just take the terminal to the mac and just debug it directly than to take and read the logs).

Some tips on android development:

  • Think the user workflow within the application and minimize user taps and input steps. Make it simple, vertical application vs “The killer app”.
  • Prototype the application with simple buttons and don’t waste time until the domain logic is really working.
  • Try your software on every android device you can get. This probably should go on top of your list.
  • If you plan to create a free and a paid version, develop with a single application and when you are ready to go to market, convert the project to library and reference it from your free and paid android projects (check this: http://developer.android.com/guide/developing/projects/projects-eclipse.html).
  • Android market share is growing, but it’s fragment in devices and versions. Android 2.2 and 2.3 are currently in almost 90% of the devices out there, develop with this in mind.
  • Avoid NDK unless you are really sure about any performance boost that may gain. For gifagram we had to use it no matter what and was a bit tricky at some points.
Side note: There are a lot of useful resources, for example stackoverflow.com is a great place to look.