New answers tagged client-server
1
Warning: Sweeping generalizations will be made here.
Client and server development (for the most part) is written in languages suitable to the task. The client will (most likely) be C++, C#, or mobile native. The server will again most likely be written in a "web-friendly" language. You will not write your server in C++ when Java, Python, Ruby, Go, ...
1
The answer is, it depends. My MMO is a separate development stack. My client is developed in Unity, and my server is .NET so they necessarily must be developed separately.
However, Unity for example allows for developing server code and client code right alongside each other. When you are done you end up compiling both the client and the server, OR each ...
3
It's fair to say that for the sort of authoritative server / pure client which nearly all MMORPGs use for unavoidable security reasons, the server is typically developed with the specific purpose of serving that specific data which the client engine needs to consume in order to function.
This works much the same for highly visual business applications, which ...
2
This is too context-dependent.
Some MMORPG games that I had a chance to look at in terms of source code preferred to develop the server and the client as separate codebases. Some of them didn't even share any code between the two. If it was a custom engine I too would probably prefer them to be separate.
But if you are using an already established game ...
1
You can run a virtual machine for either the server or the client. That way you don't need to have two physical computers.
2
One approach I've seen is to include in each packet an ID of the last update you received from this client/server, or a bitmask of which packets you've received in a sliding window.
When forming an update packet to send, you include the current state info, plus any "important" messages from any packet for which you don't yet have a confirmation of ...
2
One thing you can do is make the addon path user-configurable. Besides allowing you to configure this differently on the server and the client, your end users may also find this feature useful, especially if they have multiple storage drives on their computer.
However, at least under Linux, it is possible to have a directory show up as having different ...
2
I'd say this is a very poorly phrased survey question, so it's natural to find it confusing.
It looks like it means to ask:
Do you have multiplayer features where a server (possibly but not necessarily cloud hosted) maintains the shared game state and sends updates to all players in that session?
or
Do you communicate with a server for other features, like ...
1
I believe that what they mean with an "authoritative server (cloud hosted) multiplayer" is a server holding TCP connections or UDP pseudo-connections with the clients. All the game mechanics run on the server. The clients send messages to tell the server what they want to do. The gameserver calculates the results. Then it sends those results to any ...
1
Authorative and REST seem like orthogonal concepts from my understanding.
Authoritative Server
Clients become glorified controllers and rendering engines. They send inputs to the server, and ultimately the server sends back information which is correct (or authorative). Basically the server is always right, and is the baseline of truth. Unlike in P2P, where ...
0
Technically, your gameserver is already an API used by clients as an intermediary to communicate with the database. API does not necessarily mean web service API.
A service-oriented architecture (SOA) has several advantages:
When you have multiple consumers, then you can offer a static interface which is decoupled from the implementation details. This is ...
1
You can do whichever one you want. Note that the second option is more work. Note that the database is already an API, so if you want to put your own API on top of that API you'd better have a good reason for it.
There are some good reasons, like if you want to make it possible to drastically change the database system later. If you use MySQL and the game ...
0
Send a packet when the player stops or starts or changes direction. Record the direction (or lack of it) and calculate the movement on the server at the end of each tick. The client should check the server for the player position and not calculate it locally.
The player's client can then send an unlimited number of requests, it won't help them move any ...
2
Have clients stamp their input packets with the index of the 30 Hz input window to which they correspond.
On the server, keep a bitmask of windows for which you've received input from each client. You can use this as a circular buffer and keep recycling it so you don't need to store input flags going back to the dawn of time.
If you receive an input that's ...
Top 50 recent answers are included
