oronbz

Switch Levels and Seperate Files

Recommended Posts

Hey,

 

1. I haven't seen an example of switching layouts/levels, like from Title Screen to the first level, or from the first level to second level, or from second level to game over screen.

 

2. I would like to have an example of how you would separate game objects like different enemies, pickups, player object to separate js files in a phaser project.

 

Thank you for your time!

Share this post


Link to post
Share on other sites

 

This post is kind of confusing between what the OP tried to achieved and his problems, and what I want to achieve here.

Just looking for a boilerplate of how to divide my project into separate js files and switching between levels.

 

I see that he used states but I still didn't understand the whole thing because he used states also for preloading and booting, which doesn't count as "levels" to me.

Share this post


Link to post
Share on other sites

They function the same as completely separate levels. For example, you could have a spot in your world that if the player touches or interacts with, it can trigger a state change, instead of being just when you click inside the world.

Share this post


Link to post
Share on other sites

They function the same as completely separate levels. For example, you could have a spot in your world that if the player touches or interacts with, it can trigger a state change, instead of being just when you click inside the world.

 

On the examples, I saw they add the sprites directly to the 'game' object, I saw alot of forum posts talking about the 'world' object, should I add the sprites to the game.world instead?

 

And what about re-usability of same sprites or sprite functionality in different states and separating the sprite declaration and functionality from the state?

 

If i'm using the same player/enemies in different states how would I not repeat the same code over states?

Share this post


Link to post
Share on other sites

I had this same question when I started with Phaser too. I was told to check out the "State" example (/wip/examples/state in 1.0.6), it solved my problem and demonstrates what I think you're looking for as well.

 

It's really just a case of lack of documentation. I would have been able to figure out that a "State" in Phaser is synonymous with screens or levels in other frameworks if there were docs. Hopefully that 1.0.7 update comes sooner than later!

Share this post


Link to post
Share on other sites

You'd create them in objects outside of the State class itself.

YourGame.Player = function (game) {  this.game = game;  this.health = 100;  this.sprite = null;  .. various other player related properties}YourGame.Player.prototype = {  add: function (x, y) {    this.sprite = this.game.add.sprite(x, y, 'playerimage');  }  .. various other useful player related methods here}

Create the Player object when the game starts, add a reference to the object into your level and so forth. When you change state this object will still exist quite happily (although the sprite value will be reset as the display list is cleared on state change). So you can just add it back in again on the next level.

Share this post


Link to post
Share on other sites

Hey Rich,

thanks for the answer,

 

I would suggest recommending in the documentation using RequireJS or whatever AMD framework you prefer,

this helped alot on ImpactJS I think it would be great to embrace it here as well.

Share this post


Link to post
Share on other sites

It is your decision, but those kind of AMD's are designed for complicated architectures like Single Page Apps and Games.

 

Think about a situation when a game have thousands of lines of code, without AMD, you have to load all the code to the DOM at once which takes time, and some of this code may do some very complicated calculations when its loaded, so it can even increase the loading time much lmore.

 

With separation to modules, you keep the code DRY, with dependency injection which tear up your spaghetti code of dependencies and decouple it, and the best of it is that the code loads asynchronously, so only when the modules are needed they are called.

 

Just think about it... it's not related to website and it's not related to games, it's relevant to any piece of code.

Share this post


Link to post
Share on other sites

I've written JS games with thousands of lines of code and I would still always preload the source files up front. You'd never really have complicated calculations in object constructors (and even if for some reason you did, they wouldn't actually be run until instantiated), there's little to no impact on load time. The code minifies and compresses to a few hundred KB (in this specific example), smaller than even the preloader image assets. Having code load at run-time isn't a good thing in my books, the absolute last thing I want is for my games to be hanging waiting for something to load, especially not code, especially when I have to ensure they run over crappy 3G connections where it's possible to loose connectivity at any point.

 

You can keep your code clean and separated without using AMD, plain old traditional good programming practise does that.

 

So, no. I will never enforce someone using Phaser to have to put up with AMD or similar. It's properly wrapped if they want it, but equally happy without it.

Share this post


Link to post
Share on other sites

I appreciate that call Rich, and totally agree.  While the AMD module approach has much to recommend it and has many adherents, there is an entire other camp of people who prefer CommonJS modules (ala Node.js).  It's one of those religious wars that would be good to stay out of in any event - and as you say, there is no need to be so opinionated about modularization when most games will get by just fine without either approach.   Finally, as you also mentioned, Phaser does not prevent folks from choosing either or neither approach, which would seem the best of all possible worlds. 

Share this post


Link to post
Share on other sites

This sounded so simple the first time I read it, but unfortunately I'm having trouble with it. I have a player class that looks something like Rich's example below, as well as various states corresponding to different parts of my game -- boot, preloader, level1, level2, etc . But what I'm unsure about is where to "create the player object when the game starts" and then how to "add a reference to the object" in each level. Do I create the player in my index.html where I create the main game variable? Or do I create it in Boot.js where I have some other global variables as part of the BasicGame object, like "score" for example? I assume I need to do something like: var player = new BasicGame.Player(game) at some point, but I'm not sure where and I haven't figured it out by experimentation yet. I would appreciate any help. 

 

You'd create them in objects outside of the State class itself.

YourGame.Player = function (game) {  this.game = game;  this.health = 100;  this.sprite = null;  .. various other player related properties}YourGame.Player.prototype = {  add: function (x, y) {    this.sprite = this.game.add.sprite(x, y, 'playerimage');  }  .. various other useful player related methods here}

Create the Player object when the game starts, add a reference to the object into your level and so forth. When you change state this object will still exist quite happily (although the sprite value will be reset as the display list is cleared on state change). So you can just add it back in again on the next level.

Share this post


Link to post
Share on other sites

I got it working. I added:

BasicGame.player = new BasicGame.Player(game)

To the javascript section in index.html right below the line where I created the game var. 

 

It didn't work right away. When I called BasicGame.player.create() in the create function of my level prototype, it didn't work. When I changed the player function name to add() and called BasicGame.player.add() it worked. On the other hand I was able to call BasicGame.player.update() in the update function of my level prototype, and that worked fine. 

Share this post


Link to post
Share on other sites

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.

Guest
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.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.