I'm an experienced software dev but pretty new (or rusty) when it comes to games, and current web technologies. So I figured I would quickly describe what I'd like to achieve, and hopefully get a quick point to the right framework/tech to get it started :)

So on the website www.mygame.com, I want to have rooms with maps (and be able to create new ones dynamically), e.g. www.mygame.com/room453124. Only two people can join a room at once, and they play against each other.

The single webpage game is a static image ("map") and the players can place, move (via dragging) and remove little objects, represented by a static image. Super simple.

Here, I made a small mockup:

That's pretty much the extent of what I'd need to do. Load images, move around markers dynamically on a shared 'map area' between the two players, have a chat room, and be able to record all events in a log of some sort.

Alright, I hope that gives a pretty decent summary. I'm looking for info on big picture what framework/tech to use to get this off the ground ASAP. Thanks for any help!

Lools exciting! What languages and frameworks have you been using so far? That might help landing part of what you could use for this. Are you familiar with websocket?

@SuperVGA I have some Javascript/html/css experience. I haven't actually started the project, I'm still in the research phase, both for concepts and technology to use.

One that's caught my eye is threejs, in fact I'd love to be able to make my map area somewhat 3D. I don't need any physics for my purposes, just being able to set positions (and maybe scales) of imported 3D models, that would be sweet. Exact same concept as the OP though, just visually a bit superior, if it's not too much of an investment vs the 2D version I've proposed.

This kind of demo would be the perfect ‘map’ setting, assuming I could import some images as textures and/or 3D models:

https://threejs.org/examples/#misc_controls_orbit​

I'm not that familiar with websockets from a coding perspective but I know the high level idea. Would I be able to have two players clicking and moving about models/objects on a threejs map using websockets and the like?

Cool - then I'd just stick with that and perhaps have a little nodejs server. If the 3D part will be a client only thing, I'd start with making the game 2D with canvas or svg - anything to just see that the server is working, players can take turns etc.

To make it easier to flesh out, you could start defining a REST api for the button/tile presses now, and then you could rig the clients with some reuseable js just for that. Then you could let the server update the clients with ws?

(just throwing ideas around - sorry for not being more concrete)

All sound like very good ideas to get into. The best analogy I can think of is the 2 players having a ‘shared (hopefully 3D) canvas’ to add (and remove stuff) to and from. Latency doesn't really matter, if there's even half a second delay it's not a huge deal, the players are meant to coordinate via chat.

I'll continue my research, by all means if you get any more ideas let me know ? Cheers

If your game doesn't require fast updates you could consider using a database server as your backend. You might want to store user data anyway and it gives you free persistency in the case of connection drops etc. The technology is proven and well-known and there are tons of frameworks to make your life easier. Websockets are cool but require a lot of work on the server side to make it all stable and rugged.

Prototype said:

Websockets are cool but require a lot of work on the server side to make it all stable and rugged.

Sure, but how would you get updates to clients? Let them poll for it? That is a good idea for a prototype, perhaps.

SuperVGA said:

Sure, but how would you get updates to clients? Let them poll for it? That is a good idea for a prototype, perhaps.

Normally it will require some sort of polling scheme, but it isn't mutually exclusive. You can use websockets and still connect to a database. But building a reliable multi-user server from scratch is rather difficult to test and debug, so walking a treaded path may save you a lot of time. Especially if you don't need several updates per second.

Prototype said:

SuperVGA said:

Sure, but how would you get updates to clients? Let them poll for it? That is a good idea for a prototype, perhaps.

Normally it will require some sort of polling scheme, but it isn't mutually exclusive. You can use websockets and still connect to a database. But building a reliable multi-user server from scratch is rather difficult to test and debug, so walking a treaded path may save you a lot of time. Especially if you don't need several updates per second.

Sure... I'm not really following wrt. how it would be easier to test using polling than websockets. Except if you mean that you'll end up writing something more uniform and simple with the polling approach, that is, in which case it's just easier to debug because it's simpler in general.

Today it's rather easy to spin up websocket support on a nodejs server, as well as listening in a browser.

Again, I can completely acknowledge that the polling approach is simpler, but that ws “requires a lot of work to make stable and rugged" is a bit unfair ?. If your server is multi-user it would be so no matter this approach, and those are just tricky to test and debug by nature.

I'm not really arguing whether polling is easier than setting up a WebSocket. It might not. But it can be beneficial to use proven backend technology that is known to reliably handle hundreds of connections and provide persistency out of the box. Personally for a turn-based game I would always use the common stack instead of inventing new wheels. But I'm not a networking expert so your mileage may vary ?