36
First of all, are you sure you really need that? Have you calculated the memory footprint?
A small back-of-the-envelope calculation: A single mob and its state should fit into 100 byte of data. Let's give it a whole kByte, in case you are doing something extraordinary. When a cell has 1000 such entities, it requires a MByte. If your world is 100x100 cells, ...
17
From an API design perspective, when deciding whether to make multiple separate communicating programs or just one, the question is: can each program function meaningfully without the others? The answer will vary based on your project and preferences.
If they can't, it's not worth thinking about. Clearly they're so heavily linked that they're not really ...
16
1000 player may or may not be a problem. It depends on how often you need to update the database. However there is a simple solution: put the database on its own server.
I had a peek at how the database system works a game that people would call an MMO-Lite – which one I will not disclosure – yet I can tell it consistently has more than 1000 players, this ...
15
Independent of feasibility (yes, depending on scale) there are often better or easier ways.
For instance, in your typical MMO, the server really only needs to know about the coarse navigation map used by AI and player pathfinding. Instead of storing the location of a tree, you can instead just cut a hole into the navmap at the location of the tree. Likewise ...
14
Web browsers disable some Javascript features for security reasons.
My bet is that you just hit Google Chrome forbidding XMLHttpRequest on local files by default (see this answer on SO for how to disable that, but beware: this is dangerous). See this page on the Chrome dev site for details.
This is why you have to setup a local HTTP server to workaround ...
14
One way you could solve this problem is not actually storing state on disk, but just setting up your generation code to use a seed for the random number generator, so it generates the same thing for a given area every time the area is generated, deterministically.
Then you just keep the 1000 or so most recently visited areas in memory. When areas are ...
11
As others have said, the first step is separating logic that's shared from logic that's not. While it's great to draw that line wherever it's clear, your addendum illustrates that sometimes you don't have a clean line to split the code down.
So, how do we solve cases where the client and server want to do semantically the same thing (play a sound), but take ...
11
is it worthwhile to have a separate process that listens for connections and messages from clients and sends the data via local sockets or stdin to another process that runs the actual game server?
To answer whether it is worthwhile, you had to first ask yourself, what is the problem you are trying to solve by adding a dedicated queuing service. If it ...
11
After searching around, it seems that synchronizing the clocks of 2 or more computers is not a trivial task. A protocol like NTP does a good job but is supposedly slow and too complex to be practical in games. Also, it uses UDP which won't work for me because I'm working with web-sockets, which don't support UDP.
I found a method here however, which seems ...
9
System.Net.WebSockets seems to be completely built-in to .Net and freely available in Unity.
Here's a full Websockets client for Unity for example:
using System;
using System.Text;
using System.Threading;
using System.Net.WebSockets;
using UnityEngine;
public class Comms: MonoBehaviour {
Uri u = new Uri("ws://blah blah.us-west-1.compute.amazonaws....
8
Scrambling the transmitted score is probably worthwhile.
To avoid cheat-engine type stuff, you can always scramble it in memory too. If you're storing seven variables, each of which, %10, is a digit, and you add a random number of 10s to each variable whenever a score changes, then it will be tricky to find a variable that matters. You could also get quite ...
8
One way to do this is not to change the actual values in the database in realtime. When the player logs on, you see how long it's been, and how much stuff he should have if he were earning during the time he was logged off, then update the value accordingly.
One benefit of this is that if a player never logs on again, you're not spending server time and ...
8
Both approaches are used with MMORPGs. Keeping everything in memory and periodically check pointing it to disk seems to be the most popular option, at least for older games. It has the advantage of being fairly simple to implement and scaling fairly well, but making it reliable is completely up the to the developer. SQL databases provide ACID properties ...
7
Do the LOS and AOI (Area Of Interest) filtering on the server. Yes, any data you send the client can be hacked. OR extra programs can be inserted as a proxy between client and server to sniff excess data, like the old EverQuest viewer that lets players not only see far-away monsters but even what loot they would drop (which is a bit mind-boggling why that ...
7
Yes - it is feasible. MMOs often split the game world into multiple areas, as this makes the job easier, but you can still do it with 1 massive area - you just need to use a good spatial partitioning scheme.
Because most objects in MMOs don't move, you can also perform a preprocessing pass where objects are used to create collision checking trees.
Memory ...
7
Client-side prediction depends very heavily on a deterministic physics model that exactly replicates the way the game object behaves on both the client and the server. Even small floating point errors, differing random seeds, or slight differences in time if your time step is not fixed can cause very different results. These results can then rapidly diverge ...
6
Just read this:
http://www.gabrielgambetta.com/?p=22
On every recording record current time/frame
On every RPC sent to server attach frame/time
Server sends back result with frame/time
Now the client knows exactly which frame the server's result is about
Commence "player prediction" + rewind & replay
6
As per the documentation, [Command] and [ClientRpc] should be in a NetworkBehaviour, not in a
MonoBehaviour. NetworkBehaviour's must be spawned using NetworkServer.Spawn(). Moreover you should use a NetworkClient Object to connect to the Server.
Take a look at this
Note: As of Unity 5.1 offline documentation is not up to date. Even some aspects of online ...
5
There are several reasons why to use a backend. Without backend, you can't really have states in your game. That means players start all over when they refresh the web page. The facebook API stuff that you mentioned also comes from backend. You can do lots with facebook API, but it's not even pretending to cover all the cases. Facebook recommends Parse.com ...
5
It isn't necessarily as clean cut as you expressed but in overly simplified terms and generalized notions, you are on track.
The thing to remember is that the client expresses it's intent to perform some operation. Some operations are entirely authoritative by the server. In these cases, the server must respond before the client can proceed. This works ...
5
I agree with ratchet freak. As long as you have a single gameserver, it's not worth the trouble.
However, this architecture might prove useful when you need to scale up horizontally. When one gameserver is no longer enough and you need to distribute your game on multiple gameservers for performance reasons, the "socket server" architecture could very easily ...
5
If what you get is just a score number, you can not verify how it was achieved.
To make it more secure you need to obtain a full replay and verify that the game was fair (no cheats used, no score hacking). One of possible implementations of this idea is keeping the game on the server. If all logic is on the server and player can only send his actions, then ...
5
Depending on what language you are using, the answer can vary.
However, if you know any Java, or can at least get the gist of it, here's some old code I wrote to handle something like this.
https://github.com/TheDudeFromCI/WraithEngine/tree/5397e2cfd75c257e4d96d0fd6414e302ab22a69c/WraithEngine/src/wraith/library/Multiplayer
Basically it works like this. ...
5
I'm inclined to assign this task to the server for security and integrity reasons, but i'm not sure on the way i can accomplish that.
Yes, definitely; never trust clients. Clients sometimes "predict" what is likely to happen to help isolate the user's graphical experience from their network conditions, but any actions that could affect the outcome of the ...
5
Introduction
There are pros and cons to each method of synchronization you gave that depend on a couple of factors. First, is your game singleplayer or multiplayer, second, how real-time is your game? If your game is only single player, you may want to consider having a client side only game which would make things simpler. However, assuming you need a ...
4
Database access is always an expensive operation. For that reason it should be minimized as much as possible.
In an ideal case, you would read and write the player data once per session: When the client connects you read it, and when the client disconnects, you write the changed data back. In the meantime it should be kept in the memory of the gameserver.
...
Only top voted, non community-wiki answers of a minimum length are eligible