Big Bad Robots Blog

For the past week or so, I have been investigating various Remoting solutions that I can implement for the Flex Games I have currently developing. The basic features that I am looking for were:

• Translation of complex data types (being able to map classes on the client and matched on the server)
• PHP supported
• Compressed data format
• Transparent RPC mapping

I initially started with AMFPHP but switched to ZendAMF. AMFPHP seems to be falling behind in support with the last release in 2008 which is decades in Internet time. Zend AMF is also backed by Adobe which is a good sign. On the side note, iPhone integration looks pretty good to with a Cocoa AMF. I would have preferred C++ but I guess it will do in  pinch for now. I will be testing that next week or so.

Zend seems a bit fat, because you have to also include the Zend Framework as well. That’s something I’m going to have to figure out to see if it can add value to services I am writing.

Game developers are fairly practical in their implementations. The most practical of Design Patterns that every game developer should understand intimately are:

• Singleton – Singletons are needed but often abused as a design pattern. A singleton is basically a class with one instance. Most prior singletons were not thread-safe but with multi-processor architectures of hardware, this should be a consideration. Singletons are common used for creating loggers, database/networking access objects.
• Factories – Factories are usually coupled with singletons. Factories are often found in resource/assset managers allow  managed assets to be created. The role of a factory class is to “create objects” based on a template with specific functionality or generic
• Model-View-Controller – The Model-View-Controller is a way to separate (but not necessarily simply) functionality of complex systems. A Game Engine could use the MVC design pattern to sort out the various components into logical blocks of code.  MVC is used extensively in Flex development to break up monolithic applications into manageable portions. The Model contains all data used by the application. The View is what the user sees and the Controller is Application core, responding to events from the View and coordinating resources from the Model.

Right now there aren’t  any good open-source development environments for Flex. Everybody seems to be using Flex Builder, which you have to pay for. For me, I like things free especially since my primary web development platform is Ubuntu 9.10. I did find AXDT which, which I feel shows the greatest promise in evolving as a free alternative to Flex Builder. Plus it helps that the primary target seems to be Ubuntu.

For more information, you can go to: www.axdt.org. I have got it working with the latest Flex 3.5. I am having some trouble with Flex 4 though but that’s still in Beta. Primarily I wanted something to allow me to edit mxml and Actionscript files not caring much about layouts. I have also been able to get it working with AMFPHP. So far it has done most of what I want.

I finally had enough time to look at developing on the Android platform and got my test integration of C++ code with the Android NDK working. The biggest hurdle proved to be familiarity with the Android development environment itself. The following tips apply to NDK 1.6r1:

1) You DO NOT have to have surround your functions with a various extern “C”’s. Unlike what people are saying out there about having to do it you do not have to do it.

2) Check the names of the class to make sure the packages match your JNI interface. (i.e. if your class with the native interfaces are com.examples.HelloWorld…..your JNI class should be Java_com_examples_HelloWorld_<class>

3) Check your android.xml file for the proper package export. When you refactor/rename things in the Eclipse editor it will not update the package export. This will result in Android not being able to find your JNI interface and complain in logcat.

As of 1.6r1, the NDK is something still to play around with and not really ready for production development. That seems to be way the Google Android teams seems to like to run things. Although the OpenGL ES 1.0 libs are available, other supporting libraries are not (i.e. those to load png or jpg’s for texture. The audio libraries). My initial experiments on writing xPhone with Android has a initial platform would prove daunting to say the least.

I was checking the Google Android site and noticed that the Native Development Kit release 1 is out. The exciting part of this release, is that now we can natively write games in C++ with access to the OpenGL ES 1.1 api. This should mean that we can start looking at developing proper games on this platform. This will also mean, that I will need to figure out how to get xPhone to start compiling against the NDK. Unlike my research into Windows Mobile and it’s broken Graphics API support at this time,  this means working with a 3D API versus having to support Direct Draw.

Still need to poke around it more. The bad part will probably be working via Eclipse to get things done. I already have to use 2 other IDE’s (Visual Studio and Xcode) and so a third is fairly unproductive.

I was working on integrating tinyxm into the current xPhone build to handle configuration files and was having a heck load of problems. It seems that that Windows Mobile doesn’t like it when you don’t specify the UNICODE/_UNCODE predefines and use other data types. Understandably a mobile device should Unicode ONLY targets because phones need to be able to support multiple language out of the box. Still, it didn’t help with me having to play around with compiler settings until I was blue in the face.

That’s part of challenge of cross platform development is that everything is different on different platforms even down to the way text works.

I have been doing some research on how to approach configuration files for the xPhone Game Engine (A cross platform game engine for Smartphones). The design objectives are:

• Human readable – Should be able to read and change configuration
• Used only for initialization and not run time configuration
• Any library used should be small and minimal impact because we are targeting embedded devices

The choices are either to:

• Wrap up tinyxml and have configuration as xml files. xml files are barely human readable though
• Use libconfig, which allows for more human readable. Problem is integration with scripting language in the future
• Code another ini type library

My current favorite is still leaning for xml because:

• tinyxml will be useful if the user of the game engine wants to read/write their own game data in xml format
• xml is supported by python which is the scripting system I would use for the tools and ingame scripts

I have always had a heck of a time reading and figuring out what ‘consts’ apply to. As some of you may well know, you should try to train yourself to use const as early and often as necessary. Read more at Const Correctness to get an idea when and where to use it.

Then I found this gem while reading Scott Meyers Effective C++, hope he won’t get mad me replicating some of it here:

char *hello = "Hello World";    // non const pointer, non const data

const char* const hello = "Hello World";  ///const pointer and data

Basically the idea is to draw line on the asterix. If const appear on the left on the line, what is pointed to is const. If the const appear on the right, then the pointer is const.

This is more of a note to self about how to format a C++ header file based on what I think is important:


class MyClass

{

public:

<Public defined enums and constants>

public:

<Public variables OR Get/Set functions. Public variables are frowned upon anyways>

public:

<Public defined interfaces and constructors

private:

<Private variables>

private:

<Private functions>

};

The basic rules of thumb are:

• Public interfaces are on top because that is the first thing programmers reading your code want to know without scrolling down through the rest of the file.
• Protected interfaces follow
• Private interfaces are last (and often don’t change)
• Be consistent
• Use white spaces
• Split up constants, variables and interfaces with seperate “public/protected/privates”s

This is my first posting after migrating from Lunarpages to Dreamhost. I have actually moved a while back but haven’t been able to get round to setting up the blog properly.

I’ve been busy working on our first iPhone game. It’s a little stuck right now and needs a good swift kick in the pants to get done. Our target is to have it out by Christmas. I’ve also been puttering around with developing a cross-mobile game engine currently called xPhone. Setting up the project and getting it on two targets (iPhone and Windows Mobile) is a lot of work.

I’ve also need to finish up our my technical workshop on Game Engines/Game Programming that I am teaching later this month.