One thing I forgot to mention is all of these games run server side and thin clients just render and send input back to the server. So a game session needs to exist for the back and forth communication to work.

Theoretically you could do this all client side too, but that would remove the magic of every game getting multiplayer for free

▲

avaer 2 hours ago | parent | next [-]

If you architect your protocol cleanly, you should be able to run the simulation client side too without much effort (certainly the web platform has everything you'd need). This is how modern game engines do it, it goes back to the Quake VM and probably beyond.

You'd still get multiplayer "for free", but it could be turned on and off. You could do it with zero code change for the actual games, they don't have to know.

It seems some of the games could do with a singleplayer mode that doesn't depend on the backend having free slots.

Just an idea from a fellow web games person!

	▲	purple-leafy an hour ago \| parent \| next [-]
		This is something I’ve done with my web game, I run the entire simulation client side so as to never worry about scaling issues. Why reach for a server unless you truly need one! My multiplayer mode is p2p planned
	▲	homegamesjoseph an hour ago \| parent \| prev [-]
		Thanks for the feedback! Local games weren't something I really considered until recently, but it would definitely be cool

▲

__del__ 2 hours ago | parent | prev [-]

as a matter of ux, users probably don't need to know that a session is being instantiated, and probably expect a simple play button

fun

	▲	homegamesjoseph 2 hours ago \| parent [-]
		Thanks for the feedback! Need a good way to clean up the UI to distinguish between joining someone's multiplayer session or creating your own