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?

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.

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.

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

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.