I'm interested in creating a server for an undetermined multiplayer game, either PC or mobile based. Any game server would obviously be event driven, asynchronous, and fast. I'm very experienced in web development, where it's common to use a framework such as Symfony for PHP or Django for Python.
Is there anything comparable to web frameworks for high performance game server development? ROS (Robot operating system) is an example of a complex C/C++ framework which is optimized for real time performance and includes common robot functionality. Is there something comparable designed for games?
Right now I'm most interested in creating a browser based WebGL game or an iPhone game. As such, I'm thinking of using Django as my request handler, and just doing communication over AJAX. I know that'd work nicely for a PC web game, but I'm not sure what the best ways of doing remote communication with an iPhone/other mobile device. Is it common to use a web framework to arbitrate mobile apps?
This is an open ended question, so any advice, thoughts, or links to further readings are much appreciated. If anyone has any good reading material I'd love to take a look.
Is it common to use a web framework to arbitrate mobile apps?
yes it is take a look at webview (in android)
Is there anything comparable to web frameworks for high performance game server development? ROS (Robot operating system) is an example of a complex C/C++ framework which is optimized for real time performance and includes common robot functionality. Is there something comparable designed for games?
you dont need a realtime system for this just a very good server (depends on the amount of clients) in any case I would recommend java. It is almost as fast (if not faster) as c++ applicators (thanks to jit) and you can connect it to android easily (they are compatible) or use it as a classical web framework
Since you have background in web development, you might be interested in the experimental Node.js/HTML5 game by mozilla http://browserquest.mozilla.org/
The source code is available here https://github.com/mozilla/browserquest
It's using websockets for client/server communications.
It is defiantly possible to use a web framework. A lot of this is dependent on the type of game. The requirements are a lot different between words with friends, and Eliminator Pro. But in general, for a lot of game designs a web framework/service model works great.
You could also look in to existing projects, such as cocoas live.
Related
I am involved in developing application for mobile sensors, data from these sensors is to be collected using Android/iOS mobile apps. We want the end users to be able to view this data from desktops also. This data is uploaded to be uploaded to our own database(s) from the mobile apps. I have done this development of the prototypes using native applications (iOS/Android) and implemented web services using Django 1.6 with SQL database. This was just for prototype.
We are at stage where we really need to make this into real product with paying customers, so we are in position to revisit our technology stack question. So I am looking for suggestions.
Currently I am thinking of using Play Framework on the server side. I really haven't seen anything compelling that can provide Native app like feel so we will have to keep developing mobile apps using native libraries. We will interface with our web services using REST API. My concern with Play framework is it doesn't seem to have lot of plugins similar to django, but its early days hoping that situation will improve.
Is this right approach we are very small team ( 4 people, we can hire 2 more probably). Given this is this right technology path I am choosing anything I should be looking at?
I have looked at Parse library but doesn't seem to offer too much data flexibility, geared towards more social media aspects.
We will be using StromPath for user management, any other choices I should be looking at for user management?
We really don't want to do a lot of MVC programming on client side, so on desktop app we will keep it simple jQuery/Javascript & html
-Sam
With jQuery mobile you can assure the look and feel like in a native app. The library it self does media queries and stretch or shrink the content accordingly. So in terms of UI you will not face any problem providing native app like look and feel to the users. For client/server communication I recommend normal ajax functionality so you can dynamically add content.
When working with JQM there are certain rules that you will have to obey.
I've read about the native feature-support of Phonegap here. Clearly, it makes no mention of Bluetooth support. I've failed in finding or locating any other platform with cross-mobile platform development support. As a result, I'm currently faced with two choices.
Build independently for all the platforms (very painful option)
Find a suitable cross-platform development solution (which I've not found yet).
My question is; for mobile developers out there, which option would you suggest I take, one not listed here? If possible also help with details of pros and cons.
Thank you very much.
Build independently for all the platforms (very painful option)
In my experience, this is by far the least painful option, and not just for Bluetooth. The overhead of dealing with leaky cross-platform abstractions tends to outweigh the benefits by the time you get to a real, production product. Build an excellent iPhone app. Build an excellent Android app. You can share a lot of the UI design (though not all of it). You can share much of the data structure design. You can share some of the internal architecture. You can share any network protocols (particularly if you design them in JSON). But avoid code sharing and avoid shooting for the least-common-denominator. It's pretty far down....
For some kinds of projects it makes sense to share some C++ code between platforms. Trying to develop this stuff in JavaScript is a recipe for frustration the moment you go beyond the most basic of applications. It's easy to hack up something in mobile JavaScript that kind of works. It's very hard to get it to look and work great on all platforms; much harder than just writing them natively in the first place.
Some more discussions on this:
Mobile development - Native VS Cross Platform VS JavaScript
How to code sharing between Android and iOS (Where I discuss how to share large, established C++ code bases. But this isn't applicable for new development.)
You list iOS as one of your desired platform. On iOS, any generic Bluetooth communication (other than Bluetooth LE or communication via Gamekit, headset or keyboard) is available only to Apple MFi program licensees. To get any details about this license, you need to apply to Apple's MFi program first. AFAIK, no 3rd party or cross platform tool chain can help you with this for iOS.
I don't believe the OP is talking about iOS app to device communication but rather peer-to-peer bluetooth communication. Would the requirement for Apple MFi program licensing apply?
If so, are the peer-to-peer Bluetooth APIs (and hardware) on say, Android or Windows Phone 8 be compatible with the one from iOS? And if they were, shouldn't passing data around by JSON be fairly straight-forward for building cross-mobile apps?
IMHO, for simple business apps, building native apps for each platform is the way to go if you want to make full use of available resources on each platform and conform to their differing UI design principles.
I have a question about mobile application development. I'm wanting to develop an application for my Kindle and looking through the tutorials I found that HTML5 CSS and JavaScript could be used to develop Mobile Applications instead of native Programming language like Java, Objective C and so on.
Don't get me wrong I have nothing against learning a little more Java and the Kindle/Android specific APIs. But knowing that you could use HTML5 CSS JavaScript for the Android, Blackberry and iOS platforms AND WEBSITES sound very interesting to me. I've have also seen Game frameworks like Play'n from Google that seems to do a pretty good job with HTML5 and JavaScript.
My question is, is it worth the learning curve of each individual API, and programming languages or are HTML5 CSS JavaScript just going to change the way we do front end development?
Any input on this will be very appreciated.
In general it is worth learning the native SDK for the platform you're targeting because you'll have maximum flexibility, best performance, broadest API coverage keeping up with the latest advances from the platform vendor (e.g. iCloud, Siri APIs etc), and you'll find plenty of open source software that's built by and for the platform's native developers (see http://cocoacontrols.com as one example). So it's definitely worth investing in a platform's native SDK, especially if the platform itself is proven to be successful, such as iOS and Android.
However, sometimes it can be more practical to build an app using Javascript/HTML5 frameworks like Titanium Appcelerator. This can be useful in controlled environments like enterprise apps where your customer base is limited, or just to rapidly prototype a concept.
I would consider a Javascript framework a disadvantage if my app or game had to compete in the open market / App Store against thousands of other native apps. If my competitors are using native code and can rapidly evolve their UX or features, I don't want to be "stuck" with a limited Javascript framework.
On the other hand, if I worked for say, a large supermarket and my job was to create an app that only their staff would use for a few hours a day to do inventory, a Javascript framework would help me prototype faster without any threat of competition or unexpected requirements.
Hope this helps.
This topic can be debated forever but this is my take on it:
If you need performance on a device (such as for a complex game), then it's better to go native because you can fine tune to the specific device or set of devices and platforms you are targeting.
If you can build your idea and have it scale and function well using Web Technologies then it would be wise to continue using Web Technologies because it's extremely easy to scale to multiple platforms with relatively little effort.
If you want to leverage cutting edge API's for a specific platform then it's better to go native
Personally I think that if your app is going to be complex (doing beyond the standard enterprise data API stuff), then it'll be easier to go native in the long run. I've leveraged both methods and whilst Web Technologies were incredibly easy to implement and prototype, implementing anything complex increased the amount of effort needed by a large amount to the point that it negated any time saved by not going native. Eventually I just decided to concentrate on native apps but your milage may vary as Web Technologies are increasingly improving.
I'm currently in an early stage of my internship at a company which offer VoIP solutions. I'm basically here to create a custom SIP-client App for iPhone. I told them however, if I were to set up the MVC pattern correctly and more efficient in terms of portability, there would be minimal code to write when porting to different platforms.
I've chose to go with MonoTouch C#.NET, for high portability and productivity (learning Objective-C is too steep for my timeframe + memory management too time consuming). To create even more portability I've been thinking of exposing a C# SIP library as webservice, so when porting to Android there's even less hooking up to different APIs. Also, MonoTouch for compile reasons does not allow usage of Dynamic Libraries.
My app would communicate to the SIP webservice and the webservice in turn to the SIP server.
SIP is very familier to HTTP, but could this solution work? As I'll be facing Realtime Transport Protocol aswell.
Kind regards
As far as I know, it won't work because, as you mentionned, you will face RTP. You'll probably get a lot of lag in your conversations. Also, you'll have to figure out how you are going to stream the data between the clients and the server.
However, to really know if this can be done would be to do a few prototypes to test these kind of issues.
I'm considering developing apps for Android and Windows Phone 7 that allow the user to read content from an online producer (newspaper/magazine/blogs etc). This provider has a REST API that should allow for straightforward access to the content. A few questions I have:
I saw an OData demo, where getting data from a feed was super easy, with no parsing of any sort required. Is it worth building an OData provider on top of the publication's existing API, just to make it easier for the mobile apps to get data?
I have heard that C++ can be used on wp7 and Android. Is there any reason to develop an app core in C++, then interact with the device APIs in C#/Java? Or is the core logic layer of the app so thin that it's not worth the hassle? It seems like there's really not that much to developing a publication reader app - basically just a GUI on top of an API that provides all the data.
Or, would it make more sense to just develop a mobile version of this publication's web site? Then there could be one service for all mobile platforms. What are the pros and cons of an app that runs on the device as opposed to a website specially built for mobile devices? (Like the Gmail, Google Docs, and GTalk "apps" for the iPhone.)
Thanks.
C++ is not a development language for Windows Phone 7. There are two development platforms for WP7: Silverlight and XNA. There is no possibility of interop with a C++ module.
As far as I know, C++ cannot currently be used to develop WP7 applications. I would check on that before you try to go too far down a cross-compatibility road.
That said, the UI between WP7 and the iPhone is really, really different - the backend code is so small in comparison to well-written UI later, I'd just write two separate apps. It may seem like a time savings but either your app is going to look like it does not belong to one platform or the other, or you'll be spending more time trying to keep the compatible stuff working OK on two platforms.