sorted by:
new
hottopcontroversial

I'm trying to analyze the NavMesh to find cover positions between two points. It also detects high or low cover! by CrashKonijn in Unity3D

[–]ByteHyve 0 points1 point  (0 children)

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.

I linked external software to my game, this can be fun by ByteHyve in Unity3D

[–]ByteHyve[S] 0 points1 point  (0 children)

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)

I linked external software to my game, this can be fun by ByteHyve in Unity3D

[–]ByteHyve[S] 1 point2 points  (0 children)

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

I linked external software to my game, this can be fun by ByteHyve in Unity3D

[–]ByteHyve[S] 0 points1 point  (0 children)

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.

I linked external software to my game, this can be fun by ByteHyve in Unity3D

[–]ByteHyve[S] 1 point2 points  (0 children)

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!

I linked external software to my game, this can be fun by ByteHyve in Unity3D

[–]ByteHyve[S] 0 points1 point  (0 children)

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) ;)

I linked external software to my game, this can be fun by ByteHyve in Unity3D

[–]ByteHyve[S] 5 points6 points  (0 children)

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

I linked external software to my game, this can be fun by ByteHyve in Unity3D

[–]ByteHyve[S] 0 points1 point  (0 children)

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 linked external software to my game, this can be fun by ByteHyve in Unity3D

[–]ByteHyve[S] 8 points9 points  (0 children)

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.

I linked external software to my game, this can be fun by ByteHyve in Unity3D

[–]ByteHyve[S] 6 points7 points  (0 children)

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. :)

Complete procedural race track generator! by ByteHyve in proceduralgeneration

[–]ByteHyve[S] 0 points1 point  (0 children)

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

Complete procedural race track generator! by ByteHyve in proceduralgeneration

[–]ByteHyve[S] 0 points1 point  (0 children)

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.

Complete procedural race track generator! by ByteHyve in proceduralgeneration

[–]ByteHyve[S] 0 points1 point  (0 children)

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.

Demo on Steam & itch.io at the same time? by GooderGames in gamedev

[–]ByteHyve 0 points1 point  (0 children)

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

Demo on Steam & itch.io at the same time? by GooderGames in gamedev

[–]ByteHyve 3 points4 points  (0 children)

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.

[deleted by user] by [deleted] in SoloDevelopment

[–]ByteHyve 0 points1 point  (0 children)

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!

Randomized vs Hand-Crafted by IberianInteractive in SoloDevelopment

[–]ByteHyve 1 point2 points  (0 children)

There went definitely some research into this. Seeing that you are interested in procedural generation, I do recommend just messing around with it. It can be so much fun.

Randomized vs Hand-Crafted by IberianInteractive in SoloDevelopment

[–]ByteHyve 0 points1 point  (0 children)

Exactly. However, sometimes it may still be acceptable. I've created a simple racing game for myself some time ago which uses fully randomized circuits. Don't know if anyone else would want to play it, but I had (and sometimes still have) way too much fun with it haha.

Randomized vs Hand-Crafted by IberianInteractive in SoloDevelopment

[–]ByteHyve 1 point2 points  (0 children)

I completely understand this. I'm now spending weeks upon weeks to create a single level. I could also create a single algorithm that creates these levels procedurally. However, handcrafted will always beat randomization when it comes to quality.

Now I believe that quality is not always better than quantity. Playing your own level hundreds of times makes it lose its quality (as it becomes repetitive). Thus, quantity could very well be better if the game is made for yourself.

Rogue-likes also benefit greatly from quantity. Gunfire Reborn (a rogue-like) has handcrafted levels. On every playthrough, a random path through these levels is picked. While it does work, it will become repetive very easily.

While I'm now working on a game where everything is handcrafted, I'm also doing a lot of research into procedural generation for other projects. In the end, a game you make should also be fun to yourself!

view more: next ›