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.
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 need to reduce the volume of a radio that plays in the browser, play a song in my Electron app, then raise the radio volume in the browser again. Is it possible to do it on Electron?
I searched for a library that made isos but I couldn't find anything.
Explained
You could simply do it via the DOM within a renderer process, keep in mind, you wouldn't be able to approach the problem like this if you desire to handle volume within the main process, simply because you cannot access the DOM within the main process.
I mean this may not be the best way, however, it's a simple way, at least in my opinion, and it saves having to include anymore dependencies into the project. Thus in my opinion, possibly making it more stable & reliable, with this approach, you wouldn't have to worry about 'x' dependency changing, expect for Electron itself. I may even go as far to say that it could also mean that it's more performance friendly, as you don't need to load in another dependency, although I'm not confident enough to say that all of this is a solid fact, this is, for the most part, opinion based.
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!
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).
I am in the process of developping a game, and after two months of work (not full time mind you), I have come to realise that our specs for the game are lacking a lot of details. I am not a professional game developper, this is only a hobby.
What I would like to receive help or advices for is this: What are the major components that you find in games, that have to be developped or already exists as librairies? The objective of this question is for me to be able to specify more game aspects.
Currently, we had specified pretty much only how we would work on the visual, completely forgetting everything about game logic (AI, Entities interactions, Quest logic (how do we decide whether or not a quest is completed)).
So far, I have found those points:
Physics (collision detection, actual forces, etc.)
AI (pathfinding, objectives, etc.)
Model management
Animation management
Scene management
Combat management
Inventory management
Camera (make sure not to render everything that is in the scene)
Heightmaps
Entities communication (Player with NPC, enemy, other players, etc)
Game state
Game state save system
In order to reduce the scope of this queston, I'd like it if you could specifically discuss aspects related to developping an RPG type of game. I will also point out that I am using XNA to develop this game, but I have almost no grasp of all the classes available yet (pretty much only using the Game component with some classes that are related to it such as GameTime, SpriteBatch, GraphicDeviceManager) but not much more.
You have a decent list, but you are missing storage (save load), text (text is important in RPGs : Unicode, font rendering), probably a macro system for text (something that replaces tokens like {player} with the player characters name), and most important of all content generation tools (map editor, chara editor, dialog editor) because RPGs need content (or auto generation tools if you need ). By the way have links to your work?
I do this exact stuff for a living so if you need more pointers perhaps I can help.
I don't know if this is any help, but I have been reading articles from http://www.gamasutra.com/ for many years.
I don't have a perfect set of tools from the beginning, but your list covers most of the usual trouble for RUNNING the game. But have you found out what each one of the items stands for? How much have you made already? "Inventory Management" sounds very heavy, but some games just need a simple "array" of objects. Takes an hour to program + some graphical integration (if you have your GUI Management done already).
How to start planning
When I develop games in my spare time, I usually get an idea because another game lacks this function/option. Then I start up what ever development tool I am currently using and try to see if I can make a prototype showing this idea. It's not always about fancy graphics, but most often it's more about finding out how to solve a certain problem. Green and red boxes will help you most of the way, but otherwise, use Google Images and do a quick search for prototype graphics. But remember that these images are probably copyrighted, so only use them for internal test purposes and to explain to your graphic artists what type of game/graphic you want to make.
Secondly, you'll find that you need to find/build tools to create the "maps/missions/quests" too. Today many develop their own "object script" where they can easily add new content/path to a game.
Many of the ideas we (my friends and I) have been testing started with a certain prototype of the interface, to see if its possible to generate that sort of screen output first. Then we build a quick'n'dirty map/level-editor that can supply us with test maps.
No game logic at this point, still figuring out if the game-engine in general is running.
My first game-algorithm problem
Back when I was in my teens I had a Commodore 64 and I was wondering, how do they sort 10 numbers in order for a Highscore? It took me quite a while to find a "scalable" way of doing this, but I learned a lot about programming too.
The second problem I found
How do I make a tank/cannon fire a bullet in the correct direction when I fly my helicopter around the screen?
I sat down and drew quick sketches of the actual problem, looked at the bullet lines, tried some theories of my own and found something that seemed to be working (by dividing and multiplying positions etc.) later on in school I discovered this to be more or less Pythagoras. LOL!
Years and many game attempts later
I played "Dune" and the later C&C + the new game Warcraft (v1/v2) - I remember it started to annoyed me how the lame AI worked. The path finding algorithms were frustrating for the player, I thought. They moved in direction of target position and then found a wall, but if the way was to complex, the object just stopped. Argh!
So I first sat with large amounts of paper, then I tried to draw certain scenarios where an "object" (tank/ork/soldier) would go from A to B and then suddenly there was a "structure" (building/other object) in the pathway - what then?
I learned about A-star pathfinding (after solving it first on my own in a similar way, then later reading about the reason for this working). A very "cpu heavy" way of finding a path, but I learned a lot from the process of "cracking this nut". These thoughts have helped me a lot developing other game algortimes over time.
So what I am saying is: I think you'll have to think more of:
How is the game to be played?
What does the user experience look like?
Why would the user want to come back to the game?
What requirements are needed? Broadband? 19" monitor with 1280x1024?
An RPG, yes - but will it be multi-user or single?
Do we need a fast network/server setup or do we need to develop a strong AI for the NPCs?
And much more...
I am not sure this is what you asked for, but I hope you can use it somehow?
There are hundreds of components needed to make a game, from time management to audio. You'll probably need to roll your own GUI, as native OS controls are very non-gamey. You will probably also need all kinds of tools to generate your worlds, exporters to convert models and textures into something suitable for your game etc.
I would strongly recommend that you start with one of the many free or cheap game engines that are out there. Loads of them come with the source code, so you can learn how they have been put together as you go.
When you think you are ready, you can start to replace parts of the engine you are using to better suit your needs.
I agree with Robert Gould's post , especially about tools and I'd also add
Scripting
Memory Management
Network - especially replication of game object states and match-making
oh and don't forget Localisation - particularly for text strings
Effects and effect timers (could be magical effects, could just be stuff like being stunned.)
Character professions, skills, spells (if that kind of game).
World creation tools, to make it easy for non-programmer builders.
Think about whether or not you want PvP. If so, you need to really think about how you're going to do your combat system and any limits you want on who can attack whom.
Equipment, "treasure", values of things and how you want to do the economy.
This is an older question, but IMHO now there is a better answer: use Unity (or something akin to it). It gives you 90% of what you need to make a game up front, so you can jump in and focus directly on the part you care about, which is the gameplay. When you run aground because there's something it doesn't do out of the box, you can usually find a resource in the Asset Store for free or cheap that will save you a lot of work.
I would also add that if you're not working on your game full-time, be mindful of the complexity and the time-frame of the task. If you'll try to integrate so many different frameworks into your RPG game, you can easily end up with several years worth of work; maybe it would be more advisable to start small and only develop the "core" of your game first and not bother about physics, for example. You could still add it in the second version.