Jump to content


Recommended Posts

I'm happy to present to you Phaser Quest, a top-down real-time multiplayer adventure made with Phaser and Socket.io. Explore the map, find better equipment, fight monsters and defeat the final boss, alone or with friends! It was for me a practice project, and is a reproduction of Mozilla's Browserquest.

Hopefully the source code will interest you, as the project integrates of a lot of Phaser features together (such as tiled maps, text input, tweens, animations, sound, click handling, camera management, etc.), as well as pathfinding using Easystar.js. It is also an example of how a Phaser client can be made to interact with a Node.js server using Socket.io.

On my website, I have written a few articles about some aspects of the game. They are mostly concerned with networking for the moment. If you'd like me to write an article explaining how I accomplished this or that in the development of this game, feel free to ask, I'm always happy to help.

In addition, I'm interested in any feedback you might have, it's always valuable, especially with future multiplayer projects in mind.



Link to comment
Share on other sites

@samme It wasn't, but I just added it now because it's a nice idea ;)

@NicoA Yes, it's a strange behavior of the input plugin. To be honest I didn't put a lot of effort into the mobile aspect, because I considered it only at the end, and I should have thought more about it since the beginning (because it's not only a matter of scaling and a few lines of Phaser code, ideally the whole game interface has to adapt depending on the device size). It's a good lesson actually. Because of this I didn't really investigate this strange behavior yet. I may do it in the near future!

Link to comment
Share on other sites

9 hours ago, Jerorx said:

Yes, it's a strange behavior of the input plugin.

@Jerorx @NicoA Its not strange behaviour, its a browser feature for accessibility and user experience, although in your case it harms user experience. Looks like the input plugin you are using shoves an input element into the DOM, unfortunately its position -100, -100 with a width of 131 so the phone tries to zoom in to focus that element. Pretty sure it would zoom back out if you could unfocus the element (which is good behaviour generally when using input fields), but, your canvas element (which fills the screen when it does the zoom) captures all events so you can not unfocus the element nor 'flare' to zoom back out.

Given that you've got a fake UI for the input field you could hack the created invisible input field to be full width at the same height as the UI, this way the phone will try to zoom but will want to capture the entire field which is the full width of the screen so will not zoom. Or, stick the form field in the correct place on screen and allow the native zoom/unzoom behaviour. A good rule of thumb (well, more than this, its a good rule to follow) is to let native browser actions/events occur so I'd probably favour the 2nd option there.

Great work on the project @Jerorx, really enjoyed playing that game again!

Link to comment
Share on other sites

  • 1 month later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...