FNet License

[north trout]

No Beef here, just pure information
@wooden mango

"FirstGearGames grants to you a worldwide, non-exclusive, no-charge, and royalty-free license to reproduce, modify, and use the Software for developed game, or other content with Software."

This section grants rights for personal use and modification but does not explicitly permit redistribution

We can modify, reproduce, use it but no "distribute"

[wooden mango]

Sounds like someone needs to reach out to him to get him to add the word since from his actions he obviously wants people to use it and distribute their games.

[north trout]

the license is too ambigous which are the things we allowed to do and we do not.

I like the generic license gpl 3.0, mit because it has the points what things are allowed and do not

[wooden mango]

Right now I am heavily considering photon quantum so not sure if this really matters to me anymore

Just trying to figure out if it can do the things I need it to do

[north trout]

quantum is surely very nice

build a few games using it

[elfin coral]

Distribute here normally means the package itself. So I can't fork it and release OtakuNet

[north trout]

so the final question, is fishnet open source?

GPL 3.0 = we can distribute but we cant make the software to be paid

MIT = Its all free country

[wooden mango]

For me. If the "distribution" issue is resolved it is effectively open source. You can use it as is. You can PR into the repo. Or you can fork it and use it for yourself (You just can't distribute the fork as a library).

[elfin coral]

If I can view the source then I consider it Open. But there are Open Source purists that will die on that hill

[lime viper]

from understanding you can tweak it for your game needs but you can't repackage it as a new netcode library and then compete with him

that's the same license 3d assets have, they allow you to change them according to your needs, but not repacking it to sell them on asset store

I do use Fishnet, but I heavily modified it, I use my own CSP and tick alignment system

[north trout]

I think I (for myself) can conclude fishnet is not open source. if we cannot redistribute it, then its not open source. because we dont have any authority over the code.

Lets say fishnet go berserk and change the license for all users who uses it to be paid.
which are the things software engineers afraid of, in this case similar to unity licensing fee.

Therefore several developers moving to godot to claim their safe space and have the authority of the engine

[wooden mango]

It's very good in this case that we are able to disagree and no one is forced to use anything. Those complaints are not strong enough to make me hesitant to use the library.

On the other hand the fact that the data usage grows exponentially with the number of clients connected is a factor that has lead me away from the library.

I seriously don't see how difficult it is to just do solid research and provide good solid reasons to not use a library instead of going with doomsday arguments.

[north trout]

the reason I made this thread is not to convince you not to use the library, but instead infromation sharing if noticed it

[wooden mango]

There is definitely some information sharing. And a lot of opinion sharing. End of the day the library is "effectively" open source for anyone who isn't incredibly strict on the term. But performance issues have driven me away.

[north trout]

But performance issues have driven me away.
Could you elaborate on this one?

[wooden mango]

As I said. Server outbound data usage grows exponentially with the number of clients connected.

An old benchmark I saw online said for 30 users connected fishnet would have around 1MB/s of data usage.

Mirror for the same test had around 2MB/s.

In my most basic mockup scene 30 users would use around 4.5 MB/s in fishnet right now.

My goal with going with fishnet originally was to use less data. It fails at that goal.

[north trout]

hmm where di you see that?

Mirror in terms of performance I agree worse than fishnet

[wooden mango]

Fishnet recently released "prediction v2". It is implemented in a way that makes that no longer true

[north trout]

you mean the prediction v2 is a horrible performance?

Here's a benchmark I conduct

[wooden mango]

It is the reason for the expoential data usage

I saw that one as well

https://github.com/hpcvis/MuVR/tree/benchmark/base

[north trout]

the photon fusion shared is very misleading there

fusion-shared tick rate cannot be adjusted, and always fixed to the cloud

unless you are using a host mode

[wooden mango]

I was more interested that Prediction v2 causes a nearly 4.5ish times worse performance.

[north trout]

maybe prediction 1 is better after all?

[wooden mango]

Even though prediction v1 still exists... it's no longer "supported". So you're on your own for any problems.

Which is not appealing.

[north trout]

you just recently tested this?

[wooden mango]

Who knows maybe he will get it performant in a few months. But it's going to be a few months too late for me.

[wooden mango]

I tested it up to 5 clients connected and confirmed to myself that data usage was growing exponentially.

For me a single client connected used 5KB/s.
2 clients: 20KB/s
3: 45
4: 80
5: 125

The formula was clients squared * 5 KB/s.

[woven nimbus]

its much worse because reconciled properties cant use compression

[wooden mango]

And it's sending all reconcile data to every connected client.

[woven nimbus]

exactly

check out netick 2, it has a similar api to photon

and performs much better than fnet. its also not as well known, so the developer can fix any issue you find pretty fast

[wooden mango]

I looked at that library as well as an alternative. I've decided I am only willing to use a library with a large community.

That leaves either photon or mirror.

[north trout]

Is there any reason you want to use prediction? @wooden mango
Fusion and Netick are the only battle-tested prediction

Mirror prediction is still experimental sadly

[woven nimbus]

fusion is the only option then

i urge u to try netick tho. even if u decide not to use it, you can switch to fusion really easilly. the api is very similar

[wooden mango]

Still heavily in research phase of what I need. Last couple of days I have been leaning heavily towards not using prediction.

[north trout]

depends on your gameplay type still

[wooden mango]

Without going into too much in depth. Constructing and piloting vehicles will play a major role. And having accurate physics for all players connected is incredibly important.

At some point down the line there will be FPS aspects.

From my understanding prediction is very useful for the physics simulation and FPS.

[woven nimbus]

both are correct

[north trout]

might go as well with quantum then..

[wooden mango]

I was heavily leaning towards that when I stumbled across it

Can't remember what it was now, but there was something that made me hesitant

Think I'm going to go play with quantum for a bit and see what a basic system looks like over there. Thanks for the help

[north trout]

awesome

[earnest adder]

There is no option to control this?

[wooden mango]

Unsure

Biggest room for improvement is to not send reconcile data that didn't change from previous tick.

Every rigidbody sends all of it's data even if not moving.

[earnest adder]

Yes, that's what we do in Netick.

In fact, the whole networked state of the game is delta-encoded, so only byte-level changes are sent.

[wooden mango]

Maybe I need to come check out netick... Remembered what made me not want to do quantum. From what I've seen from their official announcements they only support up to 64 players in a lobby.

[earnest adder]

I think in V3, they increased it to 128.

[north trout]

huh. how many players do you want to support?

[north trout]

yes correct

[earnest adder]

Though using Quantum means being locked in Photon's ecosystem.

They built a whole "game-engine" to make Quantum possible.

Since it requires bit-level determinism.

[wooden mango]

Honestly I don't expect more than a couple dozen to ever be on at a time. But I don't want the networking solution to be the limiting factor if it does happen to be more popular.

[north trout]

But I don't want the networking solution to be the limiting factor if it does happen to be more popular.
if your game is popular I dont think its make sense just to increase your max players count

[north trout]

what kind of games, do you want to have 64 players at a time

[wooden mango]

For now the goal is to achieve something similar to what starbase promised

[north trout]

starbase is a MMO?

[wooden mango]

Of sorts

[earnest adder]

What did they promise? Not familiar with that game.

[wooden mango]

It's just an open world space game. Persistant game world.

[earnest adder]

Seamless transition in the world?

[north trout]

there is not much of a game that uses prediction in a open world game

[wooden mango]

Released as early access and then completely cut off development a couple of months later

[wooden mango]

Which is why I've been realising I probably don't need that

[wooden mango]

yes

Which will need floating origin

[earnest adder]

So a true MMO world?

[wooden mango]

More or less. Less world and more floating around in space

[earnest adder]

I mean you can go huge distances and meet players playing etc? Seamlessly?

[wooden mango]

yes

[earnest adder]

If so, none of the networking solutions available are suited for this.

[wooden mango]

That is what I've been gathering.

[earnest adder]

Quantum won't work at all, since it's suited for very small worlds.

They resims the entire world in client.

[wooden mango]

I've seen floating origin solutions created in fishnet and mirror. Though they'll need to be created custom from scratch. Is there another reason the existing networking solutions wouldn't work?

[earnest adder]

Seamless transition.

[wooden mango]

I don't understand how that's an issue.

[north trout]

its better to have multiple servers managing a single "region" rather than a single server manage 100 regions

[earnest adder]

In MMO solutions, you are connected to multiple servers at the same time.

And there are complexities associated with object ownership and handling between these different servers (shards), etc.

Assuming this is the goal.

[wooden mango]

Unlikely I'd ever get that far. If it became popular enough to "need" shards. I'd spin up multiple servers with population caps.

And the things in the different servers would not interact.

[earnest adder]

Ah, so no seamless transition?

My point was the world is a huge distributed simulation between hundreds of shards.

If you mean a single server can handle the whole world

Then yea that can be done.

[wooden mango]

I'll definitely need to do testing along the way. But the intent is for a single server to handle the entire world.

[earnest adder]

Then yea, most of the popular solutions can do this.

[wooden mango]

There are other partial solutions that i'd do before doing actual shards

[earnest adder]

The thing is, seamless transition between shards can't just be added.

You need a netcode designed for that.

[wooden mango]

My goal right now is to get a prototype done. By the time it is done I will know whether I need to explore a custom netcode solution or if I feel confident that a single server can support enough people that I'm happy.

Who knows. Maybe I'll set it up to where I spin up a another unity instance for the physics sim for each region to offload that.