league community project

[meems]

since we're all oldfags reminiscing about the good old days, i thought this is a fertile place for a group project

anyone fancy doing a League of Legends clone? As jaded as many people are with it, it still made >1$bn so it can't be that wrong to have a go. Something we can get a skeleton up and running in a week or 2 : a lite, 2D, top down version.



What annoyed you about league?
me :
- shift from mix of game styles to focus on skill shots, multi flashs, and globals tp
particularly the multi-flash it just ruined the coordination
- always same map
a random map generator would be easy to make. One thing i loved when I 1st played league was getting lost in the jungle.

other minor things. When they started reworking the control panels every patch I realised riot had 100 idle staff that they couldn't get rid of so were giving them pointless jobs.

what I'd like to see in our clone
- random map
- major brainstorm to make very different play styles.

sign up on this thread. State your coding skills, which language u want and what you'd like to contribute. All welcome.



anyone up for it? or am i just an oldman reminiscing about a community spirit and energy that no longer exists?
oh well at least i tried.

[meems]

whats your preferred\recommend network protocol \ framework for indie network games?
never touched networking before. Am just learning tcp and udp networks, and am becoming aware that it can be very difficult & involved to manage realtime game states when the network lags or data goes missing. I figure there must be some refined framework everyone uses.

[RonTek]

whats your preferred\recommend network protocol \ framework for indie network games?
never touched networking before. Am just learning tcp and udp networks, and am becoming aware that it can be very difficult & involved to manage realtime game states when the network lags or data goes missing. I figure there must be some refined framework everyone uses.

Hey meems, if you're talking about desktop only and standard multiplayer, here's a few..

• RakNet
• kNet
• enet

[meems]

thks. Today I feel like getting my hands dirty and learning the horrors of syncing a non-framework udp game over the net.  This way I'll get a better idea of what udp framework components are for when i learn them.

[RemiD]

A multiplayers game using UDP, is all about previous states/values and recent states/values.

Basically, you have one "server program" which updates the important parts of the games to sync everything and to prevent cheating, and you have several "client program".

You choose an interval at which a "client program" will send the state/values his player.

The "server program" is always listening to receive new state/values from a "client program", and it always uses the most recent state/values to update this player, as long as these state/values are valid in the "server world" (not too far from the previous state/values).

As long as the "server program" has not received a new (valid) packet with state/values of a player, it uses the previous (valid) packet with previous state/values, to update the players in the "server world", then the resulting states/values are sent to each "client program".

When using UDP, you need to have several infos in the packets you send : the packet id (a number, in order of creation), the packet size (in octets/bytes), the client/player id, so that when a a "server program" receives a new packet, it can check if the packet is not corrupted (with its file size), it can check from which "client program" this packet is coming from (with the client/player id), it can check the order of the packet compared to others packets which have been received recently, and thus decide to consider it or to discard it...

That's why sometimes you see a freezing of the game in multiplayers game : it is when the "server program" has not received a packet from a client during xupdates, or when a "client program" has not received a packet from the "server program" during xupdates.

Another useful info :
->a "client packet" only has state/values about his player
->a "server packer" has states/values of all players and also on some others important things of the game world

[Derron]

During multiplayer games you experience "freezes" when they use "lockstep" which does not necessarily mean they use a "server-client" architecture.

Server-client (as RemiD explained): All clients communicate with the server (which might be a client too) and server decides what is the truth and what not (so he sends to all players the new state, the actions to run...)

Next to server-client you could also play server-less, all clients communicate with all other clients (A sends to B, to C, to D ... and B to A,C,D, ...). It is all a matter of "trust".

If you plan to have a "server" than do your game in a way that another client can take over the functions of a server. Else the game will end as soon as the server quits out (eg. game over and quit, disconnected from network ...)


@ actions, states
There are multiple approaches to this:
- lockstep (and the likes)
- synchronizing states

