About mobile game porting

Question

Hello

I would like to ask a few questions regarding mobile game porting...

Let say if I have a simple 2D C++ game engine and have a PC game based on that engine and I want to port it to different mobile platforms BREW, J2ME, iPhone, Android, Symbian, etc..

Do I need to re-code the engine and the game for each platform? or is there an easier and more efficient way? I am sure the process is complicated since different phones have different graphic/processor/memory/etc. I am just curious about the overview of mobile game porting process. :)

Thanks!

Answer 1

This of course depends on in which language your "simple engine" is written. Java is supposed to be easier to move between platforms, since it in effect is a platform of its own. If your engine is written in something more low-level, like C++, it will likely depend on platform-specific libraries for graphics and input, since C++ doesn't provide you with that.

Answer 2

1. If the engine you have is not written in JAVA or FLASH I don't see a way that you can use your engine out of the box without recoding it in a language which might run on a mobile phone.
2. If it is coded in JAVA or FLASH, I think you're main problem (beside the performance difference between a phone and a pc) is the main memory. As I've heared, the main memory is the biggest problem in mobile phone game development.

Answer 3

As others have pointed out, if your engine is built on top of some 'platform independent' framework such as Java, then it's supposedly easier than if it's written in a lower level language. However, neither Java nor Flash is, for example, supported on the iPhone/iPod touch, and it'll probably take a while until they are. On the other hand, if I recall correctly, the only SDK available for those platforms is Objective-C, which, guessing wildly, you didn't use to implement your engine.

In general, it depends on the application/game engine you've written. Most likely you'll have to change something, as very rarely are all features available on all platforms. J2ME graphics is a classic scenario of 'platform independent'-dependence, or so I've heard. How much you'll have to change solely depends on how portable your code is, i.e. how well did you separate out the parts that potentially need changing.

Unfortunately, this is the best answer I can give you.

Answer 4

There is no free lunch. The platforms you are considering are not compatible, most of then allow you to run C/C++ code so in theory you could port the engine to some Standard, such as ANSI, or C99 and it would compile in most of the platforms PC, BREW however this does not take in account the libraries your engine might need. For example if your engine uses OpenGL then it would work in the PC, and some consoles but on Symbiam devices you need OpenGL-ES which is not exactly the same, so you need an abstraction for all libraries you use.

About J2ME and Android they are Java platforms, so no C/C++ can be run there without any special VM lib at least. In this case you need to port the C/C++ code to Java which can be overkiling.

So my answer to this is while you can make an abstraction to your libs and code using standards you might be able to use the same engine in several platforms as long you can use the same compiler for them.

Take a look for example to this engine CubicVR it allows you to compile the same engine for PC/Linux/MAC/iPhone (maybe)/Sony PlayStation Portable

Answer 5

What I have used for multiplatform development is to implement a hardware abstraction layer. The engine is coded in C++ but using a plain C interface to implement the system calls. This allows you to use full-fledged C++ for your game and engine and link with the system abstraction written in whatever language your platform needs. Symbian doesn't support 100% of the features of C++, and still has a few bugs, and IPhone API uses Objective C. C is compatible which most of the platforms you mention (well, not Java) and linking C is easier than C++, as there are less problems (ABIs and all that stuff).

Implementing a additional interface in C is a little slower, but will help you a lot when porting it to other platforms. Also, it allows you to have a Win32/Linux/Mac build besides the Symbian, BREW, etc. one. I have worked, mainly, with Symbian and N-Gage, and the debugging capabilities of those platforms are signifficantly behind Visual Studio or GDB. Iphone, on the other side, has a lot of cool tools to debug and profile your app.

Answer 6

There are several ways of attacking mobile game porting. First of all, until very recently it was mostly BREW and J2ME. The iPhone, Android and BlackBerry are changing this landscape and making the impossible task of mobile game porting even more impossible. I worked in 3rd party mobile game development for many years until recently. I watch BREW vanish and saw publishers completely focus on J2ME as the cost of porting is strangling the industry. There are estimates to its cost, both time and money, and it seems to bell curve around 50-60% of the total development cost for each game is just porting.

At our company, we handled porting by having two engines that paralleled each other, one in BREW, one in J2ME. We never supported Symbian as Symbian development does not make any money. It is mainly for high-end tech demos that might be on one or two devices, nothing that could reach the mass market. Plus, most Symbian phone supported J2ME.

We would be required by publishers to provide any where from 7-23 reference builds of the game, targeting many different devices, in both BREW and J2ME. Just before moving on, publishers were also starting to require a J2ME touch screen reference version, and an iPhone SKU was being left as "to be determined" based on the final product and how cost effective an iPhone version would be at that time. The reference versions would then be passed on to a porting house to translate the different references to the thousands of other required SKUs.

Companies like Gameloft still brute force their way through porting. That's why Gameloft's games are constantly at a higher quality than the rest of the industry. However, it is just not possible for smaller companies to attack the problem this way due to costs. Not everyone can afford an office in Beijing with 5000 developers.

There are many companies out there developing engines to cut porting costs. Mobile-Distillery is one I was in contact with quite a lot, but we ended up never using it. So, I can't vouch for them. The problem here is that you will be at the mercy of another companies engine. Performance could be problematic due to the fact that it is being built to target thousands of SKUs. Plus, you really have little control over the low level implementation of your game in this instance. The end result seems to be a game that targets the lowest common denominator of phones.

Finally, a lot of developers are just abandoning the idea of supporting all mobile platforms. There is a huge flood on games on the iPhone because 1) it requires only targeting one platform and 2) there is a 70 percent profit share through the AppStore for developers. Through carrier releases, the percentage is not even comparable.

Answer 7

I can personally recommend edgelib as a cross platform layer for mobile games and application development.

It is widely used, offers excellent performance and supports most of the important smartphone platforms in existence today: Symbian, Win Mobile, IPhone and others. Most important: It's cheap and offers a free complete evaluation until you decide to produce commercial content with it.

You can find it at: http://www.edgelib.com

You can see a showcase of games and other projects based on this platform at the site.

Unfortunately, BREW is not supported though. And since it isn't a real open platform, it poses quite a challenge compared to other mobile OS platforms as it's development community is mostly professional and not very "talkative" in online terms... This will perhaps change as the competition is getting more open by the minute.

I am not affiliated with Edgelib... this is just my personal opinion. :)