u/ByteHyve

Really happy that you enjoy it. Same for me though. It was an experimental project but I had way too much fun with it not to publish it in some form. And interestingly, the track generation is still pretty bare. There are numerous ways that it can be improved upon.

That would be really cool! I'd love to revisit this project in the future as there are so many fun things to do with it.

Hey, I hope I can still be of use. The easiest way is to randomly define some points around the player, then find the closest navmesh node to this. An optimized navmesh can do this very quickly (e.g. octree, boundary volume hierarchy). Then it is a matter of firing a couple raycasts towards the player to see if it could really be a 'good' cover position.

By continuously doing this, we get a decent set of random cover positions that AI agents can use.

The great thing about the randomness is how natural it looks. Enemies might hide behind objects you have never thought of hiding behind haha.

Of course! While it is almost indistinguishable from a real console, it is actually an (HTML) webpage. This is converted to an executable using Web2Exe. Node js and Electron allowed me to perform some OS-level actions (such as reading and writing data).

It is much easier to write a custom console with the .net Console template (from Microsoft Visual Studio). However, the webpage approach gives me a ton of extra functionality. (e.g. scary artifacts in the console itself)

Haha thank you! I'll definitely add some fun easter eggs though (with such commands)

I have created a custom console application (also for some extra functionality). Then, it is just a matter of letting it write JSON data (e.g. '{ "message" : "removeprops" }'). The game reads this periodically. To ensure that messages are arrived, it works vice-versa. The game sends back a message, which is referred to as an "acknowledge" message.

Understand that this is a 'cheap' solution. Constantly reading and writing can be time-consuming for the CPU. But when testing, it has proven to work very well.

Hey! While the style is relatively simple, a lot is still going on. Fortunately, there is a ton already on YouTube on this subject. The biggest tip that I can give is to remove/disable all lighting (and shadows). This did half the trick for me.

Furthermore, I have created a blog post describing a GoldenEye-style aiming (and shooting). You can find it here_era). If you are new to all of this, following a YouTube series can get you very far. Good luck!

Thanks! I'm sure I wouldn't manage to finish this in a game too. The console is custom-made (which also allows for some interesting behaviors) ;)

Some of the techniques I used are also used in (TCP) networking. So yes, there are definitely some similarities!

Thank you!

Exactly!

Haha, I have yet to play that game. I'm trying to stay as original as possible. Thus, I do not want to steal any ideas. But there could be many similarities eventually.

I was kinda afraid that this could easily introduce bugs. Thus, I went for the most straightforward approach: writing and reading from a persistent easy to access path. As the communication data is so small, this can be done almost instantly without any problems.

Hey, thanks! The game is a (fourth-wall-breaking) horror. I was messing around with communicating between external applications and the game itself. This can lead to fun interactions where you might need to 'hack' into your own game to proceed. It seems to work better than I initially expected. :)

No problem! I took the exact same approach, starting with the basics, so do not worry. Good luck :)

That is great to hear!

I highly recommend looking at how (and why) nodes are scored in pathfinding algorithms. My algorithm is actually very similar to pathfinding algorithms. But, instead of generating a path from A to B, it is a path along a base shape (e.g. circle, 8-figure). And, instead of using pathfinding nodes, there are track segments.

Regarding the grid-based approach. My pre-defined segments are grid-based. But, this was not necessary for the algorithm to work. Each 'placed' segment can be represented by its 3D ending position and forward direction.

Deviating from a grid-based approach does give more unique tracks (which I do recommend). However, it adds complexity. For example, connecting the starting and ending segments is more difficult.

If you would like to have a go at the demo (and have not yet tried it), you can find it here. Let me know if you have any questions. I had so much fun with this project haha.

Hey, thanks! I don't know if there is a name for the algorithm, but I'm happy to help. I will keep it somewhat short as it was pretty complex. (if you have any further questions, let me know!)

I first defined grid-based pre-defined segments (e.g. 1-forward, small 90-deg turn, large 90-deg turn). With a ton of backtracking, these are placed until a full circuit is formed.

Before this though, I generate a base shape (e.g. circle, 8-figure). When picking a segment to place, I give each option a score. This score is based on: distance from the start, distance to our base shape, etc. Based on this, it picks the best option and proceeds. (The scoring is extremely important and requires a lot of trial and error)

This does not always guarantee a circuit. For example, it might take way too long. To counter this, I simply pre-maturely terminate the process and restart it (with a different prng seed). This is not a problem as the entire process can be extremely fast (possibly 0.01 per track).

When finished, I turn it all into a single path and alter it slightly (e.g. some smoothing, extra elevation changes, banking). This is then procedurally converted to a mesh, that acts as the finished track.

Haha they probably don't want this, but also impossible to regulate. Not a bad tip :)

You are definitely allowed to do such things (or sell on other platforms). As long as you don't link those on your steam page, which is understandable.

Very often, you'll understand the scale of your project only after a certain time of development. There is nothing wrong with starting a simpler project, especially after only a couple months of development. You can always return later on. Good luck!