Wow, this is a really interesting topic! It’s cool that you’re diving deep into game development and networking. The whole debate between kernel bypass and userland UDP implementations definitely has its pros and cons.

You’re right—libraries like Raknet and ENet have been around forever and are trusted by many developers, mainly because they’ve been thoroughly tested over the years. They handle a lot of the heavy lifting for networking in games, so developers can focus on creating fun gameplay rather than getting bogged down in the nuts and bolts of networking.

As for userland solutions like DPDK, it’s true they can bring big performance improvements thanks to lower latencies. But there’s a big trade-off, right? Game development isn’t just about speed; it’s also about reliability and ease of use. Implementing something like DPDK might require a learning curve or even changes to how the game is structured, which can lead to bugs or unexpected behaviors, especially in a multiplayer context.

Plus, gaming environments are often a bit chaotic with players joining and leaving, and you need to ensure that the networking layer can handle that smoothly. The traditional libraries have a lot of built-in functionality to manage those challenges—things like connection handling, data integrity, and more—which can be super helpful.

It’s not that game developers are completely avoiding these cutting-edge solutions; it’s more about weighing the risk versus reward. For most games, sticking with time-tested libraries offers peace of mind. Sure, you could potentially get performance boosts with kernel bypass, but there’s also a chance of introducing new issues.

As for examples, there have been experiments and indie projects dabbling in alternative networking solutions, but it’s still pretty niche in the big industry. Most AAA games continue to rely on established solutions because they have a lot to lose with new, unproven tech.

So, in a nutshell, while there’s definitely potential for kernel bypass techniques in gaming, it seems like for many developers, the overhead of switching isn’t worth the benefits just yet. It’ll be exciting to see if more developers start experimenting with it in the future, though!

Hey, I totally get the struggle with the inventory system! It can be super tricky when it comes to dealing with sprites and paths, especially when you’re trying to keep things organized.

One thing you might wanna consider is using a ScriptableObject to handle your items. You can create a ScriptableObject for each item in your game, and inside it, you can reference both the single sprite and the stacked sprite. This way, you don’t have to worry about constructing paths or anything like that, and you can keep everything neatly organized.

[CreateAssetMenu(fileName = "NewItem", menuName = "Inventory/Item")]
public class Item : ScriptableObject {
    public string itemName;
    public Sprite singleSprite;
    public Sprite stackedSprite;
    public int quantity;
}
  

Then, in your inventory system, when you want to show the icon, you can simply check the quantity and choose which sprite to display:

if (item.quantity == 1) {
    image.sprite = item.singleSprite;
} else {
    image.sprite = item.stackedSprite;
}
  

Also, since you’re using the Resources folder, just ensure that all your sprites are stored in the right place so you can reference them easily with the ScriptableObjects. This approach keeps things clean and organized without having to mess too much with paths and folder structures.

I hope this helps out a bit! If you still hit a wall, feel free to ask more questions!

It sounds like you’re at an interesting crossroads with your game’s timestep handling! Both your approach and your colleague’s have their merits, but there are definitely trade-offs to consider.

Your fixed timestep method can help ensure predictable updates and make collision detection easier, especially since it avoids the risk of fast-moving objects skipping over each other. That consistency can make it easier to debug, as you know exactly what time step your game is on. Plus, it can simplify the physics calculations since everything is happening in regular intervals.

On the other hand, your colleague’s method feels more fluid, which can lead to smoother animations and responsiveness to player input, especially on systems that can handle it. It allows the game to account for varying frame rates, but as you pointed out, it does have risks—especially regarding collision detection. If units move too quickly, they might miss collisions entirely if you don’t have strong measures in place.

The continuous collision detection your colleague mentioned could help mitigate some of the phasing issues, but you might end up spending a lot of time fine-tuning that system. There’s definitely a level of complexity that comes with it, especially if your game involves lots of moving parts.

A way to think about this might be to combine both worlds: you could use a fixed timestep for the core game logic and collision detection but allow for interpolation or frame smoothing for rendering. This way, your game could still feel responsive without sacrificing the robustness of your collision detection!

Ultimately, it might come down to what feels best for your game. If your game needs to feel very precise in terms of collision and movement, sticking with fixed timesteps could serve you better. If performance and smoothness take priority, exploring continuous updates might be the way to go. It’s all about balancing those needs!