itch.io

Duude, thank you for the comment! I appreciate it very much)

I chose these visuals for multiple reasons:

First, it's 2D which means I can get away with ancient level of tech (the graphics module for example can only output textured 2D triangles - not even tinted and only from a single texture and the math in gameplay is super primitive compared to what had to be done for 3D) and the cost of asset creation, processing and importing will be near-zero (all had to be done by hand in Go in which the dev server was written. I did not want to spend too much time with it and also doing full rebuild is instant - currently its under 200 ms for ~1000x1000 atlas. I had to cache sounds though 'cause I'm using FFmpeg for resampling and it takes ages for a single file). I think hot reloading was one of the few things that helped my significantly during the jam and kept me sane.

And second, I was fascinated by Project Landsword - it was the second time I've seen a game that was that good and used sprite stacking. It nailed the idea for me that this kind of game can be really cool. The first one was Racing Gears but it's a GBA game and only the cars in it were sprite stacks. What's interesting is that the cars would tilt when going over ramps which was appearantly done with 2x2 matrix transformation for all layers. I don't know any other game that used this effect. And also Landsword uses sprite stacks for almost everything: mechs, buildings, signs etc. It also has sh*t ton of particles. That accumulates to 1000+ sprites on the screen at each moment which my 10 y.o. laptop can't handle for some reason. Still that sparked that "I can do that myself and better" thing which helped with motivation.

By the way, the "smoothness" was sort of an issue for me: it looks good for objects inside the game world but not for UI. There are no labels for bars in the HUD, like HP or EN, and the bars themselves are rectangular and not triangular  (with 1 pixel cut out at the top on both sides of each bar) because the renderer did not support single-pixel precision / integer positioning (or like floating point truncation for UI layer) which meant I could not draw anything 1-3 pixels wide consistently - the lines would randomly get stretched or squished.

Additionaly, in the early stages there was a problem with texture bleeding when tiles would have their edge pixels sampled from a neighbouring texture. So I had to add padding and repeat edges for all textures in the atlas.

About the game feel: I wanted to make a twin stick shooter that was fast. Like as fast as AC4 was compared to the previous games. I tried to find these kind of games on steam but couldn't. I think it feeling too fast is the issue primarily with the map being too small and not the controls themselves, although they are not that great, especially the dash - it's just a lerp between the start and end points which is too primitive IMO. Also maybe the game resolution is too small for these speeds - only 240x160. At the start I wanted to add a 3rd mode of movement - boosting so you could simply roll around, release D-pad, press dasg button and press the D-pad again to slowly (compared to dash) accelerate to higher speed. Like walking, dashing and quick dashing in AC6 (from what I could understand, I never played it). But my programming ability let me down and niw the game only has a crappy dash.

Yeah, the bots were worthy of more attention) At some point they did shoot you only if they were on screen but that felt too easy. I wanted to fix them shooting at you from far away being a surprise by adding markers at edges of the screen but didn't have enough time. But yeah.. I don't know yet what to do with this.

And oh yeah! Before I nerfed their bullet speeds, they would annihilate you immediately if you weren't going in circles)

Swapping weapons was from AC1 (I only played 1st gen) and Nuclear Throne. Kind of have to have it when the whole mech thing is mainly about customization and variety. I tried with the time that I dedicated to that to make the weapons different from each other, especially with GM (series of shots and the spinning radar). I'm glad it was fun) Actually I wanted to add repulsion for enemies but forgot ¯\_(ツ)_/¯

Thanks man) It was the main selling of the original idea: ~ online PvP duels ~. But I failed miserably again with trying to implement movement smoothing. Plus the way I chose to transfer packets was sending them over WebSockets which I was afraid would suffer from flooding which would baloon RTTs. So I'm sending them in a ping-pong fashion: the server sends game world state only after recieving a packet from the client. The same goes for the latter. I don't know actually how much of an issue it is because the raw ping itself is pretty bad - around 150-200 ms. I will try to use WebTransport, i.e. UDP for websites, for my next project - a proper competitive sailing game in the same style, because alwaysdata's proxies that handle SSL for you makes life just so much easier (you would have to have a domain and your own signed certificates for WebTransport to work IIRC). But I haven't tried it yet so I don't know for sure.

Actually, setting up a simple game-server connection over websockets is almost trivial. You really only have to check the origins but apart from that it's just the example code everywhere. Now I wonder why there are so few online projects when it is so easy to set up one. Also making a single-command deploy was a little rough on the edges, but not something complicated either.

I wish I could do music too! But I am a total zero in that. There is sound in the game only thanks to jsfxr xD. I really do find anything creative much much harder than programming - I get completely lost and demotivated. So I try to compensate with the number of lines of code)

Sorry if my english isn't pleasant to read. Thank you again for the review. That really makes me think that all of this was worth it.

As a sidenote, I've seen your entry before the deadline but haven't played it yet. Will fix that when I get back from work)