I prefer having less resources as possible. From my experience, it seems to load faster that’s for sure (on first load onto the server anyway). Also, for stream resources, I think they are better to be combined, yes the loading can be slow and problematic but it’s about finding that sweet spot and then separating them into their own resources if they take too long to load on the server. The client seems to unload stream resources faster when it’s a single resource from my experience. What might be a good test for you is to go into a server with a bunch of resources and then try one with just as many in-game features but less resources.
I commented mainly just to ask what is the main benefit of writing in typescript? Type safety and stuff yeah but is it more performant?
I’ve been asking the same question. My current stance is that separating systems into individual resources allows each system to be restarted independently, without restarting all the other systems.
On the other hand, from a dev experience standpoint it’s far better to work in a single environment than calling exports all the time. Or at least that’s my case.
I separated inventory, jobs, vehicles, housing, ui, banking, etc. into individual “resources” that don’t really do much on their own. They define logic and expose API other resources build upon. And while I like it, sometimes I miss working in a single OOP environment. Right now there are exports left and right… and up and down
If you are developing your own server for your own needs and not necessarily want your resource(s) to be public anyways, might as well go for a single resource encompassing everything. You can already design your own resource to “restart” only certain modules. No need for separate resources that way.
However if you want to make your server/framework/resources public, you should consider separating it into individual resources. Others always want to adapt where possible which can be a real hassle in a large singular code base.
I always struggle to find that single thing that is bothering me and needs changing but does not have an easily accessible config entry. Especially with frameworks for many other games where they only have a single large resource/mod and everything becomes a clusterfuck rather quickly.
Though there is the argument of having one large resource (e.g. the framework with its modules) and then have other standalone resources separate where possible.
E.g. a resource for “sitting down everywhere” does not really need a tie-in into a framework to work its magic.
Impossible to develop a server entirely on your own if you want to make something people actually want to play, until you have a multi-person dev/admin team working full time.
You will likely be using multiple resources from other developers unless you plan to run a server with 1 or 2 players.
Use multiple resources so you can restart/push fixes on your live server as quickly as possible, lets you be flexible.
Only situation I’d recommend you combine assets/resources is in situations where there is no chance/need of them being reset on live. I.E. Vehicles, clothing, etc.
Gains you get from packaging all your resources is marginal vs the convenience of multiple resources. You’re sacrificing convenience for potentially a second or two saved at start up.
I think there’s a “benefit” to do so with C# since every resource has an overhead of 0.01, so there’s a benefit to bundle everything, but there’s like 2 devs in the entire community publishing in C#, so not even worth worrying about.
My project is built entirely in TypeScript, and I initially decided to consolidate all interfaces into a single UI resource while keeping the logic in separate resources. However, build times became excessively long; furthermore, although the resource would launch, the interface wouldn’t actually work until I restarted it again. It seemed to function fine after that initial hiccup, but the situation was becoming a nuisance. I concluded that it is better to have many small resources rather than one massive, monolithic one.
