Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by JakeCake

  1. One big one is better, but keep in mind maximum size supported for some graphic-units. I think the general rule is to keep atlases at or below 4048x4048. If you have to split them into multiple atlases, try to put sprites that would be drawn at the same time on the same atlas, like background images in one and foreground in another. That way you can minimize the number of texture-swaps to a minimum.
  2. THIS!!???!!?=??!! OMG cant get past lvl 32!! Very nice game so far, seems very polished, but I hope to see more updates to the difficulty curve and randomization. Now that I got the hold of it, it's alright difficulty wise for me, besides lvl 32 of cause, but as a first-time player it was super difficult to get past even the first boss or two. Even now though, because of the randomization, some runs I just can't get very far because of poor items / not enough health-potion drops etc. So maybe some kind of rating of items and make them drop at least X amout before lvl 10, 20, 30 etc. inste
  3. Best you can do is to uglify the code using something like Google Closure Compiler Service. To be fair, if competitors really wants to steal your stuff, it doesn't matter what language you use, they will always be able to get the source-code, even if you obscure variable-names and remove comments etc. Use copyright and go the legal way instead of making the code unavailable.
  4. You can use sqrt( (ship.x - bullet.x)^2 + (ship.y - bullet.y)^2 ) to get the distance between the ship and a bullet. Check this each frame for each bullet and kill the bullet if the calculated distance is greater than 250. The other option is to set a lifetime on your bullet, all sprites have this I believe. After the given time it is automatically destroyed. Just figure out how fast a bullet is traveling per second and make sure this add up to 250 or whatever you thing is proper. Third option is to check if the bullet is in the camera-bounds. I think sprites have a method for this a
  5. I agree with matt; transparency in png is a built in mask, so why overcomplicate? If you like the compression-rate of jpeg over png I suggest you take a look at some good png-compression like on https://tinypng.com/ You can get just as good results with png compression as jpeg. EDIT: I myself use a gulp task to take my loseless PNG-files and combine them into texture atlases and then pipe them into a compression task using gulp-pngquant. So I am always working with uncompressed png-files, but the final build will be compressed based on settings I can always change for quality ov
  6. Upgraded from 2.4.7 to 2.4.9.rc4 and did a throughout test. No problems to report, everything I tested works. Is there a way to test release candidates with NPM? I normally just update my package.json to the newest version of Phaser when it comes out, but I can't seem to find release candidates in NPM, newest is 2.4.8
  7. Something I've been longing to ask for, if you don't mind. Does Phaser draw all sprites from one atlas first and then move on to the next as it saves the depth-value for each, or does it draw in the order of depth, so behind most sprites are drawn first and multiple texture-swaps to the same texture might occur per frame? It's so I know how to pack my textures, as in which order of depth they are usually drawn in. Little off-topic sorry, but it's just a quicky question.
  8. I don't think it's directly possible, as the parent sprite works as a display group and applies it's transformation on all it's children. You could however negate the effect by either: Not adding it as a child, but instead set the x/y of the child to the same as wave_left each frame and then have them in the same display group. Negate the rotation by setting the childs rotation to the negative of the parent and then displace with a vector from child to parent, but the first solution seems easier Wait for a better answer, there might be a built in way of doing this.
  9. JakeCake

    Game inventory

    Well it depends a lot on what you are doing. Developing websites or libraries, populating the global scope is a big no-no, but I don't think HTML5 games have aged enough to have best-practices yet. I mean if all you have on your website is just your game, and you know this for sure, then I don't see a reason not to use the global scope, and in the end you can just throw a function-scope around your entire game-code. Best practices are widely different depending on which language you use, but also the type of project you are developing.
  10. JakeCake

    Game inventory

    I like to have one class per file, so I would have put your Inventory inside a separate file and then do this.inventory = new Inventory() in your player class. Either way it's fairly nice code, you divide responsibility in a good way. If your player is the only one ever to use an inventory I think what you are doing is perfectly fine and won't populate the global scope as bad as my "one class per file" will do. So go on along the path you're on, it looks good.
  11. Also just wanted to let you know that upgrading 2.4.6 -> 2.4.7 went without problems. Where can I read more in details about the new Camera shake effect? I wrote my own one for my current project, but if the built in is better and easy to implement I might as well switch to it.
  12. (function() { // ALL YOUR CODE HERE })(); Effectively puts everything into it's own scope. You want one of these around each game. You can also switch out all your "var"s with "let" and just put { } around the games, but I like to add function scope around better. Alternatively you can make it a class object instead that you initialise with a "new" operator, and then all values defined as "this.yourValName" will be available through that object, the rest closed off completely inside the function-scope.
  13. 1. Yes to this, v4 is a huge step it seems. I don't think Phaser needs to natively support new features of v4, but the performance is definitely worth the effort in my opinion. 2. Havn't heard of this yet, but it seems awesome! Generally anything that has to do with better performance, or the illusion of better performance gets a +1 from me. 3. There are some great plugins for this already, so I vote no. 4. This seems like a huge API change. I'd wait and only do it for Lazer. 5. A rebase of code seems too timeconsuming and error-prone, maybe let this be a Lazer-only feature
  14. Use Google Tag Manager perhaps. You can set up events in javascript such as: dataLayer.push({ event: 'canvas_loaded', load_time: '2867ms', label: 'whatever you want here etc.'}); These events you can add anywhere. You can even log all client-side javascript errors to see if your game have any fatal bugs.
  15. I use brackets as my IDE for it's flexibility, and automated Gulp-tasks for as many other tasks as possible like atlas-generation, image-compression, javascript bundling, localhosting etc. Visual studio is probably the way to go if you develop in typescript over javascript.
  16. For me, it depends on how far away Lazer is from it's initial release. At this point it's been more than 4 months since the last minor Phaser version, so if Lazer is still a year away, I would very much like to see a large update to Phaser in 3 weeks instead, but if Lazer is around the corner, then I see no reason to do anything but fix minor issues for Phaser.
  17. Download as zip does not work in Safari 9.0.1 for OS X. Used chrome instead, this is awesome, thanks!
  18. Any plans for Phaser and WebGL2 you can share? I don't know about "Migrating the shaders to ES3 dialect", but I reckon this is a small task for the primary shader?
  19. 97/108 stars with the current levels. The difficulty of the levels seems shifting, but I think I like it. Normally games like these have a constant difficulty increase, so the first time you run into a frustrating level, each level from there on will be frustrating, which in turn makes you stop playing because you start to feel stupid. This however can have a frustrating level, but then you get 2 or 3 after that one that are easier, or at least less complex. I think that works out very nicely, as in being difficult, but also rewards you with a few easy breaks between the most difficult moments
  20. How are they in any way the same thing? A texture atlas is a way to pack textures together to reduce texture bindings on the graphics unit, while a particle emitter is a way to spawn sprites. It's like comparing how efficient it is to zip a movie compared to playing it in VLC or Quicktime. Two very different things, or am I missing something.
  21. For any future reference, here is the solution I ended up coding: Phaser.Cache.prototype.getAtlasForTexture = function(texturekey) { for(var key in game.cache._cache.image) { if(game.cache._cache.image[key].frameData.getFrameByName(texturekey)) { return game.cache._cache.image[key].key; } } return null; };It returns the key to the atlas containing the texture with the texture key given. So in all my sprite creation I do this: layer.foreground.create(x, y, game.cache.getAtlasForTexture("unique_key"), "unique_key");Since I'm prot
  22. I am loading a bunch of texture atlases with many sprites in them, but now, for performance testing I would like to bulge some of these atlases together. Due to my automated gulp tasks this is no issues and only takes a couple of seconds, as to create the new textures, but still all my sprite creation use something like layer.foreground.create(x, y, 'enemies', 'enemy_pig'); which will no longer work if the atlas name has changed. If I combine the two atlases "enemies" and "pickups" into one, all these initialisations will fail. Since I have named the textures within each atlas with an unique
  23. You should get a stack tree with the error message if you are using Chrome or any other major browser with dev tools. That should tell you the exact line. I suspect either "Phaser.Tilemap.TILED_JSON" or problems with something you are trying to load. You are not defining cursors as a variable either, but that should not break the game, but you might want to do it for performance reasons.
  24. I got the first one since I'm a patrion, but even though I liked the idea, I ended up just skimming it through in about 30 minutes because it seemed to only cover very basic topics. This second one however seems spot on for me, not just because it's a more difficult topic, but because I love the whole graphics engine thing and performance is my most important aspect of any engine. While I am somewhat familiar with OpenGL I think I can spend many many hours reading this next one
  25. Rendering a texture happens through a shader in Phaser just as rendering a filter does, as long as you are running in WebGl mode of cause; which you might not want to do at all on mobile devices, but that's another talk. If you write your shader somewhat efficient - and there's a very large margin here - it should render just as fast as rendering a texture directly, plus you even save room on your graphics-ram, which mobile devices have only little of. That being said there is a small overhead on switching shaders, marginally longer than switching textures. To compensate you could render to
  • Create New...