• Content Count

  • Joined

  • Last visited

Everything posted by pixelburp

  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.
  16. 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.
  17. 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.
  18. 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 }
  19. @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;
  20. @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!)
  21. 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.
  22. 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
  23. 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...
  24. 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!
  25. Apologies if this has either been asked before, or I'm misunderstanding how to use RenderTextures I have a renderTexture that's outputting the contents of a Phaser.Image(), which in turn contains an instance of Phaser.BitmapData(). In my update() loop, I want to update the position of some geometry drawn in the BitMapData, but those changes are never seen in the RenderTexture. What would be the reason for this? Like I said I could be misunderstanding how & why you might want to use a RenderTexture, but this portion of my code will be quite expensive & updated regularly - so it seemed like a good idea to pass this logic out to the GPU if possible, which is what a RenderTexture allows, right? Am open to some better ideas if I do indeed have the wrong idea! Below is the code: it's written in TypeScript and the class extends Phaser.Sprite(), so hopefully it makes sense even to those only familiar with JS. As you can see in my update() I'm redrawing a bitmapData.circle() with a new x position, then rendering back to the RenderTexture again. However, the circle never moves from its original position of 0. If I console.log out the x value, it's clearly update per tick. constructor(game: Phaser.Game, map: any) { const texture = new Phaser.RenderTexture(game, map.widthInPixels, map.heightInPixels, key); const bitmap = new Phaser.BitmapData(game, 'BITMAP', map.widthInPixels, map.heightInPixels); super(game, 0, 0, texture); this.bitmap = bitmap; this.image = new Phaser.Image(game, 0, 0, this.bitmap); this.texture = texture; // Other code to add this .Sprite() to the stage. } private update() { const bitmap = this.bitmap; bitmap.clear(); bitmap.circle(x, 100, 50, 'rgb(255, 255, 255)'); this.texture.render(this.image); x += 10; }