rogerfgay's Forum Posts

  • 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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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

  • Mozilla Launches Online Game Using HTML5, WebSockets

    tomshardware.com/news/Mozilla-WebSocket-HTML5-BrowserQuest-MMOG,15136.html

  • So, my next question is: How does the HTML 5 page work? c2runtime is rather small. Does that load and provide all the needed support? Even for the webocket calls? Or does anyone who uses this have to have a game engine installed first?

  • Now I've even exported to HTML 5 and put it on my dev system's server. Only works when I have the two servers running though. Dev system isn't the same as the demo computer I'm running for the other WebSocket demo ... which is full time.

    Arrows cause movement but do nothing with websocket. czsx send r, l, u, d websocket commands which are returned as JSON strings. You get approx. the same movement with both.

    isr.servequake.com/WSGameTest

  • Yeah you can either have the server send a 0 after x amount of time, or have the client do it.

    Of course if the client does it you run the chance of getting out of sink.

    Then again the ideal method would be to do all the movement on the server, and just update the position data, then all the client would do is interpolate the xys, etc.

    Seems like I always have to think at least twice whenever you post. :)

    I recalculated and kept track of position in a robot control center I built to demo the prototype of the HLL Framework ... at that time using a workaround for websockets since they didn't exist yet. Then passed position information to the browser that controlled an SVG object that moved around in an image of rooms (walls and doors).

    That was ok.

  • Adding a wait in between makes the simple demo more convincing. It's not performing the same operation as the arrow keys. I think that's the core problem here. Anyways ... this may be enough for my very first proof of concept experiment. You're right on track newt ... next step is to think about what it would take to assure things are in sync.

    Whether or not this can work really well can depend on whether I can get a solid understanding of how Construct 2 works and whether I'll be able to perform the operations of the game via server input (if I may think in print by stating the obvious).

    It seems quite oriented to people who don't program so I'm wondering if they're just not going to be interested in sharing any detailed technical information. I know there's an SDK. Maybe that's enough.

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

    So, you've got a command like "move right" and it's hung up in transmission somewhere. How does WebRTC solve that?

  • Yeah you can either have the server send a 0 after x amount of time, or have the client do it.

    Of course if the client does it you run the chance of getting out of sink.

    Then again the ideal method would be to do all the movement on the server, and just update the position data, then all the client would do is interpolate the xys, etc.

    Would rather not try to keep the server in sync with game calculations. It would seem practical if I could just yank the new pos info and send it to the server for distribution.

    In order to make this work really well, maybe I'll have to dive into the SDK and build a plugin. I'd rather not make that decision at this point though ... with so little experience with Construct 2. I'm starting to wonder how cooperative the Scirra team might be if I get all fired up about doing this.

  • Tried initializing dictionary values to 0 and conditioning movement on a value = 1. That in itself still works as above .. continues movement until another key is pressed. Then I added Set &Key& = 0 after the 8Direction simulation in each.

    I can tell that the event is still triggered because the sprite changes shape to indicate direction. But it doesn't move at all now. I'm guessing that the reset happens before the movement occurs and stops the movement.

  • You can add an action to the on start of layout to download the contents of the dictionary as json.

    This is what that string would look like:

    {"c2dictionary":true,"data":{"right":0,"left":0,"up":0,"down":0}}

    So basically you could just concatenate your data with an &:

    {"c2dictionary":true,"data":{&your data&}}

    SUCCESS! of a sort. Had to escape the double quotes to make it work and I apologize for my initial confusion. I've been using JSON like objects for many years without ever calling them JSON or using any special JSON processing objects. They're JavaScript objects. Easy enough to roll my own. :)

    I'm now using czsx for right,left,up, down to send websocket messages. "right" "left" etc. are defined in the dictionary and Key "up" = 0 ... event triggers sprite simulate 8Direction up as per the first suggestion.

    I can use the arrow keys and they work locally but do not send any websocket message. Since I haven't coded for multiplayer (all I'm doing on the server end is sending back a JSON string with right, left or whatever in it) ... using different keys to send the websocket message avoids the infinite looping.

    What I'm getting now though is if I press S for up, for example, the sprite continues moving up until I click another button. I'll start looking. I think maybe there's a way to reset the value or something.