monkey

Are you applying any velocity to the trail? If you fly directly against a wall in Continuum, it will shoot the exhaust backwards. I was trying to replicate how Continuum does it and found it important to apply the velocity to get a good result in any situation.

I created a powershell script that automatically downloads the releases for C# SubspaceServer and this zero bot. It will automatically download the releases, unzip them, configure the arena, configure multiple bots, and launch them. It only requires the 9.0 .NET runtime to run the server. Repository: playground

I was working on a client for a few months back in 2021. It was made in C++ and rendered with OpenGL. I had it running on Windows, Linux, and Android. The code is written in a simplistic subset of C++, so it should be pretty easy for anyone to read if they ever decide to work on a real client. I haven't seen it crash ever, but it wouldn't surprise me if there were bugs and crashes somewhere. I never finished the ui stuff like arena menu, profile menu, etc. I also didn't implement profiles or zone list; everything is hardcoded into the build. It has VIE encryption and Continuum encryption support, but the Continuum encryption is private/disabled and done by using a network service. The simulation is done in floating point, so it's not 100% perfectly aligned with Continuum, but it's pretty close. The weapons will follow the same trajectory as Continuum, but weapon-player collisions can be off slightly due to using floats. I used this simulation code for my zero bot project. Github repository: nullspace Another earlier video showcasing it after a few months of work linked in the repo. Here's a video of it spectating in Trench Wars around the time I stopped working on it. nullspace is on the left and Continuum is on the right for comparison. (I guess Firefox doesn't support 4:4:4 chroma videos, but works with Chrome) 2021-08-16_16-30-05.mp4

Reduced memory usage and optimized player range lookups with a k-d tree. This was a major speedup in player-weapon collision tests since I don't have to go over every player for each weapon now. With those optimizations, I could run 200 bots on a local asss server. It starts to get laggy at around 250 bots, but it's probably just a limitation of my machine. The Windows version of asss crashed at around 275 bots connected. I can run around 150 on subgame, but it starts to get laggy if I go any higher with default settings. I changed some of the subgame network settings and it let me get to 200, but it came with a reduced quality of play. These bots are all doing pathfinding and doing full simulation of the game, so I think the results are pretty good.

I put together a little network bot that implements most of the game. It's not very configurable, but the source code shouldn't be too hard to work with. Source code: zero It can connect and play in zones with VIE encryption. It supports Continuum encryption, but that part is not available to the public. Should behave very similar to a normal client. It has been tested in both asss and subgame servers. Has a debug render window for a display of it playing. Uses behavior trees for gameplay behavior. Has some simple behavior trees defined for a few hardcoded servers. Downside is that the core update loop uses floats for position data, so it can sometimes eat bullets/bombs when it's very close. Most of the bot is hardcoded to what I was working with, so it's not very configurable. Bot command controllers, servers, etc. I don't use this bot anywhere, so I'm not sure about its stability. It's pretty easy to setup a subgame server that you can connect to locally. Allow vie clients and make sure you listen on 127.0.0.1 so multiple connected bots don't get throttled by subgame. I would recommend setting the zero config server to Subgame and pointing that to the local connection. That will cause it to use the default svs behavior tree.