Tag Info

Hot answers tagged

18

The only similar system I know is OGame. In OGame, players are protected from other players until the have a certain amount of points (I think it is 50.000). It makes more sense to protect players based on their score instead of time, as score gives you a better aproximation on how powerful players are. The theory is that with that many points, players are ...


10

You can't stop them. But you can make their lifes miserable, as they have to spend lots of time writing their bots, and updating them. You have to use whatever you have to verify if user is valid. Check for request headers, and reject requests with invalid values. Either set custom headeror check for existing like user-agent. Sure it's easy to overcome, ...


9

Don't make your game so vulnerable to johnny-on-the-spot effort First, make sure that players who only play your game for twenty minutes or an hour a day in a single sitting aren't at a huge disadvantage to players who leave it open at work and play 16 hours a day. This may require a change in your game mechanics - for instance a move allotment that fills ...


8

Reduce progression in your game mechanics. Avoid making players stronger in a game-mechanical sense based on how far they progressed in the game. That way an experienced player has no unfair advantage over an inexperienced player except for their game knowledge, which a new player can also acquire when they do their research. Herd your players. When a ...


7

The resolution should not affect computation of simulation logic such as "where your bullet hit." Any reasonable game will divorce such simulation data from the final render resolution of the screen. That means the main thing you're talking about with respect to resolution is what the player sees. If all other things are equal, then a lower resolution ...


7

In order to get a server list, you will need a central matchmaking server to which all game-servers connect and announce that they are online and to which all game-clients connect to obtain the list of currently online servers. How many servers are you going to have? For comparison, I remember that during the high-times of the original Counter Strike, the ...


7

In general, distinguishing between bots and humans fully automatically is hard, some form of human-assisted decision process works best. What I would do: define some heuristics that hint the user is probably a bot - doing a lot of actions, doing stuff 24/7, ... Then if these heuristics get over a certain threshold, do an invasive check. You can manually ...


3

The best and only effective defense against bots is to design your game in a way that players don't feel the need to automatize in the first place. When your players automatize simple tasks which do not actually require skill, it is a sign that your user interface is lacking and they are substituting an UI feature they are missing. Does your game include ...


3

The main problem you want to solve is strong, powerful players pick on weak, new players after their protection ends. There are quite a few social solutions to this: Punish players for attacking those weaker than them: The spoils of defeating another player should be decreasingly lower the more weak your opponent is (and they can be multiplied the ...


2

Every network application requires some system to act as a server. There are two ways to implement a multiplayer game: peer-to-peer - in every match, the machine of one player acts as a server, the others as clients. client-to-server - there is a dedicated server application all players connect to but which doesn't play itself. It is either hosted by you ...


2

Let's look at two examples of games that IMO do quite well to deter this behavior: Clash of Clans: In Clash of Clans, new players are given a small amount of starting gold and elixir and a 3-day shield. This shield prevents other players from attacking the new player, but is removed if the new player attacks other players. This gives the new player 3 days ...


1

Embrace the botter. You've built a restful API, perfect for a coder to experiment with automation of your game. Design your gameplay so that the bot doesn't gain an advantage over a human player due to being automated - eliminate the advantages of speed of execution etc that a machine has; design your game so the bot provides the same revenue as a human ...


1

Create a separate bot only server. Look at the data this generates. Ban users from normal severs whose behaviour profile looks like that of a bot.


1

Game states can be synchronised by sending "deltas"—messages that describe how to get from one game state to the next, rather than sending the whole state. You seem to have figured out that this is possible. To get you started on the right path of thinking, here's a more concrete (but naïve) way that could be implemented: In server code, store a boolean ...


1

Crashing? Does not make sense. You can send a lot of data nowadays. There is no reason using a lot of bandwidth would crash a properly implemented client. If it is literally crashing, you may need to debug some more. What to send: You don't need to send everything. Remember the client program is only used (normally): To accept input from the user, parse ...


1

NPC on a path only need to be sends periodically. However instead of only the position you also send the speed and direction the NPC is going. That you only need to send the data a few times a second and the client can extrapolate the current position of the NPC. Health should only be sent when it updates and once every few seconds as a sanity update.


1

Pros Higher resolution should give the player more visual information about the game world. Everything will be clearer and more sharply defined. This should confer an advantage in overall situational awareness, which in an FPS is important. There should be no effect on game state as the game engine does not compute the position of objects and actors based ...


1

For simple matchmaking only, you can create an ASP.Net or PHP website that the players login to (via your game app) and push a notification when they create a server. The problem is securing the server to make sure only your players are accessing critical services like advertising a host or requesting the available host list. There are also services like ...


1

I personally think these values are best stored inside a text file in plain text. There is nothing easier to read an edit. Each class (game character class like Fighter, Mage and so) could have it's own text file and every monster as well. It keeps things manageable and accessible to none programmers. JSON is great until a confused none programmer erases a { ...


1

There are different options to consider. Which one you pick depends on your requirements and preference. Hardcoded values You just put all the values right into your sourcecode. This is the easiest solution for the programmer because no code is needed to read these values from a file or database. Unfortunately it is a real maintainance nightmare, because ...


1

Different browser games I've played used different strategies for this. All came down to resetting all players on a set time. One game dropped all new players in a new world with 400 at the same time, let them all compete against each-other until only one or a handful of alliances where remaining. A single round took about 1 month, and after that everybody ...


1

I think what you are asking here is whether to use authoritative servers or non-authoritative servers. Unity network documentation has a nice discussion about each mode. Also if I'm not wrong, some people call semi-authoritative to a mixed approach where some state is handled by the server and some by the client. I think Unity discussion should give you a ...



Only top voted, non community-wiki answers of a minimum length are eligible