pixelburp

Members
  • Content count

    18
  • Joined

  • Last visited

  1. Are you using JavaScript ES 6?

    I've used TypeScript a little and while at first the typing was a great way to catch edge cases and enforce stricter code, the actual code became a bit of a mess to maintain, having to type evvvvvvverything. I think it's a bit excessive. I haven't looked at something like FlowJS, so dunno if that reduces the code smell but it seems quite popular ATM. Conversely, almost all the JS devs I know use ES6, and that seems to reflect in the broad trend with devs generally (see something like https://stateofjs.com/2016/flavors/ for last years trends; very interesting to see how Coffeescript has effectively died a death after briefly being championed for a while) TBH there's not a lot to 'learn' anyway, it's just an extension to the existing syntax to introduce saner & smarter options to how you code your applications or games. The "class" sytax alone is enough reason to start using it - the old way of doing JS classes is insanity. Equally, it's ridiculously easy to set up something like BabelJS or Browserify to convert your ES6 into whatever JS version you wish to support - TBH at this point, there's no good reason for any JS Dev not to learn ES6. Hobby coding is the perfect environment to learn these things too - no project deadlines or management pressure to interfere with a chance to properly upskill. I'd recommend it, because those not 'bothering' may find themselves struggling to stay relevant or hirible; not trying to sound harsh looking at the state of recruitment there's an increasing focus on devs familiar or experienced with ES5 => ES6 :-)
  2. Are you using JavaScript ES 6?

    I use ES6 almost exclusively now, it's so much easier and more development friendly than all the hacky ways of the past. I'd suggest anyone serious about learning JS should lean towards ES6+ and let things like BabelJS handle the backwards compatability, rather than struggle with prehistoric JS versions.
  3. Phaser Plugin: NavMesh Generation

    Yeah you're probably right @rich Ok, so if people want to actually use the plugin, I've published a rough, pre-alpha version that's available as a NPM package (it can be loaded normally as a script tag too though, and comes with source-maps): it can be found here: https://www.npmjs.com/package/phaser-navmesh-generation As for the SRC, I've made the repo public, so if people want to play / hack / criticise / comment on the SRC, it can be found here: https://github.com/amaccann/phaser-navmesh-generation Both contain rough documentation on how to use the plugin; there are really just two functions to use it (for now), with a couple of config. options to do the rest. Hopefully it's clear enough and works OK for people. Happy to answer any questions, queries etc. I freely admit that my geometry is a little rusty, and as this is a pre-pre-alpha, I don't think this is anywhere near as performant as it could be; there are a few places I'm sure better options are available, but Stackoverlow got me out of a jam quite often!
  4. Phaser Plugin: NavMesh Generation

    Yeah, I have a couple of ideas on how to solve the main bug that's highlighted, so I might wait until that's (hopefully!) solved before making the GH repo public. And yes, this plugin is for Phaser 2. The whole plugin is kinda independent of the main Phaser pipeline, so assuming Point, Line and Polygon (not to mention Plugin loading) remain the same it should migrate to Phaser 3 without too much fuss.
  5. Phaser Plugin: NavMesh Generation

    Update 19 Sept: v0.0.9 Released: I've published the plugin and is available on NPM: https://www.npmjs.com/package/phaser-navmesh-generation The SRC can be viewed on the GitHub repo: https://github.com/amaccann/phaser-navmesh-generation Summary (apologies for the long post) I've been working on this for a few weeks now, and thought I'd share the Work in Progress so far: I'm still working on various edge cases, bugs and performance R&D, but it's in a state worth demoing IMO & thought I'd share the progress with the forum, see if there's any interest in that sort of thing. It's a relatively simple plugin to use, where you give it the ref. of a Phaser.Tilemaplayer, a couple of options & it generates a Navigation Mesh for use later by your Sprites & Game Objects. This plugin for now has a very simple set of options; all that's passed to it includes: The Phaser.Tilemap (required) The Phaser.TilemapLayer that's acting as your 'collision' layer (required) Any collision indices that determine the impassable tiles (required) Any debug options you want so you can see the calculations How much you want to offset your Sprites from the calculated path What I call a 'midpoint' threshold - more on that in a minute Demo Videos: (NB: the 'pause' between the drawing of new tiles & the NavMesh update was intentional, so it didn't get run until onMouseUp - it's not performance lag - the NavMeshs are generating / updating in about 15 - 20ms ) This demos basic movement; the test Sprite is a little hard to make out, sorry! I draw some extra impassable tiles to show the NavMesh re-calculating new triangles: https://youtu.be/7v4wIn7mrNY This shows how with narrow spaces, the NavMesh uses the 'midpoint' of the the polygon line segment, instead of trying to turn around corners https://youtu.be/AYUKLRmVzUQ Why do this? This all started with a larger project I'm working on: it's going to (hopefully!) involve large tilemaps, a large number of sprites and procedural generation. A messy combination. As a result, I've been looking into ways I could perform pathfinding around Tilemaps in Phaser, and the most popular choice seems to be the grid-based a*star plugins; while in the main it probably does the job for smaller tilemaps, I don't think they scale very well. One standard method of pathfinding used by other engines is something called Navigation (Nav) Meshes: basically, you calculate all the passable areas on your map and reduce it all to a small array of connected polygons, then figure out how to travel across those polygons. In my R&D, I did come across Mike Westhad's great Phaser NavMesh plugin that does this, but one limitation of it is that it expects the Developer to have manually drawn the NavMesh in the Tiled Editor. IMO, this didn't go far enough as it'd be great if a plugin could 'just' take any Phaser.TilemapLayer, inspect its passable areas and calculate a NavMesh on the fly. Assuming your game uses a larger, more complicated map, then in theory a NavMesh could be much more performance friendly than a giant A*Star grid. Because we're reducing all passable tiles into a smaller number of triangle space, there are fewer computations needed to get from point A to point B, as rather than (for instance) iterating across dozens, or even hundreds of grid tiles to find the shortest path, you're only iterating across a handful of polygons instead. Equally, if you do this at the load of your game level it should be a relatively small footprint of memory in your game. The Science Bit: How does this work? Well, the principle is actually quite 'simple' really. To give a rough breakdown of the process of calculation: Iterate across the tileLayer and merge all the impassable tiles into a series of unified polygons; this is done using what's known as 'Marching Squares Algorithm' - often used for finding the outlines of graphics objects. Recursively do this until we're confident we've found all possible impassable tile groups, and any groups within each other Extract all the corner points for these polygons, and perform 'Constrained Delaunay Triangulation' on these points. Basically, fill the area with connected triangles with these corner points. Loop over all these triangles, and find each others' neighbours. When we actually want to trace a path from A to B, find the triangle underneath the two points, then use A*Star to discover the shortest sequence of triangles to get to that destination. Use Funnel Algorithm to draw a path through those triangles, finding the corners around which to move. - This is where the 'midpoint threshold' comes into play, as some polygons might be too small to properly corner around: so instead we just take the midpoint of the funnel edge instead. Performance / Bugs: I'm still working on performance, and I'd like this to be as fast as humanely possible. IMO the biggest bottleneck is the Marching Squares phase, when it searches the map for impassable outlines. It's inherently a brute force iteration, so it could take a long time - depending on the map size One solution I'm investigating is using Web Workers to perform this calculation in another thread, but I'm not yet convinced this is the way to go here. One major bug I have ATM is while the corner offsetting works fine in most cases, if the edges of the polygons are parallel, it gives weird results: see an example here: https://youtu.be/nApp17njzkg
  6. Phaser and larger-scale games?

    So, service workers would come to the rescue? I imagine you meant "Web Workers" for multithreading, but unfortunately this isn't a silver bullet solution to passing computations to other threads. JS workers don't have access to the window or document object for starters, so Phaser can't be accessed from the worker, and couldn't be cloned into the worker either as it needs window itself. There are also speed trade offs for starting / loading workers too so while they can give a performance boost for the actual calculations you want to have in another thread, the startup cost may impact performance itself.
  7. Phaser and larger-scale games?

    I think there's a lot of wriggle-room though between Browser Games & what are thought of as "AAA" games that Phaser could fit into; it doesn't feel like an either-or scenario here that Phaser is simply out of the question. The burgeoning indie side of the games industry has shown there is space for keen developers to make their mark (though arguably it's a bit of an over-saturated market now & difficult to make a splash) and often those games are made within fairly narrow budgets or technologies: Binding of Isaac was famously built with Flash to pick just one example of a popular game that used an ... unorthodox tech - even if its own limitations forced Ed McMillen to port the game to another language. In theory, you could build a modest, low-fi, small to medium sized game in Phaser IMO, albeit with an appreciation that you'll be massaging every line of code to eek out every last drop of performance - effort vs. reward might be its own frustration there. I definitely think there's a culture gap between Javascript developers & game programming though, one that accounts for the relatively smaller amount of JS Game Dev - technological limitations notwithstanding. Going by my own personal experiences & career, a lot of JS devs I'd know would have come to the language explicitly from web development, either via Web Design (like myself) or backend technologies such as Java or Ruby; so their general focus & areas of interest then tend towards web applications, data presentation etc. rather than anything more multimedia based. From the outset, there's a cultural base that just doesn't think of game programming.
  8. Phaser and larger-scale games?

    Phaser seems perfectly capable for making "large" games, from what little I've worked with the framework, all the moving parts you'd need seem to be there (at first glance, the only thing missing IMO is a robust way of saving / persisting game data). I think just the broader JS community isn't really geared towards game-making so there's a much smaller volume of game output, compared to what to me would be the vast majority of JS work - WebApp frameworks, plugins etc. For me, I feel there's a fair equivalence that can be drawn between something like Phaser & the SNES / MegaDrive era: both emphasising the necessity that the engineer be aware and considerate of the hardware limitations you're building for. 3D frameworks have their own drawbacks, but from what I've seen of Unity etc., you can pretty much throw what you want into the editor and magic happens in the background (I know there's more to it than that); with Phaser you kinda need to know what you're doing, and be ready to deal with the reality that what you've done may need fine tuning in Chrome / Electron / Native app etc. Back in the heyday of 2D gaming, all the studios had to factor in the basic limitations of the SNES, PC, or whatever the game was being built for. So there's a natural learning curve that (so far) dissuades developers from diving too deeply into Phaser, but IMO it's all there and viable, just needs some creative thinking to get around the performance / upscaling issues that'll arise.
  9. Can't jump and walk at the same time

    Just glancing at that code, your chain of if/elses is written in such a way that you can never actually get at this portion: else if((this.cursor.right.isDown || this.cursor.left.isDown) && this.jump.isDown){ this.player.body.velocity.x= 200; this.player.body.velocity.y=-200; } The first two conditions checking for left & right will always be accessed before this above one, and that's because you've chained all those ifs to be dependent on each other; if you can't do if 1., try if() 2. If you can't do if() 2, try if () 3, and so on. Instead, something like the below might work - though I haven't checked it. Ideally you want to check the jumping code independent on whether you're pressing left or right. if(this.cursor.right.isDown){ this.player.body.velocity.x= 200; this.player.animations.play('correr', 5, true); this.player.scale.x=1; } else if(this.cursor.left.isDown){ this.player.body.velocity.x= -200; this.player.animations.play('correr', 5, true); this.player.scale.x=-1; } if(this.jump.isDown && this.player.body.wasTouching.down) { this.player.body.velocity.y= -400 } else { // Whatever you want to do if you're NOT jumping }
  10. Call a function inside events with states

    @deepsky88 There is your problem: var esperienza = 0 this is a local variable, not a member property of your Game State; it's scope is only wherever it was declared - the boot function. So assuming you mean the preload() or create() functions, if you declare it like the below instead, it SHOULD be visible to the physics callback: this.esperienza = 0;
  11. Call a function inside events with states

    @deepsky88 Hard to say from just that snippet, but I'm guessing "this.esperienza" doesn't exist on 'this', so performing a += 10 operation returns the NotANumber (NaN) property because it's operating on a property that can't be accessed. First thing: has this.esperienza actually been created, and what is it: just a basic type like a Number, Sprite etc? Second, it's always worth debugging yourself to see why a variable or object isn't behaving as expected: either adding the debugger breakpoint (perhaps after this.esperienza += 10 assignment) to see what the scope of your anonymous function contains, though you can do the same with just a console.log(this) in the same place (though sometimes with Phaser that can cause a cascade of console.logs!)
  12. How to prevent manipulation by console commands?

    There's no way to completely block the JS code from the User on the client-side, however there are a few ways to made it harder for them: Uglify the JS as much as possible, so inspecting the code is (close to) meaningless. IIRC you can even uglify the 'top level' so namespaces are obscured. Someone could still use a 'beautifier' to reformat it all, but with no human-readable var names, comments, etc. it'd be an exercise in patience just to work out how your game works. Honestly if you're publishing a game this is the very least you should do to 'protect' the code. None / little of your code should be publicly accessible from the console anyway. If possible, declare your new Phaser.Game() as a private instance somewhere, that makes it harder for a curious User to inspect the game's current state from the console. IMO it's good practise anyway to make sure you don't extend the window/document object, so it's a good habit to get into. @Zampano just quickly looking at your game, you've declared 'player' as a global variable within Game.js - this is why it's available in the console. Maybe you should think about wrapping your .js files with anonymous functions so that all the code within is 'private'. That causes its own problems however, as you still need to expose things like your 'x_player' class globally (or through something like NodeJS imports), so the main Game code can access it later.
  13. The Phaser 3 Wishlist Thread :)

    Thanks @rich for clarifying those two things. I did presume V3 was probably still a fair bit in the future, but I was very curious / anxious that the versioning would be a major revision to the framework's structure. Good to hear that eventually not too much will require refactoring :-D
  14. The Phaser 3 Wishlist Thread :)

    Just wondering as an aside (and apologies if this was already asked & answered), but what is the expected difficulty curve between updating code from Phaser 2 to Phaser 3? I appreciate v3 is a WIP, but are there likely to be many gotchas but otherwise a fairly simple transition? Or will it be something similar to the angular framework where there was a wholesale top-to-bottom change between version 1 & 2+. If not done already it might be worth an article from the Phaser team themselves. I have a few WIP projects and part of me thinks it might be worth waiting until Phaser 3 arrives, as I'm worried I may have to refactor large chunks of my code...
  15. I see the plugin's a bit dormant ATM, I think, but perhaps you guys have had enough experience to answer what _seems_ like a simple question: Given I have a Phaser.Group() of Isometric.ISOSprite() acting as the 'floor' tile-map, is it possible to constrain the state's bounds based on this Group? The group will be dynamic so the number of sprites will change. I had initially thought simply going: game.world.setBounds(myGroup.x, myGroup.y, myGroup.width, myGroup.height); would work, but of course those coordinates don't accurately reflect the 'true' dimensions of the isometric grid, given the plugin projects the coordinates. I tried a couple of guess/combinations, but I always got 'weird' bounds as a result. Any ideas? Hopefully the answer's simple!