Coming up to the middle of the quarter, the goal was to have a functioning barebones multiplayer game. We had a solid foundation for the game on the front-end using the Phaser3 framework (spoiler alert: not so much, but more on that later) but we needed a server to facilitate multiplayer. That’s where my teammate (Thomas Headland) came through and built a FastAPI server.
Now that we had this server to host the game a small hurdle presented itself in that the project spec requires the use of an authoritative server, we interpreted that as a server that validates all actions of each player. So for example if a player hits a key on their keyboard the client notifies the server that a key has been struck and the server then determines the appropriate response. The problem we had here was that our server is a python framework that is incapable of using many of the built-in features of Phaser3 such as physics and collision detection. This mean we had to recreate all of these in Python which kind of rendered most of initial front-end functionality useless.
Now the good news is we have mostly been able to do this as we now have the following features built:
Movement (acceleration/deacceleration included)
Health and score tracking
Meaning we not only have a basic functioning multiplayer game but the power-ups add that little extra to make it not completely barebones. Even better is I’m not sure how long the last two features listed above took to implement because I’ve hit my runner’s high and am having a blast seeing this game become what I hoped for in the beginning.
So after creating a simplistic (but still meeting our minimal requirements!) single player space arcade shooter using the Phaser3 framework, we have moved on to our next major feature right before the midpoint of our project timeline… Making the game multiplayer.
We chose to have the back-end of our to use the FastAPI framework due to its comparable performance to Node.js and its use of Python. Unfortunately for us, all material provided by Phaser on implementing multiplayer for its games is written using Node.js.
To ensure our project timeline didn’t stray too far off our projections we decided to move forward building a Node.js server using the material we had found during our initial research while also trying to implement a FastAPI server capable of speaking to our Phaser client through websockets. We figured the use of websockets will be the backbone of multiplayer implementation regardless of what we build our server with allowing us to transition whatever progress we have made in Node to FastAPI relatively painlessly (this is the hope and it still lives).
Initial impressions of building a multiplayer server is that its all about communication. What information is critical for all clients to have so that the game can proceed as intended and what information acts a unnecessary fluff that bogs down the whole operation. Once these bits of critical info are determined at what time and how frequently do we need to update/communicate this info with the server/other clients? Questions like this are what I am currently dealing with as I transition our single player experience into a client game that interacts with a server.
So my last class at OSU comes down to making a multiplayer space arcade game, if only this would’ve been the pitch for college when I was in junior high.
Diving into this project, the thoughts and emotions ive had are eerily similar to almost all projects. At first completely overwhelmed with new concepts and an endless list of paths/solutions (none of which stand-out) and then a calming realization that its not due within the next 15 minutes and I start breaking off chunks piece by piece until I have a plan written out in my handy dandy notebook (shout out to blue’s clues).
The back-end will be handled using the Python framework FastAPI, which can be summarized as easy to use as Flask with the performance of Node.js. Unfortunately, all resources I’ve found involving Phaser multiplayer development use Node.js but at the very least that will help give us a start to find equivalent methods/functions/strategies to implement FastAPI. It’s the Capstone Project, we cant have everything be simple.
The next few weeks will be a blur but the plan is to have a fully-functional game in the short-term so that we can go nuts and throw whatever features we want into the game to help it stand out from the crowd. What that entails is a complete mystery at this point and in no-way is that a bad thing because these early brainstorms have only produced ideas, not roadblocks.
Well its finally here, CS467. The end of the line and where I start freaking out about changing careers. After spending 5 years as a mechanical engineer for the Navy and deciding it might not be what I want for the next 30, I decided to start this program with the hope of giving myself more options.
Now that I’m here and after reading all the options we have for our Capstone projects I find that I’m drawn to making a game. My top 3 choices are all drastically different styles of games:
My first choice is the firefighter simulator, not only is my house regularly engulfed in smoke due to forest fires but my dad is a firefighter so this topic has significance to me. The idea of using a strategy game to help spread awareness of the cost these fires take sounds not only like a good cause but also a fun game.
The second project that caught my eye was the multiplayer space shooter. I took CS372 as my first elective and enjoyed it thoroughly (in particular the traceroute project). Expanding on that class by creating simple (maybe not if time permits) multiplayer 2D space shooter sounds like fun way to build my portfolio.
And my third choice was the machine learning breakout game. I feel like machine learning is a bit of a buzz word people throw out there to sound smarter so why not learn a bit more about it by using it to make a game.
With all three of these options I see potential to make exciting projects id be proud to show friends/family/future employers. The biggest downside I’m seeing right now is that all three of these are different enough that using this first week to prepare for any of them doesn’t have a ton of overlap so I feel like I’m stuck until I see what I get assigned.
In the end, whatever project or team I get assigned to; I’m just excited to get started.