Jump to content
GameMonetize.com © The leading broker of high quality cross-platform HTML5 games ×

phaser with es6

Cedric

By Cedric,
in Phaser 2

 Share

Recommended Posts

Cedric Newbie

Cedric

Posted
Posted

Hey everyone,

Just a quick question: Can we build phaser games with es6 ? 

I'm currently learning the es6 language by making pong, and as I go along I want to make the same pong game but with using phaser or Lazer.

Very Kind Regards,
Cedric

Link to comment
Share on other sites
fillmoreb Newbie

fillmoreb

Posted
Posted

Boilerplate simply refers to the code that you have to write every single time you do a specific task.  Here's an example of an HTML boilerplate. 

<!DOCTYPE html>
<html>
<head>
	<title></title>
</head>
<body>

</body>
</html>

For the purposes of this conversation, however, you can use the term interchangeably with template.

https://en.wikipedia.org/wiki/Boilerplate_code

Link to comment
Share on other sites
eXilz Newbie

eXilz

Posted
Posted

@Cedric I think it's really basic for now. It's probably because you haven't actually started working on the game yet :)

You'll find that you will need a more complex folder architecture once your game will start to grow.

As for the use of ES6, I simply cannot imagine someone making a big serious game with Phaser without using either TypeScript or ES6 ! It's fantastic.

I highly recommend this boilerplate though, it comes with a preconfigured Gulp so you can just jump right into it without worrying about the tooling too much :

https://github.com/belohlavek/phaser-es6-boilerplate

Link to comment
Share on other sites
mattstyles Newbie

mattstyles

Posted
Posted

I dont see anything wrong with your template, it scaffolds out your build system for you so that you dont have to go through the repetitive work and just start coding whatever your new project needs.

Is there a typo in the package? Are you starting a dev server using budo? the script says bodu.

Also, if you are using budo to fire up the project, you should have it as a dev dependency and I certainly would not expect npm to be a dependency.

You are also committing source and dependencies to your version control, this is unnecessary and is bad practise. Your VCS (Git) should contain just source, your scripts then build out your code on whatever architecture that source is to run on (with front-end JS this is kind-of moot but its a good idea to follow along anyway).

I'd also strongly advise that you separate your source and your production/distributable code. Whack game inside a `src` directory and have your build output into a separate directory, depending on your own convention you could call this `lib`, `dist` or `prod` (you can call it what you like but its usually preferable to stick with convention when it does not harm your project, that way other developers can jump in and understand what is happening, my recommendation for front-end code would probably be `dist`).

There is also no mention of how you are actually building your .js files in your package and all info should be in there. Budo works by piping browserify straight into a transient html scaffold (you can supply this), it is not a build system, it is just a development environment that makes it easy to mock your build process.

There is also no need to call your source files .es6, your files are javascript and should be labelled as such, again, this is so other developers can understand quickly what you are doing. es6 is not some separate thing, it IS javascript, the only issue is that browsers do not (yet) fully understand it, that is a separate concern and you shouldnt really make developers jump through another barrier.

These are all small things, and, as always with these things, if this scaffold is primarily for you and you like it this way then keep the way that makes sense to you.

Link to comment
Share on other sites
Cedric Newbie

Cedric

Posted
  • Author
Posted

Dear Mattstyles,

half of the things your were saying were Chinese for me since I am a true novice when it comes to all this :P

I am just in my first week of es6 and babel and all that ^_^

My plan was on building a sort of template that copies my file structure but that didn't work out since I have no clue on how to do it. The compiling side of it all, is done with language babel. which recognizes the es6 extension. This made it easy for me to see which file was the es6 file and which was the transpiled js file. My main focus was on how to get it all working not particularly on how it is done. I think I was mixing all sorts of tutorials together. Hense the budo type. I couldn't figure out how to use budo to make a server like you would with a phaser project using an index.html file. So I stuck with good old MAMP and went that route. 

So the budo was a remaining thing.  But further more I don't understand the most part of what you all where advising me to do. What is the best I can do know to learn the ins and outs of everything. I really want to become a pro let's say in this because I find it insanely interesting. And it gives me a great foundation to start developing games with the upcoming Lazer :P

Also my actual achievement I want do get is to follow this tutorial: 

and make it in es6. with seperate files and all. But I want to understand every single part of it, from file structure to everything es6 and transpiling. the whole nine yards. Sure I can use a boilerplate which is awesome but as I said, I want to understand every step :D;) 

How would I approach this the best way ?

Thank you for all your replies and you all are freaking amazing people !!!

Very kind regards,
Cedric Van Roeyen

Link to comment
Share on other sites
mattstyles Newbie

mattstyles

Posted
Posted

