LÖVE

I've been thinking about very simple morpg like game (like mmorpg, but not as much players, can't host powerful enough servers ). Löve games are open-source, but after reading this interesting thread there seems to be some ways to prevent players from reading straight from .love file (luac). It probably solves these problems for most of little online games, but I'm still interested in the idea of open-source morpg.

I'd like to have ideas and examples (from games that does this, not actual code) in this thread about techniques for writing open-source online game, with server and number of clients playing on it. There's too big temptation to modify the code a bit to i.e. run faster than others in the world. But it would be great to share the code for server and I'll start with some ideas:

md5sum: After game is started and loaded needed .lua files, it compares client files with server's own files and if they're same, then lets the client to connect. I'm not too good löve+lua coder, so problems that comes to my mind are, that you can't read the .lua files on the run for comparison. Or you can modify the files on the run (would pretty much make the comparison at the start useless). Tried to find md5 things for lua+löve on forums, but didn't find anything useful, so that could be problem too. Some people said it was impossible to do it in Löve, but I'm not sure about that.

Calculating everything on the server: One idea that came to my mind (and was suggested in the thread I linked) is to do all the important calculations on the server and send data needed for displaying the game right to the client. This is of course very power consuming for the server to do calculations for i.e. 50-100 players at the same time, and very lagging without proper net lines.

Correcting the client: One idea, which is similar to above, is to calculate i.e. players movement on the server (which is again, power consuming) and on the client itself. Server just sends correction x and y values from time to time to the client and it corrects it's position. It would be very annoying for player to modify it's character faster than it should be, but then it gets corrected every 3 seconds.

Can't think clearly for anything more now, but there should be more ideas like this to prevent cheating even if it's open-source game. Shoot ideas!

You could do stuff like checking every once in a while if the player has moved too much, if so, kick him, that kind of stuff.

About the md5sums, it is basically impossible to do this correctly in lua, and c is non-portable, and it will still be hard, so this is basically impossible. The best thing to do is as mentioned above, do periodical checks on stuff you can easily check. You might think about a punkbuster-like screenshot-checking.

Calculating everything on the server: One idea that came to my mind (and was suggested in the thread I linked) is to do all the important calculations on the server and send data needed for displaying the game right to the client. This is of course very power consuming for the server to do calculations for i.e. 50-100 players at the same time, and very lagging without proper net lines.

I'm a strong believer on the server-centric approach, and I don't agree with some of the things on the parragraph above.

By server-centric I mean a process in which:

• The clients just send their inputs (keypresses, mouse clicks, etc) to a server
• The server does the calculations (this player is now here, this orc is there, this sword is on this table, etc)
• The server sends information to the clients (you can see this orc here and this sword there).

These steps are repeated on every frame.

I believe that any current desktop computer should be able to perform the calculations of step 2, for 50-100 payers, every frame, without much trouble. The problem is step 3: sending information back to the clients, fast.

The most common approach is to send information only about itens that are a) visible and b) changed since last update. I've also seen systems in which there was a "network priority" for objects. In FPSs, players have the max priority, then bullets, then powerups, and then the rest of the things, such as sparks. This way, if you can't send everything to every player, you can at least send the most important stuff (that has changed and its visible).

Certainly, your clients will download more stuff than if they calculated some of that stuff themselves... but only as long as these calculations are not important for other users. Otherwise, they will have to be *uploaded* from the client to the server, and then *downloaded* to other clients... which is slower than having it calculated directly on the server! Broadband connections these are typically fast on donwloads, but not so speedy for uploads - so your clients are best left out downloading as much as possible, and uploading as little as possible, IMHO.

Another issue that you don't mention is what happens if a client suddenly disconnects or if its network is too slow. What must the server do? It could freeze the game and wait for the client, but this means that you block all clients just because one client has a slow connection. What if he/she disconnected? If you choose to "predict" instead(which is a complex problem on itself), what happens if your predictions don't match the player's behaviour?

The "server-makes-all-decisions" approach bypasses all these problems; a player with slow connections will just appear to be iddle. Players with faster connections will be unaffected, and you will not have to predict (delayed input from previous frames is just ignored).

And with server-centric you can pretty much ignore the MD5sum problem, too.

Sorry for the long post, I've just strong opinions about network games being server-centric .

The issue I have with server-centric theory is the latency. Disregard any algorithms and complex techniques for determining what to send and what not to send, and think solely about the travel time of a single packet. On a very good day, with a fast connection, to a nearby server, you'll get a ping of about 50ms between the client and the server. That's unacceptably long as far as input latency is concerned - any input latency > 20ms is noticeable by most people, and if I have to wait 50ms (or, most likely longer) for my character to perform an action after pressing a key, I will begin to get very frustrated very quickly. Particularly in a twitch game like an FPS, such latency is absolutely unacceptable.

I agree with you in that a slow network is a huge issue on the server.

What I'm saying is that having the server handle the calculations is actually the fastest solution, traffic-speaking - because the server will have to replicate each of the client's calculations to the other clients.

Good points here, thanks guys!

Calculating everything on the server really seems to be best option about those three (especially now that md5 is not an option), but it's still not really suitable for more fast-paced games (FPS, racing, flying, etc.). Correcting the client time to time (and then kicking+banning if continued) is a good option too, but it can still give a lot of advantage for cheaters.

Currently thinking a bit about calculating things that needs to be fast (e.g. race car moving), within the client compiled with luac, and then using server calculation for things like shopping items and things like that. I'll probably start a new thread about my game idea, so you can get better idea what I'm trying to do and what could be the best solutions for each thing in game. After I've used some more time thinking the game idea though

If you have any other crazy/not-thought-through ideas, shout them! Haven't had enough time to think those myself, but maybe christmas gives some time Going to be interesting thread if we can gather more different ideas here!

Well, I have a not very original advice, but here you go:

Steal!

Lots of programmers have trackled the client/server game. You can "get inspired" by lots of articles already written about the subject.

I particularly like how the Unreal Engine does it; they have a way of specifying things like "this function is invoked on the client, but executed on the server - the client has to wait" or "this object can be simulated in the client this way if network is too slow". This is called replication in UnrealScript lingo.

By the way, I don't want to drive people away from LÖVE, because it is awesome... but have you noticed that the complete Unreal Engine is free for indie programming? Maybe you will want to give it a look

Hehe, of course stealing is the best way. Why invent the wheel over and over again Especially if you're doing it for profit.

But it's still interesting to talk and brainstorm about these concepts. Any new ideas not already written on here? Is there some other ways of doing checks similar to md5 in lua? Even if using compiled client, and some server -> client correction, it would be great to have some simple check of files in addition. If we could do it right, we can use that as a client version checking. No md5 match -> different version of the client -> kick, in example.

UnrealEngine's replication seems really complex, but have to look at it closer. Thanks for the link!

And yeah, it's wise to use engines already available (especially now free UnrealEngine and Unity Indie), but I like the idea of doing almost everything from the ground up for my liking Especially what I have in mind, it should at least start as a so simple game, that UnrealEngine could only make it more complex than it should. And I love how simple it is to do 2d stuff in Löve

Brainstorm, brainstorm, brainstooorm!