• Content count

  • Joined

  • Last visited

About Str1ngS

  • Rank
    Advanced Member
  • Birthday 04/12/1987

Contact Methods

  • Website URL
  • Twitter
  • Skype

Profile Information

  • Gender
  • Location

Recent Profile Visitors

1,068 profile views
  1. Funny that you ask now because yesterday it was told in an interview that the Switch won't be released with a browser. (altough it might be added later) Imho this means it will seriously set back html5 development for this machine
  2. We have a slightly bigger team than your's but the amount of people fixing stuff is more or less equal in percentage. But it is as you said, depending on where your revenue is, it's definitely worth updating some of your games. As for the infra, we are on Amazon (bit of legacy, we already started working on amazon 5 years ago), is there any particular reason why you went for Azure?
  3. As someone who also maintains a large number of HTML5 games I'm also very interested on what goes on behind the games. I'm talking about hosting, updating games, managing different versions etc. (If you are willing to answer of course;)) We are really running into the limits of what we can do with our current setup and I'd love to hear about your endeavors regarding this.
  4. Firefox's Developer Edition has build in support for this:
  5. You can create a new Phaser.Loader object on your own that isn't tied in with any states. It's the same as game.load, but now you can use it for lazy loading let loader = new Phaser.Loader(; loader.image(outro, 'assets/images/outro.png'); loader.onLoadComplete.add(() => { //Do something here to signal loading has finisged }, this); loader.start(); The browser already know this, if you load the same assets twice, the browser will return the same result. No idea how Phaser handles duplicates in this regard.
  6. Another thing you could do animate the lightning effect yourself in your favorite tool, and then export it as a spritesheet. In your code you should be able to rotate and stretch it your liking. We did something similar for one of our games:
  7. Although that example is made in Phaser, the principles can be added to PIXI as well. It uses some simple draw calls to draw the lighting adds some nice tweens to them, and a WebGL Filter for glow (which you can offcourse dismiss, it's just glow)
  8. Remove the var before controls in your create function controls = { right : this.input.keyboard.addKey(Phaser.Keyboard.RIGHT), left : this.input.keyboard.addKey(Phaser.Keyboard.LEFT), up : this.input.keyboard.addKey(Phaser.Keyboard.UP), };
  9. This whole game feels like one big boss battle, also the voice is great! Really like it
  10. That behaviour is different per browser, and in order to always be safe it's better to use /
  11. That's because children don't have names, nor are they refenced by such a thing. They are basicly just a list of objects.
  12. Yes it's allowed. We publish our games on external portals with our own AdSense/DFP included, in fact I made a phaser plugin that allows you to do just that
  13. I maintain an unofficial Spine plugin for phaser over at That plugin is already maintained in TypeScript, but the official JS runtime general runs behind the latest version of Spine. From what I can see I'll be updating Phaser-Spine towards using the spine-js runtime withint the next few weeks
  14. That just isn't true. Apart from the alphanumeric keys, the rest are defined by using their keyCode. Pause/Break (keyCode 19) however indeed isn't mapped. I'd suggest you submit a bug in github. But drhayes isn't wrong, you should be able to register an event handler for keycode 19 like so: var pauseBreakHandler = game.input.keyboard.addKey(19); pauseBreakHandler.onDown.add(function () { //do something }, this);
  15. Chrome's task manager gives you a complete overview of what Chrome needs to draw the page, this is on average a lot more then just the JS memory heap (which is what we care about, and more or less have most control over). The measures stated in there are interesting, but don't really help you fix issues regarding memory consumption of your app (and probably also not the reason why it crashes on mobile.) As for the memory heap, there are 2 ways in Chrome to review them. The simpelest way is creating a snapshot, which can be done in the developer tools under Profiles. Taking a heapsnapshot gives you an accurate overview of the actual object in memory. It's also possible to diff 2 snapshots but you can read about that over here: The second way is a bit more interesting to you, because it will show you memory allocation over time, you can use this to check how much memory is used between your states, but also when Chrome does some garbage collection on your memory. You can find this option in the developer tools under Timeline, also read more about it here: With these 2 options you should be more than capable of finding memory leaks in your code.