• Content Count

  • Joined

  • Last visited

About pixelburp

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I take it you don't mean the old MVC framework BackboneJS, right? This some prototyping tool?
  2. Yeah, that's the jist of what I'm getting at; interesting, will have a look at RxJS. Something I keep meaning to review anyway. Thanks! Yeah, I get what you mean, and does feel like a tricky needle to thread; in real terms I won't be tracking anything that'll be updating as fast as (for example) a sprite's x,y position, but the option to catch things like health, or unit buffs - that sort of things. It's just a pity there isn't a way to quickly prototype UIs in Phaser / Canvas as neatly & universally as HTML/CSS allows - or at least I don't think there is. I see there is the Button class, which seems like an input enabled Sprite, but having to define spritesheets etc. seems like a fussy trade-off for the more extensible avenue of HTML & CSS.
  3. What's appealing to me about going the html/css route is that it's naturally capable of dealing with varying screen sizes and browsers through trivial css selectors, and these days crossbrowser issues are fairly minor (compared with the bad old days of ie6 etc - yes, I'm that old!). Animation is still possible with css, and feels like less work phaser is asked to do. The events thing is a pain, but angular1 would in theory be able to watch any game object data I want, without the need for extra events or methods - the only problem is angular 1s well documented performance issues. I suspect once I threw a lot of data at it at 60fps, angular 1 would chug & die. So something LIKE angular 1, that can just watch any object you point it at, but with better performance would be ideal. TBH I'd also prefer this way, because my background is frontend development, so building html,css,is UIs is familiar.
  4. So in leaning towards drawing the UI using the DOM, CSS and a JS framework of choice, but am a little unsure what's the best tool for the job here. Seems counter intuitive to create a user interface in phaser when this is the web's strongpoint. I wrote a proof of concept with React-Redux but having to dispatch an action for every event is a little bloated; I want my UI to display live unit stats (as well as buffs, effects, queued actions etc), but even though the redux reducer contains objcect references to the game actors, the html components never update (obviously, as this isn't how react works as such) Anyone got any better frameworks in mind, better suited to live, per-frame updates? Angular 1 I've used a lot, but it's got poor performance IMO for fast updates against groups of complx objects - never used angular 2 so unsure if this is a better option and they made things faster. Ditto vueJS; seems to have growing popularity but not sure if it's geared towards fast, live updates or more static, 'react' esque. Thoughts?
  5. I meant when a stable / public release was ready, if it hadn't been considered, it be useful!
  6. Maybe I'm blind and it was already addressed, or this has come up before, but perhaps a migration guide would be handy for people porting from v2 to v3? I get the impression there's isn't that much difference between the two versions bar a few key functional issues, but a list of snags / gotchas might reduce confusion or heartache...
  7. The plugin has been updated to 0.2.1. I've added what IMO makes the navMesh a little more practical for use in games - the ability to dynamically override areas as impassable; useful for setting Sprites such as trees or buildings as blocked parts of the mesh. The main changes for this version include: Included support for 'sprites' to mark blocked areas of navMesh that isn't an explicit collision tile. This can be accessed through addSprite() method of plugin (use removeSprite to remove the sprite by uuid) Tilelayer data is now flattened from 2D Phaser format into 1D array; this makes it faster to iterate across the whole grid. Added updatedAt timestamp to generated navMesh Added createdAt timestamp for generated paths The full changelog is here: https://github.com/amaccann/phaser-navmesh-generation/blob/master/CHANGELOG.md
  8. Interesting; I must have a look at that, thanks @mikewesthad :-) Throughout my work, one of the big stumbling blocks was actually digging out some good documents & explanations over key pillars of NavMesh generation. A lot of the discussion was dominated by Unity / Unreal engine's GUI components, which didn't really help detail exactly what went into NavMeshes. As for updates from me; ATM there's a couple of things I'm working on that I think will be big improvements: A developer might want non-map based obstacles or blockages on the map (Sprites such as buildings, trees etc.), which the plugin doesn't support. I'm refactoring the plugin to allow for parts of the Grid to be toggled as "blocked", which will override any tileLayer index underneath. Trying to improve performance during triangulation. First step here is to STOP iterating across 2D arrays (which is how Phaser 2 stores its tileLayer data); a flattened 1D Array structure is much faster to iterate across, and already I'm finding the NavMesh is generating a lot faster. (Don't have any timings just yet) Investigating if WebWorkers can be used to make things even faster. This feels like a frustrating dead-end though. Proper multithreading would be so nice, but there's too much overhead simply loading threads; my brief experiments showed it could take 1-2 seconds simply creating a new instance, and there doesn't seem any real benefit in the speed of messages to & from the Worker. The A*star pathing is still not perfect, and sometimes the less optimal path is taken, even if it's obvious visually you can get to your destination via a (technically) longer path. Not sure how best to fix this though; it's a bit of a blocker.
  9. Bumping the thread as I've fixed a big issue that was preventing use as an imported node package; that probably didn't help get much useful feedback if people couldn't actually use the plugin :-( The newest version is 0.1.0 and also fixes a bug with pathfinding around parallel clusters of impassable terrain. ES6 / Node import it as you would any other project: import NavMeshPlugin from 'phaser-navmesh-generation'; Legacy If you're doing it the old fashioned way, simply add <script> tag after your main Phaser tag: <script src="my/path/to/phaser.js"></script> <script src="my/path/to/navmesh-plugin.js"></script> Then in your game's JS code: preload() { var plugin = this.game.plugins.add(NavMeshPlugin); }
  10. 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 :-)
  11. 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.
  12. 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!
  13. 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.
  14. Update 27 Sept: v0.1.0 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.
  15. 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.