• Content count

  • Joined

  • Last visited

About Antriel

  • Rank
    Advanced Member

Contact Methods

  • Website URL
  • Twitter

Profile Information

  • Gender
  • Location

Recent Profile Visitors

646 profile views
  1. Way 1: It's gonna be very difficult to prevent cheating if the client is authoritative about its state. You could limit some things like teleporting across the map, but it wouldn't be possible to detect things like teleporting a small distance. Way 2: This would definitely make cheating more difficult, at least in regard to movement. But it's more complicated to implement. In the end it depends on the type of the game and what you want to achieve. If the game gets popular, it's bound to have a lot of people trying to cheat – that's one thing to keep in mind. Way 2 will also need stronger server. Personally, I would go for way 2. Cheating can kill a game – that's basically the main reason. I wouldn't implement it in the way @space_elevators said though. That approach would cause visible lag and make the game borderline unplayable. I would use client-side prediction and server reconciliation techniques mentioned in the article in my previous comment. What @space_elevators described is called entity interpolation and is used for entities of other players, not the user's entity/character. Other resources about this topic (though imho more difficult to understand, they do go more deeply into it): Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization by Yahn W. Bernier from Valve. What every programmer needs to know about game networking by Glenn Fiedler. Real Time Multiplayer in HTML5 by Sven Bergström. I would start with this one. It's for HTML5 and Sven explains it really really well.
  2. I recommend reading this and other articles you can google about client-side interpolation. Good luck
  3. This week I talk about how seemingly simple things can have not-so-simple issues – AABB physics.
  4. I started developing multiplayer online platformer to get back to things that got me to programming in the first place. I have no idea how it will work out (if at all), but I decided to blog about my progress in a devlog/tutorial fashion. The first entry is about my proof of concept prototype and why it wouldn't work
  5. Well you could just use the generator yourself, but I guess I could do it if you don't want to. I guess I would just commit new phaser externs and tag them with phaser version? Or what's the intended usage for your repo?
  6. I wrote some ugly ugly code to generate externs from TS definitions. It still has issues but seems like it works: Also wrote a small blog post about the process
  7. Right, well I thought it was given that the physics need fixed time step I don't agree that errors differences in floating point calculations are insignificant though. All it takes is the calculation landing on edge case and the rounding error can make all the difference -> chaos theory. And just so I am not saying it without any proof: That's fixed time step difference between running on the same PC in Flash Player vs HTML5 in Chrome
  8. Windows 7, chrome, Galaxy S3 as test device. Flash Develop as coding environment. Haxe as language. Flambe as engine currently. Custom tool for converting assets from swf to spritesheet atlases. ToDoList or any plaintext editor for To Dos.
  9. Most of what permith said makes sense, but I don't see how timestep has anything to do with it. C++ simulation also doesn't make sense much, unless the physics library you use in js actually does any approximations. As far as my experience goes, physics engines are deterministic. Any randomness comes from testing on different CPU which can solve floating point operation slightly differently. Unless the engine purposefully adds some randomness factor, if you execute the code exactly the same, the result should be exactly the same, on the same CPU.
  10. If I had to do something big like that, I certainly wouldn't use Flash IDE. You can use flex SDK to compile actionscript code (or even rather use Haxe). You create the basic core code/engine. You keep everything data driven. Player loads the game? Well load the base swf, then load all the assets needed for the login screen, initial area, etc. Player travels? Well load another area so you can display that.
  11. Hmm, maybe Rich could query the post database, extract the code tags, run content through some beautifier and replace the original with now beautiful code
  12. I once went into lengthy (2 weeks+) discussion with QA of certain company. The scenario was exactly the same, game worked for me, didn't work for them. I asked for console output couple times, never got anything out of them – they avoided the question. After couple rather heated emails they finally sent me url where they test the game. I didn't even ask for that, I asked for console output, but whatever. I navigate there, see it doesn't work, look up console: missing file. They didn't upload game.js file. So my recommendation? Ask them for the url they test on, I seriously doubt there's nothing in the console, they probably don't know what it is.
  13. I used flambe, thought I didn't do much for last couple months. Getting back in the game very soon I hope.
  14. At fast glance it looks good to me. @chg The point isn't really to increase FPS. Point is, you design your game based on 30FPS updates, because you suspect older devices will work around that fast + you don't need more FPS. But you can't really control fps with requestAnimationFrame, so what you do is interpolate, to make it look smooth. All this is based on assumption that rendering takes a lot more time than logic updates, which usually is the case. There shouldn't really be any unevenness because if logic update takes too much, you won't be able to render more frames anyway and it will stay locked at 30FPS, even lower if needed.
  15. Extrapolation will always be inprecise, so I wouldn't recommend that. Especially with physics you would get things like objects changing directions in a weird way or being rendered inside other objects. Yes, that's the only way this can work, you are always a bit behind with interpolation. But by how much? If your logic update is 30 Hz, then it cannot be more than 33~ ms. Which isn't a lot really. Afaik human reaction time from seeing to reaction is about 200ms, with muscle memory reflexes it's around 50ms iirc. So it can't be noticeable by player. Now if you were doing something extremely skill based like Super Meat Boy, I would worry more, but then you are sure to have at least 60 Hz updates, so again the time delay is very small. I think even with the delay, brain learns to compensate for it anyway. Anyway I wouldn't worry about it, most games these days (on pc) enable triple buffering, so you are always 2 frames behind anyway. Regarding the question: There is no way to compensate. But there is no reason not to use it for precise physics. It doesn't alter the physics in any way, just what the player sees and that is more precise than you could get by just redrawing all the time. That goes for interpolation though, extrapolation as I mentioned before, would draw stuff at wrong places (actually noticeable).