Jump to content

pixelburp

Members
  • Content Count

    27
  • Joined

  • Last visited

About pixelburp

  • Rank
    Member

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 i
  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 suspe
  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 re
  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 ma
  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.),
  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">&l
  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 Coffeescr
  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 real
  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
  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 impac
×
×
  • Create New...