WebSockets: What do you want?

rogerfgay, I enjoyed the article. Not sure why I thought it was going to teach me how to setup a websocket server. None the less, great read!

I'm curious about your take on the WebSocket C2 manual entry section, "WebSockets and multiplayer games".

scirra.com/manual/153/websocket, section

What is a reasonable time frame to expect a client and server can constently communicate: 50 ms, 100 ms, more? Assume were talking about a client and server being in the USA.

I find this all very interesting but my coding skill is limited. I can probably figure out Python Tornado, tornadoweb.org/en/stable/, for web server code. I guess its time to start tinkering.

I have some issues with the WebSockets and multiplayer games section and have voiced my concern in another thread. It is wrong about TCP being a problem: completely wrong. I don't think "reliable transmission" means what they think it means, and their argument seems irrelevant to any reasonable kind of design. I'll go into detail if you wish, but you can also just look through the discussion here:

scirra.com/forum/topic75529.html

I think Node.js has been popular because it's JS. That's their big sales point. A lot of front-end developers have good JavaScript skills. That's why setting up for JavaScript handlers on the server-side is on my list. I started playing with that while working on the HLL Framework, and it's about time I finished it. But it's going to be running in a system written in Java, which is much faster.

I haven't done timing tests to answer your second question. When I run the demo on the same LAN as the server, it seems instantaneous. WebSockets have the most efficient message passing protocol possible, other than just passing raw data and nothing else (simple socket server). From there, delay is greatly overshadowed by Internet speeds which can be unpredictable (no matter whether you're using TCP or something else by the way).

I'd like to ask a question back. For you, what seems to be the difference between 50 and 100 ms? I mean to the game design you have in mind?

Before trying to answer your last question, I must confess that I know nothing about Tornado. It says that it's a framework that they consider ideal for "applications like" websockets among other things. The reason they give is that it can "can scale to tens of thousands of open connections". So can any good server. So, not being familiar with it, I can's say why I'd use it.

But in any case, I think your point is that you think Tornado is something you can figure out. It's really my goal to provide the framework (based on HLL Framework) around the HLL WebSocket server that will be easy for a lot of people to use.

I'd like to ask a question back. For you, what seems to be the difference between 50 and 100 ms? I mean to the game design you have in mind?

....

So can any good server [does what Tornado claims]. So, not being familiar with it, I can's say why I'd use it.

....

It's really my goal to provide the framework (based on HLL Framework) around the HLL WebSocket server that will be easy for a lot of people to use.

I'd like to know what kind of time frame client and server can communicate. I guess if I'm constantly seeing less then 100 ms in most all domestic US stuff I can assume a WebSocket can do the same.

I'm only looking at Tornado because its written in Python. I don't know JavaScript. Although, I probably should learn it so I can make C2 plugins. Teaching myself and using either Oracle's Java or a C variant are not an option for me.

How are you trying to make it easy to use? It seems to me the problem is its not easy to setup the server. In order for the majority of C2 users to start using WebSockets we'd need a non-coding really simple way of setting up the server. I guess what C2 needs is a plug and play server where we upload a C2 exported html5/WebGl project that acts as the server. How about creating a Dropbox Application? With this users can drop their server C2 files there and easy-setup program takes over from there.

I'm now wondering if it would be possible to use C2 to make the server side program. I don't know how many concurrent connections a C2 created app can handle. Then there are all the logic decisions to handle 100's of different entities doing things, and finally the database is likely another issue. Perhaps a C2 plugin could be made to interface with SQLite.

My basic idea for a game uses a scheme where client and server send/receive dictionary of arrays in JSON format. It would be an isometric view adventure, hoarding, building game.