Hi Cedric,

Well if you are new to this then your boilerplate project is even more incredible! Well done! And I totally agree with you that learning this stuff means learning all the stuff! The more you can soak up the better I think!

Nothing wrong with using a pre-built server, but, it is far far more than you need, at some stage you should learn how to fire up budo or a quick node static server, seeing as how you're JS anyway it makes sense and it can fit in with your existing build systems and dependency management (npm).

I'll try and quickly summarise some of the points (note that some of these are subjective, I've worked with some very very large companies who eschew these 'standards' and go their own way, they have their reasons, usually legacy, but just so you know there is no cut-and-dried best way to do things):

Github runs a program called Git, which is a version control system (VCS), or a source code management tool (SCM). Git should, ideally, only be used for your source code. In JS source code and production code is often the same thing, but, nowadays with stuff like ES6, Typescript, Coffeescript, concatenation, minification, uglification etc etc we often force ourselves into a corner where we differentiate between source and production, hence, we need to compile it ready for the target platform (in this case, the target platform is the browser, yes, there are a few, which complicates things). In JS-land we call this compile a build as in computer science a compile really means something else (this happens in the browser along with execution, dont worry about it, but if you want to know more check out just-in-time (JIT) compilation).

All of this means that you source code and production code are different and you need a build system, You can complicate this further by turning your source code into 'development' code, this is code that is understood by your platform (browser) but is not production ready. Usually this means that development code is unminified, probably contains source maps and probably outputs more logs or does some subtle things differently.

The key is that you've introduced a build system, and that means there needs to be some project structure.

First rule: Source code and Production-ready code do not live together.

You build system produces your production code. You then NEVER EVER EVER touch your production code. It is the product of your build system, the input is your source code and output is your production (or browser) ready code. If it is not building correctly then change your build script.

Second Rule: Never ever ever touch dependencies

Npm stuffs your dependencies into node_modules, this directory should be considered read-only. Dont touch it. There is a special place reserved in hell for developers who muck with dependencies. Dependencies are specified in your package.json and pulled in using npm, besides that they are a black box.

These two rules are governed by automation, they should be automatic processes. This helps to ensure they are predictable and repeatable. This is very important.

Neither of these rules concern your project source, they live outside of version control/source control (git) and should not be committed to the repository. Anyone wanting to use your project should follow your automated steps to get the dependencies and then the production-ready code.

So, how could this play out:

Consider a file structure like this: 

- index.html
- package.json
- src
   - main.js
   - module.js

In this case `main.js` contains some code but also links `module.js`. This is your source code and lives happily in the 'src' directory. We'll make the assumption both files contain es2015 code that requires a transpilation, babel will not care if the file is actually regular ole JS so the assumption is safe to make.

We can use babel to transpile our code, but, we've added a module, so we'll need something to pack up those modules. We can use browserify together with babel to do this (I'm following along from what you already have, which is 95% there). 

mkdir dist
browserify  -t babelify src/main.js > dist/bundle.js

Here we simply create a new destination directory (`dist` stands for distributable, again, this is by convention, sometimes `lib` is used depending on the project) and we use browserify and babel to turn our source code into something the browser can understand, even more helpfully browserify packages it all in to one file.

Our index file lives outside of source (to simplify things) but still within version control and contains a script tag pointing to `dist/bundle.js`. Fire it up and see your code running.

We can add this build script to our package.json so that other devs will know exactly how and why our project is doing stuff. Our final package.json might look something like the following (fields omitted for brevity): 

"scripts": {
  "prebuild": "rm -rf dist && mkdir dist",
  "build": "browserify --debug src/main.js > dist/bundle.js"
},
"devDependencies": {
  "babel-preset-es2015": "^6.6.0",
  "babelify": "^7.2.0",
  "browserify": "^13.0.0"
},
"browserify": {
  "transform": [
    "babelify"
  ]
},
"babel": {
  "presets": [
    "es2015"
  ]
}

We've specified the browserify transforms and babel config in the package.json (again, so its all in one place and clear), we've specified our build dependencies as devDependencies and we've added a short script that destroys the previous `dist` folder just before running the build script, this is important as we need to know that our built files are from scratch and not tarnished by previous builds (without this you will get stung at some point).

Now to build this project any dev knows that they just need to clone the repository, use `npm install` to install dependencies and run `npm run build` to turn our source code into production-ready code, they can then fire up index.html into a browser and see the project (this could also be automated). We'd add all this to the top of a readme just to be clear.

TL;DR

Sorry for the long post. 

The two things I think you need to clarify are separating source code and production code and maintaining a clean and well-defined package.json. 

 

Link to comment
Share on other sites
Cedric Newbie

Cedric

Posted
  • Author
Posted (edited)

thank you for your amazing reply and for the very kind compliment.

I decided to take the given boilerplate and learn from it and then improve my boilerplate from there :) Although the gulp stuff is quite a bit of Chinese still but I am starting to understand it a bit.

