A real-time game from scratch - PixiJS [3]
November 12, 2020
Previous Entries
Introduction
At some point I need to be able to show something on the client side that is not simply text retrieved from the server.
Short of making some super complex ASCII art based rendering engine I will need to use some library or framework to avoid messing with the canvas manually.
Research
I did not do much research before making my choice.
Admittedly this may be flawed logic if one is considering a long term project, however in my case I would not mind starting with one and switching to the other as it means I would have gained in experience in two tools rather than one.
As a result, my criteria for selection were very simple:
- I had heard about it before
- It looks vaguely popular (GitHub stars, albeit a noisy indicator of popularity, was a useful consideration here)
- Updated semi-recently (This is easy to do with open-source projects since I can take a look at how recent the last commits are)
- If open-source, a permissive licence
- TypeScript support
Fitting all of the above criteria very well, I chose PixiJS. I did not choose PhaserJS as it appeared to be more featureful but also more restrictive. I do not want to spend my time learning “the Phaser way” of writing a game.
Admittedly in a few article’s time I may bemoan my lack of open mindedness on this matter.
PixiJS
PixiJS is currently sitting at version 5. Whilst getting started was easy, the example on the GitHub readme was not completely “copy-pasteable”. It helps me greatly when my first impression of any library that I want to try out is an example I can simply copy paste onto my machine and get running as fast as possible so that I can verify my setup is correct.
After a bit of digging, I found an examples section on the website which contains both the example running and editable source code I could tinker with to see the effect of my changes.
Soon enough, I had a spinning yellow square on my screen. Initially it was rotating around the origin (top left corner) in and out of the screen. This would have left me very confused had my Bachelor’s Degree in Creative Computing not taught me about global and local co-ordinates and how rotations work in 2D and 3D spaces.
From here it was not difficult to wire up the exchange of data between client and server to the new visual frontend. On every tick, I would update the Yellow Spnning Square’s X and Y position values to whatever was received in the last message from the server.
Whilst a promising start, the box moved too slowly! To get it move faster, I began multiplying the retrieved position by 10 so the box appeared to move faster across the screen.
This however got me thinking: the front-end visualisation is tightly coupled to whatever state is sent back by the server, mapping it 1 to 1 from game state to pixel position on the browser.
In reality, rather than simply using whatever the server sends back, it would make sense for the front-end to map it to the current browser, otherwise a player on desktop with a 4K screen would be able to see more of their surroundings than a player on a laptop with a 1080p screen.
Conclusion
A yellow spinning square is not much of a game, but it beats simply showing text and provides a good foundation to be able to properly visualise changes in game state being sent by the server.
So far any changes are caused by my input from the browser, so in my next article I will attempt to implement a basic physics system, simulating what one could expect if they were in space.
You can find the code for this article at the article-003 tag.
Next Entry