Development Info

This game is part of a series of games I've been working on for fun and to learn. I use TypeScript in Node and in the browser for my day job and it has become my goto for projects unless I have a specific need for something else.  This being a browser based game, it made the most sense to use it here too.  It's edited in VS Code and has no dependencies. Modern browsers have so many features and such good performance compared to when I started Web Dev in the IE6 days that I really felt I could make at least basic games without needing plugins or frameworks.  So far so good.

Game Loop
The game loop is simply a function that calls requestAnimationFrame with itself as the callback. It uses a few event handlers to capture keyboard and touch info which gets passed through to whatever gamestate is active.  For Starfury there is just one game state with all the game logic and graphics in it. Another dumb little game called ASTEROIDS-ZENECA uses the same basic structure and the same underlying game code but with a different gamestate. 

Graphics
The graphics of the game are loosely based on how vector graphics worked in old 80s arcade games.  In those games a "sprite" was a collection of draw commands relative to an origin point. I decided to opt for the same approach. Each graphic is represented by a Geometry that contains a set of points. Each point is actually an action (move or line), an X offset and a Y offset.  The Geometry gets X,Y coordinates in game space and when its time to draw the canvas translates by x,y and rotates by the geometry's angle, runs through the points either moving or drawing a line, and then undoes the translate and rotation to the canvas.

It has some obvious bugs. The drawing system relies on using canvas rendering context attributes but it doesn't reset them at any time. So if I forget to set the color (strokeStyle) for a Geometry, it'll use whatever strokeStyle is around from the previous Geometry that was drawn.

Performance
Performance isn't fantastic when there are a lot of things on screen, if I keep the project going eventually I'll check out optimizing it more. For now the only optimization it does is to not draw items that are off screen. Truly the most basic optimizations only.

Collisions are also extremely unoptimized. Each bullet literally checks for each shootable item to see if they are colliding.  I think a big performance boost will come whenever I get around to optimizing that. It manages to perform alright-ish even with this basic set up because it uses axis aligned bounding boxes that get updated on the fly to the shape of the geometries that are shootable. That's a pretty light weight way to check for collisions and right now the game is just brute forcing its way through everything.

Audio
The game has no audio yet but I am working on an audio module to provide music and sound effects. I don't want to just upload audio files and make the thing gigantic, I'd rather mimic the audio systems of old arcade machines in this regard as well, so right now the test audio system is using AudioContext to generate music and sound effects on the fly.  Once it sounds at all like music and sci-fi sound effects, I'll include it in the version here on itch. 

Multiplayer?
I've been thinking a little about multiplayer, it's still very far off, but I don't want there to be a reliance on a game server. So instead I am looking into using webrtc with a signaling server to power a p2p multiplayer system.