Popular Content

Showing content with the highest reputation on 04/02/19 in all areas

  1. 1 point
    Sure you can. If you're brave enough you can use webRTC over UDP and create you own UDP stack to handle packet order/drops etc. This has an additional advantage of less overhead in each message and that in turn means possible performance improvements.
  2. 1 point
    HTML5 is establishing itself as a language for everything. Nothing to do with HTML. Now we discover an open source platform that allows you to create 2D and 3D games. It is about Turbulenz. Tubulenz is a platform for creating games based on HTML5 that works mainly with Canvas, WebGL and JavaScript, its engine is very powerful or that is what it shows when using a game or any of the tests we can do with it (try), seeing as it generates complete 3D environments, controlling everything necessary in a video game to perfection (such as cameras, lights, shadows, particle generation...) and with an impeccable performance by the leading mobile game app development company. Using an engine like this one can be very useful, since it speeds up the development process, not to mention that browser games have a certain charm, being able to be played from anywhere without major complications. Well is another example of the growing importance of HTML5. Orient our training to master HTML5 I think it's a good choice.
  3. 1 point
    In many cases you can assume the container size and just add a PIXI.Graphic to that container like so. if (clientConfig.drawChunkGrid && layer.name === 'front') { const grid = new PIXI.Graphics() const text = new PIXI.Text(`${chunkPosition.x}, ${chunkPosition.y}`, { fontFamily: 'ArcadeClassic', fontSize: '16px', fill : '#fff', align: 'center', stroke: '#000', strokeThickness: 4 }) grid.lineStyle(1, 0x000000, 0.6) grid.moveTo(0, 0) grid.drawDashLine(fs * clientConfig.chunkSize.x, 0, 8, 8) grid.moveTo(0, 0) grid.drawDashLine(0, fs * clientConfig.chunkSize.y, 8, 8) chunkContainer.addChild(grid) chunkContainer.addChild(text) } use lineTo instead of this custom drawDashLine. In this case my chunkContainers already have positions and constant dimensions.
  4. 1 point


    That setting adjusts the delta emitted from the ticker, not how often the ticker is emitted. console.log that delta value and you'll see a difference. If the setting is left alone, if requestAnimationFrame can emit 60 times a second, that delta will come out as `1` as it's hitting it's target.
  5. 1 point
    Hi @maximlus, welcome to the forums Logins need two things: * A way to track logged-in status * A way to set logged-in status You can track logged-in status on either the client or on the server, but you almost always want to track _something_ on the client. The complication comes from identifying _who_ that client is, and that you can not trust clients. A common flow for a single-page application (your game probably is this) would be something like: * Hit your webpage holding your game * Navigate to log-in screen * Enter log in details (e.g. id/email, password) * Send those to your server. Check the details, if correct, generate a token, store it, send it to client. * Client stores this token (local storage is fine) and uses it to make subsequent requests or to actually enter the game. * Next visit, when client boots up (after hitting the url), check local storage for a token, maybe send it to your server to check it is still valid, become logged in. This flow means you have to store 3 things: * id/email and password details (server) * valid tokens (server) * logged-in status (client) Valid token status dictates logged-in status i.e. you should probably check the token is valid before assuming that it is. Tokens normally have two things: * An expiry * Are revocable An expiry means they will expire, you don't necessarily need to store this on the client, i.e. when the expiry date is hit then delete from server storage, when a client tries to use it, that operation will fail and you'll direct the user to a place where they can enter their details to generate a new one. This system also means that if you think anything is compromised (or problematic) then you can revoke a token. You could go a step further and associate a token with a user explicitly which gives you more control if you want to boot out a user, i.e. you revoke their token so they stop immediately, and you stop them from being able to generate a new one. It is normal to do this link between tokens are users, check out JWTs. If your game requires accessing authenticated endpoints (getting levels, scores, anything really) then using a token to do the auth stuff is quite nice i.e. your services _could_ inspect the token and respond appropriately for that user (or user type) i.e. to get the _next_ level, you wouldn't have to ask for it from the client (remember, don't trust clients), you could hold current level on the server and your endpoint could inspect the token, inspect the current level (and completion status maybe) and return the next level. There are lots of services out there that can handle these flows (and more complicated ones, such as 2FA) for you. It's worth looking up how they work and if they would work for you. Unless you want to code this all up and have to deal with holding emails or other personally identifying information (or even user tracking).