• Content Count

  • Joined

  • Last visited

About johncl

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Thanks for the reply. Yes I see that the animation system in Phaser is built for a richer purpose besides the one I had in mind. It is certainly good that they can be shared between instances of each toon "type". Once I had added the code to generate variations for each type it worked fine for now. I guess I'd need to have a lot of types to worry about the space it requires which isn't much anyway. I guess I am just very easily hung up on optimizing both memory usage and complexity from the old days.
  2. Reading through the source code for AnimationManager and Animation - I see its almost there but no quite. I was fooled by this one:'up', true, 5); Thinking that perhaps the index there at the end was the offset that would be added to all animation frames on playback, but no such luck - it only sets the start frame within the configured animation that 'up' was created with (even checking if its above, and if so setting it to 0). Actually if an animation wasn't also set up with a texture key you would have been able to set the texture on the sprite once (which you have to do anyway when creating the sprite) and just split each toon into separate sprite sheets and reuse all animations for all toons as they animation system could only just set which frame the sprite has to show. I will likely just write my own animation system then to simplify this.
  3. Ok, yes I guess I can build an extension and drop the whole Phaser 3 animation system. Just feels like a shortcoming that in order to play an animation it seems you do this:'up', true); You have to specify a key that is configured globally on the game.anims object. To me it looks like you have to make a separate key for each 'up' then, 'player_up', 'player_with_different_graphics_up', 'monster1_up' etc - even if they all could essentially share the same index offsets using some start index set on the sprite itself. From the Phaser 3 tutorial I linked I even got the impression that was the whole reason for making the animation manager a global system, to encourage reuse.
  4. I see that Phaser 3 now uses shared animations on the game/scene object itself, but I am stumped at how you can actually reuse these for several sprites that have the same index offsets relative to each other? For example, with this I am using a spritesheet where the toon sprite is at index 128, 3 frames each direction (offset 16 sprites down). But the method takes the sprite sheet name as well as an explicit start and end. Considering each of these get their own name, I cant really see how they can be reused for another sprite where I want to just offset the animation to another part of the sprite sheet or another sheet for that matter? I am missing something? As it is now I have to generate a lot of game.anims entries with keys for each type of toon which I find odd - since they might as well then just have been defined on the sprite itself like Phaser 2? var so = 128; game.anims.create({ key: 'down', frameRate: 8, repeat: -1, frames: game.anims.generateFrameNumbers('toons', { start: so, end: so+2 }) }); game.anims.create({ key: 'left', frameRate: 8, repeat: -1, frames: game.anims.generateFrameNumbers('toons', { start: so+16, end: so+16+2 }) }); game.anims.create({ key: 'right', frameRate: 8, repeat: -1, frames: game.anims.generateFrameNumbers('toons', { start: so+32, end: so+32+2 }) }); game.anims.create({ key: 'up', frameRate: 8, repeat: -1, frames: game.anims.generateFrameNumbers('toons', { start: so+48, end: so+48+2 }) }); To put it into context, this is from the new Phaser 3 tutorial pages: If the animation contains both absolute indexes as well as the sprite sheet, I cant really see how this is the case? Again, I am likely missing something.
  5. Although I am a bit torn whether to use a class that inherits Sprite or use the component pattern which I see some advocate. Maybe I am just more used to inheritance as I see the code becomes a bit more terse with the other pattern since you store the sprite in a variable and have to remember to access that whenever you actually want to modify/read something from the phaser sprite itself. What do you feel is the better approach? For example I want my player to react to controls, but that either means to pass the controls object into the update method or create the controls within the player object itself. I sort of feel that it would at least be good to separate those? If so maybe some sort of game model object could be passed into the update method? Especially since movement updates has to e.g. check for collisions with the scene objects. Any pointers would be nice.
  6. Remember to call super.preUpdate() as well or your animations wont play. - Just had a serious debugging session here to figure out why only the first frame showed.
  7. Thanks for the help on this one. This stumped me as well as I'd like to split up my code in several files and extending sprites seems to be a good way to make it more modular. Why havent they added a generic .add( x ) function to game that just looks at the type and knows that its a sprite? the this.add.existing( x ) looks rather cryptic?
  8. This is a pretty complicated topic due to the fact that there are so many different resolutions and even aspect ratios to consider. Also depending on art style one would have to be careful so your graphics doesnt get too fuzzy/blurred if you opt for old school pixel style and scale it up for e.g. tablet use. Pixel style graphics needs a certain amount of sharpness to make them look decent. It also depends heavily on what kind of game it is since some can have varying play area as you would scroll around it anyway so on some devices you could see more than others (or more up/down compared to left/right depending on aspect ratio which differs between an iPad vs the average Android tablet/phone). The problems start to surface the moment your game needs to show the whole play area on the screen - and you want pronounced pixel art. As mentioned above, one would have to make the game in a form factor that fits all systems, so for Android tablets and most phones one would consider those "tall screens" (assuming portrait mode), and try to fit it all in the height for the lowest phone resolution (e.g. 568 pixels for an iPhone5) and then add padding graphics for even taller mobile screens and then for bigger tablet screens do actual 2x 3x scaling of everything for crisp pixel graphics. It would likely mean that some devices would have more side border than others (for example on iPads with 4:3 format, a portrait format game would have areas on the side not used). Another way is to actually use the padded area for user interface buttons/score/etc if you for each device type adapt to either having this on top/bottom - or left/right depending on screen aspect. The nice thing is that its rather easy to test all these variables when running in a web-browser (I use the Chrome mobile option in devtools). It's a tricky problem in general, and the best way to learn is probably to check out youtube videos of people playing the same game on different devices and see how they vary.
  9. Just a quick one, is there any way to adjust the tween object so it moves to another point when it reaches the goal? It seems like just calling the "to" function again does nothing. Atm I am calling game.add.tween again for every time but it feels a bit like it could be not as efficient as it should?
  10. Thank you mattstyles and Tom Atom for the nice discussion. My experience with javascript is mainly a lot of jQuery code so both Typescript and more complex javascript understanding (which has recently surfaced) is limited. Coming from a C# and Java world the way one work with member variables generally works nice as a container and where the understanding of "this" is pretty well defined. Not so with JS - which has now started to dawn on me. There are lots of pages trying to explain this and I am sure its all very good once I get the hang of it with some experience. I agree with mattstyles that my problem was simply the way I was fooled by the function pointers when passing it to the Phaser.Game but then seeing it not work the same way when I did the same to a function within Phaser ( I have since encountered the same issues in work related use of Typescript so I see this is just something I need to learn to do right. The ".bind(this)" behind the function makes some sense as it creates a readable piece of code that explains what has been set as the functions context. The other example using the "= () => { .. }" , although getting rid of the bind, is actually less readable for me as I sort of like functions to look alike within a "class" context. Again thank you mattstyles and Tom Atom for showing the examples and the discussion - it has cleared up some things. And I will definitely try the extending of Game and using State as I like this way of splitting up functionality. The main reason for wanting to use Typescript is to arrange my code in some kind of "objects" so I can extend classes and give each of them behaviours that way. A bit off topic, but are there any good tutorials how to make native builds using Phaser? I can see wanting to do at least Android, iOS and Windows builds for any Phaser game project I do. I had troubles finding a good howto on the Phaser site. I am used to working with ionic2 and there it is rather simple ("ionic build android" and even "ionic run android --device" for deploying directly). It would be good if there were similar simple CLI's for packaging Phaser game projects to different platforms.
  11. Hi, i have been using Typescript quite a bit for an Ionic2 project sort of like working in Visual Studio Code with Typescript as it assists me quite a bit with autocompletion. But when I tried using Typescript with Phaser I soon realized my understanding of javascript is somewhat lacking with how the whole context thing work. Especially what "this" means. For example all the examples at the site will not work very well due to the fact that you have to put this. in front of all object references you put in your class "scope" which can feel a bit odd for those used to C# and Java coding. I have not yet figured out how I can make callback functions work when I pass them as a reference like most Phaser examples use. Here is an example from the Phaser examples:, createEnemy, this); // spawn an enemy every second by calling the createEnemy method that adds it to the game So in order to get this working in Typescript I have to write something like this:, function() { // create and add enemy sprite here }, this); So the game object is part of the class so it has to be explicitly referenced by this. everywhere. Well that isnt so bad (gotten used to that). The problem is that I cannot pass a function as a parameter just by referencing it. I then get all kinds of runtime errors where it fails to find some "apply" function on the context passed. So this does not work in typescript: class MySuperGame { game : Phaser.Game; constructor() { = new Phaser.Game( 800, 600, Phaser.AUTO, 'content', { preload:this.preload, create:this.create }); } preload() {} create() {, this.createEnemy, this); } createEnemy() { // create and add enemy sprite here } } If anyone has any tips on making this work I would be very happy. It seems that passing this.createEnemy and this as context does not work very well in Typescript. I'd prefer to have separate functions instead of inline functions (which does work). Obviously I need to learn some more about javascript and how the context things work which is where this fails.