All my life I've build my games and programs on top of prebuilt software, Unity,Unreal, Python etc, But I've never really learned how it's standardly done in the industry, ya engines are cool, but they also cause problems such as having limitations with what you can do, as well has having to work around bugs etc. But let's look at other software: MS Office, 7Zip, Evernote, Firefox, Youtube, Amazon Alexa app, Inkscape, Autodesk cad, Photoshop etc. These are just some random examples but they were NOT built in an engine yet manage to be cross-platform. What skills/languages are required to do that? To be clear I'm not asking for a miracle answer that can tell me everything I need to know, but I'm looking for a guide on the tools used to build things like that. Is it C++? Is it OpenGL? Am I still think too high up? I don't know much about it but are that the right direction? I've heard of things like electron but I think you could consider that more of an engine. I can't imagine these companies doing this at the binary level, I would think that would be absurd doing that for every program in such a day in age, also impossible for startups like Mozilla and Evernote to do as brand new companies without a large amount (if any) incoming revenue. In the end, I guess what I'm asking is, what is the industry standard when building cross-platform programs? What are the tools they tend to use? And what sources could I learn from to learn ore about this?
P.S. To be clear I understand things like Evernote, Youtube, Alexa App, etc have back-ends behind them, but I'm not talking about those, I primarily mean the front-end though I would think whatever the standard is would be capable of handling a back-end.
Ex-Middleware Game dev here. To make anything work on any given platform, at the lowest level you will have to start accessing the OS or hardware specific API's (So for example, on windows, CreateFile to open a file, or open() on linux). The C/C++ standard libraries build on top of those API's to provide a somewhat generic platform on which to build cross platform apps.
Realistically though, the C++ stdlib isn't overly helpful in this regard, mainly because things such as graphics, windowing APIs, etc; they are all outside of the remit of the stdlibs. Another big issue for us game devs w/r/t the C++ stdlibs on console, is that their behaviour tends to be targetted towards the 'general case', rather than the specific platform. Take for example the cmath functions. I am not, under any circumstances, going to be calling the extremely inefficient std::sin() implementation. std::sin is great in one regard - it handles denormal numbers, correctly identifies NAN/INF, and has a well described method of reporting errors.
In the games engine world, we tend to spend a lot of time upfront baking assets so that these INFs/NANs cannot make their way into the games computations ever. So handling of that stuff at runtime is a waste of time, so we usually write our own maths approximations (We aren't landing a man on the moon, we're just throwing some polys at the screen, so we usually don't need the accuracy provided by the stdlibs).
So how would a typical cross platform game be organised? You'd probably see a directory structure somewhat akin to this:
game/
platform/ //< contains all OS specific code (timers, mutexs, etc)
vpu/ //< wrappers over the SIMD instructions on the platform
maths/ //< fast versions of cmath + Vectors/Quats/Matrices/etc
graphics/ //< wrappers over the core graphics APIs
sound/ //< wrappers over the platform specific audio stuff
This is pretty much the 'platform' against which all other code is written against (in other words, we basically end up writing our own version of the C++ stdlib for each new platform). Whilst there is quite a lot of work involved in the above, it's usually reasonably straight forward to rewrite the entire code library when a new hardware platform comes along (e.g. Playstation 6, XBox 99, etc). Certainly that's less work than re-writing an entire game.
In some cases there are bits of that work that won't change (e.g. iOS and Android all use ARM CPUs, so the maths routines optimised for ARM NEON will be shared by both, as will the OpenGLES graphics routines).
With any luck, 99.99% of the games code will not need to be modified. With any luck - in many cases we aren't that lucky :( [Although its easier now than it was ten years ago!]
All to often (especially on console), towards the start of a games development you'll target your lovely abstracted core libraries, and all will be good. As you near the end of the project, you'll probably end up with a load of #ifdef XBOX defines that exploit specific performance gains of that specific hardware (we need to meet that 60fps goal, and we don't really care how tbh). In extreme cases you may find that a given platform needs so many platform specific optimisations (in say, the renderer) that it has effectively diverged into an entirely new library for that platform only.
Anyhow. This situation is a little different on PC and android - simply because the variety of hardware is significant (unlike say an XBOX, where they are all identical!). In those cases we will be writing code against an already abstracted API (e.g. OpenGL, OpenAL, D3D, etc), and we will have to insert a lot more runtime error checking than you would on console (for example, on console we may know we have 256Mb of ram. On Android it could be 32Mb, it could be 2Gb, who knows! It doesn't matter, we need to handle failures gracefully).
When it comes to desktop APPs, for windowing APIs, the vast majority of sane people just use QT now (possibly with OpenGL if they need 3D rendering).
Related
I'm interested in getting started with Android development and would like to use a Lisp-style language. However, I want something that won't limit me if I choose to write a complex app, so it also needs to have reasonable performance, executable size and startup times. This limits my choices to languages that compile to JVM bytecode that have Android support.
Clojure (Neko)
This would be my first choice because of Clojure's expressiveness, but I have heard that it has problems with slow startup times and poor performance on Android. However, the threads that I came across are quite old so I'd be interested to know if things have improved since then.
Scheme (Kawa)
I came across this option here. Scheme is a nice language, so this option is appealing but it looks like the Android specific libraries it provides may be somewhat minimal. Of course, one could always call the Java libraries from Scheme.
I'd be interested to hear about any experiences with using the above languages (or other lisps for that matter) on Android. Thanks!
As the topic states - is there any technology that would let me write code for a simple commercial 2D game which could be then compiled to work well on Android, iOS and Web browsers or at least two of them (e.g. Android and iOS)? There is so much buzz about cross-platform nowadays that I was wondering if I'm missing something.
My goal (set by my producer) is to make this game for all of these three platforms, and so far I planned to use:
- Web browsers: Adobe Flex,
- Android phones: Java (since my favourite C++ is recommended only for short snippets),
- iPad/iPhone/iPod: Objective-C (are there any alternatives?).
It pretty much means re-writing the same source code three times. Is there any way to speed it up by using a technology that would work on at least both of them?
However, I don't want to use Adobe Flex for all three (though it's possible), because it requires Adobe AIR (works only with Android 2.2 and higher) and not a lot of phones have it (it's totally different with browsers where 98% of people have Flash).
I don't mind adding some platform-specific code for each version, of course.
Also, if you have any suggestions about choosing a fancier technology for any of the platforms (maybe some nice frameworks?), I'd really appreciate that, too.
Take a look at Corona and Moai both are Lua-based frameworks for game development targeting multiple platforms.
I would like to say that Multimedia Fusion was capable of doing this, but it isn't quite ready yet. There are currently a number of runtime exporters for the product which allow you to export your game to multiple target platforms which include flash, java and iOS at the moment. XNA and Android exporters are currently in the works. I should probably mention that I am only affiliated with these guys as a happy consumer of their products. It is probably worth checking it out even if they can't do everything you want yet. If it's not suitable for your needs it is still a very good choice if you wish to rapidly prototype your application.
See:
http://www.clickteam.com
On a side note, personally I would recommend against going down the js+html5 route, particularly if you are targeting mobiles. I should probably stress that it's simply an opinion I have and that there are plenty of people here who will disagree with me. In all javascript games I have played, I have felt the garbage collector. The issue is that without control over garbage collection it is free to run when it feels like, causing infrequent but very obvious pauses in the middle of your game. You can work around this but I don't see why it should be that difficult. I can definitely align with the ideals of being able to write the thing once and run it on all platforms, but I can't see it working just yet.
To offer some advice assuming you find no suitable tools for the job, your aim is to maximise reusability. This means all of your games resources and levels should be well defined as independent resources. For non-critical logic you can make use of embeddable scripting languages such as Lua, which will maximise your code reuse. C (or C++) code will also be reusable on a lot of platforms, and might be a good choice if you are familiar and confident with the language.
I'm personally using Phonegap and Zepto.js. But you may have more luck with jQuery mobile. Phonegap is nice because its website will compile the apps for you.
1) If you write your game in C++ you can use it for iPhone & Android (NDK) as well. Preferably, you write your game engine in C++, than you can use a OS specific layer for UI stuff..
2) Implement your game in HTML & Javascript. iPhone/Android users will have to use a webbrowser to play your game. For iPhone, you can even create a launcher, that looks like an app, but actually is a webview with HTML & Javascript
Unity3D should be able to do this for you, if you purchase some extra sprite addins to handle 2D (like Ex2D or SM2 or Toolkit 2D). Also right now until Apr 8, the iOS and Android license is free.
Game Maker Studio. It has a package that let's you deploy on all of the platforms you outlined.
http://www.yoyogames.com/gamemaker/studio
I've been working on a game engine runtime environment in C++ for my future games, and have started to consider android as a platform. I noticed that it was tightly bound to Java and uses Java VMs heavily.
But is it possible to sustain a full C++ runtime environment in Android NDK? I have nothing against Java and am prepared to use it if I have to, but performance is one of my prime concerns (I intend for my games to be resource-intensive), especially on phones.
And if a full C++ environment is possible, how exactly would I implement it in Eclipse Indigo CDT? Would I be able to create a compiled game executable for Android ahead of time for maximum performance? And would there be any additional plugins I'd need to install in Eclipse? Could I use MinGW for compiling my games, or would I need to use a different compiler? If I had to use Java in one way or another, would compilation of the C++ code even be required? These are all questions I'd like to answer to get a sturdy development environment going in the Eclipse IDE.
Please know that I'm still fairly new to Android development, and multiplatform programming in general. My goal is to create a game engine that'll take the most advantage of the new hardware out there, especially on phones!
Thanks for any advice you guys can give!
NativeActivity, added in Android 2.3 (API 9) might be what you're looking for in terms of writing Android games using only C++. http://developer.android.com/reference/android/app/NativeActivity.html
However since you say you're new to this you may want to start with one of the currently available Android game engines instead of writing your own right away. Mobile devices have a very different set of constraints than other platforms. A phone isn't very useful if the battery dies mid-afternoon, so starting a project with the stated goal of being "resource-intensive" is already getting off to a bad start. Few people will want to play your games for 20 minutes here and there if it means they won't be able to make a phone call in the evening.
If what you meant is that you are shooting for high-end graphics, keep in mind that devices have a wide range of capability in this area and targeting only the high end limits your audience. Different GPUs have very different strategies and performance characteristics and all have cases where they shine or lag behind. The most successful mobile games aren't the ones with the highest polycounts or the most complex lighting shaders, they're the games that achieve a consistently smooth framerate and have a distinctive style.
Have a look at some of the existing game engines for Android and try them out. Write a couple small games to take them for a test drive and see where they do and don't mesh with what you're trying to do. If you find yourself feeling limited with what's available, take what you've learned and try to write your own engine that fits with the types of games you want to make.
Here are some links to get you started. These engines power some very popular games on Android Market and many developers have found them useful:
http://www.andengine.org/ andengine is written in Java and is open source.
http://unity3d.com/ Unity is based on C# and Mono.
http://www.madewithmarmalade.com/ Marmalade, formerly Airplay SDK is based on C++.
The answer you want to pay close attention to is #adamp's. Ignore his answer at your own peril.
To address a couple of other points in your question, though:
Would I be able to create a compiled game executable for Android ahead of time for maximum performance?
No, insofar as Android does not use "compiled game executables". Your C/C++ code will be compiled into a Linux shared object (.so) file and packaged with other stuff (like your manifest) in an APK file. Compiling the .so will be ahead of time, though.
Could I use MinGW for compiling my games would I need to use a different compiler?
I get the distinct impression that you will claw your eyes out trying to do NDK development in Cygwin on Windows. I heartily encourage you to do your NDK development on OS X or Linux. At least set up a VirtualBox with Ubuntu or something in it to do your NDK compiles.
Regardless, the NDK comes with its own GCC compiler. AFAIK, MinGW is not a cross-compiler, and most Android devices are not running on x86 CPUs.
If I had to use Java in one way or another, would compilation of the C++ code even be required?
Yes. Now, for Honeycomb, you have the option of using Renderscript for OpenGL work -- that amounts to a C99 environment whose code you will not need to compile with the NDK.
I've tried a bunch of them, and one of the best I found that cross compiles instantly to a bunch of other devices and let's you program your goodies in HTML5/C++ combo (sweeeeet) is MoSync (http://www.mosync.com/) and another little known one that is a little more setup friendly is MotoDev by Motorola (http://developer.motorola.com/tools/motodevstudio/?utm_campaign=mhp01092012&utm_source=mhp&utm_medium=mws)
I've noticed there is some virtual machine images and tutorials you can use to prevent the setting up hassle.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Our company is on the verge of picking between native Android/iPhone development and some cross-platform solution, specifically Marmalade SDK (former Airplay SDK).
We are a computer vision company, meaning we need low level access to the camera devices. Also, our applications are computationally expensive, meaning we tend to squeeze out every little bit of processing power available.
Our team has sufficient experience in both Objective-C and Java (or C) to provide platform specific solutions. However our main focus was always on C++, as such we would like to prevent fragmenting out team and rather work with a cross-platform solution.
Our biggest fear is that choosing Marmalade will either sacrifice processing speed (main concern) or severely increase development time by complicating low level access to camera frame buffer.
So my question is, besides the obvious, what are the advantages, but specifically limitations of Marmalade SDK for processor intensive video processing applications.
I have used Marmalade/Airplay for almost two years now in my indie game company. For me it's a win because I'm just one programmer, and I can do virtually all my work in Windows using MS Dev Studio (which is my favorite dev environment by far) and because it shields me from having to deal with a lot of the platform-specific details, especially with the various development tools, that could eat up a lot of the time I'd rather spend on game content.
Speed will not be an issue with Marmalade. Your C++ code runs natively. Also, access to camera and other functionality should not be much of an issue; it's either already provided or can be added using the extensions SDK, which is pretty straightforward to use.
Marmalade is a mature product and the company is pretty helpful in resolving issues quickly, even for indie developers that are using the product for free. In addition to the cross-platform-ness, it has some nice tools built in, such as a memory leak tracker, a logging system, graphics analysis tools, and others.
There are some downsides that I've experienced with Marmalade.
Even though in theory any API or third-party SDK is accessible through the extensions system, in practice the thing you need may not exist yet. As an example, a number of developers are currently struggling to get the analytics package Flurry integrated, and it's been a challenge for some. The situation is similar with lots of other third-party SDKs; they may be just a couple lines to integrate if you are doing Objective-C development, but can be more difficult via Marmalade.
Some things are less natural because of the cross-platform layer through which you operate. Some examples for me have been:
I've had trouble getting my splash screens (application start-up screens) to display properly in all screen sizes on both iOS and Android. And it's been hard to get them to show without some flickering, short black-out periods, or resizing of images as it transitions between the device load of the Marmalade app itself, and then Marmalade's step of loading your app code.
Marmalade imposes a very simple memory model, where you get a fixed heap up front, and all memory allocation is done through Marmalade. From the system's point of view the app just has and keeps a big block (or a few big blocks) of memory. This has some advantages, but I've had problems squaring this model with the iOS model of, for instance, receiving memory warnings and being expected to jettison any unnecessary resources. It appears to be a case where "one size fits all" ends up actually losing some key functionality.
You can use the extension manager and some other methods to show native UI elements, but integrating a significant amount of native-look-and-feel UI can be a challenge. So if your app is game-like and users can deal with non-standard buttons and so on, that's fine, but if you anticipate needing significant native UI, it is harder. [edit: Recent versions of Marmalade have added a native UI framework that lets you specify standard UI elements in a generic way and then implements then using the appropriate widgets for the device. I have not used this, but it looks fairly comprehensive.]
If you run into problems, it's often not clear whether it's a generic OS problem or a Marmalade problem, and it can be lonely trying to find help. For instance, I recently added in-app purchase to my game, on both iOS and Android. IAP is challenging, and even without an additional SDK layer there are lots of special cases to deal with. In my case, I had a situation where my app had been rejected by Apple for a small issue, and while it was in the rejected state my in-app purchase was also in a "rejected" state (even though there was nothing broken about the IAP itself; this is just a quirk of Apple's process). When I was trying to regression test the in-app purchase functionality (while I was submitting the fix for this non-in-app-purchase-related issue), the game was actually crashing, instead of getting an appropriate error result. I was able to determine that the crash wasn't in my game code, so it was either the OS (unlikely) or the Marmalade middle layer for handling the in-app purchase callbacks (which is what it turned out to be [update 11/28/2012: Marmalade has reportedly fixed this problem in a recent SDK update]).
So in a situation like that you can try going on Stack Overflow to get help, but really nobody is there to help you, so you are dependent on the Marmalade team to get back to you with an answer. As I say, they do a pretty good job of this, but there's no way it can compete with nearly instantaneous responses on Stack Overflow from the world-wide community of regular iOS programmers. So I'd say this last one is my biggest concern with using a system like Marmalade. It saves you time up front not having to come up to speed on the details of the various platform SDKs, but when you run into problems you are "at the mercy" of the Marmalade team (or friendly Marmalade community members) to get back to you with an answer. (Keep in mind here that I'm writing as a freebie indie developer who just gets standard priority for issue resolution. You can pay to get guaranteed quick resolution.) For me personally, it's been hard having to keep coming back to my producer and saying "I'm waiting for an answer from the Marmalade guys on this one."
(Another example of issue 3 is that until recently there was a problem with sound effects being delayed on certain Android devices. It was a Marmalade issue, and they did eventually resolve it, but it took a while, and there's basically nothing you can do in the meantime.)
Keep in mind that (as other responders have pointed out) even without Marmalade you can still have the bulk of your code base in C++ on either iOS or Android.
In spite of the long list of potential issues above, I am a fan of Marmalade, and I appreciate all the company has provided for me for free. The tool really shines when it comes to other platforms that you'd otherwise never bother with, such as (for me) bada or PlayBook. You really can deploy to a wide array of devices from the comfort of your PC and Developer Studio (or from a Mac with xcode, if you want to make your life a little harder ;). The simulator tool they have is great, and there have been only a small number of instances where I've had to debug on the device itself; in general if it works on the simulator it just works. IdeaWorks has taken on a huge challenge and they are doing a great job juggling all these features (i.e., basically every features ever offered on a mobile device) on all these platforms (i.e., all significant devices in existence, with the exception of Windows Phone 7 because it does not currently allow native code). It just comes with some caveats.
I am biased, being the CTO at Marmalade... but if your key requirements are (1) camera access and (2) the ability to "squeeze out every little bit of processing power available" then Marmalade is a great choice.
Marmalade compiles your C/C++ to native ARM (or x86) instructions... no transcoding, no virtual machines. It's very easy to bring across existing C/C++ code, nearly all the C/C++ standard libraries are supported, etc. And you can use ASM code within your project. Also, you can do all your development either on Windows or Mac, regardless of what platforms you deploy to (yes, you can even compile/test/deploy to iOS purely on Windws).
As far as I can tell you from ANDROID Development:
The Camera API from Android itself seems to be a little buggy (in example: before 2.1 there is no solution to get Camera shown in portrait-mode without scrambling the Images).
Another abstraction layer on top of that might be better (in terms of accessibility, features, whatever), or even more worse. What it does for shure: It steals resources, which may be needed for your own App.
Marmalade offers an excellent Native Extension framework
http://www.madewithmarmalade.com/marmalade/features/extensions-development-kit
WHich ultimately means that you can jump directly to a native implementation of any particular feature. You still keep the core benefits of cross platform development for your main app.
Also on android because marmalade makes use of the android NDK your c++ code for processing data will be running faster than the corresponding android Java code.
Im making games with Marmalade and the extensions and native code speed make me extremely confident of being able to deliver at least as well as a 'native' app.
I would use MoSync Android/iOS, but I would say that, since I work at MoSync.
But in all fairness I prefer the MoSync Camera API.
If you really want to squeeze out all the processing power out you should use ASM.
/Tony
Marmalade's not bad, I used it in 2013. Some bugs, some annoyances (fixed memory pools), but overall not a bad experience.
The only real disappointment is the lack of support for Linux. I cannot see how the Marmalade guys can support obscure platforms like Blackberry, but not Linux; it makes no sense. Maybe this will change as Steam OS (a Linux-based, gaming-centric platform) matures, though admittedly Steam OS doesn't bring a whole lot to the table outside of what other OSs bring, for now.
In the recent weeks I have been busy with the issue of cross-platform development. That starts with the problem that I had the feeding to write a wrapper for the communication-API of MoSync (I don´t knew this SDK and others for cpd before). It should be used in our Java environment for instance to easy create a bluetooth-connection to different phones and so on.
For me the other question is now, how I can use such SDKs like MoSync, Titanium and others in a existing project? In my opinion it is not possible. Either you develop nativ or with a cpd-framework.
I would also be interested in when do you recommend this frameworks (I know already that there are some other threads about this). I personally would say that there isn´t a great future for this SDKs because of technical drawbacks and dependencies. In addition, the market for cross-platform solutions (hybrid, interpreted, cross-compiler) is at least as fragmented as the market for mobile operating systems themselves
What are your experiences?
Martin
Cross-platform implementations of any type, on mobile or anywhere, are primarily to reduce the time to market. That statement may look like oversimplified, but it more or less holds true. So, the ideal situation to use it would be to have an application/game that maybe, uses the common denominator of features across the smartphones, which could include touch, a decent UI, the network, maybe the accelerometer in some cases LBS. So, you land on multiple phones in quicker time and reduced development cost.
If you are looking to utilize a lot of hardware specific features, then we land into what's commonly known as the unknown territories. Then you have to do what people always do, gather more information about the landscape of phones to target and see if the "chosen framework" has the power to dish out the features on those platforms. In this case, you cant possibly deploy one off-the-shelf.