Hacker News new | ask | show | jobs
by aroman 3048 days ago
I've spent the past 6 months building a game[1] using Phaser and TypeScript. On the whole, it's been a great experience.

Actually, I was surprised to see this posted here now, since Phaser 3.0 is not yet out. It's mostly feature-complete, but they're still working on docs and preparing for the release (in the few days to a week). I've really enjoyed following the v3 devlog[2]. Richard Davey's dedication to the project and his and the other contributors herculean efforts towards v3.0 have been inspiring to watch. Truly a labor of love.

Some tips for others based on my experience with Phaser:

- USE TYPESCRIPT! One of the worst parts of Phaser is its documentation. In fact, the docs on the main website have been outdated by about 4 major releases, and the new docs are ugly and hard to use. TypeScript + VSCode massively improves this experience, by auto-completing functions and adding inline JSDoc info.

- Webpack is great, but hard to use with Phaser 2 OOTB. This may be a moot point since V3 is almost here, but if anyone wants to see how it can be done, my whole game is open source[3].

- Phaser.Group is a weird concept, but very powerful. Not only useful for object pooling, but also for creating custom GUIs using surfaces with coordinates relative to the group size/position. Makes nested dynamic UIs very easy.

- Phaser's scaling system[4] is awesome. Use it. Don't try to reinvent the wheel yourself!

Richard and crew, if you're reading this, THANK YOU! You've built an incredible project. Thank you for sharing it with the world.

[1] http://www.toomanycaptains.com/

[2] http://phaser.io/phaser3

[3] https://github.com/TooManyCaptains/TooManyCaptains/tree/mast...

[4] https://photonstorm.github.io/phaser-ce/Phaser.ScaleManager....

5 comments

My open source game is Electron+PhaserCE+Typescript+Webpack.

I tried to avoid webpack since I knew compile time would be an issue for my other team members and it turned it out it was. As a web-dev I'm use to its workflow but onboarding game devs hate it. I have to hear everyday lets move to Godot, Unity, Unreal Engine because waiting 4 seconds for compiling is a headache.

Switching to Typescript is great for larger teams because it makes properties explicit. I personally like coffee-script and find it more productive if I'm the only dev but I swallowed the medicine on this one and it was worth it.

VSScode is powerful with Typescript but its not as productive as VIM. I think of code completion and seeing errors right away as crutches that atrophies a developers own skills to find code and errors but they can make it much easier for juniors and lower the bar, pair this with wallabyjs and you have a controlled environment that catches everything for you.

I found no resources on testing Phaser but figured out my own way of mocking Phaser objects, and came up with my own way to write acceptance-like tests for my game without electron.

I really wanted to contribute to Phaser3 and had put great effort to join but Richard was useless in responding. He said he was porting their tickets from Trello to Github and then I could contribute which never happened, I asked month over month. I really wanted to use Phaser 3 to future proof my game and I would have contributed significantly. I could have forked PhaserCE but its a mess which makes sense for the rewrite but working blindly on Phaser 3 would be futile. I am quite bitter about bitter about this because I 20 hours a week for 6 months I could have contribute and now I don't

I think I will likely just write my own lightweight game framework to map only what I need and gut Phaser. Even looking at Phaser 3 codebase with their big rewrite from scratch its still clunky and I think this is because they don't build games at a large scale with a team to have a good feeling to fine tune an engine.

https://github.com/omenking/swap-n-pop

>> would be an issue for my other team members[...] I'm use to its workflow but onboarding game devs hate it. I have to hear everyday lets move to[...] I personally like coffee-script but I swallowed the medicine on this one[...] I think of code completion and seeing errors right away as crutches[...] make it much easier for juniors and lower the bar

That's an awful lot of "I am very smart" for one comment. You shouldn't need to repeatedly insult your fellow team members to express your thoughts on such matters.

Preferring vim over an IDE isn't enough to convict, but when someone starts associating the use of an IDE with "juniors", the verdict is guilty. Your choice of tools should be about getting the job done efficiently - using vim isn't a skill that demonstrates seniority or superiority.

>> I really wanted to contribute[...] put great effort to join but Richard was useless in responding[...] I asked month over month[...] I would have contributed significantly[...]

Classic "nice guy". You might have taken the hint after the first few weeks - or months - that he wasn't interested. I'm sure that, upon reading your comment, he would be relieved to know he didn't invest his time onboarding someone who would have sucked the life out of the project.

Source: You sound like me 10 years ago. Right down to the perspective on vim.

`I think of code completion and seeing errors right away as crutches that atrophies a developers own skills`

