Official Phaser 2.0 Book - Looking for feedback

[lessmilk]

Hi everyone,

 

Phaser is getting a lot of attention lately, and with the new 2.0 release it now makes sense to have an official Phaser book. It would be the perfect way to learn and master our favorite HTML5 framework. That's why Rich and I are really excited to start working on the first Phaser book! We have a few interesting ideas in mind, and we’d like to share them with you to have your thoughts. 

 

We think that the perfect Phaser book should contain two main things:

- Some theory: a reference manual containing all the classes explained

- Some practice: a lot of tutorials to learn how to make different types of games

 

This looks nice, but would require too much work to do at once. So we plan to split the book in two parts, released a few months apart. We are currently considering two different options on how we could split the book.

 

Option 1: Split by theory/practice

- First book: only a reference manual, covering all Phaser classes

- Second book: full of tutorials on how to make different types of games

This option is the cleanest one, but we are afraid that releasing a “reference manual” first is not really appealing to people.

 

Option 2: Split by difficulty

- First book: cover the basic Phaser classes + some tutorials on how to make simple games

- Second book: same as above, but more advanced

This option seems more user-friendly (just pick the first book to start learning and making games), but this might be a bit messier.

 

What do you think? Choose your favorite option in the poll I created above. 

And more broadly, we are also interested in your thoughts about the book (your feedback, the type of game tutorials you'd like to see, etc.) :-)

 

We are just starting to work on the Phaser book, so we don’t know yet when it will be released or it’s price. But if you are interested to learn more about the book, make sure to visit phaser.io/book to sign-up to the newsletter.

 

Thanks,

Thomas & Rich.

[Heppell08]

I back this idea 100000000%

I'd say spilt the difficulty. Ease them in with the basics then start throwing some epic dev shapes at them. But yeah this is an epic idea!

[Kai]

Option 1 seems to be less popular so far, but I'd much rather see a clean, well documented reference book.  There is plenty of opportunity to review examples and tutorials on the website and in these forums.  I'd rather absorb tutorials online than as a book anyhow.

[Rollover]

In my opinion reference material should always be freely available as part of the Phaser documentation. There's no one stopping you from formatting it nicely and also selling it as a reference book. When the reference material is ready you can start writing the tutorial book. Every time a new concept is used, It should point to the appropriate sections in the reference documentation. Additionally it should also contain a chapter on how to effectively use the reference documentation since that is a huge barrier for beginners.

[Rocco]

great idea!!!
 
I prefer an almost complete scripting reference sheet at first, so my vote goes to option 1.
I think its the most neccessary thing when you work on a bigger project 
 
I would like it this way (AGS-Engine) with little practical examples, so that even a newby can follow the idea behind the functions with ease:

 

 

DrawCircle DrawingSurface.DrawCircle(int x, int y, int radius)
Draws a filled circle of radius RADIUS with its centre at (X,Y) in the current drawing colour.

Example:

DrawingSurface *surface = Room.GetDrawingSurfaceForBackground();
surface.DrawingColor = 14;
surface.DrawCircle(160,100,50);
surface.Release();
will draw a circle in the centre of the screen, of 50 pixels radius.

See Also: DrawingSurface.DrawLine, DrawingSurface.DrawingColor

[elwis]

love the idea, Im just about to play around with phaser myself and would love one. (can it be written this weekend, pleeease.. )

 

Option 1 is, as you say, less user friendly. Newbies with less programming experience won't have much use of a reference book I'm afraid, so my vote must be on option 2. However, a reference guide is awesome once you know the basics so ...

[TeamAtomicJim]

I prefer option 1, it annoys me when I buy a book about an engine and the information is kept to a simple level. I buy a book so I can sit and study the engine away from the computer and hope to gain a deeper understanding. Explaining the design rationale behind the classes and their structure would help the reader utilise them more effectively.

Regarding the second book, you already have a fantastic wealth of samples available so what I would like to see is an in depth study of a projects life-cycle from cradle to grave. The project would need to pick a game genre that covers many of the typical topics. Doing it this way the reader would see how all the different topics fit together in the overall implementation, something that usually gets lost with isolated examples/tutorials.

[Mike]

I'm really behind the idea.

 

And 100% sure that Option 2: Split by difficulty is the way to go.

 

As developer, reader and gone trough some tutorials, game and language books and articles

the best ones for beginners and intermediate are the ones which makes you crate something - practical experience is a must.

 

For advanced and more experienced developers things like optimizations and coding patterns are way more interesting and useful.

 

And also class reference with explanation is cool for documentation... but nobody wants to read them as book... because well it's reference when i get there I'll read it.

[ctmartinez1992]

I think that you should go for the less friendly option, which is option 1 unless, your objective is to make profit from the book. My reasoning is that hardly anyone will buy the book to learn the basics of Phaser when there is so much online content. I think that the book should have great insight on how the engine works and how it does stuff internally. Just my 2 cents...

[jerome]

option 1

A book is the final reference, kind of Phaser Bible.

The verb.

Where everything is described, explained, why, how, what.

 

We can still find tutos, examples, help on the Web, on this forum, etc.

[nem0ff]

In my opinion reference material should always be freely available as part of the Phaser documentation.

+1

Reprinting the documentation on a framework that evolves as fast as Phaser doesn't feel as valuable to me.

+100

[chib]

I would prefer to see a strong reference manual first, I'm sure the community is more than up to the challenge of providing some tutorials in the meantime. 

[Lonan]

What will the reference manual consist of?

 

For instance, will it contain code examples/snippets and use cases?

 

Currently I've voted for option 2 since I understand things better by seeing them in use, but if there are loads of examples in the reference manual, then I'll easily switch to option 1.

[codevinsky]

I think you should do away with the reference manual all together. The documentation for Phaser is actually pretty fantastic and explains how to use the classes perfectly already.

 

I think a single "Learn By Example" or "Cookbook" tome would be the best bet. In doing this, it's likely that you'll cover most of the basic and some of the advanced usages of all the classes already, you won't duplicate effort, and you'll minimize redundancies.

[drhayes]

I'm the kind of dev that hoovers up documentation and sits there reading about methods and classes trying to puzzle out how to fit them together. Reprinting the documentation on a framework that evolves as fast as Phaser doesn't feel as valuable to me.

 

I think a "how to put it all together" book would be super valuable. It could answer questions like (pardon my newbishness if these are obvious):

 

* When loading levels, why would you also switch states? Why would you not?

* When should you choose the Canvas renderer over the WebGL renderer?

* When would it make sense to use a bunch of sprites vs. a group?

* What are some performance considerations around using sprites vs tilemaps?

* Advanced strategies for using Tiled? (object layers, interpreting custom properties, etc)

 

I'm biased but it'd be neat to show an actual game, soup-to-nuts: start with some images, talk about why they're sized the way they're sized (power of 2, all that), bring them into Tiled, make three levels, create the game (boot, main menu, level 1), how to switch levels, etc.

[StuffBySpencer]

Option 2 sounds best. That way people can read the first one, practice and by the time the second one comes out, it may be easier to learn. Either way, awesome idea! Thanks for your contributions!

[i3Designer]

Fantastic Idea! I want them both.

[luxgud]

Option 2 (or two books)

 

I teach and therefore I need worked examples. I know there's a lot of documentation already, but worked examples that can be added to is useful.

When looking to use a HTML5 game engine, having a book was a big influence. I was almost going with ImpactJS (which has two books already out) but development seems to be stopped or at least resting.

 

I love the simplicity of Phaser. Please don't ruin it

 

Thank you 

[luxgud]

When will it be published/available - approximately ?

What format - pdf, printed or both (PACKT Publishing are recommended)

 

thanks

[hongping]

Like this idea of books. I like option 2 more. Reasoning is that the API can be viewed online. Best is in the books, kindly add some examples walk through .

[jerome]

I've been buying computer books (languages, frameworks, etc) in french and english for years.

Imho, a good example of very attractive book is "Agile Web Development With Rails".

As far as I can remember, the first chapter is very long and only describes a complete use case : how to develop a merchant web store from scratch. It's like a incremental tutorial (authors do errors in purpose, then fix them) covering main framework features and revealing concepts to readers by examples.

Then next chapters are the reference : not by classes (API is enough), but by modules or concepts. Explaining how, why, what, etc.

 

The same model to Phaser would be :

a first long ambitious chapter : coding a whole game with states, sounds, sprites, atlases, particles, tilemaps, physics, persistent objects, js optimization and organization (a complex platformer ?), propose webgl enhancements for desktop (filters, etc) or sweet degradation to mobiles. Everything along a practical coding process with common errors, workarounds, etc.

 

next chapters would then be the reference featuring concepts in groups of classes :

Game (classes : game, state, stage, world, how they interact, and moreover what's under the hood : when an object is inserted in the world, when it's inserted in the display list, when rendered, etc), Sprite (sprite, groups, body, physics, particles), Physics (each engine, how manage many at once, etc), Tilemaps, Inputs, Preloader (cache, http concerns, etc)

Or other pertinent organization.

 

Just my suggestion ...

[iam13islucky]

jerome, I'm right there with you. If there was a big, catchall tutorial for phaser, I would have a much better time getting into it. I'm still very new to game development, and if there was a tutorial for using most common elements of phaser, I would be able to get the concepts easy. Having the rest be a quick reference for the concepts, or better yet some other things you could add to the game, would be even more help!

[xronn]

I'm a fan of option 1, but I think its important to do examples of how to use the classes a book sort of like the documentation maybe like this format;
 

game Phaser.Game

A reference to the currently running game.

x number

The x coordinate (in world space) to position the Sprite at.

y number

The y coordinate (in world space) to position the Sprite at.

key string | Phaser.RenderTexture |Phaser.BitmapData | PIXI.Texture

This is the image or texture used by the Sprite during rendering. It can be a string which is a reference to the Cache entry, or an instance of a RenderTexture or PIXI.Texture.

frame string | number

If this Sprite is using part of a sprite sheet or texture atlas you can specify the exact frame to use by giving a string or numeric index.

But then below how to use it aswell like this;

 

hero = this.add.sprite(135, 380, 'hero');

[jerome]

I personaly tought about something different from the API doc which is enough by itself.

Something more explaining what are the concepts used, how they are implemented, how they interact which others, etc...

I tried in that way here :

https://github.com/photonstorm/phaser/wiki/Phaser-General-Documentation-:-Game

https://github.com/photonstorm/phaser/wiki/Phaser-General-Documentation-:-States

 

but I don't master everything enough to go further :-(

[Robert O'Rourke]

I'm not convinced a complete reference book is a good idea while the library is still developing. A physical book can end up out of date so quickly so my opinion is that teaching the methodology and approach to actually coding, structuring and organising different types of games is more important.