eddieone Posted July 22, 2016 Share Posted July 22, 2016 Let me introduce you to the Phaser Goldilocks Template. It combines everything I wanted during that first week of Phaser. This solves a few things. First, for development all code can be separated into different JS files. For production, all JS files can be combined into a single one for the fastest loading. The second thing this solves is the common scoping pitfalls I see many people encounter. So no need to use prototype as the game variable is available in each file. https://github.com/EddieOne/phaser-goldilocks-template dr.au 1 Link to comment Share on other sites More sharing options...
crazyDev Posted August 2, 2016 Share Posted August 2, 2016 I haven't used grunt before. Can you please elaborate on how to use this template? The instructions on github page are too short. How can use it with XDK as I want to package the result with crosswalk. Link to comment Share on other sites More sharing options...
mattstyles Posted August 2, 2016 Share Posted August 2, 2016 Not sure you're asking for feedback but... * You need to mention global dependencies you need, node is a given as you're expecting an npm install but grunt-cli is not, either add it as a project dependency (best solution so you don't nuke the target system with global deps, not sure you can with grunt though) or state that you need it. Ditto for cloning the repo and killing the existing git history, I dont want all that for a new project, I want it nice and clean. * No idea where your prod build is, I see an uglification but in your post you mention a concatenation, that does not currently exist. * Keeping your deploy/target around (i.e. persisting between builds) is a serious bad idea, like, terrible. At the very least you should nuke that folder with every deploy, so you start from clean and you have your automated build scripts build everything. The only criticism here is that a clean install is timely, but, how often do you deploy? Shouldn't be too regularly (by not regularly I mean, you don't deploy a live build on every code change/save, if you get your CI/CD right then a deploy nightly is a good goal) so time is not a factor, although reliability and consistency are. If you build into a dev folder (you don't here) then time becomes a factor and you can probably accept some sacrifice to consistency, but certainly not for a deployable version. * If you're worried about the latest version of Phaser don't include it in your repo, either ask people specifically to include whatever version they want (i.e. latest), include a script to grab the dependency (akin to npm install), you may also want to manually trigger that script on npm install, perhaps even checking to see if a newer version is available. The url's all exist so the script is fairly trivial. * In your current setup you don't need to wait for the window load event, you've stuffed all your deps into the head so they'll all be there by the time it hits your script, just out of interest, why include that directly into the html? sure, it saves a further request but just seems odd to separate it from the rest of your JS. * You mention solving scoping issues, again, I dont see it, looks like fairly standard Phaser architecture (which is good). How does your project scaffold help with scoping issues? I also see a load of variables being declared in Game, whats the thinking there? * What's the banner doing in there, you don't use it anywhere? I love seeing people create tooling, but, bad tooling is a real put-off, particularly when people using that tooling have invested some of their effort & time into using it. I don't think you're far away from creating a good start for people to use, just gotta tighten up the edges (calling it the Best Template in your post header is bold, and, sadly, totally unfounded, it certainly isnt the best...yet). drhayes 1 Link to comment Share on other sites More sharing options...
eddieone Posted December 7, 2016 Author Share Posted December 7, 2016 @mattstyles Thanks for viewing the code. Please create a pull request. I took this from a project I worked on and decided to share it for free. At the vary least, you could create an issue for each problem and hope someone will be able to do it. This is the open source way. Posting on a forum that doesn't have good notifications is not a good process for open source. Link to comment Share on other sites More sharing options...
drhayes Posted December 7, 2016 Share Posted December 7, 2016 I think having frank discussions about code *is* the open source way, especially on forums where you posted about the code in the first place. Yes, you did put this out there for free... but matt also gave you his advice (and a lot of it!) for free, right? mattstyles and Skeptron 2 Link to comment Share on other sites More sharing options...
mattstyles Posted December 8, 2016 Share Posted December 8, 2016 @eddieone yeah, I'm going to avoid a war about this, open source is not, "get other people to fix the problems they see", many times problems can be seen but not easily fixed. Part one of any software development (OS or not) is visibility of current or potential pitfalls, actually part one might very well be encouraging people who might have advice on those things to be a part of your project. Some of my points fit nicely into an issue and a PR, some need discussion, github has facility for that to happen within issues but you do realise OS is not a github specific thing, how do you think collaborators communicated before github issues existed? This is a place to discuss and you've posted it here, so discuss, tell about your project, tell us how it helps us, tell us what you're doing to improve it. Phaser and Pixi (and presumably the other libs/frameworks here) do a great job of discussing issues here and within the walls of github and they benefit from discussions in both places. drhayes and Skeptron 2 Link to comment Share on other sites More sharing options...
Skeptron Posted December 8, 2016 Share Posted December 8, 2016 Love the title. You just forgot to add "by the best dev ever". mattstyles and drhayes 2 Link to comment Share on other sites More sharing options...
Recommended Posts