WebSockets: What do you want?

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.

I really hope somebody teams up with you on this ! I've been so surprised to see that the community is so lax about Multiplayer functionality, although I am a little biased as I only started researching Construct 2 to build a Multiplayer game I had though of and have been sorely disappointed ever since.

It's very rare an expert pops up willing to build a plugin, can somebody please please work with this guy !?

Best of luck !

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

phuse, I am currently working on a C2 plug-in that would support the ASP.NET SignalR library. SignalR support websocket but also long polling in case the user's browser does not support websocket.

The server backend would be all C# but the front end can support JavaScript (a Construct 2 plug-in).

So far, I have been able to connect to my SignalR server from C2. I am now looking into connecting into server functions and vice versa.

I will post a new plug-in thread as soon as I do have a working prototype.

Hi there, i am also in websocket development myself. I have done more than 1 year of research in websockets in my previous projects. I have a full C# server backend that is working pretty well with my c2 client i have just done. I think a new plugin is useless because to have full control over your game only sending receiving a message is all you need. Construct2 will only serve as handling thoses queries and represent the state od your game. All the logic must remain on the server. Ive read your first post and what happen basically is that the server only know the positions of players then it broadcast this position over all client. Also keep in mind that security is important factor in all this. You need to validate all the queries sent to the server... even the collision must be server side. I added all thoses security features on the server including login etc.. it work with a sql database foe the data and have full logging features. I am pretty sure something like this would be useful here but its all C# i am not sure if many are familliar with that language. Sorry for grammar errors i am writting off a mobile phone.

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?

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?

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.

rogerfgay Here is the link to the SignalR documentation: asp.net/signalr

SignalR can be deployed on IIS web server or built in as a self-host server on OWIN: owin.org

To enable WebSocket protocol, you will need Windows 8 or server 2012 and IIS 8 setup. You can use SignalR on older OS/IIS but it will then fall back to using long polling instead.

I do agree with your comment on Microsoft C# for game development but since my coding background is on the Microsoft .NET framework for my work, I tend to use it for my server code for personal use as well.

rogerfgay

If you need someone with a bit more C2 experience to help you with testing and building simple apps to test, I would be happy to help in that regard.

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.

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: rogerfgayqlq@yahoo.com

Christian verse Flying Spaghetti Monster

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

rogerfgay

Its a bit hard for me to explain the benefits of the server itself... and sorry i don't have an easy demo i can put on.. the server itself is based on a library so you could check it out yourself its open source (Google SuperWebSocket) but all i can say is that ive never seen something smart like that for years. The dude have very high skills in C# and made probably the best WebSockets server solution in my opinion offcourse but i have experienced for like 1 year and trust me this lib kick ass. The websocket lib he did is based on his tcp lib he made himself (SuperSocket) supporting any protocol you wish. That explain why it wasn't so hard to bring the websocket protocol in it. Its based on it.

But the way it work is amazing.. not only it have the option to use JSON (Your queries in JSON are automatically converted in objects using JSON.NET which make things easily for us) for sending and receiving queries which is a big plus for any Construct 2 creation since all work with JSON because its javascript offcourse. That why i am here btw.. the last client engine i was using was making development way too slow and probably wasn't the best tool for the job. Construct 2 was a revelation to me! But all is modular.. if you want to change how it parse queries.. no problem just create your own class that do this job. All the operations are class based. A class = one operation and the server detect it automatically.. if your query start with the prefix of the command you defined then he know which command to execute and then you have full access to the current session connected, the server, data if you wish, etc. and you can send back a response in JSON to the exact session connected. Plain and simple. You can even plug attributes to commands. Attributes are pieces of logic in C# that is executed on a class or property context. So basically they are executed before the command and after via 2 methods. Man this is pure awesomeness to work with.. do you realize how much fun making a server with this lib is ? You just have to focus on important matter and forget about the networking side of your server.. so you can focus on game logic, login system, security features via the attributes. There even a way to make connection filters.. and plug them. You can hold tiny servers in one server like a port that use SSL and the other standard without SSL. Yes it support SSL secure websocket too. If you guys really interested in making a multiplayer game with WebSockets (Which i really recommand btw.. based on my tests and experience) then you have to check out this library and give it a try. I would have paid easily a lots of money to have such a server but its open source and its not GLP licensed. However, keep in mind that WebSockets are TCP only.. there some support for UDP but its limited the standard way it work is intented to be used as TCP. On a side note, WebSockets are not only for HTML5 games.. i have used them on Android, Desktop, etc. This is basically TCP and is based on a http protocol. Its also simple to work with.

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.