Really? You would rub sticks together for fire rather than use modern tools such as a lighter? I can't see how this reflects being a better programmer. While you are rubbing sticks, I am probably wondering how X can be improved and implementing that.

Ugh, this point of view is so annoying. Just because you prefer an IDE to something like VIM/Emacs doesn't mean your skills are less in any way. Such an elitist way of thinking.
Debuggers, autocompletion, even syntax highlighting help a great deal. I like to think that they let you program on a higher level.

I usually program in Emacs, but fire up an IDE when I need to debug or want some assistance in navigating the codebase or learning some new library.

I find that the code I write in Emacs is much more succint and cleaner. I think the more layers you remove, the more you can focus. I bet that if I wrote my programs with pen and paper, my programs would be much more beautiful.

But if you need to manage complexity, it is far more feasible to use an IDE.

Choose the right tools for the job. Use editors/pen and paper/whiteboards/IDEs to meet your requirements.

Advocating the use of text editors over IDEs is IMHO the typical example of the "Real programmers use Fortran" syndrome.

Fwiw with a couple of plugins[1], I have very nice code completion in vim with ruby/rails along with useful "go to definition". Perhaps not as challenging as punching cards - but it's not like vim is some kind of bare bones editor...

[1] for a starting point see https://github.com/tpope/gem-ctags/blob/master/README.markdo... I'm on my cell, but as far as I can rember my ruby specific part of vim rc is ~5 lines or so. Coupled with 'guard' to run ctags over changed files...

At a glance, this seems to cover the essentials:

https://chodounsky.net/2016/12/09/using-tags-to-browse-ruby-...

FYI, I just tried your game on windows 10 and the "enter" key is not working to start the game. So I can't get past the start menu. No errors or warnings in the console.
For Ludum Dare 34, my friends and I used Phaser and Typescript to make a Jam-game[0][1].

(meaning: team-based, has more days available, not part of the main "competition", which is about the solo achievement of making a 48 hour game)

It was my first introduction to either, and none of us had used Phaser before. My experience matches yours: combining the two made for a great dev experience, and the docs are confusing at times.

Luckily my friends Thomas ten Cate (aka Frozen Fractal) and Marten Veldthuis (aka... Marten Veldthuis) are excellent developers, who have struggled with way worse documentation, so we managed anyway. Docs aside, Phaser-the-framework seemed very well constructed.

Tangent: a few competitions later Thomas made Leonardo's Paint Machine[2], which is so amazing, especially for a 48 hour game, that I'll link it despite being made in a different framework (he uses Ludum Dares to try new out new frameworks and such).

[0] http://ludumdare.com/compo/ludum-dare-34/?action=preview&uid...

[1] https://blindedcyclops.neocities.org/ld34/index.html

[2] https://frozenfractal.com/games/leonardos-painting-machine/

If we’re doing tips, here’s another: don’t use bazillion timers to control your actors lifetime! Timers array gets resorted at every addition and that can really add noticeable lag on slow devices. If you need to, rewrite the add timer method to use an insertio sort instead of adding last then sorting the whole array

(I was using timer instead of collision for bullets since I had the hit/miss outcome coming from a percentage base rile as opposed as game phisycs and expired bullets just at the right time to make them appear misses - maybe not the greatest idea mind you but eh got it working and was cool enough)

imho the reason why Phaser docs are so bad is an excuse to sell... Books about Phaser. Maybe I'm wrong, but why they exists if community repeated many times that docs should be improved?
Hanlon's Razor. It seems to me that if there's limited resources, then if they've decided that they're not using "documentation as marketing" (which for free frameworks doesn't seem to be the best strategy to be honest), then directing time to developing paid for learning materials over and above using that time for free docs is a valid strategy.

I can't imagine any project deliberately having crappy docs in order to sell resources, as you'd get almost no buy in to begin with.

hmm I mean that could be why, but the simplest explanation is that they're lacking the peoplepower to work on documentation.

Who wants to work on docs after all? Some people, but probably not enough

everyone is entitled to an opinion, even if that opinion is quite clearly wrong. Phaser is a tiny team of very dedicated individuals and they have successfully produced one of the best JS/TS game frameworks. If you want better documentation, why not produce some? Want to help the team grow so they can afford to employ someone to write docs? Buy the books, pledge to the Patreon. Basically: help in some way. That's much more productive than suggesting they did all this work simply to sell some books.
An opinion can't be wrong, a statement maybe, but a statement "this is what I believe: <opinion>" is in any case not up to debate. Because An opinion has to be supported by arguments and those can be wrong. But of course, you are entitled to your opinion.
fair point. I disagree with his opinion because what he is suggesting is wrong. They aren't doing this to sell a few books.