We are going to build a multiplayer game.
The idea is that every player has a tablet and is connected to a server.
The server should control the game logic, while the clients (the tablets) will only serve as a frontend to the game.
We need to make a decision about the frameworks/programming language we are going to use.
A crossplatform frontend would be cool, but is not mandatory. It has to run on Android devices at least.
The communication between the server and the client must be bidirectional and realtime.
We don't care about a small amount of delay.
Currently we consider an HTML5 client in combination with a javascript server (running upon nodejs) to be the best option.
The communication would be managed by the javascript library socket.io.
The HTML5 frontend can be run either in-browser or as an app (built with PhoneGap).
However we did not decide yet since we want to be sure to make the right choice.
There might be frameworks that can do a better job.
Does anyone know a better solution?
Play 2 is great for this well, but node/socket are great choices too. I would use backbone.js for the front end as it gives you a lot of flexibility and it's easy to keep the views in sync. (there is an example of such an app on my github if you're interested)
Related
Background
I'm a noob programmer looking to create a simple turn based mobile game as a side project. I've pretty much got the game logic down and am left with implementing the online multiplayer/PVP portion.
More specifically, i'm looking to implementing a system when the player clicks play and will be matched with an opponent in a 1 v 1 format, without any lobbies etc etc.
I'm currently trying to develop my game in android studio(i'm new) but am also open to unity if it makes the development easier.(I have no experience in Unity).
What i want to know
From what i understand,i need to create and host my own server for the multiplayer to run(i.e matching of player to opponent). Do i also need the server to run the game itself or am i able to connect the player to the opponent and simply record the result of the game to my server/database?
Also, how would i go about creating and running/hosting the server? I heard nodeJS is a good choice for writing the server.
Can anyone point me to a good resource/tutorial for creating and running my own server, and if possible free(or cheap) hosting for my server?
Also, is unity a better choice than android studio for my game?
End Goal
I just wanna publish my game onto the app store,IOS store,etc etc.
If you don't have any experience with creating multiplayer games, I'd recommend looking into one of the several ready-made solutions available on the market (Unity Multiplayer is one such service). You could essentially make your entire online game without ever needing to code a server.
Coding game servers is more work than you think. You'd first need to make a working game server, then you'd need to consider hosting, data storage, scaling, ping, etc. The downside is that you'll get less customizability and less security (you'll need to handle much of the game client-side, which means you're susceptible to hacking by modification of the client, known in the android world as "mods"). However, if you're just starting out, a game server of your own will probably do more harm than good.
You should always choose a multiplatform engine for mobile games. You do not want to code your entire game twice. So yes, Unity is a good choice, and it's the de-facto standard for mobile these days. If you're going to be making games, learning Unity is a worthwhile investment.
Last, and this one comes from my personal experience only with no real statistical data to support it, people who implement game servers with node often end up discovering that their server just can't handle the load, which leads to a need for stacking a whole lot of technologies up on one another to scale the server(s) out or squeeze more performance in some way. It'll often prove to be bad choice in the long run. Or then again, maybe the people I know just aren't good with node.
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 am developing a system including an iOS and Android app. I have two approach:
1 - I thought about use MySQL as the backend.
And then use REST in java using jersey to transfer my resources to the apps.
2 - Currently I heard about Parse which is consider as a easy way to add a backend to the mobile applications. It lets the mobile developers write server code without servers.
Which one is your suggestion? please support your answer with proper reasons and your personal experience.
If you want to be trendy, use node.js and MongoDB. (Although MongoDB is not trendy anymore, but it allows binary files of arbitrary length and works beautifully.) PHP with MongoDB works fine too.
My reasons: they are widespread technologies and with a very low barrier of entry. Avoid Java unless you want to nurse your JVM.
Assuming your typical backend for a mobile app which involves one or more REST apis and provides server-side functionality such as user authentication, communication (e.g. chat, messaging), or persistence (e.g. a leaderboard for a game, or retrieving geo-location related data). You basically have the two options you mentioned, build yourself or use a backend-as-a-service platform.
Build yourself (pros):
You retain all of the IP
You have the best level of customization
Build yourself (cons):
Very high learning curve if you lack server-side coding experience
Longer to implement, and harder to iterate quickly if you need to change something or add a feature
Higher risk of critical issues if you lack experience (e.g. security vulnerabilities, reliability etc)
You need to monitor and maintain the system once it's deployed. This can become a full time job if the app gets big enough
Backend-as-a-service platform (pros):
Much faster to get something up and running. This is a big one if you're launching something new and want to validate the market
Benefit from the years of experience of server-side developers who built the platform
Often, platforms will provide ready-made components that already do what you need
Running and operating the backend is included as part of the service, you don't need to worry about it.
It's actually cheaper than implementing it yourself if you consider the time investment, or if you hire a backend developer to build it for you
It allows you to focus your energy and time on the client side app, which is where you'll most likely differentiate yourself anyway
Backend-as-a-service platform (cons):
You have less flexibility, depending on the platform (some are better than others)
There's usually a recurring cost (although you'll also incur some of this if you build it yourself, to run the servers and databases)
There's always a risk that the provider will shut down (like Parse) and you're left scrambling to find an alternative or rebuild it yourself
There are now many backend-as-a-service platforms available to chose from. Unfortunately, Parse is no longer one of them, having been acquired by Facebook and subsequently shut down https://www.computerworld.com/article/3027537/application-development/facebook-is-closing-down-its-parse-developer-platform.html
I feel that a backend-as-a-service platform is a good option if you don't have much experience on the server side, or if you have limited time and want to focus your attention on the client side app. One of the greatest benefits is fast iteration. You can try something out and change it quickly with relatively little investment if you realize that your feature didn't hit the mark. Some examples of backend service providers can be found here https://en.wikipedia.org/wiki/Mobile_backend_as_a_service.
Some of the platforms actually allow you to build a full custom app without actually writing any code, and some of them provide ready-made components (like chat, leaderboards etc) but are less flexible.
Here's a list of Backend-as-a-service providers:
http://pipegears.com (No coding required)
https://www.appcelerator.com/
https://cloudboost.io/
http://api.shephertz.com/
https://backendless.com/
https://quickblox.com/
I participated in the development of an iOS/Android app. We used a server coded in java working as a web service running on Tomcat 7, with a mongoDB database, and JSON parsing for communication. Certainly not the best solution ever, but it was working.
I'm working on an Android game based on Playing Cards (Bridge, to be precise), which can be played by four players at time. And there'll be a server available via Web, to which devices will connect, and server will keep track of game progress.
My game is very basic when it comes to graphics that I can attain the UI without using any gaming engine.
While I'm supposed to build the game (the client) for Android, I wanted to develop server which can be RE-USED in future ports of the game, even if it is ported to other mobile platforms or even desktop.
So I thought of first possible candidate for server architecture was having RESTful Web Service so that I can leverage the server with any client as long as the client's programming end supports HTTP methods.
But later I realized that since there'll be persistent connection between devices and the server throughout the game session, would it be okay to have such a server, where connection will terminate after the request is responded (I'm not sure if it is true)?
Or shall I use DatagramSocket and DatagramPacket way of Java to build the server? (will that ensure re-usability of server?)
Any other suggestions or recommendations?
Note: I'm not new to Java or Network Programming in Java, but I'm new to both Android Development and creating RESTful services.
While writing for Android, don't plan for a persistent connection. Connections break very often (and often for good reasons, like switching from GSM to wifi). HTTP is a great, popular and proven choice (you get some lower levels of the stack out of your way and can focus on processing the payload).
BTW: saying "RESTful web service" int this context is meaningless - what you need is a HTTP server that serves data and accepts commands, not a mental framework for structuring your game logic as a set of stateful resources.
I think your HTTP-based plan is appropriate for this situation, I don't think the question of persistence of connection is relevant for a slow turned based game such as bridge.
Edit: as suggested by tdreger almost all Android docs recommend that you plan for routine connection failure and reestablishment through a different channel, as such the html connection seems the most resilient solution.
I think your idea of making it client-side independent is correct and important - in this light the HTTP idea is clearly much better in that it will be much easier to code client-side applications in other languages (which you will probably want - Javascript for a web-client and objective-C for an iOS app).
I also think the Android development will be easier as Android and appache have strong support for these HTTP-like connections.
I have just started researching creating mobile apps and from what I understand one big advantage of using HTML5/Javascript is that you can write one application that works with both Android and iOS.
I have also read that one of the drawbacks is that there are certain things that you can't do with HTML5/Javascript that you can with a native mobile app.
Is what I stated above correct? What will I not be able to do if I decide to go the HTML5/Javascript route?
While both native and web have their own positives and negatives, the one main advantage that native apps had over web apps was "Offline Access"
However that is now changing as HTML5 has support fo Offline Web Applications.
Some things for iOS:
Background audio/sound effects
Address book
Leverage CoreGraphics & OpenGL for advanced drawing
Camera access
Accelerometer
Limited Calendar Access
It all depends on what you are going to do. If your app needs GPS, the accelerometer, or is very graphics intensive, then a native app is the only way to go.
Otherwise, I would go with something like Sencha Touch for your app for a couple reasons. First off, if you release an update with a HTML5 app, you don't need to force everyone to download it, it will update automatically. Also, as you mentioned, you only need to write one application for all mobile platforms, which expands the potential user base. Lastly, I think the internet on phones is getting fast enough to support internet applications very well, and this is only going to improve in the days to come.
Basically, it all depends on the specific needs of the application. Personally, I would go with HTML5 whenever possible, due to the mobility it gives you with platforms.
I think we can separate this into two lists...
What can be done on a mobile device that is not possible in HTML5:
Push Notifications
Advanced Graphics (3d, OpenGL)
File Uploads (possible on Android but not iOS)
Connect to Address Book
Connect to Calendar
What can be done in HTML5 but is easier or implemented better on mobile devices:
Camera Access
Offline Use
Device Location Services
Sound
Accelerometer
Speed / Slickness of UI (hard to quantify, but apps typically still feel nicer when native)
(Please note the date this was answered on, this landscape could be quite different in 6-12 months or more.)
In theory not much, if you use titanium. http://www.appcelerator.com/products/titanium-mobile-application-development/
Unlimited Extensibility
Titanium’s plug-in architecture allows you code modules in Objective-C or Java to
extend your mobile app with custom native functionality and then call those
modules using Javascript in Titanium.
Though i have never used Titanium and dont know how well this works. I would stick with native development anyhow ... for now.