Phaser World Issue 28
When most people pick-up Phaser, the main thought going through their mind is "let's make a game". They've probably already got a rough concept planned, an idea of how it'll play. They start throwing some sprites around the screen, dropping in assets, tweaking, testing and refining, until they've got a game, or at least a prototype of one, running.
If they wondering how to code something they will likely look at the docs or an example, perhaps refer to a previous project, or ask online. Once they find an answer they'll implement it, and if all is good they move on to the next part of their game. This is a natural and logical process.
However when I code a game in Phaser I find it virtually impossible to do this.
There isn't a single line of code in Phaser that I haven't read multiple times. Indeed the overwhelming majority of it I actually wrote. So I intrinsically understand what it can do, and which bits to use. This may sound like a God send, but more often than not it feels like a curse. Because when I look at function I can't help but think "it should be easier than this", and then get side tracked from the game I was meant to be writing.
For example at the moment I'm building a Fruit Machine game for the Interphase 2 book. I instinctively knew that the fastest way to handle the spinning of the fruit machine reels would be to use a TileSprite with a large vertical texture. I was right, and within a very short while I had a realistic looking spinner that ran well cross device. With a fruit machine you of course need it to stop spinning and be perfectly aligned with an item. This in itself was an interesting issue: how to use TileSprite.tilePosition to align a texture to the center of the TileSprite, regardless of what dimensions either had. I solved it for the game, but in doing so I couldn't help but feel that the TileSprite class should have been capable of doing this for me already.
In a similar train of thought I was updating the Phaser Invaders game, and I was frustrated that having to iterate through a for loop just to position the sprites in a grid formation was something the Group class should be able to do for you.
It's a fine line of course. When I used to work for The Game Creators we would joke that what people really wanted was a language with a "make game" function. But it's too easy to think "the dev will figure it out". In most cases they can, but that doesn't mean they should have to, and those that get frustrated and leave are the very ones you want to help the most.
Phaser isn't just about creating games, it's about creating them easily, with as minimal code as possible. It's about removing road blocks to common development tasks, not just the hardcore ones. And every time I sit down and use it I find myself seeing road blocks that I want to smash.
I guess that's the problem of being both creator and consumer. You see imperfections where others may not, you constantly challenge the status quo and want to push in new directions. It's part of what gets me out of bed in the morning, but it can drive me to distraction as well.
As soon as someone starts to use what you've created it inherently places shackles on progress. As soon as thousands of people are using it, whole companies relying on it, the responsibility becomes even greater, and the fear of change even more compounded.
At the end of the day though it's only code, and you should always put people before code. Help them create, to not get bogged down in the nitty gritty. Let them be explorers rather than forcing them to be experts.
When most people pick-up Phaser, the main thought going through their mind is "let's make a game". They've probably already got a rough concept planned, an idea of how it'll play. They start throwing some sprites around the screen, dropping in assets, tweaking, testing and refining, until they've got a game, or at least a prototype of one, running.
If they wondering how to code something they will likely look at the docs or an example, perhaps refer to a previous project, or ask online. Once they find an answer they'll implement it, and if all is good they move on to the next part of their game. This is a natural and logical process.
However when I code a game in Phaser I find it virtually impossible to do this.
There isn't a single line of code in Phaser that I haven't read multiple times. Indeed the overwhelming majority of it I actually wrote. So I intrinsically understand what it can do, and which bits to use. This may sound like a God send, but more often than not it feels like a curse. Because when I look at function I can't help but think "it should be easier than this", and then get side tracked from the game I was meant to be writing.
For example at the moment I'm building a Fruit Machine game for the Interphase 2 book. I instinctively knew that the fastest way to handle the spinning of the fruit machine reels would be to use a TileSprite with a large vertical texture. I was right, and within a very short while I had a realistic looking spinner that ran well cross device. With a fruit machine you of course need it to stop spinning and be perfectly aligned with an item. This in itself was an interesting issue: how to use TileSprite.tilePosition to align a texture to the center of the TileSprite, regardless of what dimensions either had. I solved it for the game, but in doing so I couldn't help but feel that the TileSprite class should have been capable of doing this for me already.
In a similar train of thought I was updating the Phaser Invaders game, and I was frustrated that having to iterate through a for loop just to position the sprites in a grid formation was something the Group class should be able to do for you.
It's a fine line of course. When I used to work for The Game Creators we would joke that what people really wanted was a language with a "make game" function. But it's too easy to think "the dev will figure it out". In most cases they can, but that doesn't mean they should have to, and those that get frustrated and leave are the very ones you want to help the most.
Phaser isn't just about creating games, it's about creating them easily, with as minimal code as possible. It's about removing road blocks to common development tasks, not just the hardcore ones. And every time I sit down and use it I find myself seeing road blocks that I want to smash.
I guess that's the problem of being both creator and consumer. You see imperfections where others may not, you constantly challenge the status quo and want to push in new directions. It's part of what gets me out of bed in the morning, but it can drive me to distraction as well.
As soon as someone starts to use what you've created it inherently places shackles on progress. As soon as thousands of people are using it, whole companies relying on it, the responsibility becomes even greater, and the fear of change even more compounded.
At the end of the day though it's only code, and you should always put people before code. Help them create, to not get bogged down in the nitty gritty. Let them be explorers rather than forcing them to be experts.