Cross Platform Game Development with GDAP, December 2012

Cross Platform
Game Development
Philippine Game Development Festival 2012 / GDAP
University of the Philippines, Diliman
December 8, 2012

Markku Kero / Job and Esther Technologies

Copyright (c) 2012 Job and Esther Technologies, Inc.

What is the meaning of “cross
platform development”?


CROSS PLATFORM DEVELOPMENT

Developing software that works on multiple
“platforms” (operating systems / execution
environments)


What are these platforms, then?


OPERATING SYSTEMS


EXECUTION ENVIRONMENTS


For a developer, are these
platforms all same?

Are there differences?

What kind of differences?


PLATFORM DIFFERENCES (#1)

#1
Programming language /
base technology



C# Java ObjC C/C#
C# Java C
JS
C C++ C++

NATIVE vs. NON-NATIVE

There are two kinds of software applications:

NATIVE
and

NON-NATIVE


NATIVE

NATIVE applications interact with
the underlying platform (= operating system /
execution environment) directly

NATIVE is something / someone
that does not need an interpreter


NON-NATIVE

NON-NATIVE applications interact with the
underlying platform through another program
(often this is called an interpreter)

Something that is not native, will never
be native: Even if it may very much look
and feel as if it was.


NATIVE LANGUAGES

C# Java ObjC C/C#
C# Java C
JS
C C++ C++


#2
APIs and libraries



Android iOS Windows Phone
Graphical rendering Android API, Cocoa Touch, UIKit, Silverlight, (XNA),
API / framework OpenGL ES Quartz, OpenGL ES Direct3D
Standard library Java C / Posix .NET

Networking API Standard Java Standard Posix / .NET
CFNetwork
Memory management Garbage collection Reference counting / Garbage collection
manual
Library format .jar .a / .so .dll

Web browser WebKit / V8 WebKit Internet Explorer
component



#3
User interface design



Windows Phone Android iOS



#4
Development tools



Microsoft Visual Studio – Windows products
Eclipse – Android, Blackberry,
Symbian, ..

Apple Xcode – Mac OS X, iOS


ANOTHER THING TO CONSIDER

Different versions of each
platform are also different
(fragmentation)


PLATFORM FRAGMENTATION

(As of June 2012; source Chitika)


So we have all these platforms ..


.. And we will continue to have them (and more)

cc


Bottom line

While targeting only the most popular
target platforms, you will need to work
with 10-20 different operating system
platforms/versions, at least 3-4
different programming languages,
each with different API libraries.


How to approach this?


A classic solution (#1)

Only work with one operating
system / platform

+ Easy to do

- Self-limited market reach

- The destiny of your game is tied to the target
platform


The way to extend to different platforms:

PORTING
“PORTING is the process of adapting software so
that an executable program can be created for a
computing environment that is different from the one
on which it was originally designed.”


A classic solution (#2)

Make several versions of your game, one
for each platform / programming language

+ Expanded market reach

- Massive amount of work / development cost

- Not very rewarding for a programmer

- Difficult to maintain, fix and develop further


THE THIRD WAY

The third way:

CROSS PLATFORM DEVELOPMENT

Developing software that works on multiple
“platforms” (operating systems / execution
environments)


THE PURPOSE

Desired outcome: Only one codebase per
app. The single codebase will be used for
all desired target platforms.

+ Expanded market reach
+ Optimal amount of work / development cost
+ Programmer can focus on enhancing the app (not
rewriting it)
+ A single codebase is easy to maintain, fix and
develop further
+ Your game is not tied to any particular platform


There are different ways
to achieve this


.. NATIVE and NON-NATIVE ..

Some cross platform development approaches
produce NATIVE applications
(not requiring interpretation)

Other cross platform development approaches
produce NON-NATIVE applications
(requiring interpretation)


Six different cross platform
development approaches


#1: The “scripted” approach
(Adobe Air / Flex, Appcelerator, Corona, RhoMobile, ..)

Runtime /
Virtual Unmodified
machine Source code
+ iOS
Interpreter / application
Virtual machine
For iOS

Source code Development
In a scripting tool
language Unmodified
Source code
(JavaScript, + Android
Lua, Ruby, ..) Interpreter / application
Virtual machine
For Android
Run in
browser


The “scripted approach” architecture

APIs and libraries Application code

Language interpreter / runtime

Operating system


The “scripted approach” architecture

Increases memory APIs and libraries Application code Makes application
usage
Installers much bigger

Language interpreter / runtime

Applications can only
Reduces runtime Operating system Access selected
Performance Parts of the native API

Due to this approach being very popular, many consider
cross platform development to be slow, high in memory use,
and producing bigger installers.


#2: The “bytecode” approach
(MoSync, Mono)

iOS
application
Bytecode
Class
Library Android
application

Bytecode Development
Compiler Tool

Source Windows
code Runtime / Phone
Virtual application
machine Run in
browser

Very similar to the “scripted” approach,
with the added bytecode compilation step.


The “bytecode approach” architecture

Increases memory APIs and libraries Application code Makes application
usage
Installers much bigger

Bytecode interpreter / runtime

Applications can only
Reduces runtime Operating system Access selected
Performance Parts of the native API

Due to its similarity with the “interpreted” approach, the
benefits and disadvantages are very similar


The Mono / Android architecture

(Source: http://docs.xamarin.com/Android/Guides/Advanced_Topics/Architecture)


#3: The “C++” approach
(Marmalade, Qt, WxWidgets, Unity)

iOS
Cross
application
Plaftorm
Class library
In the specific
language
(Usually C++) BlackBerry
Playbook
SDK / application
Source code compiler
In a specific
Language
(Usually C++)
Android
application

Windows
Run in Phone
+ Truly native (100%)
browser application
+ High performance
- Limited platform support
(not really cross platform)


Unity on Android (includes Mono)

C++ code


#4: The “embed a web browser” approach
(PhoneGap)

Run in C source code
browser Libraries
That opens a
iOS iOS
Browser and
SDK application
Displays the
program

Source
Code in
HTML, CSS, “Compiler”
JavaScript
Java source code
That opens a
Android Android
Browser and
SDK application
Displays the
- Very poor performance program
- Suitable for only “web-style” apps
- Limited access to platform APIs
- Application source code can be easily retrieved
+ Easy way to convert existing websites to
“native apps”

#5: HTML5

+ Commonly known skillset (HTML, CSS,
JavaScript)
+ Very popular, many Internet resources available
- Unfinished standard
- Fragmented, non-compatible implementations
- Extremely poor performance on mobile
- The language is poorly suited for large programs
- Applications are inherently “open source”


#6: The “source code conversion” approach

Libraries C
iOS iOS
source
SDK application
code

Java
Android Android
Source source
Compiler SDK application
Code code

Javascript Run in
+ Truly native (100%) on any platform code browser
+ High performance
+ Optimized memory use
+ Small installer size
+ Unrestricted API access
- The tools are difficult to make

EQELA

Eqela reads source code written in the Eqela
programming language / API, and translates it to
various other languages, targeting different APIs /
platforms

How it works: Sample application

class Main : LayerWidget
{
public void initialize() {
base.initialize();
add(LabelWidget.instance().set_text(“Hello World”));
}
}

Main.java, Android
Eqela
Main.eq LayerWidget.java,
Compiler SDK
LabelWidget.java

LayerWidget, Android
LabelWidget application


How it works: Sample application

Only native code → “100% native”
No virtual machine added
No interpreter added

Main.java, Android
Eqela
Main.eq LayerWidget.java,
Compiler SDK
LabelWidget.java

LayerWidget, Android
LabelWidget application


Main.eq → Main.java

class Main : LayerWidget
{
(EQELA)
base.initialize();
add(LabelWidget.instance().set_text(“Hello World”));
}
}

package mk.test;
public class Main extends eq.gui.LayerWidget
{
@Override
super.initialize();
((eq.gui.ContainerWidget)this).add(((eq.gui.Widget)eq.widget.LabelWidge
t.eq_widget_LabelWidget_instance().set_text(eq.api.StringStatic.eq_api_
StringStatic_for_strptr("Hello world"))));
}

public Main() {
}
} (JAVA)

Unrestricted API access

class AndroidHTTPGet
{
public static bool execute(String url) {
embed “java” {{{
org.apache.http.client.methods.HttpUriRequest hur =
new org.apache.http.client.methods.HttpGet(url.to_strptr());
android.net.http.AndroidHttpClient hc =
android.net.http.AndroidHttpClient.newInstance(“testing”);
org.apache.http.HttpResponse resp = hc.execute(hur);
if(resp == null) {
return(false);
}
}}}
return(true);
}
}
→ All platform specific features / APIs
are accessible


Comparison: “Hello world” application

The “scripted” approach:
Appcelerator Titanium: 8MB
Mono: 4MB

The “embed a web browser” approach:
PhoneGap: ~300KB

The “source code conversion” approach
Eqela: 96KB


Summary of approaches

Performance Native Web Memory use API Source
or not compatible / application access code
size visibility
Scripted Low Not No High Limited Open
approach
Bytecode Medium Not No High Limited Hidden
approach
C++ approach High Native No Low Full Hidden
Embed a web Low Not Yes Medium Limited Open
browser
approach
HTML5 Low Not Yes Medium Limited Open
Source code High Native Yes Low Full Hidden
conversion
approach


How to apply this?

Be aware of and understand
the technical factors

Make informed decisions based
on technical facts

Do not choose your approach on
arbitrary criteria or emotions


Contact me / us

Markku Kero Eqela
@markkukero (Twitter) @eqela (Twitter)
http://www.markkukero.com http://www.facebook.com/eqelasw
http://www.eqela.com

www.jobandesther.com


Cross Platform Game Development with GDAP, December 2012

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (10)

Semelhante a Cross Platform Game Development with GDAP, December 2012

Semelhante a Cross Platform Game Development with GDAP, December 2012 (20)

Cross Platform Game Development with GDAP, December 2012