rogerfgay's Forum Posts

  • BTW: Just now, I'm seeing about a 50ms latency on http fetches between two different cities in Sweden. That's about 20 times faster than the human eye can process imagery (Wikipedia). It's under 10 times faster than film refresh rates in the later half of the 20th century and somewhere around half that (still faster) than TV, which was synced with electric power cycles (50-60 per second).

    In 50ms, a real life bullet will travel 3-25 feet.

    But since you've all spent time on computers and the Internet, you know that you're not always getting what is possible. Switching protocols doesn't solve that problem. Still though, there's a great deal of potential fun. :)

  • And now I'm also considering the business model and who / where / how servers will be installed.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Not sure I've been perfectly clear about everything. I think game exchanges should be command driven, not by constantly updating the state of each character. Even holding down an arrow key can be done with "left down" and "left up" or "left" and "stop left" for example. I believe that there does need to be some basic synchronization supported by the server as well as a simple way to deal with latency. But that's a far cry from putting all the game logic on the server.

    RE: Cheat ... teleporting as an example. If there is no teleporting command in the game, you won't be able to teleport in the multiplayer world. If someone finds a way to change their local position, it won't show up on any other player's screen. It will just leave the cheater confused.

    I'd like to see good responsiveness, but until the activity is making huge bucks, I don't think I'll start an R&D project on the cutting edge of Internet connection speeds. I'm comforted by the fact that photon torpedoes can take as much as 15 seconds or so to reach their targets in Star Trek movies. Cool effect. Why wouldn't you want to see the photon torpedo run its course? With everything from sluggish goofy old canons and catapults to futuristic energy blasters (I've seen it in games already), it's possible to use projectiles that take at least a few seconds to reach their target. And that's more than enough time to sync up.

    If the game does larger troop movements, it can take a second or two for ground commanders to respond to the player. I'm not saying that's technically required, just saying it wouldn't be bad to design the game as such. Player / general orders swordsmen to attack the flanks - couple seconds later, acknowledgment from the ground commander. Humans are like that. Why should it not be so in the game? (This can also work if you're giving instructions to an individual character rather than directly remote-controlling it; although I'd have to think more about a game in which that's interesting to do.) It then takes time for the group of swordsmen to move in and fight ... lots and lots of time for sync.

    That's just a couple of examples. There might also be some good examples for extremely rapid action play, but I'm just not treating conservative / safe action as what I'm after right now. I'm not against rapid interaction, you understand. And maybe somewhere during the development of what I've described, I'll see an opening, or at least be set for some preliminary timing tests. As I start out though, I don't want to lead game builders astray. I'd rather advise them to do things that we know will work. For those who have the time and interest, ok, they can test the outer limits if they want to. I'm just not going to push someone who just wants to get a good game on the market into doing experiments. I think that's part of responsible support.

    And once again ... My WebSocket server is fast, very fast, but WebSockets don't make data move faster over the Internet.

  • Interesting question has come to mind from the discussions. Surely, there can be no doubt that I need to provide good support for game developers, making it easy to build the games. But who's my target market?

    If what game builders are saying is that they need a subscription service, so that all they need to do is upload their games; maybe I'm looking mostly for people who want to set up and run a subscription service: Either that or someone who wants to run mmo games ... either way ... someone who's interested in running servers.

    A lot of independent game developers aren't interested in doing that.

    Some might be.

  • Christian verses Flying Spaghetti Monster - HTML 5 Games, WebSockets, and AI

    Demos using WebSockets: highlevellogic.blogspot.se/2013/09/christian-verses-flying-spaghetti.html

    Free WebSocket JavaScript Code and Tutorial

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

    I've done one proof of concept experiment so far using C2; controlling the sprite via commands from the HLL WebSocket server. Further discussion on the C2 forum at: scirra.com/forum/topic75532.html

  • Let me follow up to the already mounting commentary I've given in the past couple of hours. I'm sure you will all enjoy the book when it comes out. LOL!

    Grain of salt on having all the logic in the browsers. What I have in mind, game developers will be able to decide how much logic is on the server. I think the details will become clearer as I implement, even for me. I'm not at this point, considering running a game loop on the server. I suppose that's possible, and might be a consideration at some point. But phase 1 anyways ... it'll just act like a good and proper server.

  • That's fantastic. You'll find my email address in the upper right hand corner of my blog ... highlevellogic.blogspot.se

    Not sure if I can use a C2 language exactly. Is that patented or copyright protected? Or, is it ok if it's like a C2 plug-in? But wait, I'm not planning to restrict development to C2 at this point. I don't have a business deal with the C2 people or anything.

    I think the C2 tools and approach to allowing game developers without programming skills to build games is the thing I'm after. C2 isn't the only tool that does it. The idea is fairly generic. Plugging in actions related to events ("event sheets") is just a simple interface away from the XML form (which C2 and others also have).

    I've done a simple proof of concept using the HLL WebSocket Server with C2. It was very simple with a single sprite. I'm imagining that C2 can have independent characters, but don't know that. If characters can be independently controlled, I think it's already possible to build multiplayer games.

  • Now that I'm slightly more awake ? we were talking about cheaters and what they might be able to do in their own local environments. I think we might be moving forward on that question inch by inch, but we both seem to be asking questions back and forth at each other.

    I don't know yet whether people can do, in C2, what has been described. I believe it is possible to deny access ? i.e. not allow anyone to manipulate what's going on in the browser code. If C2 denies access, then C2 covers that problem already.

    Here's my current thoughts:

    I think it's a terrible idea to continuously pass position or more generally state information and simply rely on that. I think it's a terrible idea for more than one reason. Outside of the cheat problem, it requires much more data to be passed than is needed and it builds latency problems. I would like to see more reliance on passing commands linked to behaviors that are defined by the game. That means each players UI code already knows how to handle the commands it receives. At the max. end of that, behaviors can be passed in real-time (but you don't have to ? it's something that seems like an interesting idea to me). Passing in new behavior can for example, be used when players go to a new level (and I have some other ideas). This may also make it more difficult for cheaters.

    It can be done in a way that manipulating data would only confuse the cheater. Implementing that is down the line for me and I'm not even sure yet whether it can be a built in server feature or something that needs to be covered in tutorials for game builders.

    One of the favorite cheats in some mmo pseudo-rt games is to set up robots that automatically do things. When the game logic is simple, it can be relatively easy to do. If you're building something, you go to the documentation and find the building schedule. Then you build a robot that automatically logs in and initiates the next building level as soon as the last one finishes. You might need wine in all your towns to keep villagers happy, but only produce wine in one town. So, you might want to automate shipping wine to nonproducing towns. Other players might not even notice the difference, let alone be irritated by it. How do they even know that the guy didn't wake up at 2 in the morning to click on the building to upgrade? It can be more irritating if someone automatically detects war ships on the way to their towns and recieves notification via text message.

    On the other hand, mmo game companies may provide an option to buy automated services. Maybe you can get the commodity used to buy these services free, but that's not easy and you don't get much. So there's an option to buy more of that commodity with real money and that's in the overall strategy for the company to make money. So, companies running mmo systems define such robots as against the rules, code to defeat the behavior, and look for ways to detect it and boot people for doing it. Lots of people don't do it to begin with of course (which means money is still coming in) and mmos have gotten pretty good at defeating it. Anybody who wants to set up and run mmo games to make money that way should be aware and even thinking about that as the game is developed.

    I also have an idea for people who are particularly driven to build such things as automated cheats ? pitting them against each other in a type of game that relies on those skills.

  • OK, so that was a long answer that I'm not sure answered your question. I don't believe a tool should restrict creativity. Building the tool, isn't building the application. Above, I've chatted a bit about the early days of the HLL WebSocket Server and game support; focused on ease of use and basic requirements for game support.

    Game builders build games, but I believe demos are critical. If there can be some good ... build this type of game this way ... demos and tutorials, it would help game builders get a good rapid start.

  • It's early in the morning and I'm just working through my first coffee. Started a response and realized I was really saying what we already know. At first I thought maybe I should just come back later. But since I came here to learn, and have been learning, it seems about time I summarize a bit and organize my thoughts anyway. It seems I have some basic things written in soft stone already and it's time to jump up to the next platform, so to speak.

    As a server / back-end framework developer, it's my task to provide options in a way that application developers can and will be willing to use. It seems to me that it's essential to allow game developers to continue to use their current tools, like C2. C2 allows game developers to put all their game logic in the front end. My first focus is on setting up the server side so that game creators can create server-side application logic in much the same way they build game logic in C2.

    Before first release however, there are some other things that need to be done. I think the server should already support logins and managing groups for example. These are examples of basic server tasks that are beyond simple proof of concept demos and into real-world necessity. Game developers will simple be able to use options for communication between players and their play environment. There are things that, if you're going to do multiplayer, you need to have. Individual game developers shouldn't be struggling what that. They should be supported by features in the tools they use.

    Things like all of the above, at least taken one at a time, are not big projects for me. They're just added features to an already existing server and some of it can depend on work I've already done in the HLL framework. So, how long it will take me to add these things depends entirely on how long the list of "necessities" turns out to be.

    I've recognized however that many C2 developers have never built a multiplayer game, and since WebSockets are new, there needs to be some education and training, along with demos.

    My greatest concern at this point is that a lot of work can pile up and easily overwhelm an individual developer (me). I know from experience that it's true, and I want to stay focused in order to deliver a high quality server + server-side tools and framework; giving the best product possible. Besides the need for demos and training, there is an apparent interest in a subscription service ... i.e. someone running the servers so that developers simply upload their code and run it, rather than setting up their own or having one or more game players install servers on their machines. (I don't think the idea is totally impractical btw).

    So I want to be very clear that I'm interested in finding collaborators and even partners. Anybody out there want to run a subscription service? Do you want to be an early adopter and produce a game together?

    On my personal idea platform level 1, I want to support easy to use logic on the server (event -> communication action), perhaps with some nice extra features. It's obvious that when one player clicks to move, the other players need to know about it and I believe there should be a well thought out sync mechanism to ensure that results look the same on all screens. I mean, if a player pushes the right arrow twice and moves to the center of the screen, his character should end up in the center of the screen everywhere. I've also had some thoughts rolling around in my mind regarding timing issues. I think I should include some mechanism to allow results, like a cannon ball reaching its target, happen at very close to the same time on every screen.

    I think the demos are going to be important. If it's up to me, I'm going to stay away from things that require rapid split second timing. There is a huge range of possibilities for other kinds of multiplayer games that do not require it. A sluggish, slow moving cannon ball doesn't seem like a problem to me. Ordering troops into a fight is easy as long as you don't focus on individuals battling with swords where the timing of each blow is critical. WebSockets are even good for games in which players take turns.

  • I'm not entirely convinced that all the logic has to be on the server. I'm trying to ask some questions about that. Security issues are not unique to games and I've dealt with some things effectively. I'm not saying there's no possibility. I just need to confirm. Sometimes the "common wisdom" isn't all it's cracked up to be.

    It might be possible to deny access effectively to begin with. But as I said before, changing what's going on in one's browser, doesn't mean it's going to change what's going on in everyone else's browser, or what the server thinks is going on. The way I imagine the interactions would work, it would just cause confusion for the player trying to cheat. She would lose track of what's really going on.

    But back on that point of denying access to begin with. Such things are possible. I'm wondering if anyone's tried to cheat a C2 game? That seems important in the context of this forum which is about C2.

  • Word of warning, players will use cheats and spoofs if you do too much game logic or persistent data storage client side. In your example I could use Cheat Engine to hack the memory address for player position and perform teleport-like movement around the map.

    There are also various cheats and spoofs used on other commercial sites, so I'm wondering if this is done in a way that I already understand and am prepared to deal with. After sleeping on it, I am also wondering if such a trick would just leave the cheating player yelling "I won, I won." and everybody else in the game saying "No you didn't" because the behavior would only be seen on the cheater's screen. Anyway, I'd like to look into this, this weekend.

    What I'd like to know, if you've tried, is whether these things are problems in games built with C2? My security strategies are implemented in my own code of course.

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