* the Clients job is to capture user input (keyboard, mouse click, I'm not sure how to do mouse stroke yet). Format it into and array, then asJson, and send to server. The client uses JSON data received from the server to draw the world relative to its view point. In other words making and sending serialized user input; and receiving view point relative drawing information.

* the Server stores all persistent data in a data base, does all logic, and sends what the clients needs to know to render its current view.

rogerfgay,

i will preface by saying i know nothing about server code.

is there a great deal of difference between coding 'turn-based' multiplayer, as opposed to real time or semi real time? i ask because i have seen a plethora of websocket/online/multiplayer type threads begin and end, in no short time. not because the people were not motivated, but because the task seemed to big to encompass. at this point, i don't think there is a way to accommodate everyone...unfortunately. so, would it be more plausible to create a 'simple' turn-based setup for multiplayer, that would work for all the game types that would require it. and then, later tackle the 'big' stuff.

as i said, i know nothing of the intricacies of this stuff. so i'm speaking from a position of extreme ignorance.

please forgive me.

Jase5z

I'm going to set up more than one option for programming the server side. Sure, if you're handy with a language, you can do all sorts of whatever you want. But you should be able to build server side game logic without a lot of complicated stuff � just on the same level that you build C2 game logic. There's just an extra layer. If this happens, send that message � with the message related to triggering some normal C2 game behavior.

I'm first doing XML support which can easily be programmed using a C2 type tool interface. When a message is received by the server, it's an event defined by the message, which triggers a message sent to other players typically. It might even be that messages from one player simply need to be passed on to other players in one play group � simple as that � and let your C2 game code take care of what happens when the messages are received in the browser.

As for speed; yes, WebSockets are definitely not slower than other communications. It's my view at this point however, that if you're going to build a game that relies on split second responses; like a boxing match or high paced racing game, then all users should be in the same room or on the same LAN at least, and probably plugged into the same game machine. There can be delays in messages getting from China to Florida, or even if you're closer. I have a lot of ideas for games that are much less sensitive to or just don't care about a bit of latency here and there.

I don't know what limitations might be in C2 either. WebSockets and my server can handle a great many � limited by the memory of the computer that's running it really. On the browser end, there only needs to be one connection per browser .. i.e. per player. So, it doesn't seem reasonable to think that C2 imposes anything that could get in the way.

As for DB; I'm kind a thinkin' I should do all that at the beginning. I'll say more when I get to it. IN my first go, I'm considering not using a DB system at all. It will likely be needed to gear up a lot; but I think there's a lot that can be done simply by extending the XML stuff. IN many cases, using a DB system could just be overkill.

The types of games I'm going to demo and describe will have much of the information needed on each user's machine � i.e. data that comes in with the web page. Messages from the server will trigger behaviours in each browser that each browser-side program already knows how to do. If you want to set perspective to a particular place on a map, just send the map coordinates. If you want one of the players to move somewhere, just tell it where to go and what behaviour it should use to get there (run, jump, walk �.) The rest of the logic should be in the browser already.

But then � at some point, I want to make it easy to send behaviour descriptions in from other places. You might even want to provide access to new and different scenes. That's another story, but I wouldn't want to be constantly streaming background scenery and millisecond by millisecond position information.

harrio

I don't know everything about everything either. No need to apologize. I came here without game building experience and not even knowing how to do simple things with C2. I asked and somebody answered. It's a good thing.

I've been through a few conversations on Websockets and multiplayer games already, and it seems that some people jump immediately toward trying to solve theoretical problems at the cutting edge of computer communications and game interactions, whether they understand any of it or not. I think you're right to think about pulling back from that, doing something that works, and deciding for yourself what type of game is something you can handle. In my view, you're acting pretty smart.

You're right that turn-based would be easy to do. Whether ?real-time? is much harder depends on what you mean by ?real-time.? I mentioned in the post above, that at this point, I'd stay away from stuff that requires millisecond response times. But I've played games that are called ?real-time? because you have to wait minutes, hours, or days for something to happen; like travel time to another island, or building something to the next level, or 15 minute long battle rounds. I think it could be interesting to use WebSockets to change the battle round part of such games, allowing ?generals? ? players to send in and pull out troops at any time, and watching the battles as they occur. I've given a good bit of thought to that one and might set up some kind of demo later.

There's a lot in between the two that seems very practical to me and doesn't need to be complicated. I think the trick is that I need to finish getting the server-side set-up easy to do ? at least as easy as using C2 on the browser side ? and then doing some more demos, showing that it's not complicated to set up practical yet interesting player interactions.

I am of course interested in getting others to build demos and games since I'm basically not a game builder. But, I'm learning that I must go far enough with this on my own to show others what I mean, and how to first.

rogerfgay, Thank you for the conversation. I've come to the conclusion that at this point its all just too complicated for my script-kiddy skill level.

To answer your original question, "What do you want?". Simple, a way to set up a server using c2 style coding. An example might entail: I put a c2 file (this is server code!) in a dropbox linked application, rent some server space, then the application takes my server code c2 file and sets it all up. Finally, I use a different c2 file with client code to complete the communication circle.

The types of games I'm going to demo and describe will have much of the information needed on each user's machine ? i.e. data that comes in with the web page. Messages from the server will trigger behaviours in each browser that each browser-side program already knows how to do. If you want to set perspective to a particular place on a map, just send the map coordinates. If you want one of the players to move somewhere, just tell it where to go and what behaviour it should use to get there (run, jump, walk ?.) The rest of the logic should be in the browser already.

Word of warning, players will use cheats and spoofs if you do too much game logic or persistent data storage client side. In your example I could use Cheat Engine to hack the memory address for player position and perform teleport-like movement around the map.

I've seen many people comment that the best way to handle this problem is to make it so the client only handles capturing user input, sending this input to server, and rendering what the servers tells it too. All game logic and persistent data storage are on server.

Then again, If you just playing with a bunch of buddies on local network or lan party I'd hope they aren't try to cheat!

To answer your original question, "What do you want?". Simple, a way to set up a server using c2 style coding. An example might entail: I put a c2 file (this is server code!) in a dropbox linked application, rent some server space, then the application takes my server code c2 file and sets it all up. Finally, I use a different c2 file with client code to complete the communication circle.

That's basically what I have in mind, but I also think I'll set up so that JavaScript, C#, Java and other programmers can do whatever they want. If this gets popular and has community support, some of those programmers will write extensions that you can use in the C2 style set-up.

Thanks for the tip re: security. I Googled Cheat Engine to see what it is. I'll give some thought to it. Are you really going to be able to figure out that mmptz is your current position and pmtrq is the other player?

Word of warning, players will use cheats and spoofs if you do too much game logic or persistent data storage client side. In your example I could use Cheat Engine to hack the memory address for player position and perform teleport-like movement around the map.

There are also various cheats and spoofs used on other commercial sites, so I'm wondering if this is done in a way that I already understand and am prepared to deal with. After sleeping on it, I am also wondering if such a trick would just leave the cheating player yelling "I won, I won." and everybody else in the game saying "No you didn't" because the behavior would only be seen on the cheater's screen. Anyway, I'd like to look into this, this weekend.

What I'd like to know, if you've tried, is whether these things are problems in games built with C2? My security strategies are implemented in my own code of course.

No theses things are problems in html 5 games and even normal games on desktop in general. If someone have access to game client logic you must take into consideration it can be altered. The only way to counter this is to put all the logic on the server there no other ways. You will probably (depending how you coded it on the client.. either by refreshing the stats regulary or whatever) end up with your scenario at some through where the dude that altered it get into a false sense of winning cause all he did is teleported himself to x y pos. But the server alway know the truth, he know that the player are not at this position because of server game state logic. So wht happen if he execute a move based on wrong origin coords ? Well at this point its up to you.. you can kick him for having sent bad data once you validate it. But in the end you wouldnt really care since you know its secure ans cant change the game state.

I'm not entirely convinced that all the logic has to be on the server. I'm trying to ask some questions about that. Security issues are not unique to games and I've dealt with some things effectively. I'm not saying there's no possibility. I just need to confirm. Sometimes the "common wisdom" isn't all it's cracked up to be.

It might be possible to deny access effectively to begin with. But as I said before, changing what's going on in one's browser, doesn't mean it's going to change what's going on in everyone else's browser, or what the server thinks is going on. The way I imagine the interactions would work, it would just cause confusion for the player trying to cheat. She would lose track of what's really going on.

But back on that point of denying access to begin with. Such things are possible. I'm wondering if anyone's tried to cheat a C2 game? That seems important in the context of this forum which is about C2.

Offcourse i am not talking about UI logic or anything like that. However i would be interestes to know which kind of logic you have on mind.

It's early in the morning and I'm just working through my first coffee. Started a response and realized I was really saying what we already know. At first I thought maybe I should just come back later. But since I came here to learn, and have been learning, it seems about time I summarize a bit and organize my thoughts anyway. It seems I have some basic things written in soft stone already and it's time to jump up to the next platform, so to speak.

As a server / back-end framework developer, it's my task to provide options in a way that application developers can and will be willing to use. It seems to me that it's essential to allow game developers to continue to use their current tools, like C2. C2 allows game developers to put all their game logic in the front end. My first focus is on setting up the server side so that game creators can create server-side application logic in much the same way they build game logic in C2.

Before first release however, there are some other things that need to be done. I think the server should already support logins and managing groups for example. These are examples of basic server tasks that are beyond simple proof of concept demos and into real-world necessity. Game developers will simple be able to use options for communication between players and their play environment. There are things that, if you're going to do multiplayer, you need to have. Individual game developers shouldn't be struggling what that. They should be supported by features in the tools they use.

Things like all of the above, at least taken one at a time, are not big projects for me. They're just added features to an already existing server and some of it can depend on work I've already done in the HLL framework. So, how long it will take me to add these things depends entirely on how long the list of "necessities" turns out to be.

I've recognized however that many C2 developers have never built a multiplayer game, and since WebSockets are new, there needs to be some education and training, along with demos.

My greatest concern at this point is that a lot of work can pile up and easily overwhelm an individual developer (me). I know from experience that it's true, and I want to stay focused in order to deliver a high quality server + server-side tools and framework; giving the best product possible. Besides the need for demos and training, there is an apparent interest in a subscription service ... i.e. someone running the servers so that developers simply upload their code and run it, rather than setting up their own or having one or more game players install servers on their machines. (I don't think the idea is totally impractical btw).

