• Content Count

  • Joined

  • Last visited

About dreta

  • Rank

Contact Methods

  • Twitter
  1. It makes absolutely no sense to specify requirements for a graphics library other than the minimum API version the graphics card needs to support (in this case it's a WebGL-enabled browser).
  2. Cool Good luck with your future projects!
  3. Looks great, plays horribly. The jump is awkward, the character floats too much and there's no controllable jump height, meaning that you have to stop the character in the air when jumping over short gaps. The game doesn't register jumps when the character is near the edge of a platform, this is awful. There should be a leeway as to when you can perform the jump; it should be possible even a slight amount of time after leaving a platform. This is important in 2D platformers in general, but here it's MUCH more important because everything is 3D and the camera's angled. Additionally the character has a massive head and tiny body, you won't be looking at the character directly when playing, you'll be looking ahead, so with the corner of your eye you'll register the head as the width of the character and that should be the basis of whether the character is still on a platform or not. This is just another WebGL demo for this reason. Games require polish and strong core mechanics, a cool idea or graphics won't carry a game.
  4. Occasional lag most likely means you're producing too much garbage. If the game runs slower with lower FPS, that means you've tied your game logic to the FPS, what you should do instead is update the game depending on the actual time passed between frames, or better yet, by a fixed amount of time, but only update if the time between frames is at least as big as the fixed time. The size of your level shouldn't matter as long as you implement proper space partitioning structures for physics and rendering.
  5. It's absolutely distinguishable between 30 and 60 FPS. It's always a big deal when a fast paced AAA title drops to 30 FPS. "Juicy" mobile games and infinite runners need high FPS for appeall, though for a lot of titles it probably isn't as important. People that play games often are used to 60 FPS and they can tell the difference. Should be the other way around. Run your physics at 20 FPS and rendering at 60 FPS with interpolation.
  6. http://buildnewgames.com/optimizing-websockets-bandwidth/ Use https://github.com/Worlize/WebSocket-Node instead. It allows you to send binary data and doesn't bloat packages.
  7. To expand on what Deltakosh said, it's common practice to load any assets that aren't Image or Audio by using XMLHttpRequest (or xhr for short). XMLHttpRequest won't work offline, because it doesn't allow cross-origin requests for security reasons. You have to set up a local server (since you're dealing with HTML5 development, you'll need to do that no matter what anyway). I suggest either setting up a static node.js server or using XAMPP.
  8. dreta

    Elliot Quest

    I enjoyed the few minutes i spend with the game. There are a few immediate issues though. For one the game desperately needs volume control, even if it's just a demo, and secondly you can't move diagonally on the world map, which gets annoying.
  9. Well it should be a basic feature for any physics engine. How do people who use Phaser handle things like explosions or more complex AI without world queries?
  10. Hey, I've downloaded Phaser from GitHub and the only object that's documented is the TimeManager, so i tried building the documentation with yuidoc myself, but not the whole documentation builds, f.e. physics isn't building at all. Which leads to my next question, since i can't look this up in the documentation, can somebody tell me if Phaser has the ability to query the physics world? F.e. retrieve objects or tiles that overlap an AABB or retrieve the first object or tile hit by a ray. I looked at the physics source and i can see that you're using a quad tree and making it publicly accessible, but it doesn't have the functionality i want.
  11. Using socket.io for games is a terrible idea.
  12. You can center content on a page by setting the horizontal margin to auto. For this to work with canvas you have to set display to block first. canvas { display : block; margin : auto;}This is how pages are centered. You either set the margin for the body or a div that holds the page content.
  13. dreta

    WebGL HUD

    You mean HUD as in UI? For every UI element, you build a rectangle out of two triangles and you texture that rectangle with the graphic you want to use for it. If you use pixels to position your UI elements instead of the (-1, 1) range, then you'll have to build an orthogonal matrix that will transform your rectangles from screen space to NDC space. Remember to render the UI after the scene, enable blending and disable depth testing. Text rendering works the same way by rendering individual letters, but you can optimize it by using triangle strips for a text area, by pre-rendering a piece of text to a texture, etc. The canvas trick works too, but text rendering on the canvas is ugly and you have no control over interpolation. You can use 3D elements for the UI too, of course, but that just requires you to write a shader that doesn't use the camera matrix, only the projection matrix which you should already have calculated. What i just said requires basic understanding of how OpenGL works, are you using Three.js or some other framework that's causing you problems with this? I'm asking, because the idea of rendering UI based on the camera position is so ridiculous that you shouldn't have even tried it.
  14. Your code structure is kind of a mess (in the same sense that interleaving public and private field definitions in C++ is a mess), especially the Score function and the way you use it, but since you're looking for strictly JavaScript feedback, and since structuring code is a skill you learn with time, i won't comment much on that. The glaring issue is this piece of code: document.addEventListener('keydown', function(event) { if(event.keyCode == 38) { player.Y -= player.speed; } if(event.keyCode == 40) { player.Y += player.speed; } });You have no control over when the player's position is being modified or the actual speed of the player, since it depends on how fast the player can press a key. At the same time you don't allow the player to just hold down the key to keep moving. The proper way of handling input would be something like this: document.addEventListener('keydown', function(event) { if(event.keyCode == 38) { moveUp = true; } if(event.keyCode == 40) { moveDown = true; } }); document.addEventListener('keyup', function(event) { if(event.keyCode == 38) { moveUp = false; } if(event.keyCode == 40) { moveDown = false; } });//In the update routine...if(moveUp){ player.Y -= player.speed;}if(moveDown){ player.Y += player.speed;}
  15. As i and Ezelia said, client-side prediction is the way to deal with these problems and you need it no matter which protocol you use. The only real issue could be Nagle's because you couldn't work around it if it wasn't disabled, that's why i only mentioned that.