Making my project transpile to separate directories is something I have to look for ;) 

So if I get it correctly I should work with a clean and accessible project structure and then transpile everything in one (nameOfFile).js (bundel.js) file. and use a script tag in the index.html file to reference to the bundel.js file.

also the server side of things is something I need to look further into. Because I don't understand it yet, I do get that lets say mamp comes with all bells and whistles but it is kinda convenient if you want to test your game/project IMO, because I didn't know any other way than that. But I'm willing to learn the best way to test everything :P 

I am learning so much from you haha this is fun :P

thank you for you insanely useful and awesome advice and replies :) you and this community is freaking amazing :D

Very Kind regards,
Cedric

edit: I am heading into a busy period in school so my progression on all this will be slow :( I will let you know if I have been working further on this.

Edited by Cedric
just an added comment
Link to comment
Share on other sites
mattstyles Newbie

mattstyles

Posted
Posted
Quote

So if I get it correctly I should work with a clean and accessible project structure and then transpile everything in one (nameOfFile).js (bundel.js) file. and use a script tag in the index.html file to reference to the bundel.js file.

Yep, it makes life easier having the one bundle. Call it what you like.

Quote

Although the gulp stuff is quite a bit of Chinese still but I am starting to understand it a bit

Dont worry about it, dont use it. Gulp/grunt/etc are just another cog in the chain. They dont simplify anything, they complicate things, plus, adding more cogs into your chain is a bad bad thing, it simply means there are more points of failure. Your over-riding job as a software engineer should be to remove complexity, if you are creating it (no matter how inadvertently) you are doing it wrong.

Quote

 I do get that lets say mamp comes with all bells and whistles but it is kinda convenient

Yep, it is. Stick with it. Tackle one task at a time, then move onwards and onwards, one step at a time (this philosophy will also make you a better coder when you get to it).

Quote

I am heading into a busy period in school so my progression on all this will be slow

Programming is hard, seriously hard, take your time. It takes a long time to learn all this stuff. It isnt a job you can 'just do', you have to love it. You have to love learning about it, you have to love doing it. That means you'll put up with the fact that is hard and a long process.

Good luck with it all

Link to comment
Share on other sites
Cedric Newbie

Cedric

Posted
  • Author
Posted

 don't worry about my love for coding :P my school work is suffocating by it :P

So how do I set up such system ? Because I have no idea, I can write the package file but what about the transpiling and actual testing of everything.

Basically I want to use mamp and some sort of auto refresh so that I can test my game like I normally would.

@mattstyles Do you have some games that you made that I can see :P I am just curious what an advanced programmer can make :D

 

Very kind Regards,

Cedric

Link to comment
Share on other sites
mattstyles Newbie

mattstyles

Posted
Posted

Here you go, I knocked up a quick scaffold using es2015/16 and Phaser.

Instructions should be in the readme, dependencies all come from npm and are installed via `npm install`. Apart from Phaser itself, Phaser and browserify do not play nicely and its not worth fighting, just include the Phaser distributable as a script tag in your html, I've done it via cdn.

I'd ignore any actual game code, I've never used Phaser before so I was just adding some stuff from the getting started guide and trying to add a little bit of ES2015/16 to show that the transpilation works.

There is a live-reloading dev build and a script that will produce a production-ready build. Should give you something to build on, or ideas for improvement.

Link to comment
Share on other sites
Cedric Newbie

Cedric

Posted
  • Author
Posted

oooh my fucking god, well your are the god :P

thank you soo freaking much !!!!! you are awesome.

And I will learn so much from all this, you said you quickly did this !!! how long did it took you ? 

Link to comment
Share on other sites
mattstyles Newbie

mattstyles

Posted
Posted

Dont worry about it, its a good idea that all software has some sort of license (as with any product), but, it isnt necessary. In this case, I dont care what anybody does with the project (this does not mean that I dont care about the project), hence the WTFPL license, I could have just as easily used no license.

Link to comment
Share on other sites
mattstyles Newbie

mattstyles

Posted
Posted

Ah, I'm using unix commands to nuke the directory and recreate it, this will not work on Windows. There are node packages you can use instead though, rimraf and mkdirp.

I assumed you were *nix as you were using MAMP, didnt realise that it supported Windows.

I'll update the repo, although I'm sure you could work out how to do it yourself anyway.

 

Link to comment
Share on other sites
 Share
Go to topic listing

  • Recently Browsing   0 members

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