Warm-up game: Hatchery

Cosmologicon on 2013/04/12 13:45 of Universe Factory 16
— edited on 2013/04/12 13:47

Download Hatchery

I've never made a game with online multiplayer before, so I did one as warm-up. It was a really good learning experience. I hope I'm ready to pull it off for PyWeek now. Feel free to test it out at the link above. Instructions are in the README. Python 2 + pygame required. Please let me know if you encounter any bugs, such as being unable to connect to the server or being unexpectedly booted.

What did I learn from this?

Suggestions I read online said to make the game work locally first and then add the networking. I wish I had gone the other way, though, starting with the networking. It was hard to add in after I'd already gotten started.
Lag is higher than I expected for using web sockets. I was hoping for ~300ms but I typically get ~1000ms. That's fine, I'll just choose my mechanics appropriately.
Sound logic is unexpectedly hard. For instance, making sure when you jump you play the jump sound once and only once. I usually throw sound in an the end, but this time I'll be sure to incorporate it earlier.

(log in to comment)

Comments

Python Jedi on 2013/04/12 14:12:

That's an awesome game Cosmo! I was getting ping around 120 and lag from 350 to 500. The gravity in such a confined area makes the jumps just a bit more difficult, and tempts you to try absurd jumps, just to try. Nicely done, can't wait for your actual submission! If lag is a problem on the server, possibly limit the number of players and use a queue, like an amusement park ride? Just something that popped into my head.

Cosmologicon on 2013/04/12 15:02:

Cool, thanks for trying it. I don't expect too many players to be an issue for PyWeek. I'll be surprised if more than 3 players ever sign on at the same time. I was seeing what I considered pretty high lag even when I was the only player online.

The reason for this is that even though the average ping is pretty good, it's not consistent. If I have the client run 250ms ahead of the server, then the moves that the player inputs will usually reach the server in time, but 1 frame out of 20 it won't. When this happens, the moves for that frame aren't registered and you'll see jitter as the client and server are temporarily out of sync. So I set the client to run 750ms ahead of the server, and the round-trip time is more like 1000ms. (These numbers aren't set, they're computed on the fly, so yours might be different.)

I guess the best solution is to give the client a limited ability to "rewrite history" and occasionally register moves for a frame after that frame's update has occurred. This gets complicated fast, though. For PyWeek I'm likely to just accept a high lag.

reidrac on 2013/04/12 16:06:

Pretty neat! Any reason why you're using websockets? At first I though it could be cool to have a client in Javascript without changing the server, but then I saw you're using pickle :D

reidrac on 2013/04/12 16:15:

Oh, nevermind... you're using JSON, pickle is only for saving the game. Very interesting game!

Cosmologicon on 2013/04/12 16:29:

I am using json for all client/server communications, but this is just for security. I'm not really planning to make a JavaScript client for this game, but you're right it would be possible because only the server uses pickle.

Web sockets just seems like the right protocol for this, I don't know, is any problem with them I should be aware of?

reidrac on 2013/04/12 17:03:

Not really, I can't think of any real problem. Any high level library that deals with the network stuff for you should be fine.

I'm not an expert but may be using a binary/packed protocol could help you with the lag, but your client messages in JSON format are 22-55 bytes so may be is not important at all. May be an UDP based protocol instead of TCP, I don't know.

Sorry, I'm not helping.

Python Jedi on 2013/04/12 20:31:

I would agree that too many players aren't likely to be a problem, and I've never even attempted socket communication, I was just throwing an idea out there in case you hit on something that is actually successful enough to have that problem. Again, nicely done, and I am excitedly awaiting your entry.