Offline mode

[Nemikolh]

Currently the offline mode is quite different from the online one when a lycan server is available.
We should try to update this code to match lycan better.

[ghost]

I think the best way to do it is to use Lycan in such case, or at least a subpart of it.

[Nemikolh]

I think the main issue is that we don't want the client to have lycan as a dependency. As long as the offline mode doesn't do much, I think this is fine to keep all that logic within the client.
Once we move to more complex use case for online mode, I think we will consider having a crate that is both used by lycan and sarosa.
I think for now we can keep the current simple model, what do you think?

[ghost]

Well, you should be able to define two binaries with cargo and to add different dependencies for them ?

That means most of the rendering code of Sarosa should be inside a crate, but yet another time we can use cargo for that, no ?

At least, you can in Haskell d:

[Nemikolh]

I'm not sure to follow you to be honest.

My point was essentially to say that we shouldn't try to aims for something that complicated right now. Here's why:

• Lycan hasn't been designed (yet) to run on a single machine for a single user
• Lycan's API will (already?) support authentication, something that doesn't make sense for offline mode, so it will have to cope with that or we will need to bundle an offline bz as well.
• If sarosa depends directly on internals of Lycan, this will be an even more pain to maintain it.
• The scope of the offline mode is quite simple (for now) and can stay like that for a long time. Its main use is to debug/experiment with rendering. The current version is almost perfect for that use case.

This issue is really about doing something simple that wouldn't require much work. I personally want us or any contributor to spend times on key features that will make the game progress faster and allow @Azamung or anyone else to experiment on gameplay design decisions.

Regarding your questions:

Well, you should be able to define two binaries with cargo and to add different dependencies for them ?

I think you can't without having two separates crates. But having an additional crate is not a problem. With workspace it would make even more sense. So yes, we can. :)

That means most of the rendering code of Sarosa should be inside a crate, but yet another time we can use cargo for that, no ?

sarosa_engine is a separate crate containing all the rendering code of sarosa plus other things. It is not a binary. Does that answer this question? (To be honest I'm not sure to understand what you are trying to say :3)