• Save
Cross Platform Game Development with GDAP, December 2012
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Cross Platform Game Development with GDAP, December 2012

on

  • 1,592 views

 

Statistics

Views

Total Views
1,592
Views on SlideShare
1,580
Embed Views
12

Actions

Likes
1
Downloads
3
Comments
0

1 Embed 12

http://rmyasis.wordpress.com 12

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Cross Platform Game Development with GDAP, December 2012 Presentation Transcript

  • 1. Cross Platform Game Development Philippine Game Development Festival 2012 / GDAP University of the Philippines, Diliman December 8, 2012 Markku Kero / Job and Esther TechnologiesCopyright (c) 2012 Job and Esther Technologies, Inc.
  • 2. What is the meaning of “cross platform development”?Copyright (c) 2012 Job and Esther Technologies, Inc.
  • 3. CROSS PLATFORM DEVELOPMENT Developing software that works on multiple “platforms” (operating systems / execution environments)Copyright (c) 2012 Job and Esther Technologies, Inc.
  • 4. What are these platforms, then?Copyright (c) 2012 Job and Esther Technologies, Inc.
  • 5. OPERATING SYSTEMSCopyright (c) 2012 Job and Esther Technologies, Inc.
  • 6. EXECUTION ENVIRONMENTSCopyright (c) 2012 Job and Esther Technologies, Inc.
  • 7. For a developer, are these platforms all same? Are there differences? What kind of differences?Copyright (c) 2012 Job and Esther Technologies, Inc.
  • 8. PLATFORM DIFFERENCES (#1) #1 Programming language / base technologyCopyright (c) 2012 Job and Esther Technologies, Inc.
  • 9. PLATFORM DIFFERENCES (#1) C# Java ObjC C/C# C# Java C JS C C++ C++Copyright (c) 2012 Job and Esther Technologies, Inc.
  • 10. NATIVE vs. NON-NATIVE There are two kinds of software applications: NATIVE and NON-NATIVECopyright (c) 2012 Job and Esther Technologies, Inc.
  • 11. NATIVE NATIVE applications interact with the underlying platform (= operating system / execution environment) directly NATIVE is something / someone that does not need an interpreterCopyright (c) 2012 Job and Esther Technologies, Inc.
  • 12. 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.Copyright (c) 2012 Job and Esther Technologies, Inc.
  • 13. NATIVE LANGUAGES C# Java ObjC C/C# C# Java C JS C C++ C++Copyright (c) 2012 Job and Esther Technologies, Inc.
  • 14. PLATFORM DIFFERENCES (#2) #2 APIs and librariesCopyright (c) 2012 Job and Esther Technologies, Inc.
  • 15. PLATFORM DIFFERENCES (#2) 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 componentCopyright (c) 2012 Job and Esther Technologies, Inc.
  • 16. PLATFORM DIFFERENCES (#3) #3 User interface designCopyright (c) 2012 Job and Esther Technologies, Inc.
  • 17. PLATFORM DIFFERENCES (#3) Windows Phone Android iOSCopyright (c) 2012 Job and Esther Technologies, Inc.
  • 18. PLATFORM DIFFERENCES (#4) #4 Development toolsCopyright (c) 2012 Job and Esther Technologies, Inc.
  • 19. PLATFORM DIFFERENCES (#4) Microsoft Visual Studio – Windows products Eclipse – Android, Blackberry, Symbian, .. Apple Xcode – Mac OS X, iOSCopyright (c) 2012 Job and Esther Technologies, Inc.
  • 20. ANOTHER THING TO CONSIDER Different versions of each platform are also different (fragmentation)Copyright (c) 2012 Job and Esther Technologies, Inc.
  • 21. PLATFORM FRAGMENTATION (As of June 2012; source Chitika)Copyright (c) 2012 Job and Esther Technologies, Inc.
  • 22. So we have all these platforms ..Copyright (c) 2012 Job and Esther Technologies, Inc.
  • 23. .. And we will continue to have them (and more) ccCopyright (c) 2012 Job and Esther Technologies, Inc.
  • 24. 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.Copyright (c) 2012 Job and Esther Technologies, Inc.
  • 25. How to approach this?Copyright (c) 2012 Job and Esther Technologies, Inc.
  • 26. 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 platformCopyright (c) 2012 Job and Esther Technologies, Inc.
  • 27. 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.”Copyright (c) 2012 Job and Esther Technologies, Inc.
  • 28. 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 furtherCopyright (c) 2012 Job and Esther Technologies, Inc.
  • 29. THE THIRD WAY The third way: CROSS PLATFORM DEVELOPMENT Developing software that works on multiple “platforms” (operating systems / execution environments)Copyright (c) 2012 Job and Esther Technologies, Inc.
  • 30. 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 platformCopyright (c) 2012 Job and Esther Technologies, Inc.
  • 31. There are different ways to achieve thisCopyright (c) 2012 Job and Esther Technologies, Inc.
  • 32. .. 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)Copyright (c) 2012 Job and Esther Technologies, Inc.
  • 33. Six different cross platform development approachesCopyright (c) 2012 Job and Esther Technologies, Inc.
  • 34. #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 browserCopyright (c) 2012 Job and Esther Technologies, Inc.
  • 35. The “scripted approach” architecture APIs and libraries Application code Language interpreter / runtime Operating systemCopyright (c) 2012 Job and Esther Technologies, Inc.
  • 36. 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.Copyright (c) 2012 Job and Esther Technologies, Inc.
  • 37. #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.Copyright (c) 2012 Job and Esther Technologies, Inc.
  • 38. 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 similarCopyright (c) 2012 Job and Esther Technologies, Inc.
  • 39. The Mono / Android architecture (Source: http://docs.xamarin.com/Android/Guides/Advanced_Topics/Architecture)Copyright (c) 2012 Job and Esther Technologies, Inc.
  • 40. #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)Copyright (c) 2012 Job and Esther Technologies, Inc.
  • 41. Unity on Android (includes Mono) C++ codeCopyright (c) 2012 Job and Esther Technologies, Inc.
  • 42. #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”Copyright (c) 2012 Job and Esther Technologies, Inc.
  • 43. #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”Copyright (c) 2012 Job and Esther Technologies, Inc.
  • 44. #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 makeCopyright (c) 2012 Job and Esther Technologies, Inc.
  • 45. Copyright (c) 2012 Job and Esther Technologies, Inc.
  • 46. EQELA Eqela reads source code written in the Eqela programming language / API, and translates it to various other languages, targeting different APIs / platformsCopyright (c) 2012 Job and Esther Technologies, Inc.
  • 47. 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 applicationCopyright (c) 2012 Job and Esther Technologies, Inc.
  • 48. 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 applicationCopyright (c) 2012 Job and Esther Technologies, Inc.
  • 49. Main.eq → Main.java class Main : LayerWidget { (EQELA) public void initialize() { base.initialize(); add(LabelWidget.instance().set_text(“Hello World”)); } } package mk.test; public class Main extends eq.gui.LayerWidget { @Override public void initialize() { 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)Copyright (c) 2012 Job and Esther Technologies, Inc.
  • 50. 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 accessibleCopyright (c) 2012 Job and Esther Technologies, Inc.
  • 51. 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: 96KBCopyright (c) 2012 Job and Esther Technologies, Inc.
  • 52. 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 approachCopyright (c) 2012 Job and Esther Technologies, Inc.
  • 53. 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 emotionsCopyright (c) 2012 Job and Esther Technologies, Inc.
  • 54. 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.comCopyright (c) 2012 Job and Esther Technologies, Inc.