OneShot - Devlog

📎
Jul 26, 2018 Links:

Days 1 & 2

In the weekly repl.it newsletter, I saw they were hosting a multiplayer games competition. Being fairly confident in making games in JS using p5.js for rendering, (see Captain 5ever my unfinished remake of the amazing Captain Forever) I thought I would give it a go. And to make it multiplayer, I turned to an express/socket.io node.js server, following this tutorial by Dan Shiffman. The infrastructure repl.it have setup to allow users to host small server side programs - and across so many languages - truly amazes me.

Play it here

I would have liked to have used Git to track my changes day by day, however since the game had to be created on the site, I was not able to do this. I started out with some small scale tests making a chat room style server (find it here and the project here). In all honesty, it’s not that dissimilar from the ipcMessenger and ipcRender used in Electron apps. Having done this I felt I was up to speed with sockets, and so began the development of my game.

The game was to be called ‘OneShot’ and the concept was as follows: players are in an arena, with one life, one shot and the aim of surviving as long as possible. The architecture I had figured out in my head had the following components:

Server Coordinates entity information & relays this information between clients
Renderer The main portion of the client side code, which handles rendering the data received from the server
Sprites Part of the renderer, these will be functions which take in entity data an execute the required p5 commands to draw things
Player Controller Part of the client, reads in key presses, handles player physics and relays this information to the sever to be distribute to other clients
Shot Controller Part of the server, this controls the physics and collision checking for the players shots

I first setup a simple express server to serve the files, and the created the renderer and sprites. I reused the art style from Captain 5ever (that was borrowed from Captain Forever). The player controller came next and after that the coordination side of the server. I ended up making it so that the player’s sprite was drawn straight away and the other sprites were drawn after their positions were received. I also ended up transmitting their velocities so that the client could fill in the gap between the next know position. For the shots, the player would check if it had the required shots when the shoot key was pressed, and then transmit a message announcing this to the server. The server would spawn the shot, calculate it’s physics and then send back a list of all te shots than need to be rendered. One issue that might be faced if there are many people playing this is that all sprites (players and shots) are drawn regardless of whether they are on or off screen, which is using unnecessary computational resources. I’ve noted this and will come to fix it later down the line hopefully.

I then setup some UI elements. An info panel in the top left shows the vessel id, ship name (more on that below) as well as the X & Y coordinates and lifetime, i.e the score. In the top right a ‘Radar’ shows the number of other players in game, and a scoreboard of the current top 5 lifetimes. I also added a communications readout in the bottom left and a controls diagram (‘Flight Guide’) in the borrow right.

As for naming, I thought it would be fun to base ship names off the ship’s id (which was just the id of the client’s socket connection). After about half an hour of playing with a random word generator I had come up with a system where by the fist three digits formed the name. For example:

karT8MQaqcFeN-eiAAGa => kar => King Alpaca Restrainer
lbbwcnERTdt62auMAAGi => lbb => Lieutanant Big Boy the Bagpiper

That’s just about it for what I’ve got done on these first couple of days. I’d say what I have at the moment is an MVP (minimum viable product), and so here are a few things that I seek to improve:

Days 3 & 4

I’ve spent these days implementing the features/fixes I described in my last post, and I’m probably ready to submit the game at this point.

The first fix I tackled was the issue with the comms UI element, where the previous message would redo it’s typing animation before the next one was animated. Turns out this was caused by a single line of code I had forgotten to delete. Originally, there was only one vaiable to store the message to be displayed, meaning a new message would override the new one even if it’s entry ‘typing’ animation had not finished. I replaced the single vaiabe with an array; the first element would be typed, and after it had finished, if there were other messages waiting, it would be shift()ed from the front and the next one would take it’s place and be typed. I had forgotten to remove the call to restart the animation for the new message from my old approach, so now upon recieving a message the animation would be played (causing the old message to reshow), then the new message would be loaded and moved to ther front, and then played for the seconds (and correct time). Despite all this this took me over an hour (or even two) to find, since my socket events and event handlers are in different parts of the file. That’s debugging for you kids!

Aside from a tackling a few other bugs, I also had an issue with physics, the ship would fly in an unweildly manner. My approach to the physics was this (I’ll probably have a more in depth explanation of my approach to simple physics soon):

  1. Update x, y and heading (a for angle) based on velocity (dx & dy) and angular velocity (da)
  2. Apply drag to dx, dy, & da
  3. If the user is pressing keys, calculate the increment to dx, dy & da

Due to the mental gymnastics I’m having to do to comprehend this, I’m not quite sure what the exact issue was, but somehow I realised I could fix this storing dx as forward movement, as apposed to movement along the x axis and the same for y, and then apply that to x based on cos(dx) + sin(dy) and y based on sin(dx) + cos(dy). Perhaps one day I’ll manage to wrap my head around this and have a better explanation.

I also added a few conditional clauses to only render entities if off screen, reducing load on the render engine, and added a circular radar to point you in the direction of other ships within ‘the sector’ (i.e the game area).


Arrows incicate players and circles indicate recharge powerups

I also added recharge powerups, so you could replenish your one shot if you use it. I hope this will create a draw for other players, perhaps creating a zone of conflict or somewhere to wait for other players to kill. Also on the theme of making gamplay better I added a suicide button -[X]- if you so wish as to terminate your time in the sector quickly - useful if you cannot find a recharge for your shot.

I also created some sounds, and using the sound library for p5.js, implemented some effects for the comms system, shooting, death and opening/closing the flight guide. This nicely ties the game to a point where I can call it finished, although there may be some more tweaks to add.

So, without further ado, play it here