PhaserCore dev update #2

I have uploaded an small video showcasing the new weapon system in Phaser Core. As soon you stop firing, the game enters into “bullet time” allowing to easily switch weapons. This has been designed with phone and tablets in mind as it easily allows interacting with the ship without being killed so easily.

The menu shows the remaining time available for each weapon with a circular gauge. Once activated, the ship is surrounded by a bigger circular gauge displaying the remaining time available.

So far I’m happy with that control system but will be revised in the future with feedback from everyone.

Fly safe!

 

Dev update #1

As promised, I will keep you up to date regarding the development of Phaser Core.

I’m currently working on some visual enhancements regarding secondary weapons. Currently the user has no feedback on the remaining time available for each weapon. This will be fixed by displaying a serie of circular gauges that shows how the time is recharged by picking up powerups and how it depletes by actually using the weapons. I will explain the concept in an upcoming post this weekend.

For now you can watch the new video with in-game sfx and music and improved video quality!

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!

ShadingZenCpp

A few days ago I released an initial “approach” to a 2D/3D computing library written in C++ with the ultimate idea to optimized ShadingZen (a java 2D/3D Engine). In its current state you can find various generic templates and some SSE specializations for 3 and 4 component vectors, matrices, quaternions and soon rays and bounding boxes. Those are the foundations for various common spatial queries algorithms too.

The source compiles against Boost 1.53 (its only dependency so far) on some semi-compliant C++11 compilers (cross-platform library!):

  • Linux GCC 4.7.20121109 (probably works with 4.6)
  • MacOSX Clang 3.2 (using libc++)
  • MSVC 2012

Supported SIMD instruction sets:

  • SSE: Yes, 4.1
  • NEON ARM: No
  • AVX: No

I have spent some hours this weekend tuning the Boost.Build2 scripts to ensure everything compiles in those various systems with unit testing and with just one command. I’m leaving android for some near future.

You can found the repository here: https://github.com/TraxNet/ShadingZenCpp Feel free to contribute!

1st May

1st of May is public holiday in Spain (as in around 80 countries in the world). I managed to make some hiking at Cabeço d’Or, a mountain near Alicante. Typical of me, I also took some photos:

The climb

Spring at Cabeço d'Or

With a refreshed mind I can happily go back hacking my new open source creature, ShadingZenCpp a cross-platform C/C++ library meant to speed up some portions of ShadingZen 3D Engine.

Android Performance (Object Pools)

This is the second part of my series of post about avoiding some performance hit caused by dalvik GC, first entry is here: http://traxnet.wordpress.com/2013/02/25/android-game-development-tipstricks/

Object factories are quite useful in this context as they avoid object to be GC’ed and also avoid allocating new memory which also incurs in some overhead.

In java this is done quite easily. For our objects to be poolable we need them to conform to an interface:

public interface Poolable {
   public void initializeFromPool();
   public void finalizeFromPool();
}

We also need to create a pool which allocates new objects if needed, and keeps the pool moving. The soruce code can be best viewed at GitHub here: ObjectPool.java

There is one drawback with this implementation, we need one pool for each kind (or type) of object we want to be poolable. With some more code we can have a jack-of-all-trades pool which can create any kind of object. ShadingZen has an specialized pool that creates rendering task of any type (assuming they inherit from RenderTask), the code can also be found here.

A 3d rendering engine is huge loop creating and destroying objects, thus reusing some of them will make a huge difference on mobile platforms.

Happy coding!

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.

Open code and you

doom

Moving some of my projects to the wild, I mean to GitHub, has made me realize what others already knew, much of the software we use everyday is open source or has some roots there. Be honest, peeking to someone else’s software is great. As to my own experience I started learning programming as a child reading the source code of the Doom Editing Utilities (and that probably shifted and twisted my understanding of computers for my entire life). This concepts of seeing others work and learning from it is a hidden fact that affects our life in for example every gadget we use (read Android/iOS). But not only to learn but to understand what a piece of software does, its source code is the ultimate documentation. If you are using a third party library, ask for its source code and peek at it when needed. At Video Stream Networks we made a similar approach, we had our domain logic code written in C++ every time we had to tune it for every customer’s workflow it made us feel miserable. After we moved our domain logic into Casper, a Domain Specific Language for the media and broadcast world, our customer can not only peek at what our app does but understand and fine tune it themselves.

Thanks to GitHub and the Open Source Community, ShadingZen Engine is slowly maturing. The GitHub repo received a pull request with some great changes. The project now has Maven build, the structure is more clear with all the examples and documentation centralized in just one repository and the eclipse requirement has been removed (This last point allowed me to try out IntellIJ IDEA which so far I find as a really good java IDE).

Yes, open source level editors as well a robust designed and extensible engine was behind the success of DOOM, the very same that made some of us programmers.