Com.unity.multiplayer-hlapi Alternatives

Similar projects and alternatives to com.unity.multiplayer-hlapi

Godot

2,745 83,900 10.0 C++ com.unity.multiplayer-hlapi VS Godot

Godot Engine – Multi-platform 2D and 3D game engine
rbfx

22 745 9.6 C++ com.unity.multiplayer-hlapi VS rbfx

Lightweight Game Engine/Framework in C++17 with WYSIWYG Editor. Experimental C# bindings.
InfluxDB

www.influxdata.com featured

Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
FPSSample

4 4,781 0.0 C# com.unity.multiplayer-hlapi VS FPSSample

A first person multiplayer shooter example project in Unity

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a better com.unity.multiplayer-hlapi alternative or higher similarity.

Suggest an alternative to com.unity.multiplayer-hlapi

com.unity.multiplayer-hlapi reviews and mentions

Posts with mentions or reviews of com.unity.multiplayer-hlapi. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-07-13.

Unity merges with IronSource
4 projects | news.ycombinator.com | 13 Jul 2022

> For multiplayer there was the original UNet, then the FPS Multiplayer Demo stack, then HLAPI/MLAPI, now we're getting "Netcode for GameObjects".
This doesn't seem like the correct timeline of events. Anyway, if you want a clearer picture why they decided to throw the packages away, I recommend reading the source and/or trying to use them. For your reference: https://github.com/needle-mirror/com.unity.multiplayer-hlapi
> That also means their new tech stack rewrite for ECS won't get multiplayer support until they release "Netcode for ECS" at some later date.
Uhhhh? The package is literally right there. It's one of the very earliest ECS packages they published, I think. They also reaffirmed that the package is in active development internally. https://docs.unity3d.com/Packages/[email protected]/man...
> There's stuff like buying Bolt and then depreciating it months later for Unity Visual Scripting.
Bolt is Unity Visual Scripting. I really don't know what you find so offending here (maybe except Unity's inability to develop their own tools in-house).
> It's like they have a ton of teams working on rewriting the engine but none of them communicate and often find out they've been rewriting the same feature as another team.
I can't come up with a single example of this. Unity occasionally has a tendency to develop a "vnext" tool while still supporting a "legacy" tool, which seems great for backwards compatibility (and for long-running projects), but it just keeps confusing people endlessly. I don't like Unity, but hell, I don't envy them for constantly having to deal with this shit either.