RemiD described something with states and this means you send your "I move left 10px /I buy X" to the server, server validates ("is able to move left?") and returns the correction if needed ("no according to my information you cannot move left 10px but only 5px"). Client then corrects his local information (until the response was in the player moved 10px to the left - to avoid "laggy movement"). The correction could be hard ("just move it back right by 5px") or smooth ("linear transition from 0px to 5px to the right). "I buy X" can be valid on the client as it is still available at the vendor for the client. Meanwhile another player was some milliseconds earlier with "I buy X" regarding his packages to the server. Server then validates for the other player (no correction sent out) but to our player it responses with "cannot buy x, not available". Our client than needs to remove the item.
What happens if your client signals you have this item (the correction is not received yet - high latency or so)? It might either just correct the next command ("drink item X" -> "you do not have item x") or it grays items out until it receives a validation (if you validate actions in all cases with "yes / no-but-do...").


The other system - used for older RTS games (or "slow paced games") is lockstep:
All players start with the same game situation/"world" (exactly the same!) and you need to make sure that every logical thing with "randomness" uses the same random seed. So if client 1 calls "randomNumber()" 2 times it should result in the same numbers as if client 2 calls "randomNumber()" two times. So you often end up using "Mersenne Twister" (a "pseudo random number generator"). For visuals you use your normal random number generator (this then allows render-framerates to differ between the clients).

Ok, after game start _each_ logic update is done sequentially - so better call it "turn" (btw. I somewhere in the wasted.nz-archives explained lockstep already). Each turn is completed after X milliseconds. Everything you do in that time (clicking the mouse, sending a unit, buying a house) is collected (but NOT executed, so only "planned") and send to the server/other-clients (depends on server-client or not) and this is done in the very same order! So best is to use a queue.
Ok, so "turn" ended and you send your queue to the server. Server waits for incoming queues and stores them. If it received the queues of all connected clients, it sends them out to all the clients again. So all clients receive the queues of all the other clients. If one did not send his queue in time, the other clients will start to "lag" (games then show the "drop player X for lagging"-windows, or silently ignore it for X times and then auto-drop).

Ok, we assume all send in time and you finally receive all command-queues. Then all clients can execute these commands. So client 1 who sent the action "sending a unit" in the past now actually "sends the unit". An all clients the very first action of the confirmed turn is "client 1 sends the unit". There is no "oops, received the command earlier, need to correct now".

Depending on the time between "sending queue for turn 1" and "received all queues for turn 1" (plus sending out the queues to the clients) you will have a small lag. We talk about <15ms per turn (plus package delivery time for sending queue+confirm / latency). It is not recognizeable in LAN or on faster connections.

Imho - at least as I understood - the biggest trouble here is to "asynchronize" input from "actions". So there is no "If MouseHit(1) then BuyUnit(unitID)" anymore as you need to do a "If MouseHit(1) then AddCommand(buyunit).AddNumber("unit", unitID)" (or similar).

In short: A lockstep game means to have all clients simulate the world on their own.

Benefit from lockstep: all games are always doing the same, there is no need for "corrections" - an action ("buy item x") might fail or not but this will happen on every client. Also "replays" are no problem - you do not need to save the game state at all. You just save all actions/commands ever done (for each turn). And a replay just sends the saved actions instead of real user input.

For fast paced action games you of course better use the other approach (send as it happens, correct if the server demands it). Needs to make sure that you can "undo" everything. But hey, for "lockstep" you might need that too - if you eg. simulate a successful command execution (so eg. you animate the buy-unit-button or already play a "as you wish commander"-sound or what else).

Also a "mmorpg" needs to be non-lockstep. You do not need to know everything of the world you are playing it. You only need to handle what happens around you + global events (chat, friends entering the world, game masters kicking you out because of cheating ...).


bye
Ron

[meems]

thx, that was some detailed explanation there. Would be nice to have some of that crackling enthusiam & knowledge on this community project. Gonna sign up? With our combined forces this time next year we'll be in Bangkok sipping beer and laughing about how poor we used to be before we started the project.

[Derron]

nope, absolutely no interest. It's not just because I think it wont be finished in the "near future".


There is no common language all members here use.
Asset creation takes ages if you want a decent level.
I personally never played that game, I already skipped the DOTA maps in WarCraft III.
I myself already have a "big" game project to finish first ....and others in the pipe already.


It is easy to come along and ask for help - but it might be better to assume you work alone and then have others join the already "prepared" game. If your code quality is bad then of course people might loose interest in joining, so it is a matter of convincing them.


bye
Ron

[meems]

sorry but you have no choice. You are head network guy of the community project. The prestige & trust the members here have for you rests on your performance on this. You must not let us down. I'm sure you are an honourable coder and will work hard. The net code must be ready by Christmas.