lewster32

Members
  • Content Count

    1757
  • Joined

  • Last visited

  • Days Won

    60

Reputation Activity

  1. Thanks
    lewster32 got a reaction from DiegoMontania in [Ask] Error Get phaser.Map   
    This is normal - Chrome and some other browsers can now optionally download a .map file when your developer console is open, which allows you to more easily debug a minified JavaScript file. If it isn't present you'll get a 404 error but the program will work as normal still. Also, normal users not using developer tools won't send this request and so it won't be a problem. For development you should really be using the non-minified version of Phaser just so this step doesn't have to be taken.
  2. Like
    lewster32 got a reaction from samid737 in Sprite disoration, fake 3d   
    The 'fake 3D' in the original GTA was actually real 3D - it used a 3D engine to render the perspective correctly.
  3. Like
    lewster32 got a reaction from webdva in Running Phaser on Node.js - How I did it and why you shouldn't do it   
    Yeah that's an excellent article - definitely a must read for anyone interested in client-server stuff!
     
    I have to say though I do disagree on the idea of running the same level of physics simulation on the server as on the client. It's just so difficult to keep things in sync, and the more fully featured and accurate the simulation is, the more difficult it gets, as timing and sensitivity to initial conditions become more important to the outcome of every single interaction. In 95% of cases a server should only need to know where entities are, estimate with reasonable accuracy where they'll be a short time in the future, and detect whether they're colliding (or about to collide) - finally stepping in only if the estimates don't closely match what's being sent over. The real magic and heavy lifting should be done on the client to make the relatively sparse but vitally important information from the server translate into something that's as smooth and natural looking as possible, because when it comes to networks, the client cannot rely on the server to be there for it in a consistent, timely manner every step of the way.
  4. Thanks
    lewster32 got a reaction from webdva in Running Phaser on Node.js - How I did it and why you shouldn't do it   
    Can I ask what it is in particular you need to model physics-wise on the server? To me even running P2 on the server seems overkill given the fact that network latency is going to make synchronisation of physics between the server and clients really difficult. Even simple physics calculations are highly sensitive to timing and initial conditions, and this has traditionally made such stuff very, very difficult indeed to translate into the always unpredictable network environment.
     
    It seems to me that all you would need on pretty much any server is position, rotation and velocity, along with some state to handle what the entity is doing and maybe some meta to describe it. It's not then difficult to write your own simple integration methods on the server to derive expected positions from the position and velocity of entities and do some sanity checking. This would be more than adequate for most situations, and would then allow you to specify different types of entities; player entities would be controlled by clients and the server would just synchronise them with other clients, performing checks to ensure they're moving as expected. If you have projectiles, these would be created at a point, given a velocity and then the server would just run a simple velocity-based motion calculation and update all the clients with its position. 
     
    All of this really pushes the simplicity aspect - you want your server doing the absolute bare minimum. On the client-side you can have physics calculations filling in the gaps; by all means have client-side only stuff like explosions sending debris bouncing around the world, particle systems creating fancy spell effects and so on, but this would all be happening over the top of a very simple bare-bones physics system running in the background purely driving essential gameplay features.
  5. Like
    lewster32 got a reaction from webdva in Running Phaser on Node.js - How I did it and why you shouldn't do it   
    In tests I've done, I've gotten away with simply broadcasting the x and y positions of the objects, and on the client side interpolating the positions (basically using tweens) to hide the jerky motion from the low frequency updates. You could then have the server just watch out for anything weird, such as an object moving too far in a specified period of time and correct that as needed. This makes the calculations far lighter on the server side and allows it to step in if any funny business occurs. You can then build upon this base to start to include basic simulation of physics and expected events.
  6. Like
    lewster32 got a reaction from blackhawx in Multiple Keys At Once   
    The problem is you're exclusively testing for keypresses (i.e. you're using else instead of a load of consecutive if statements). What you need to do instead is check for the keypresses separately and not exclusively to one another, and then do something based on which combination of keys has been detected as down on that frame.
    This isn't exactly going to drop into your code above, but it gives you some idea of a possible approach:
    // just a temporary velocity value we can use to apply to the body later var velocity = 0; // using else here is fine, as you likely won't handle a state where both directions are down if (game.input.keyboard.isDown(Phaser.Keyboard.A) { // A key is down (left) so set our velocity to a negative number velocity = -50; } else if ((game.input.keyboard.isDown(Phaser.Keyboard.D) { // D key is down (right) so set our velocity to a positive number velocity = 50; } // notice this is not part of an else, this can be detected in addition to the previous if ((game.input.keyboard.isDown(Phaser.Keyboard.SHIFT) { // shift key is down (speed) so double our velocity value velocity = velocity * 2; } // now we can apply the correct velocity here player.body.velocity.x = velocity;  
  7. Like
    lewster32 got a reaction from austincap in Problem making a game UI: div blocks input to game screen   
    Actually Phaser and the DOM can be quite a good idea if done properly. HTML and CSS allow for many very useful things that Phaser does not yet (and may never) support directly such as inputs, media queries (and all the responsive stuff that entails) and so on. Treating Phaser's canvas like a sandboxed area of the page is if anything a rather self-limiting way of approaching this modern web tech and smacks of a bad habit from the earlier days of Flash.
  8. Like
    lewster32 got a reaction from Balamurugan in How to tell when a sound has finished ?   
    this.gameOverMusic.onStop.addOnce(function() { this.state.start('Results');}, this); Sound.onStop is a Signal, so the documentation for that is here: http://docs.phaser.io/Phaser.Signal.html
  9. Like
    lewster32 got a reaction from Balamurugan in How to optimize/debug my game?   
    Learning how to optimise code is a deep and wide-ranging process, but learning to use the profiler tools built into most modern browsers is a good place to begin. There are plenty of tutorials around the web on how to use them, so just do a little bit of research. I find also that if I've written my game in a modular way, I can turn off and comment out parts of the game and see how the individual parts affect the overall performance, and by that methodology unearth the bottlenecks in my code.
     
    There's no single guide or set of tips that can give you everything, but here are a few solid tips:
    WebGL stuff runs much faster if you use a single texture atlas for all of your assets. On canvas this doesn't matter so much. Lots of small optimisations add up - doing things like avoiding division (i.e. using * 0.5 to half a value instead of / 2) and rounding down numbers with | 0 in your code can speed it up, especially in big loops or your update/render functions. Using the appropriate physics system (and using it appropriately) helps a lot - Arcade is way faster than P2, and if you can get away with doing something with tweens, then that's faster still. Try to only update things which need updating. Be as ruthless as you can with regards to cutting out any unnecessary operations. Be especially vigilant with what you put in the update and render loops; calling the same thing over and over when it doesn't change is wasteful, and don't expect Phaser to be intelligent enough to realise nothing has changed - it will in most cases still repeat the same operation; and just because something isn't visually changing doesn't mean there aren't a lot of calculations going on anyway. A common approach (and one Phaser and pixi both use internally) is the idea of 'invalidation'. Objects have a 'dirty' flag, which is set to true whenever the object is changed. Then, on the object's update or render loop, if this flag is seen to be true, the object is updated and the flag is set back to false. This means the object is only updated when it needs to be updated, and if multiple things are changed, they're all updated in the same pass.
  10. Like
    lewster32 got a reaction from Titus in How to optimize/debug my game?   
    Learning how to optimise code is a deep and wide-ranging process, but learning to use the profiler tools built into most modern browsers is a good place to begin. There are plenty of tutorials around the web on how to use them, so just do a little bit of research. I find also that if I've written my game in a modular way, I can turn off and comment out parts of the game and see how the individual parts affect the overall performance, and by that methodology unearth the bottlenecks in my code.
     
    There's no single guide or set of tips that can give you everything, but here are a few solid tips:
    WebGL stuff runs much faster if you use a single texture atlas for all of your assets. On canvas this doesn't matter so much. Lots of small optimisations add up - doing things like avoiding division (i.e. using * 0.5 to half a value instead of / 2) and rounding down numbers with | 0 in your code can speed it up, especially in big loops or your update/render functions. Using the appropriate physics system (and using it appropriately) helps a lot - Arcade is way faster than P2, and if you can get away with doing something with tweens, then that's faster still. Try to only update things which need updating. Be as ruthless as you can with regards to cutting out any unnecessary operations. Be especially vigilant with what you put in the update and render loops; calling the same thing over and over when it doesn't change is wasteful, and don't expect Phaser to be intelligent enough to realise nothing has changed - it will in most cases still repeat the same operation; and just because something isn't visually changing doesn't mean there aren't a lot of calculations going on anyway. A common approach (and one Phaser and pixi both use internally) is the idea of 'invalidation'. Objects have a 'dirty' flag, which is set to true whenever the object is changed. Then, on the object's update or render loop, if this flag is seen to be true, the object is updated and the flag is set back to false. This means the object is only updated when it needs to be updated, and if multiple things are changed, they're all updated in the same pass.
  11. Like
    lewster32 got a reaction from grinmonk in Sprite Glide to (x,y) (Move to with animation)   
    Not sure about 'gliding' but you can tween an object to a specified position like so:
    // params are: properties to tween, time in ms, easing and auto-start tweenthis.game.add.tween(sprite).to({x: 100, y: 200}, 1000, Phaser.Easing.Quadratic.InOut, true);
  12. Thanks
    lewster32 got a reaction from Yehuda Katz in Math.random vs game.rnd   
    game.rnd is an instance of Phaser.RandomDataGenerator which as well as having a lot of nice convenience methods, is also a seeded pseudo-random number generator, meaning you can get repeatable results from it. See this example: http://examples.phaser.io/_site/view_full.html?d=misc&f=repeatable+random+numbers.js&t=repeatable%20random%20numbers (check the developer console to see the output)
  13. Like
    lewster32 got a reaction from msqar in Show FPS   
    See this example: http://jsfiddle.net/lewster32/3Sx5h/
     
    The key is game.time.advancedTiming without which the game.time.fps value will not be set.
  14. Thanks
    lewster32 got a reaction from Fenopiù in How to tint a particle   
    A particle is a type of sprite, and an emitter is a type of group, so if you can find the particle you want to tint in the emitter using the normal methods you can just call .tint on it as normal. Something like this will tint all the particles in the emitter:
    emitter.forEach(function(particle) { // tint every particle red particle.tint = 0xff0000;}); See the Emitter documentation for more.
  15. Like
    lewster32 got a reaction from Fenopiù in How to tint a particle   
    Phaser.Particle = function (game, x, y, key, frame) { Phaser.Sprite.call(this, game, x, y, key, frame); http://docs.phaser.io/Particle.js.html#sunlight-1-line-20
     
    Particle extends Sprite (which itself inherits from pixi's Sprite, and so on) so it inherits all of Sprite's properties. 
  16. Like
    lewster32 got a reaction from Titus in switch to new state and store the score previous state   
    Just store it outside of the state, for instance:
    var score = 0;var state1 = { create: function() { console.log(score); }}var state2 = { create: function() { console.log(score); }} How you structure your code is up to you, and the above is almost certainly not the way you'd want to do it, just a very simplistic example.
  17. Like
    lewster32 got a reaction from vattujan in Can't load state (Uncaught ReferenceError)   
    The problem is just that game.js is run first, and the states aren't defined at that point. Ttry changing your HTML so it loads the states first, then game last:
    <script src="boot.js"></script> <script src="load.js"></script> <script src="game.js"></script>
  18. Like
    lewster32 got a reaction from quiphop in Place text on top of over images (sprites, buttons etc)   
    Yes you can put groups into groups into groups as far down as you want to. Handily Sprites can also have things added to them using sprite.addChild(text) - like so:
    var sprite = game.add.sprite(0, 0, 'button');var text = game.add.text(0, 0, "Some text", {font: "16px Arial", fill: "#ffffff"});sprite.addChild(text);// now text will be positioned relative to the sprite, and will move around with it like a group - except with sprites you can still use physics
  19. Thanks
    lewster32 got a reaction from Madclaws in Pausing and Resuming Timer   
    Ok I've tracked down the problem. It seems creating a new Phaser.Timer isn't the way to do it, as it is not initialised properly. Instead change the timer creation line to this:
    this.currentTimer = game.time.create(false); And all should work as needed. The reason for this is that the game.time.create method adds the newly created timer to a private _timers array, which is updated by the core Time object. Without being included in this array, the timer is never updated.
  20. Like
    lewster32 got a reaction from Von Schau in increase sprite hit area without increasing its body   
    There is a hitArea property on all pixi DisplayObjects, which Phaser's objects inherit from. You can feed this a new Phaser.Rectangle like so:
    // add a hypothetical 10x10 sprite var sprite = game.add.sprite(0, 0, 'test'); // make the hit area 20x20 - note you can also use negative figures for the first two params (x and y) to offset it from the sprite sprite.hitArea = new Phaser.Rectangle(0, 0, 20, 20); I don't know for sure if this works with all input methods but I've tested it with dragging and it works fine there.
  21. Like
    lewster32 got a reaction from Phaser911 in Problem with onHold?   
    Rather than listening for a hold event, just use the update function to check each frame if the button is held down and if so, set the bird's velocity. Like this:
    function update() { if (game.input.activePointer.isDown) { fly(); }}
  22. Thanks
    lewster32 got a reaction from Zampano in Make Phaser.Game less accessible   
    Anything that is declared inside the IIFE will be privately scoped to the IIFE, and will not attach itself to any global variables, so yes, properties of objects declared in there will also be private. The only way variables will become global is if not expressly declared with var or if properties are attached to global objects such as window. If you make use of "use strict"; at the top of your code, an error will be thrown if you try to do the former, which can help.
  23. Like
    lewster32 got a reaction from Zampano in Make Phaser.Game less accessible   
    It's always possible to mess with client code, but by having it encapsulated in an IIFE, you make it much less trivial than simply opening the console and messing with global vars.
  24. Like
    lewster32 got a reaction from Zampano in Make Phaser.Game less accessible   
    I see, that makes more sense now. Because you have separate files, they all must use global scope in order to be accessible to one another. The solution here would be to combine (concatenate) them all into a single file and surround them with the IIFE as above. I'd recommend an automated build tool such as grunt, gulp etc. for this job. If you use gulp (which I'd recommend over grunt, mainly for performance reasons) gulp-concat and gulp-iife should do the job.
  25. Like
    lewster32 got a reaction from NewGuy in Custom font works oddly with game.add.text   
    Something like this would probably help to remove a lot of the hacky timed events etc: https://github.com/Pomax/Font.js