Cross platform application development using game technology

1,155 views
1,107 views

Published on

Using game technology to develop cross platform applications. From a local cocoaheads chapter in Johannesburg South Africa.

Published in: Technology, Design
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,155
On SlideShare
0
From Embeds
0
Number of Embeds
19
Actions
Shares
0
Downloads
16
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • http://cocoaheads.org/ is a local group meeting and more info can be found one their home page. This talk is from a chapter in Johannesburg, South Africa.
  • These are the ideas behind cross platform development for applications, I do not claim to have invented anything by stating the obvious.
  • ALL from personal experience with the development toolset, All opinions regarding Torque2D are my own and do not reflect the opinions of TorquePowered/InstantAction or my employers.
    More information about Torque2D can be found at http://www.torquepowered.com
  • Good things that come from game development tools in an application context. The concept here is simple, there are options of all types and flavours, some needing to be mixed together.
  • Downsides in using game technology for cross platform applications can include the above.
  • “Corporate” game design – Using game technology for corporate or general application development.
  • These things affect all projects, game or application. Again, stating the obvious.
    Important things that influence your decision if choosing a cross platform technology to employ in developing a client application – Don’t choose something that requires extensive maintenance or setting up on the client machines. Even large and chunky dependencies might be disallowed on a corporate network or environment. Find these things out way in advance before spending time on something you need to rework late into the project.
  • Co Chaser is a mockup application that I developed for the purposes of this discussion only. The intention behind the application itself was to see how much of the application could be implemented with prior knowledge of the toolchain.
    In total, I limited my development time to 20 minutes maximum. All screenshots visible in this document were fully functional – the remaining features required included communication with the server, testing, and persistence to the device/platform. The demonstration was that I could make a prototype, a functional demonstrable prototype to sell to a company. To show to prospective clients, or to test the viability via user reaction and intake in the company I intended to deploy the application. At that point, a windows/mac/iPhone client was available to deploy for testing amongst peers and colleagues.
    A note – I made the mock-ups myself. Any representation of an actual application was coincidence, and unintentional.
  • This is MY overview of the tool itself.
  • Obviously the above mentioned stuff is not always possible. Usage example here was Opera, Firefox, Chrome. Users expect the exact same application on all platforms. When you move from OSX to Windows you don’t have a different application to learn – everything is as similar as possible in all regards. This should affect the design challenges you employ when making a cross platform application. (Again, not inventing common sense here).
    Secondly, If a user is used to pinching to zoom, try not to implement some sort of mechanic that is alien to the user on that platform. If a user expects a list to scroll, do it the same way as the native platform if possible.
  • The iPhone version of the application.
  • The resulting windows/mac application. The primary target was iPhone in this example, but this incomplete (read : missing a lot of buttons and things) screenshot is definitely not something a user would not know how to use off the bat. On Mac, the toolbar buttons housing the application view contain all the major functions while the menus have minimal but useful options. Similar options apply to the windows design, a side panel (like explorer side pane) was intended to represent common tasks in the application.
  • Just an overview of what changed between the two. Not much, just scaling the text entry and the bottom bars horizontally.
  • Features that I had set out to use to complete the application goals. These should be mapped ahead of time to minimize time spent implementing base technologies and focus on product usability and implementation.
  • <Video demonstration is currently not available, I am working on getting the video from the meet up )
  • Now we move onto working in game development tools (The same tool) to rapidly prototype games and ideas.
    Note : This was to just give insight to application developers of the options available from the technology they might employ to make applications.
  • A simple stealth game was demonstrated, showing the above features in action. For more information on this specific project and the “depth” of the example shown (with regards to game play and the simplicity behind implementing it) please see the following link : http://blog.owned.co.za/?p=246
    Also note that ctrlr is an ongoing project and is still in slow development due to work and life (see http://blog.centrc.net for updates)
  • <Video also not yet available> http://blog.centrc.net will have more information and posts regarding this game, and the video portion of this presentation.
  • Cross platform application development using game technology

    1. 1. Game technology as a cross platformGame technology as a cross platform application development alternativeapplication development alternative
    2. 2. Part One – Application developmentPart One – Application development - Cross platform application overview- Cross platform application overview - Tool chain overview- Tool chain overview - “Corporate” game design- “Corporate” game design - Application development case study- Application development case study Part Two – The side of gamesPart Two – The side of games - Building games for multiple platforms- Building games for multiple platforms - Rapid development tools case study- Rapid development tools case study
    3. 3. • Being able to outbid the competitionBeing able to outbid the competition • Offering more than one platformOffering more than one platform • Having the skill to make either orHaving the skill to make either or • Wider range of clientsWider range of clients • Not restricted to one platform orNot restricted to one platform or crowdcrowd • Not stuck requiring a unique skill setNot stuck requiring a unique skill set • More than one revenue optionMore than one revenue option
    4. 4. • 4 Offered platforms, Win/Mac/iPhone/iPad4 Offered platforms, Win/Mac/iPhone/iPad • Strong user base, (Including Torque2D forStrong user base, (Including Torque2D for PC)PC) • Quick development turnaroundQuick development turnaround • Easy to use, easy to rapidly prototypeEasy to use, easy to rapidly prototype games/apps.games/apps. • iPlatform feature integration and nativeiPlatform feature integration and native codecode • Once off many app license, Indie availableOnce off many app license, Indie available
    5. 5. • Games come automatically.Games come automatically. • Support from community andSupport from community and developersdevelopers • Lots of already implemented featuresLots of already implemented features • Lots of open source mentalityLots of open source mentality • Free and commercial alternativesFree and commercial alternatives • Wide range of varying degrees ofWide range of varying degrees of featuresfeatures
    6. 6. • C++ and Objective C programmingC++ and Objective C programming experience might be necessaryexperience might be necessary • Alien tech could take too long to learnAlien tech could take too long to learn for you application requirementsfor you application requirements • Set list of platforms exclude otherSet list of platforms exclude other platforms inherently, monolithic codeplatforms inherently, monolithic code makes it much harder to port to newmakes it much harder to port to new platforms quicklyplatforms quickly
    7. 7. • Target market, platform, audience, etcTarget market, platform, audience, etc • End users, usabilityEnd users, usability • Platform requirements (choosing somethingPlatform requirements (choosing something unavailable on a multitude of platforms)unavailable on a multitude of platforms) • Development team skillsDevelopment team skills • Alternative software options (always an optionAlternative software options (always an option if skills are there)if skills are there) • Timelines, the usual.Timelines, the usual. • Interesting yet ridiculous features ( shaders,Interesting yet ridiculous features ( shaders, physics ).physics ).
    8. 8. • Built using the “Nightmares of executiveBuilt using the “Nightmares of executive application decisions” guide book.application decisions” guide book. • "just like <successful product>","just like <successful product>", • "we could make millions""we could make millions" • MUST run on every device conceivableMUST run on every device conceivable • Target EVERY possible target market, allTarget EVERY possible target market, all agesages
    9. 9. • Its SUPER usefulIts SUPER useful • SUPER EFFECTIVESUPER EFFECTIVE • Its fake.Its fake. • Its just like <insert similar>, but forIts just like <insert similar>, but for businessbusiness • Its scalable, multiple platforms etc.Its scalable, multiple platforms etc.
    10. 10. • Designing cross platform from the startDesigning cross platform from the start • Try and stay true to the native usersTry and stay true to the native users • Treat all platforms equallyTreat all platforms equally • Users expect the same application (difficult atUsers expect the same application (difficult at times because of the above).times because of the above). • Build all interfaces at the same time if you canBuild all interfaces at the same time if you can
    11. 11. • Asynchronous updating of the backend. (TCPObject orAsynchronous updating of the backend. (TCPObject or HTTPObject or similar)HTTPObject or similar) • Keep the UI responsive. No cluttered or continousKeep the UI responsive. No cluttered or continous "loading" (animated sprite)"loading" (animated sprite) • Cache as much as possible , reduce load timesCache as much as possible , reduce load times (iPhoneSaveStringToDevice, FileObject)(iPhoneSaveStringToDevice, FileObject) • Location Bound (Geo location is a trend)Location Bound (Geo location is a trend) (iPhoneLocation - $iPhoneLocationLocation)(iPhoneLocation - $iPhoneLocationLocation) • Easy to use, Fast, Snappy UIEasy to use, Fast, Snappy UI
    12. 12. • Torque2D for iPhone case exampleTorque2D for iPhone case example • Behaviors allow drag and drop game playBehaviors allow drag and drop game play • Device specific optimizations for mobileDevice specific optimizations for mobile • Level and asset management taken care ofLevel and asset management taken care of • Non-developer friendly toolsNon-developer friendly tools • Scriptable without source/IDE access /Scriptable without source/IDE access / rebuilding etcrebuilding etc

    ×