Reflection on Phaser

In the past, I have never worked with someone else’s library of code or game engine; everything that I have coded was my code only, therefore I was intrigued to be using a game engine for the very first time. Phaser 3 is the latest edition of the Phaser game engine, which gives you tools to create games in 2D using JavaScript. It has 4 key functions, that form the basis of your games: config, preload, create and update.

 

When creating a game completely from scratch, you must code everything yourself, allowing you to optimise code for your game. The drawback is that you must code potentially complicated maths functions to have basic physics and collisions. By using Phaser 3, I saved a lot of time that would have been spent creating collision and physics maths, as I could instead simply turn gravity on/off and use simple lines of code to cause objects to collide. While I did save a lot of time and lines of code, the collisions were simplified in places. Sloped tiles did not register as so, leaving them working like stairs despite being smooth.

On the whole, I found using Phaser 3’s built in arcade physics a faster solution than how I had been doing collision for past projects. I would like to explore Phaser’s other physics systems in the future, to compare their limitations and to expand my knowledge of Phaser’s capabilities.

 

During the development of my game, I had some friends who wanted to give the game a go on their mobile devices. Since I was using a game engine, I presumed it would be simpler to put in than coding by hand, as we did in the snake game. Personally, I had the opposite experience to what I was expecting; I could not understand how to implement the controls that I wanted, as the examples and API docs were not clear on the subject. I didn’t have the opportunity to follow through on this feature, and I wish I had simply used the same coding method as the snake game, rather than attempting to use Phaser’s.

 

When I am programming, my favourite part is debugging broken code to make it work. I enjoy how methodical tracing back through you code can be, despite my frustrations from the program not working. In particular, I can have a laser focus on the bug until it is fixed, and I can often resolve the issue in a single sitting. While using Phaser, my love of debugging was somewhat challenged. The tracebacks were significantly longer, as they often went through the Phaser engine’s code, and error messages were generally less helpful, as they would occasionally only give line numbers in the engine, or were about inaccessible properties/parameters with different names that you had given them. Resolving errors would often involve referring to the API docs, which are sometimes frustrating to navigate if you type in the wrong keywords to the search bar.

 

In conclusion, I am looking forward to working with Phaser more, despite my frustrations with parts of how it works. Several of my complaints – such as slopes not sloping and debugging – will be resolved by exploring more of Phaser and getting to grips further with searching the API docs. I still enjoy coding from scratch, as I feel as though I learn more about the core components of how to make the game work, but using an engine can be far simpler, and often quicker to implement complex features.