So I want to be very clear that I'm interested in finding collaborators and even partners. Anybody out there want to run a subscription service? Do you want to be an early adopter and produce a game together?

On my personal idea platform level 1, I want to support easy to use logic on the server (event -> communication action), perhaps with some nice extra features. It's obvious that when one player clicks to move, the other players need to know about it and I believe there should be a well thought out sync mechanism to ensure that results look the same on all screens. I mean, if a player pushes the right arrow twice and moves to the center of the screen, his character should end up in the center of the screen everywhere. I've also had some thoughts rolling around in my mind regarding timing issues. I think I should include some mechanism to allow results, like a cannon ball reaching its target, happen at very close to the same time on every screen.

I think the demos are going to be important. If it's up to me, I'm going to stay away from things that require rapid split second timing. There is a huge range of possibilities for other kinds of multiplayer games that do not require it. A sluggish, slow moving cannon ball doesn't seem like a problem to me. Ordering troops into a fight is easy as long as you don't focus on individuals battling with swords where the timing of each blow is critical. WebSockets are even good for games in which players take turns.

OK, so that was a long answer that I'm not sure answered your question. I don't believe a tool should restrict creativity. Building the tool, isn't building the application. Above, I've chatted a bit about the early days of the HLL WebSocket Server and game support; focused on ease of use and basic requirements for game support.

