Jerorx

Members
  • Content count

    34
  • Joined

  • Last visited

1 Follower

About Jerorx

Contact Methods

  • Website URL
    www.dynetisgames.com
  • Twitter
    jerome_renaux

Profile Information

  • Gender
  • Location
    Belgium

Recent Profile Visitors

597 profile views
  1. From the screenshot it seems to be very nice work, I had completely missed it so far, so when you mentioned it in your issue in Phaser Quest's code I didn't know what you were talking about at the time! However I was only able to check the screenshot, because on my laptop the game doesn't load, regardless of the browser I use; it remains stuck on "creating world ... ". Didn't check on mobile. In any case, I'll feature it in the "related work" section of the Phaser Quest page! PS: It's Jerome, not Jeremy.
  2. Yes good point. I have in mind for future projects to use node-webkit, where UDP-based communication becomes possible, but while we remain in the browser (as is the case with Ensemble), this is indeed not possible. I'll update the post.
  3. Hi, I'd like to present Ensemble, an experiment in crowd design, where players, developers and artists can collaborate to collectively design a browser-based multiplayer online game. This is a very experimental project to see what can emerge from pushing the collaborative aspect of a project to the max. This project is collaborative in the sense that it is the community, and the community only, who decides how the game should evolve. Copied from the page of the game, here is a short description of the three main channels for this process: Suggesting and voting for features. Anyone can make suggestions about a feature to add to the game (with a simple embedded form, without the need to login or anything, no friction). A list of the suggested features (located below the game canvas) allows to vote for or against each of them. On a regular basis, one of the top-ranked features of the moment is selected and implemented. Making Pull Requests. Developers can choose to bypass this process, and directly implement themselves the changes they would like to see in the game. These changes can be submitted through Github pull requests. Pull requests are accepted unconditionally, provided they don’t contain anything inappropriate and work properly. Submitting art. A form is provided to enable artists to send me artwork that they would like to see added to the game, such as sprites or animations. For these as well, submissions are accepted unconditionally. For a more detailed description, as well as links to both the source code and the game itself, I refer you to the main page of the project. At the moment, the "game" consists in moving colored dots around, and dropping white blocks that serve as obstacles. This is still very basic, as only a handful of features have been suggested and implemented yet. You are free to jump in and attempt to shape the evolution of the game! In any case, this could be a valuable learning experience for those: - Interested in learning more about Phaser by experimenting and contributing to an existing project - Interested in learning how to make a multiplayer online game with Node.js and Socket.io (This is why I posted it here and not in the "games showcase" or "Phaser" sections : the game itself is only one part of a bigger experience ; and although the client is made using Phaser, the project involves other technologies of possible interest to a wider audience.) Feedback if welcome of course. Below, a screenshot of what the game looks like at the moment.
  4. Hi, So I have a loop that checks the position of a moving sprite every 100ms. At each iteration, it computes how many milliseconds elapsed since last check (it's normally 100 but it varies a bit), computes the euclidean distance between the current position and the previous one, and compares it to the maximum distance that the sprite could have traveled given its speed and the elpased time. See below: function myFunction(){ // nevermind variables showing up out of nowhere, assume everything global or sth, not the point var currentData = { x: sprite.position.x, y: sprtie.position.y, stamp: Date.now() }; var deltaT = (currentData.stamp - lastData.stamp); var euclideanDistance = Math.floor(Math.sqrt(Math.pow(lastData.x - currentData.x, 2) + Math.pow(lastData.y - currentData.y, 2))); var maxDistance = Math.ceil(shipSpeed * (deltaT / 1000)); if(euclideanDistance > maxDistance) console.log('alert!'); lastData = currentData; // it's actually cloned, but that's not the point } The velocity of the sprite is set in the update loop using: game.physics.arcade.velocityFromAngle(angle, shipSpeed, Game.playerSprite.body.velocity); (based on the key pressed, the angle is computed, and from the angle, the velocity). My understanding of velocity in Phaser is that it should remain the same and that it's adjusted for the frame rate, therefore the distance traveled per millisecond should remain the same. This is actually the case most of the time in normal conditions. But when I run this in my laggy Firefox, very often do I get values for `euclideanDistance` that exceed the `maxDistance`, sometimes by as much as 5. Even though I ceil() the maxdistance and floor() the euclideanDistance, to avoid mismatches of 1 or 2 pixels. For concrete values, the value of shipSpeed is 250. In 100ms it is supposed to travel a distance of 25, yet I regularly get 29 for example. (Btw my function doesn't often ticks at 100ms, the deltaTime is often as low as 83 ms or as high as 105ms, but that's plainly explainable by lag I guess.) Therefore it seems that the lag and variations in FPS affect the distance traveled, but not systematically. It's a bit puzzling. Or is it something else? Am I computing my variables wrong? Am I missing misunderstanding something about the physics? Any idea about an explanation and, possibly, a fix, to enforce that the distance traveled is always the same, down to the pixel, no matter what?
  5. I'm adding Phaser Quest to the list, a top-down real-time multiplayer adventure made with Phaser and Socket.io. Explore the map, find better equipment, fight monsters and defeat the final boss, alone or with friends! It was for me a practice project, and is a reproduction of Mozilla's Browserquest. If you click on the link, you'll find further details, including a link to the game, a link to the source code and a listing of the libraries I used. For more screenshots, I think Rich has done an amazing jobs at taking a few that capture the game experience, you can see them in his post about Phaser Quest. Thanks a ton by the way!
  6. @samme It wasn't, but I just added it now because it's a nice idea @NicoA Yes, it's a strange behavior of the input plugin. To be honest I didn't put a lot of effort into the mobile aspect, because I considered it only at the end, and I should have thought more about it since the beginning (because it's not only a matter of scaling and a few lines of Phaser code, ideally the whole game interface has to adapt depending on the device size). It's a good lesson actually. Because of this I didn't really investigate this strange behavior yet. I may do it in the near future!
  7. I remade it with Phaser indeed. For Browserquest, they did it from scratch.
  8. @spinnerbox I have edited my first post to add a link to it.
  9. I'm happy to present to you Phaser Quest, a top-down real-time multiplayer adventure made with Phaser and Socket.io. Explore the map, find better equipment, fight monsters and defeat the final boss, alone or with friends! It was for me a practice project, and is a reproduction of Mozilla's Browserquest. Hopefully the source code will interest you, as the project integrates of a lot of Phaser features together (such as tiled maps, text input, tweens, animations, sound, click handling, camera management, etc.), as well as pathfinding using Easystar.js. It is also an example of how a Phaser client can be made to interact with a Node.js server using Socket.io. On my website, I have written a few articles about some aspects of the game. They are mostly concerned with networking for the moment. If you'd like me to write an article explaining how I accomplished this or that in the development of this game, feel free to ask, I'm always happy to help. In addition, I'm interested in any feedback you might have, it's always valuable, especially with future multiplayer projects in mind.
  10. Thanks for the pointer to Incheon, didn't know it, looks quite interesting! @kabuto178 Keyboard-controlled movements would typically fall in the "fast-paced games" category, in which case the server would send the player coordinates multiple times per second, and the client would interpolate the sprite's position in-between. This is often done by not rendering the last update, but the one-before-last; this keeps the rendering slightly in the past but allows to cope with latency. Actually, this conversation made me think that I should make another tutorial similar to this one but for keyboard-controlled multiplayer games. That would be a good testing bed and would be useful for the discussion. I'll try to post that relatively soon!
  11. Thanks Eric, I'm sure it could be useful for some projects as well. Maybe more for 3D than 2D projects, where they could be used as textures for environment objects. In any case, that 's a very nice collection and a great contribution, good job!
  12. @kabuto178 The problem would rather be the type and movements and the pace of the action, rather than the real-time aspect. You can have a look at Phaser Quest, which is the multiplayer online game I was referring to in my previous message. Similarly to BrowserQuest, it is designed to be an MMO-like, and the solution I discussed works well for this game. @FakeWizard Good points. Actually, having a tween execute the movement from point A to point B is some form of movement prediction: you assume that the player will follow the indicated trajectory until the end and render it accordingly. The trick is then to make sure that the timing of this rendering is correct! Did you know that Blizzard's World of Warcraft uses TCP? It's true that UDP is often recommended for online games, but UDP and TCP both have pros and cons, and some AAA MMO's do use TCP apparently. I don't have a reference available here but I can try to post one later. Indeed, to handle very big loads and scale well, eventually the back-end architecture has to change, even from the hardware point of view. Thanks for the pointer to SocketCluster. I still have some margin before any of my projects gather enough traffic that such improvements are necessary, so I admit I haven't looked into much of that yet, but you are right: eventually, any serious MMO project will have to resort to that.
  13. @kabuto178 : I invite you to have a look at the source code, and more particularly at client.js, which processes the messages from the server, and game.js, which contains the Phaser code. When a new player connects, the server sends the message 'newplayer' to all clients, along with the id and coordinates of the new player. This is handled in client.js by Client.socket.on('newplayer',function(data){ Game.addNewPlayer(data.id,data.x,data.y); }); In game.js, Game.addNewPlayer() is defined : Game.addNewPlayer = function(id,x,y){ Game.playerMap[id] = game.add.sprite(x,y,'sprite'); }; So it boils down to using Phaser's game.add.sprite, using the coordinates sent by the server. (Game.playerMap is a map to organize the sprites by id). Similar methods are used to update the position upon receiving a 'move' event from the server. In client.js: Client.socket.on('move',function(data){ Game.movePlayer(data.id,data.x,data.y); }); And in game.js: Game.movePlayer = function(id,x,y){ var player = Game.playerMap[id]; var distance = Phaser.Math.distance(player.x,player.y,x,y); var tween = game.add.tween(player); var duration = distance*10; tween.to({x:x,y:y}, duration); tween.start(); }; Where a basic tween is used to move the sprite. Let me know if this is helpful or not. @FakeWizard: this is a good point indeed. Actually, I had to solve that problem for a game I just finished, which I will release in a few days. I'm also currently writing an article with a section precisely about this, which should come out at the same time. Both will be published on the same website as this tutorial. The first solution I used was the one you mention, by associating timestamps to movements. But it turned out to be a bit problematic, because timestamps are not universal, they can vary wildly from one machine to another (if you can, open a browser on two different computers side by side, and in the console type console.log(Date.now()); you should see different values). It worked as long as I was testing on my machine, but once online it broke down. I ended up simplifying this, and instead of using the timestamps, I only used the latency of the clients, which is the key factor here. Once you keep track of the latency, you can use it as follows: Player A sends message telling server that he's moving to pos.x , pos.y (In my implementation, since the environment is fixed, A doesn't have to wait the response from the server to move ; it moves immediately, and will be adjusted only if the server replies that the move was illegal, which can happen only by attempting to cheat. It makes the game more responsive but doesn't change your point.) Server receives the message X ms later. The server has an estimate of X (= latency of player A) and stores it along the move request. Server broadcasts the information to all connected clients; to each, it sends the information that A has moved, along with the latency X of A, + the latency Y, Z, etc. of each receiving client Player B receives the message K ms later. If we consider that X was the latency of player A, and Y is the latency of player B, K = X + Y. The values of X and Y are estimated by the server and sent along the movement messages, so they are known by the client when he has to update position. Now, the position update is likely not instantaneous, to be smooth you are likely to use a tween or something. The duration of the tween can be adjusted to compensate for the delay K. If K is 150ms and the tween is supposed to last 400ms, the tween will end up lasting only 250ms, to make sure that on the screens of the two players, A's sprite arrives at his destination roughly at the same time. Typically, such changes in tween duration are not very perceptible; either the tween lasts a long time, and a difference of 150ms will be no difference, either it is short, and the tween will happen too fast anyway for a human observer to really perceive the difference. Let me know what you think of this solution, I'm interested in feedbacks. Out of experience, it worked pretty well for my game in any case. Now if you make a fast-paced game such as an FPS or a MOBA, where very fast, short movements happen a lot, this solution might not be the best one (although with 200ms latency, players will be screwed no matter what in that kind of games). Dedicated solutions exist for this kind of games, but it's always relatively tricky and ad hoc. If you use Twitter, I invite you to follow me to get notified when I release the article about this problem, it should interest you. If not, I'll notify you through here.
  14. Hi, I've been working on multiplayer online experiences with Phaser, Node.js and Socket.io recently. I thought that it might be interesting to make a tutorial detailing how to make a very basic multiplayer game with these tools, so here it is : How to make a multiplayer online game with Phaser, Socket.io and Node.js . As I said, the game (which can be played here) is very very basic: you click on the small map and your character moves to where you clicked. The movements of the other players (if any) are displayed in real-time. No animations or collisions or whatever, the focus is on the networking aspect. Feedback is more than welcome, as this is my first tutorial ever. If you find it interesting and would like me to make follow-up tutorials on some aspects, don't hesitate to ask! Jérôme
  15. Ok I made some progresses based on what was mentioned here, but here is where I'm stuck now. The end goal is to be able to offer to the players very, very big maps, and to do so efficiently. That's why I try to draw only the relevant parts of the maps (or "chunks" in the procedural terminology). The big problem about performance are the layers; very big layers, even with no tiles, will make the game extremely slow. Therefore, it is NOT an option to start with a huge layer and draw to it (using putTile() for example) as the game goes. I have to start with a small layer, and then expand it gradually. But I don't seem to find any way to change the size of the render area of a layer after creation. If I create a layer of size 20 tiles * 20 tiles, I can putTile() wherever in that area; but if I try to putTile() outside of these coordinates (at 21,21 for example), it obviously doesn't work, no matter how I mess with the layer properties (I tried resize(), I tried to change the dimensions of the layer.data object which holds the tiles, etc. but to no avail). (NB: I would also need to do the opposite, that is shrink the layer to remove the parts that the player has visited and left, in order to keep as small layer size at all time. I guess if you can do one you can do both.) I may not be doing it the right way, and I suspect I would need to dig into the underlying Pixi stuff, but I'm not familiar with this at all so any hints would be appreciated.