Thanks for the comments Rushino. Although I don't use C# myself, you've set me to thinking.

From what I gather, free educational-use Microsoft tools are used in schools quite a bit and C# is one of the languages students use. So, there are a lot of people who have learned it and are used to it. The HLL framework was written with the idea that people can build app components in any language. I have a free C# compiler on my dev machine which I guess still works (although I've updated .NET since I got it ... so long ago). I'll put doing a short demo on my to-do list.

I can see that JSON is a plus. I used to be against JSON and typically am against any non-native browser extensions, like jQuery, which I regard as bloat-ware. I could always provide the exact same support in native JavaScript, even allowing JSON standard messaging. People who got used to the frameworks also never seemed to realize that you could do the same things in JavaScript. But JSON is now native to all major browsers, so it kind of doesn't matter how I implement it. Sure, no problem sending JSON into the game ... none at all ... I don't even have any theological problems with it. :)

I have some ideas for providing a very powerful, but very easy way to program the server-side logic.

Christian verse Flying Spaghetti Monster

highlevellogic.blogspot.se/2013/09/christian-verses-flying-spaghetti.html

ArcadEd: That's great! I think a good demo would be good advertising / PR for all involved. And anyone who helps by building a demo to use the WebSocket server gets a start on using it, which can be turned into something real. I'll try to contain myself from dumping a long load of ideas at this point. I always think ahead and have this tendency to do that ... which scares people. :)

I'll just remain calm at this point and express appreciation for any help I can get. You can even find my email address on my blog.

blog: highlevellogic.blogspot.se

And I should be able to give my email address: rogerfgaygst@yahoo.com

IronRick: I can't quite tell from the reading whether or not signalr provides a real WebSocket server. I suppose it's just because I'm so far into the detail on WebSockets that I see the ambiguity in their description. I'm not sure it matters to anyone else though, and I'm not really here to judge that. What I can agree with is the need for a fall-back if you're looking to capture every current browser and the widest audience.

I had kind-of considered doing WebSockets only along with HTML 5 games ... my way of starting out small by having a focused market; keeping the technology within a boundary. HTML 5 support is getting pretty good and it won't be long before WebSockets are supported all around too. It's not like it was 2 years ago when I first put up my WebSocket demo.

But it all depends on collaboration, and what my collaborators want. It's too much for me to try to do everything ... so I don't really want to develop games. Working on the technology that I have, and supporting it for game developers to use is a lot of work. And I'm not an artist either. On the other hand, now that I've built something from scratch, I can see that I will be able to make this technology very easy for game developers to use.

I have a gateway on top of my WebSocket server that currently only branches between ws and http. That can easily be used to fall back to either long-polling or forever frames. I've done both work arounds as part of HLL development. This creates a better solution, IMO. It looks like the Microsoft technology signalr ties you to Microsoft technology, IIS, which is the general concern I expressed above re: use of Microsoft technology.

There are others out there who had been nagging about having WebSocket support with the Apache Tomcat server. I wrote this article about it back in January.

highlevellogic.blogspot.se/2013/01/websockets-with-apache-tomcat-and-hll.html

As you can see, I think that idea of tying WebSocket support to any http server looks like a misunderstanding re: WebSockets. I think the gateway is a better idea because it lets you use any http server that you want, completely independently. The gateway can reroute to your choice of server. With the right set-up, it would only need to do this once at most, and possibly not at all. Or, quite frankly, I can build enough of an http server to use the same app handler as the WebSocket ... so build your server side app logic once, and use it whether ws is supported or the fall back is being used.

Interesting comments. I've been interested in bidirectional communication with browsers for many years. The HLL framework has the capability and was built before the WebSocket standard was complete. It might be a good idea to use what it has as a fall-back for browsers that do not support WebSockets yet. (It even works with old Microsoft browsers.) Making use of the framework would bring a variety of other capabilities to the table and more ease of development features.

I had definitely figured on including registration features that would allow users to play in their own defined groups.

IronRick: I'd never heard of SignalR. A quick google and what I read suggests it provides a Microsoft bound approach to the browser side of WebSockets. Do they actually have a server? Do you have a link?

I agree with you Rushino. Personally, I've stayed completely away from Microsoft technology. Not only is C# not an inviting dev. approach for many game developers, but Microsoft based cell phones only have about 5-7% share of the market. The Microsoft approach often limits the options to require Microsoft technology, which really defeats the whole purpose of a standard to begin with.

Very few actual compliant WebSocket standard servers have been built, even up to now. It's quite an undertaking. Do you have a demo site for your server?

Thanks phuse. It's nice to see some interest. Someone did help me and I got a simple demo going using the free version of Construct 2 ... so, proof of concept. I guess my last post explains that.

Since last I posted, I've started building a demo game from scratch. It's getting pretty close and I expect to unveil it in my blog next week. I'm sure people with game development experience could build a more interesting game with better graphics, but it's a good learning experience for me at the very least. I'm feeling slightly less like a newbie to the game world every day.

highlevellogic.blogspot.se

Seems to work for me. :)

How hard is it to connect my websocket server to Construct 2?

OK, after spending a 3 day weekend on it: The answer is that the very simple app that I built would have been really easy had I understood Construct 2 to begin with. I was lucky to find someone helpful in the forum to get some hints on how to start. This was actually my first time using a "no programming" game development system. (I could have done it in under and hour if I had programmed from scratch.)

Now, it would be great to work with someone who has much more experience with Construct 2 to put together a series of trials / examples for controlling actions in response to input. "No programming" approaches often have limitations, but there does seem to be hope for Construct 2. It's even possible to build addons to extend the system and maybe that would be needed to support sophisticated behavior control via text commands. I don't know. That seems like the next question.

This has been partially completed.

Websocket connection is made.

Websocket messages are sent in response to key input.

Websocket messages are received from the server.

Simple movement of a sprite occurs in response to the message input.

I still have very little experience with Capture 2 at this point, but this is an initial proof of concept. However, what I've learned to do so far, simply using the normal game development tool, seems kind of weak. I'm still looking for a better way to grab relevant event data and use it to trigger actions on the receiving end.

Maybe I just need more experience using the tool to build Event Sheets; but at this point I'm wondering if using the JavaScript SDK is a better route to take.

Life is hard when you're a beginner, as I am with Construct 2. Programming this in JavaScript would have been a lot easier for me so far with much better results. But I don't want to make the judgment so quickly, while I'm just a newbie.

Any opinions?

TCP is the problem. By hanging I mean all transmission was held up, so remote players stopped moving. It's the OS waiting for a dropped packet to be retransmitted.

WebRTC supports DataChannels, allowing arbitrary data (not just media) to be transmitted, and can use a UDP-based transport as well.

I've just got to say that this seems like a problem on the app development side. Asynchronous communication has been all the rage for over a decade. If you do not receive something, you'll still get the next thing. There is no hang up waiting for something to come in.

WebSockets use event handlers for incoming messages. The app doesn't wait for a message. It just processes it when it comes in. That means your app can handle lossy transmission; even though TCP is reliable, which is also what you want in a game. I don't even know how it would know that a message from another player was coming. So I don't see how, even if you tried to design it to get stuck, it could know when it was supposed to get stuck.

The sticker is transmission time over the Internet, and that can't be controlled by the transmission protocol.