At the end of 2018 we completed a project to re-write a multi-team game that's used as a training application to teach employees about running a business. The game is a big success for the company and since launch we've been adding more and more features as the game has evolved.
Working on this really made me start to think about what's actually possible to build as a web application using PHP and Javascript. We've been involved in building lots of applications and websites but they generally conform to the standard kind of thing, CRUD based admin panels, user form submissions and processing, booking systems, product catalogues, e-commerce etc. Whilst these projects are great to work on sometimes it takes something a bit different to come along to really make you explore what's possible with your available languages and tools.
I thought it might be worth writing up a quick overview of how we handled this and the challenges we faced. If you're interested in developing a real-time game in PHP and JS get in touch as we'd love to hear about it and get involved.
Building a game engine in PHP
The most complex part of the game we developed is the code that runs the mathematical side of things. It's running some fairly complicated financial and statistical calculations to create a realistic environment in which the teams compete. We decided to develop this as a game 'engine' that would be fed data from the gameplay side, the idea was to create something framework independent so that it could, in theory, be fed inputs from any kind of UI, not just PHP/JS.
This approach worked out rather well as it had the added benefit of being written in 'pure' PHP with no framework code leaking into it. This is achieved though the use of data transfer objects (DTOs) that are built by a DTO Assembler that effectively sits at the boundary of the framework. The entire state of the game is assembled and then handed to the engine to compute the impact of the current decision making from the teams.
The other added benefit here is that we were able to unit test huge parts of the engine in isolation, every important calculation and part of the algorithm are tested to within an inch of their lives. The test suite has given us a lot of confidence in pushing ahead with more features, it's also saved our bacon a few times after making tweaks that had unforseen side effects elsewhere.
The challenges in building the engine
The main challenges with the game engine were really encountered before the idea for how it should run was developed. Once we knew how it would work building it was relatively straight-forward.
One of the main design challenges came from the requirement of maintaining a full input history from players and teams to allow input errors to be corrected at later stages. As an example an incorrect interest rate could be applied to an asset interest calculation that might only be spotted later on, the system would need to be able to re-compute the current state with this modified historical data. The ability for the current state to be computable at any stage drove the design of the engine, it started to look like an Event Sourced solution should be used but this isn't actually where it ended up.
The engine we created allows any part of the game to be modifed at any stage, so historical errors can be corrected and then the changes bubble up through the following periods rewriting outputs etc. After being run thousands of times in production this design decision and implementation is one we're very proud of.
Building a live game environment using Vue JS and Laravel
The other side of the game to implement was the game admin and team game areas. The admin side was a pretty straight-forward admin panel built as a series of Vue SPAs that connect up to a Laravel backend. The admins can fully manage each game whilst it's in play. It allows them to manage any data, add items, remove errors, generate the game state to see how things are and generally run the show.
The teams can log in to their area on multiple devices and players will generally manage a role/department/ui each on the team. They're able to inspect previous results to allow them to plan and make decisions on how to proceed in the game. They will generally be playing against the clock with a live dashboard in the room counting down and showing them key information about the current game state and what other teams might, or might not, be up to.
This part of the design was good fun to build, we suggested several features to enhance the gameplay that the owners have reported back as being a huge success. We've recently been asked to add a feature to allow the admin to knock a team out by disabling their interfaces, this is another great thing to build, it doesn't feel like work!
The challenges in building the game play environment
The challenges here were mainly in creating a system that was capable of handling inputs from several teams at once. In some areas it has to manage resources that can only be allocated once, so it has to guard against a lot of conditions. It also has to enforce deadlines and not allow play during selected times. Again, testing was vital here as simulating every conceivable scenario helps give confidence that it'll behave itself when running in production.
In summary
What is there to say in summary? I suppose the main lesson we learned here is don't assume that your current languages, frameworks and tools can't be put to use in ways you're not used to. We've delivered a product that's added real value to the business and with the feedback we get we can see that it's made a big difference and people are really getting something positive out of it. That feels great as a developer, to know that your code is running consistently all over the world and making a real difference.
If you're interested in web based game development and are looking for a development company get in touch as we've probably already solved a lot of the issues you're going to have!
