I am designing a little soccer game where the game engine (that computes player moves etc.) runs on a server, and rendering and keyboard/mouse handling is done by the client. For the server (Haskell) I want to use
Happstack for client-server communication
Yampa / Reactimate for the game engine
Every 20ms or so, the client should send keyboard and mouse events to the server via HTTP GET, receive the current game status (JSON-encoded ball and player positions) and render it. I am thinking about using SDL infrastructure for the game loop, input handling and rendering.
The server basically runs two threads: A happstack server receives the HTTP GET, puts the keyboard / mouse commands in a queue, reads the current game status from a second queue and answers the HTTP GET request.
The second thread runs a Yampa game engine, as described in the Yampa Arcade paper: The game engine computes the new round as quickly as possible (no ticks) and puts the result in the render queue.
General question: Does this look like a feasible architecture?
Specific question: How would one design the server side rendering queue: Would one use a Chan for this? If the game engine is quicker on average than the "ticking" on the client side, the queue will get longer and longer. How could this be handled with Chan?
Your comments are very welcome!
Could you explain a bit more about the game itself. When I think of a soccer game I think of a game that requires real-time feed-back where input should be handled instantaneously and I would expect player input information to be sent over the network immediately. 20ms is quite a delay and I believe would be noticeable when the player holds down the key trying to move his/her character it will probably feel jerky the kind of jerky-ness experienced with certain types of garbage collectors.
I also do not understand why you would want to use HTTP for such a game (any game for that matter), almost all games use UDP and I would probably go down this route for your type of game. This tutorial looks great for learning about that kind of stuff.
I would also question your choice of network data format, why would you want a format that would require non-trivial parsing/formating when receiving/sending? I'd imagine that sending lots of data and frequently this would add up significant time. If I was going to use strings I would try to use the simplest format that requires very minimal parsing. On related system that I would work on it was a multi-process real-time system using sockets to communicate, and originally it used xml strings as network data format and it was terribly inefficient and all the processes where all on the same machine.
Regarding Yampa & server-side rendering, so if we think of FRP in the context of games as means of implementing game logic & entities I believe most networked games have server & client entities. Typically objects that are renderable are client entities and non-renderable are server entities, and I guess that some entities have representation on both. So in that case you probably want to have Yampa running on both the server & the client side and I would try to avoid anything related to rendering on the server-side. renderable objects should predominately stick to the client side I believe. Is there a specific reason why you want to have render commands coming from the server?
If you only want to ever give the latest game state, don't use a chan or a queue, use a samplevar: http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control-Concurrent-SampleVar.html
In case you're interested, I also wrote a similar server-client based soccer game in Haskell once. You can find the source code at github (server, client). As I was quite a Haskell beginner back then, I ran into some problems regarding threading (and blogged about them) and never really finished the project, but you can at least see from the code how not to do it. (In the end I ditched the server-client architecture and wrote freekick2.) I do think the architecture itself is feasible, though.
However, like snk_kid writes, I don't know why you'd want to use HTTP. To have it running across a network without (noticeable) latency, you'll probably have to use UDP as well as client side prediction (here's some informative material).
Related
I need to do some basic networking for a Pygame project.
Basically, it's a 2D single player or cooperative game. The networking only needs to support two players, with one as a host.
The only information that needs to be sent is the positions of players, creeps and bullets.
I've been reading around and Twisted keeps coming up, but I haven't done networking before, and I'm not sure if that might be an overkill.
So, is it possible for a relative newbie to implement networking in Pygame?
This was asked recently on Reddit, so I'll more or less just copy my answer over from there. I apologize for not being able to provide more links, I have <10 rep so I can only post two at a time.
Twisted might work, but I don't have a whole lot of experience with it. I'd recommend going with sockets, as that's what Twisted uses in the background anyway. Beej's guide (google it) is pretty much the Holy Bible of sockets if you want to learn how they work (in C++, but the concepts extend everywhere). Python does abstract some of the complexity away, but it's still a good idea to know what's going on in the background.
For Python specific sockets, you can go ahead and just use the howto (user745294 posted a link above). Here's a nice article titled "What every programmer needs to know about Game Networking". It goes into the different types of major networking styles (client-server, p2p, udp v. tcp, etc.) and the history behind what some major games used for their networking.
Below is a link to a demo I did on making a networked "game" in Python 2.6/Pygame. It's not actually a game, but each client you create connects to the server and controls a character. You can move your character with the arrow keys and the character will move on all connected clients. I tried commenting the source code with some indication of what I'm sending back and forth, but you may need a little knowledge about sockets to understand it.
The source code is provided in the codepad links in the comment below this post. You will need to provide two images in the same directory as the scripts:
bg.png is the background sprite. It should be an image 400px wide and 300px tall (this can be changed in the GameClient class if needed)
sprite.png is the player character. It should be smaller than the background so that you can see it moving around.
You can use Twisted for networking with Pygame. The "game" project on Launchpad has some examples of how one might integrate the main loops together; basically, use twisted.internet.task.LoopingCall to draw Pygame frames and handle input, while letting the Twisted reactor of your choice run normally.
Since you are already using Pygame, I think this light networking library made for Pygame will do what you need and teach you, but not overwhelm you.
"Mastermind Networking Lib" via pygame.org
There is Pyro (Python remote objects) as another solution for networking in Python.
http://irmen.home.xs4all.nl/pyro/
Using raw sockets is low-level and full of danger. As said before, Twisted is complex and takes to time get up and running. To save yourself some headaches I'd try something like zerorpc.
You need the following solutions:
discovering other player(s) on the (local) network, you don't want player to enter some IP address
handle network errors
serialize messages containing your data (positions, player name, etc.)
handle threading as networking is asynchronous I/O
Above should still be called 'basic', you should really use some fancy networking library with idiomatic API.
Essentially you need to expose the network service (in its own thread) that will push messages to Python's Queue, and then access this same queue from your Pygame code, and if there is a message then you update whatever structures you use to store player's position and draw it on screen.
You shouldn't send stuff like bullet positions over the network as they can be easily (and faster) calculated locally. You just send an event like bullet_shot over the network with a source position and velocity vector.
I am trying to make an io game using Phaser and NodeJS/Socket.io. I realized to prevent cheating I need to make an authoritative server that runs the game.
While trying to architect the server, I wasn't sure what to do for collisions. Right now my idea is to divide the canvas into tiles and check each tile for collisions but that still seems like alot of work for each update. On the flip side I could loop through all attack sprites and look for overlaps with specific tiles, and then check the sprites in those tiles. I am afraid this is too slow, but I might be wrong. Does anyone have any better ideas?
And does anyone have any recommendations for server side physics engines so that maybe I don't have to do the math for collisions and movement?
Good thinking. The best way to do it afaik is to use a method called binary space partitioning, where you split your world up into chunks, then check for collision of objects only within those chunks. If you have an object on one side of your world, for instance, you will not need to check for a collision between that object and another object on the other side of your world in a different chunk.
If you haven't done it before, you might not want to write your own physics engine since there are so many options available. Even Bullet3D has a web port known as Ammojs. Iirc there is a version that works with node, but you'll have to do some work with multithreading or replace the webworkers to get it working right.
Here is a blog post by someone else who got a socket and node game up and running with Box2d as the physics engine:
http://paal.org/blog/2012/07/06/running-box2d-on-server-with-node-js-via-socket-io/
https://www.youtube.com/watch?v=5ty6wA2wSX4
Keep in mind, even if you're running it on an authoritative server at say, 60fps, at some point you might want to run it on the client as well, especially if the client is updating between renders from the server. You MIGHT have to write some prediction or interpolation code so that the animations don't look super janky.
Hope this helped.
I'm planning to make a web-based game (using three.js and socket.io), and one of my main concerns is protection against cheating.
I know the basics to make a secure game, i.e :
Never trust the client, client is only for rendering and input capturing
Put your game logic server-side
The best anti-cheat is the human
Knowing that, vulnerabilities for which i have no ideas how to be protected are precisely those that concern the client and that the server can't check. For example, as an attacker, i can :
modify the renderer or shaders to make walls invisible (wallhack)
modify position of the camera, that is simply in a variable
inject code that will input for me (aimbot)
In classic games (executables), there are programs that can detects illegals operations. Usually, anti-cheats inspect the assembly and check that no dlls are being injected.
Maybe there is an obfuscator that is specialized in this task (even if it means losing performance) ?
I haven't done all the research yet but I hope that some of you have already been confronted with this problem, and can save me a lot of time by orienting my research.
Thanks a lot
If you wanna do an "anti-cheat" engine, you'll have to do that. You can add anything you want client-side, to facilitate the server-side work, but you must never trust the client. All Logic you have must be at least server-side. You can reproduce it client-side if you want, but no client-side only solution will do it.
After the basics:
If you don't mind wrapping HTTP, then use ExpressJS
take a look at this code for express-blacklist and express-defend:
var expressDefend = require('express-defend');
var blacklist = require('express-blacklist');
app.use(blacklist.blockRequests('blacklist.txt'));
app.use(expressDefend.protect({
maxAttempts: 5,
dropSuspiciousRequest: true,
logFile: 'suspicious.log',
onMaxAttemptsReached: function(ipAddress, url){
blacklist.addAddress(ipAddress);
}
}));
as they aren't registered with socket.io, they will be only affected by the Express route
take a look at this: https://github.com/hrt/AnticheatJS
this is a good software you might want to look into: https://www.tuxbihan.org/software/top-05-anti-cheat-software-to-make-fair-for-gamers/
Hope this helps!
First I want to apologize for my approximate English, as I'm French. I'm currently making a real-time game in java, using LWJGL.
I have some questions regarding game loops:
I'm running the rendering routine in a thread. Is it a good idea? Usually, the rendering routine is fairly slow and should not slow down the world update (tick) routine, which is way more important. So I guess using a thread here seems like a good idea (minus the complications from using a thread).
In the world update routine, I'm updating a list of entities with the current time. Each entity can then compute their own deltaTime, corresponding to the last time they were updated. This differs from the usual update loop, which updates every entity in the list with the same deltaTime. This seemed appropriate because of the threaded rendering. Is it a good idea? Should I use the second method instead? If so, is the threaded rendering still needed? If so, do I have to add a maximum deltaTime?
In general, is it a good idea to have a maximum deltaTime?
Thanks for your time!
Is it a good idea? Separate threads are fairly advanced stuff, I see no reason to do multithreading to begin with. All the mobile games I have worked on so far have not needed multiple threads, even though they are 'real-time'. Hardcore PC and console games are where multithreading really starts to come into play. Here is a link to a recent talk on the subject if interested : http://archive.assembly.org/2011/seminars/adventures-in-multithreaded-gameplay-coding.
Sounds like this could cause some strange things if the physics are not handled in one go. Not sure about this. Colliding an object that has already been updated to another position with an object that comes another time, for example, correcting this sort of situation may become problematic? Fast moving collisions may need to be subdivided, which may be why you have the separate update thread, but why not have them all calculated as happening at the same time?
'Variable timestep' and 'Fixed timestep' are the options available for rendering. Most games at the moment seem to choose a 30 fps fixed timestep. The rendering has to be kept under the limits so no catching up should be needed.
One problem with variable timestep is you are forced to pass deltaTime to all time-dependent areas. Fixed timestep is handy as you can assume you are running at say 30 fps, and use that value everywhere. It is a preferred method at the moment as far as I know.
Though this question is a few years old…
AFAIK,
Rendering is usually done in separated processor — GPU, so they're already a separated thread. But, drawing command must be processed by graphics driver (which is running in CPU) before dispatched to GPU, and this processing may be saved by being multi-threaded. Anyway in this case, you're responsible to manage synchronization between logics and rendering thread.
Generally speaking, games are all about interactions between objects, and it's very hard to divide state-graph into fully separated divisions. As a result, whole game state usually becomes single graph, and this graph cannot be updated while being rendered. In this case, you have no benefit by being multi-threaded.
If you can keep a separated immutable data for rendering, than you may gain some benefit from rendering in separated thread. But otherwise, I don't recommend it.
In addition, you should consider GC if you truly want a realtime game. GC related performance issues usually the biggest obstacles to make realtime stuffs.
I have a noobish question for any graphics programmer.
I am confused how some games (like Crysis) can support both DirectX 9 (in XP) and 10 (in Vista)?
What I understand so far is that if you write a DX10 app, then it can only runs in Vista.
Maybe they have 2 code bases -- one written in DX9 and another in DX10? But isn't that an overkill?
They have two rendering pipelines, one using DX9 calls and one using DX10 calls. The APIs are not compatible, though a majority of any game engine can be reused for either. If you want some Open Source examples of how different rendering pipelines are done, look at something like Ogre3d, which supports OpenGL, DX9, and (soon)DX10 rendering.
The rendering layer of games is usually a fairly well isolated/abstracted part of the whole application. As far as the game engine is concerned, each frame you are simply building up a list of conceptual objects (trees, characters, etc.). If the game engine chooses to render a particular object, then it's up to the rendering layer how to actually translate that intent into DX draw calls. A DX10 rendering will generate a different set of draw calls to a DX9 layer, but conceptually they are still performing the same action - 'render this tree'.
Rendering is nicely abstracted because it's rare that you want to get any information back from the rendering layer, once the 'render this tree' action is performed, the game engine will just assume that the rendering looks correct. There is little need to handle different potential results from DX9/DX10 rendering calls because 99.9% of the information is going from the engine to the graphics system, and the 0.1% that comes back likely takes the same form between the two APIs.
The application setup is a little more icky, because you've got to ask the system whether or not DX10 is supported and gracefully fall back on DX9 otherwise, but this is standard fare for application setup (in the same way that the game has to pick a resolution, refresh rate, input device, etc.).
It is likely that they have an abstraction layer and they develop against that. At run-time they instantiate the DX9 or DX10 wrapping concrete engines.
I imagine their abstraction is positioned very close to the DirectX layer and simply provides DX9 with sensible manual implementations of DX10 functions or enhances DX9 logic when running on DX10.