Fricken Hamster

Members
  • Content Count

    54
  • Joined

  • Last visited

About Fricken Hamster

  • Rank
    Advanced Member

Contact Methods

  • Twitter
    @frickenhamster

Recent Profile Visitors

1046 profile views
  1. It seems like you are running the JS to create the phaser game directly on the window. Generally you want run the JS you write on a onload function. Something like this window.onload = function () { game = new Phaser.Game(1000, 800, Phaser.AUTO, 'gameContainer', null, false, true, null); };
  2. If the physics is such an integral part of the gameplay, you might want to look into a lockstep networking method, like that old age of empires article.
  3. 0 is right. Degress go counterclockwise. I read that a lot of rendering engines had it like this because of some implementation in opengl.
  4. Since you're looking to use phaser, node.js would be the best bet. Use a websocket implementation for the server. Since you're using JS for both client and server, you can share some parts of your logic with server and client. This isn't anything you should trust a framework to handle for you. You need to plan it out and work out the problems yourself.
  5. Mean is for your webapp. The game client will likely need to interface with a completely custom server using something like websockets. The server might need to interface with your webapp to keep track of important persistent data.
  6. Another way to optimize data size is to send binary. Then you can take all the booleans and pack them in groups of 8 to make a uint8 using bitwise operations.
  7. UDP makes it fast, but the perceived smoothless is all client masking. TCP nowadays isn't too bad in a lot of places. With a good connection, minimal dropped packets, and not enough data to trigger congestion control, I doubt there would be a noticeable difference between TCP and UDP for a real time game. It does matter for a game like counterstrike because all those factors matter for fast and accurate hit detection and counterstrike is a competitive game. For your example, clientside magic would do a lot more than running on a different transport protocol. I don't see what the point of worrying about 100% compatibility on webRTC is. UDP has never been supported on browsers and probably never will be. webRTC isn't udp, but it supports unreliable delivery. Its the best that we'll get with browsers in the near future, so even your game only works on chrome, its a big step up from anything that was ever possible before. WebRTC support will grow, so it will get better over time. If you wanted real UDP support, you wouldn't be making browser games.
  8. I'm thinking a lot of the laggy feel is solved by other games by a lot of estimation and interpolation on the clientside. In reality, the real game will always look choppy, but the client does a great job of masking it. Theres a pretty good article on how the source engines does it.
  9. I think relative urls would only work if the game is served from the same url. Can you access the image just on your browser? Are your images in a public assets directory, and are you routes correct?
  10. It would probably be a good idea to have the walls server-side nomatter what you do. Say if client put poster A on wall B, you would send that client put A on B at translated location C. You shouldn't need to do translations on the server, since the server is fine knowing only a regular rectangle and the x y position of the poster on it. Validating on the client will probably work fine for this case in a vacuum, but is almost always a bad idea. One possible complication I can think of is that a client can send a bunch of crazy values, really high values, negative values, long floating points. As the project becomes more and more complicated, it is more likely and bad data like that causes hard to trackdown errors.
  11. Simple way to translate the coordinates for your example is to notice that each wall is just a sheared rectangle. You can take the x value as is. Figure out the angle the corners of the wall makes, getting a slope value and then multiplying it by the x to get a y offset. Then you can just add the y of the real world coordinate to the offset and then you get a translated y value on the wall.
  12. Server should run the same authentication as client. Off the top of my head, here is how I would do it. For the purposes of each wall, assuming only rectangles for both wall and sprite, you can think of it as a 2d plane and there are no lopsided posters. First, extract the projected position value of the top left of the poster on the wall it is being placed on, which can be done with some simple trigonometry. Then you can just check that one rectangle is within the other. Steps can be projected the same way, and check to see the poster is not colliding with any steps on the same plane. Though if it were me, since there are obstacles like that, I would treat the wall as a grid of W x H of whatever placement unit I choose. Then I can just store open cells in a data structure as opposed to allowing pixel placement.
  13. Ahh! Thank you. I thought the 2 steps you had before were 2 options of focusing.
  14. Hey, I still don't seem to have a focusable canvas. I made a jsfiddle that captures the essence of what I am doing. Could you take a look? https://jsfiddle.net/fenrtk3b/ Thanks