rogerfgay's Forum Posts

  • 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.

  • Free WebSocket JavaScript Code and Tutorial

    By Roger F. Gay

    highlevellogic.blogspot.se/2013/09/free-websocket-javascript-code-and.html

  • WebSockets are already pretty secure. You have to go through a "handshake" process to make a connection. Then that's your connection. Hackability is more of a systems issue. I've seen pretty good coverage on standard packages and routers, even giving specific information when someone tries to get in in the wrong way. Other things are application specific, such as when you take user input in forms to stash in a database ... easily dealt with. I've been all through this, in gory detail, while doing commercial webshops.

    "Server flooding" sounds like a more innocent version of "denial of service" attacks. Yes, you'd definitely want to provide enough server power to run whatever is supposed to run. That might be a more reasonable description for a solution, rather than restricting legitimate traffic. It's also something to be considered on the economic side of things .. how much power is needed ... what's it going to cost to have big enough, or as many servers as needed?

  • I'm not of the Node.js world, so this is taking a bit of looking around to catch on. NPM is a JavaScript helper library ... how it's described on a page I just found listing what it has. npmjs.org

    Obviously, I haven't tried out any of the packages. But it's an interesting idea. Some of the things mentioned ... I just thought I'd cover by having it standard kit in the game support server side; like registration, and there will definitely be messages passed back and forth. In addition, there needs to be a mechanism for pairing players in multiplayer games. I don't expect the developer to need to build that from scratch, but they will be able to customize in some way I expect.

    I'm a great believer in examples and tutorials as well, and hope to have the time to do that ... and hope people who use it will write how tos. Maybe that should be part of the deal with early free adoption - the Alpha group.

    I should be making a list of what needs to be supported as an outgrowth of this thread. I tend to do all that in my head when I'm working alone. I think you mentioned reading files. You can certainly send files via WebSockets or can fetch them using Ajax. So, I'm not sure what you need other than the WebSocket message or Ajax code. Would it be sufficient to provide that in a "package", or do you have something fancier in mind?

  • I can't figure out whether it's way out of date old, days before Chrome, Mozilla etc. etc all have HTML 5 built in, or maybe just because Node.js is JS. It could be the latter. Despite the fact that Node.js has the advantage of being in JS and thus finds an audience in front-end developers, it also has the disadvantage of being in JS; which limits its capabilities.

    I think I'm going to be ok giving developers the opportunity to write back-end application logic in JS; but then I'll also have the advantage of execution within Java running on the server ... so, I don't have to work around the limitations. They won't exist.

  • I don't see why no ones using Node-Webkit.

    You could introduce a npm package via the plugin sdk, and write all your server side logic in Construct.

    Interesting. I'm going to try to imagine how it might be useful in my work. It's not WebSockets though ... just to make sure we're on the same page; and the only page I read was the C2 intro. scirra.com/manual/162/node-webkit

    It says it uses Ajax (asynchronous http) to read files from the application folder.

    Actually though ... I can set up the HLL WebSocket server to get files as well. .... OK, brain cooking ... I wonder if it could be interesting to also give the WebSocket server the ability to fetch files from your C2 subscription application folders? ....

    Well ... What would you like to do with it?

  • I might as well go ahead and promote HLL XML processing a little. I'm going to adapt something that I developed in the framework. The idea was that the HLL development system supports a very powerful way to "configure" applications. I have quotes around "configure" just to add emphasis. Configuration becomes a more important part of developing end applications ... reuse of components. Kind of a next step beyond SOA, might be one way to put it.

    I think it's ripe for supporting development the way C2 does it, more or less. I'll see if I have time for a simple HTML interface for creating back-end logic this weekend. Not sure I'll have time for that step by Monday, but ... maybe a very simple version.

  • Being a tool builder and with my love for pushing beyond the cutting edge might give me a different perspective. But you've reminded me that is exactly what I have to keep in mind. I actually know this, but when focused on things I'm doing, I'm also focused on my own development approach. In the end, a "product" must appeal to its users and their preferences. You're not the first to mention that you use C# in app development.

    I'm hoping a lot of this won't take too long. I've done the core of the really big work already. WebSocket server in hand, it's now down to features aimed to support game development. So ... not being in the top spot on my to-do list shouldn't be terribly important. I think my to-do for language support looks like this:

    1: XML supporting arbitrary command language

    2. JavaScript for server logic

    3. C/C++/C# extensions

    Unless something pops-up and takes over my time, I should have XML looking pretty good by Monday. "Arbitrary command language" means a game developer can decide on their own set of messages. Note: JSON isn't on the list because it's supported in the browser and can be used anywhere, messages in the XML for example.

    JavaScript ... I've had this on the list for a long time and it's about time I did something about it. Up to now, all my server-side handlers have been written in Java. The success of Node.js for example, is directly related to the fact that there are a lot of people who know how to program in JavaScript who want to use this sort of technology.

    C/C++/C# can all be addressed with Java's Native Interface (JNI).

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • You can use visual studio 2012 express.Its free! You certainly dont need to buy the pro one plus the express enable commercial use.

    Yes, now I remember. That's what I have. Maybe I should download again since it's been so long. Might be some updates.

  • 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.

  • 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.