Game builders build games, but I believe demos are critical. If there can be some good ... build this type of game this way ... demos and tutorials, it would help game builders get a good rapid start.

Now that I'm slightly more awake ? we were talking about cheaters and what they might be able to do in their own local environments. I think we might be moving forward on that question inch by inch, but we both seem to be asking questions back and forth at each other.

I don't know yet whether people can do, in C2, what has been described. I believe it is possible to deny access ? i.e. not allow anyone to manipulate what's going on in the browser code. If C2 denies access, then C2 covers that problem already.

Here's my current thoughts:

I think it's a terrible idea to continuously pass position or more generally state information and simply rely on that. I think it's a terrible idea for more than one reason. Outside of the cheat problem, it requires much more data to be passed than is needed and it builds latency problems. I would like to see more reliance on passing commands linked to behaviors that are defined by the game. That means each players UI code already knows how to handle the commands it receives. At the max. end of that, behaviors can be passed in real-time (but you don't have to ? it's something that seems like an interesting idea to me). Passing in new behavior can for example, be used when players go to a new level (and I have some other ideas). This may also make it more difficult for cheaters.

It can be done in a way that manipulating data would only confuse the cheater. Implementing that is down the line for me and I'm not even sure yet whether it can be a built in server feature or something that needs to be covered in tutorials for game builders.

One of the favorite cheats in some mmo pseudo-rt games is to set up robots that automatically do things. When the game logic is simple, it can be relatively easy to do. If you're building something, you go to the documentation and find the building schedule. Then you build a robot that automatically logs in and initiates the next building level as soon as the last one finishes. You might need wine in all your towns to keep villagers happy, but only produce wine in one town. So, you might want to automate shipping wine to nonproducing towns. Other players might not even notice the difference, let alone be irritated by it. How do they even know that the guy didn't wake up at 2 in the morning to click on the building to upgrade? It can be more irritating if someone automatically detects war ships on the way to their towns and recieves notification via text message.

On the other hand, mmo game companies may provide an option to buy automated services. Maybe you can get the commodity used to buy these services free, but that's not easy and you don't get much. So there's an option to buy more of that commodity with real money and that's in the overall strategy for the company to make money. So, companies running mmo systems define such robots as against the rules, code to defeat the behavior, and look for ways to detect it and boot people for doing it. Lots of people don't do it to begin with of course (which means money is still coming in) and mmos have gotten pretty good at defeating it. Anybody who wants to set up and run mmo games to make money that way should be aware and even thinking about that as the game is developed.

I also have an idea for people who are particularly driven to build such things as automated cheats ? pitting them against each other in a type of game that relies on those skills.