I am not able to decide whether to use PUN or Bolt in my Unity based multiplayer game. The game must have LAN and over the internet playing options.
According to documentation on photon website, PUN is meant for multiplayer games over the internet. Master Server is hosted either in the photon cloud or dedicated servers running Photon Server.
Bolt, on the other hand, is meant for LAN games. One of the clients becomes the server.
My game needs both, LAN and Internet. Should I use both the SDKs? Can't there be common code for both options?
EDIT:
UNET is now depricated!
You can also go with the new network from Unity (UNet) It has both lan and Internet (if you portforward, but I think that there should be an option for that non the less. Quote me on this).
You however can take a look in the UNet manual to see if you like it.:
https://docs.unity3d.com/Manual/UNet.html
I am currently working on a 3v1 game with this. And it takes some time to understand, but you don't have to worry about payments or other things.
(I don't have 50 reputation so I can only give an answer)
Photon Support replied,
1] Should I use both the SDKs?
Combining PUN + Bolt does not make sense. Bolt works fine for LAN and online gameplay. Bolt is not based on UNET, it is written from the ground up. Photon Cloud and Dedicated servers can be used with Bolt as well. https://doc.photonengine.com/en-us/bolt/current/advanced-tutorials/headless-server
2] Should i write separate code for online and LAN feature?
No, this is not necessary - you "just" need to deal with the higher latency in online gameplay.
I would recomment you Photon. It's pretty easy to use and it's really cheap. Photon server are way MUCH cheaper than the UNET servers.
Both UNET and Photon have a great documentation, lots of tutorials and a big community, so you should't have a problem with that if you pick one or another :)
Bolt work with "internet" game as well if you prefer to differentiate games by internet and LAN.
However choose which one is highly depend on your game itself.
If the game required central secure server to handle logic process, you should go with Photon or similar approach.
If the game is p2p, fast faced and doesn't care much (not meaning doesn't care at all) to secure (avoid cheating, speed, wall hack for example) then you should go with Bolt.
Photon made a comparison here:
https://doc.photonengine.com/en-us/pun/current/reference/pun-vs-bolt
The major difference to me is the Host Migration, Bolt and UNet are not support Host Migration yet (UNet support LAN but not Internet)...
If your game is really fast pace (~30s per game) and don't care about Host Migration (Master client disconnected), then PUN or own dedicated server (which I wouldn't consider) are the only choices.
I have heard that if you want to do something well done do it yourself. This does not mean that PUN or Bolt or UNet do not work, on the contrary they serve perfectly for the scenarios that were created, but for your particular scenario they may not fit well. If you want LAN, Internet, Central Server or a client as a server, in addition to algorithms that avoid latency, such as interpolation and prediction you must do it from scratch, creating your own framework, for this use the Unity Networking API.
Related
Why do Unity game developers implement server by themselves instead of using unity built-in NetworkManager?
It seems like multi online games can easily be developed by using NetworkManager,
but why do developers implement server by themselves using node.js, ... etc??
Its my understanding that it is not possible for two separate unity projects to talk to each other using the Unity HLAPI (High Level API, which is what NetworkManager is utilizing).
That means that you would have to have all the server code, and all the client code, in the same project.
This doesnt have to be a problem really, but for larger scale projects, separating the server from client can be easier to work with, and you dont push out all the server code to the clients to possibly reverse engineer.
Lets say you have a round-based, non-realtime game like scrabble, in this case it would make sense to use node or any http protocol, where you have a centralized server with a database for persisting game states.
But i honestly have no clue why anyone would prefer pure sockets when you have the Unity TLAPI (Transport Layer API)
https://docs.unity3d.com/Manual/UNetUsingTransport.html
I hope this was somewhat helpful and not just a rant.
I have to make the online game as my project at the university.
The game must have
The server and the client of any turn-based game. Implementing the basic principles and rules of the game.
The server keeps a list of connected clients, runs the game, deals
processing and transfer of information. The application server with text-based interface
user concurrent operation. Client GUI
I would like to use Unity3D engine, but do not know if this is feasible.
How to make a console server for unity?
Feasible? yes
Easy, well, it depends of your aproach, but it is completly possible, there exist some people than do it with Node.js
But, if your thing is turn based, then maybie you can do an invention with a webserver (like uniserver for example, or Xamp, or some other Apache / mysql implementation) and, inside unity, use the WWWForm class.
https://docs.unity3d.com/ScriptReference/WWWForm.html
Is a little cheaty, but it's maybie the easiest way for testing purposes (in no way you must use it for production of a serious game if you have any decent, fast (for production) and secure aproach to the subject, which this is not.
Cheers
I'm actually trying to find the best way to write a simple XMPP server or find one that leaves a really small foot print. I only care about the core features of XMPP (statusing, messaging, group messaging) . Also learning about XMPP protocol at the moment, so please bear with me if i'm saying something that is naive.
So currently, open fire is being used in our application. It's really heavy and has a lot of features that aren't necessary for our needs.
I've looked at tigase which is another XMPP server that leaves a smaller footprint.
I also looked at apachi mia framework which contains or has an extension module (vysper - XMPP server). I've tried to google reviews on this when compared to other servers, but can't find that much information.
In general, I"m looking for the best way to implement a simple XMPP server either from scratch or from an already built library/framework in java which leaves a smaller foot print then open fire. Interested in getting more pro/cons with vysper in comparison to openfire and tigase as well.
Any advice appreciated,
Thanks,
D
I can talk for Tigase only as I am Tigase team member.
For basic XMPP features Tigase binaries take no more than 1.5MB and if necessary it could be reduced to something below 1MB.
We run periodic tests with small memory and all the basic features work fine even if you run Tigase with 10MB of RAM, of course for no more then a few dozen online users.
I think this is quite small foot print. We put a lot of effort on optimizing and testing. It is also designed to easily integrate with other systems so this is the way to go :-)
Of course I am biased towards Tigase which is understandable. Please wait for some more independent opinion.
I'm working on a turn based board game for iPhone and eventually Android. I'm using Appcelerator Titanium to develop it. My multiplayer design is similar to Words With Friends. Users take turns when ready, and then the opponent's game board is updated accordingly.
One of my needs is to have a messaging API which enables the 2 players' devices to update one another on the status of the game board after a move. Thinking of doing this with JSON and keeping a JSON object on the device which contains the location of all game board pieces at any given time. This is the object that will need to update on the local device and then send a change to the opponent's device after a move is made.
I've done APIs in the past for mobile platforms and to do so I've used PHP with MySQL and sent JSON back and forth between the API server and the mobile device. Works just dandy for low concurrent users, and generally non-massive apps. Here's to hoping this one will get massive ;)
So now, instead of a general httpd server and the like, I'm starting to think about persistent sockets and if they're needed or not for my new game. I'm also thinking that it might be smart to forgo the big LAMP stack, and for scalability and maybe ease of development, to lean more towards a data flow of something like Mongo/Couch -> node.js -> iPhone. I'll be honest, it would be my first foray into a non-sql db and node.js as well.
Interested to hear others' takes and experiences on this, more options/thoughts, and whether I am thinking about it the right way, or just creating headaches for myself.
First of all, Nodejs is awesome for writing reverse TCP proxies to NoSQL databases. You could let all the standard commands pass through but alter/extend their APIs with your own magic, e.g. making MongoDB speak HTTP or CouchDB speak a binary protocol over sockets.
When it comes to choosing a NoSQL solution for storing board game pieces and monitoring for player moves I think either Redis and CouchDB are the best candidates.
CouchDB. It's fast, reliable, and can handle a lot of concurrent HTTP connections. It's probably the best option because unlike Redis it can broadcast a message when a document changes. The continous changes API makes it super simple for you to have each player's app monitor for changes to their board. The request might look like:
curl "$HOST/dbname/_changes?filter=app/gameboard&feed=continuous&gameid=38934&heartbeat=1000Each client will receive a JSON object per line in the response anytime a pertinent document is changed. (And a blank newline every 1000ms as a sort of keepalive.)
Redis. It uses a simple line-based protocol (like MemcacheD++) to talk over a socket and allows you to store Lists, Sets, Hashes with arbitrary--even binary--values. It's very fast because everything happens in memory but is persisted to disk asynchronously. But most of all you should evaluate it because it already has PubSub notifications baked in. Note that you'll have to explicitly publish move notifications over a channel the players share because Redis won't automatically publish when a key/value changes.
Since MongoDB does not have a mechanism for observing changes as-they-happen or doing pubsub I don't consider it a good option, though with extra effort you could make it work.
So to conclude, you may be able to replace "the big LAMP stack" with CouchDB alone, Redis alone, or either one placed behind a node app for filtering/extending the APIs they already provide into something that fits your game.
Best of luck!
I've just started learning mongo, and it isn't hard to learn. Things like indexes and explain are there and work the same. When it comes to architecture, you want to think the opposite of SQL; instead of needing a good reason to de-normalize, you need to come up with a good reason to normalize. The guys at 10gen (who make mongo) will say that thinking of hierarchical is a more natural way of thinking about things, which I would agree with (tentatively). Finders feel sort of sql-ish as well, although you will still use map-reduce for aggregation queries.
From what I understand about couch, the big difference is there is a strong focus on the distributed replication thing. Mongo focuses more on performance over massive amounts of data (although they have autosharding and a great scaling story too). I would go mongo, unless you are actually going to use the distributed aspects of couch.
Node has got to be the coolest thing ever, and I think this would be a great application for it. I have zero experience with it, but from what I have read, it is great for loads of small requests, and scales up wonderfully. Idiomatic javascript lends itself quite well to the whole eventing model, and with v8 it runs just obscenely fast.
I'm designing a game where players are programmed bots competing in a programming contest. The bots can be programmed in any language - Java, Ruby, Python, C#. I'm looking for some way to transmit game data across the network or some way by which the game server can talk to the bots. What would be a better choice for this? Should i use XMPP or some other form of remote method invocation?
What you are descibing is not an RMI problem but a messaging one. I am sure there are several solutions you could use, and based on the limited knowledge of your application, I would say that XMPP is one of them. It is language agnostic and has libraries (and servers) available in most well supported languages.
Whether it is the best solution, I couldn't say, but I would think it is a viable one. It gives you the option for transmitting from point to point, point to many points, and a means for your game server to broadcast to all clients.
A REST based webservice might be easier to use if you need lots of languages to be able to call it.
I always find reinventing the wheel to be tedious. Try and see if you can use OpenTNL.
The issue with many Remoting infrastructures are that they are normally not portable between frameworks.
While XMPP might work for you - the main issue you might find is excessive data crossing the network due to all the header/presence stuff in the data being sent around. Also as XMPP is XML based any binary data would have to be sent around as a Base64 string.
A better bet might be a more low level socket interface - either way having the freedom to do bit-packing to reduce the size of the data will possibly be beneficial.