Unitystation: Proposal: Reorganize folder structure of /Assets/Scripts

Created on 13 Aug 2020  Â·  6Comments  Â·  Source: unitystation/unitystation

Note this isn't a bug, not sure if it can be tagged as a proposal/improvement.

Description

Proposal: Reorganize folder structure of /Assets/Scripts
Purpose: Make the codebase more navigable and improve organization. Compartmentalize all the things. Keep various realms of code properly separated to avoid having messy code as the codebase matures.
Risk: Low risk in the majority of cases i think since no code is actually being modified.

This is an entry from nuke's code janitorial list of proposals
_"for your health!"_

Details

Start with 4 broad categories as folders (assume we are using Scripts as the root folder):

  • Core (boilerplate code, utility stuff, helpers)
  • Gameplay (general gameplay concepts like Chat, Effects, UI, RCON, NPC, TTS, Networking. The exoskeleton of the game, BUT note that there's nothing SS13-specific here. It's all generic concepts.)
  • Modules (broad gameplay concepts such as Electricity, Explosions, Fluids, Reagents. The building blocks of the world that give the game its depth.)
  • Station (all other code that falls within the scope of SS13 - this would contain a bunch of subfolders)

Station subfolders

  • Jobs (All jobs that require specific code and such would get their own subfolder in here)
  • Gameplay (SS13-specific gameplay concepts such as the health system, medical system, inventory system, hacking system, antagonist system, gamemodes)
  • NPC (A broad category for all the various NPCs that will eventually populate the world. Can break this down further into more subfolders.)
  • World (All things pertaining to the physical station, whether it's immobile or mobile. Doors, floors, walls, windows, shuttles, maybe decals(?) ... It's a bit hazy as to whether doors would fit this category or if they'd be considered a stationary entity. Needs more thought. Can we put this entire category inside of entities or is turf/walls not dynamic enough for that categorization?)
  • Entities (A broad category for all interactable objects. We can break this down further with more subfolders)

Entities subfolders

  • Stationary (Stationary subfolder could be further subdivided into Powered and Unpowered.)
  • Movable (Large items you can move around, like air scrubbers and space heaters)
  • Items (Things the player can pick up in their hand. Break this into more subfolders - Weapons, Containers, Consumables, Tools)

As a rule of thumb you should be able to pick a folder at random in the Scripts folder and you'd be able to figure out which of these folders it belongs in. If not, then it might need to be handled on a case by case basis or maybe would need to examine the folders that could not be categorized and see if there's a missing category.

You might also be able to argue that the categories be done in a different way, i'm all ears.

There's also a chance that there's a bit of intermingling of concepts. As a purely hypothetical example, say that a lot of job-specific code were inside of the Electricity folder, which would mean the folder wouldn't perfectly fit into Modules or Jobs since it's a smoothie of different things. To me this would be a red flag, keeping the job-specific code and the system-specific code separate would be important as far as organizing the codebase is concerned. So in some cases there may possibly be a bit of refactoring/separating of concepts to do... But my hope is that this would be an exception to the rule. I am still getting accustomed to the codebase so i'll defer to someone with more intimate knowledge of it.

If this proposal were to be broadly agreed upon then i would be ready to start work on it whenever it's approved.

No Coding Discussion

Most helpful comment

I think it would be best to do it after we push the next build, a new build hasn't come in ages because the builds kept breaking and we've only managed to push them to staging recently. If we fix the nasty bugs and the maps, then push it, contributors and players wouldn't mind if you moved all the code around into their new folders.

All 6 comments

Yeah, scripts folder reorganisation would be very nice indeed – especially the UI section that is a mess
A few other thoughts off the top of my head:

  • There are plenty concrete NetMessages, both clientside and serverside, that are ss13-specific, but whole Messages folder seems alright as is. Not sure what's the best category for it.
  • There are quite a few Matrix/Transform/Tilemap-related scripts and they should probably all go into the Core category

Also this would need to be coordinated with contributors currently modifying scripts – perhaps a 1-2 day script freeze would be appropriate. And other pending PRs would have to be merged and closed before that

we also need to migrate some stuff to the packages folder,
stuff that's not dependent in anything scripts like logger,
since if they're in the packages folder they don't get recompiled all the time

Perhaps calling the Objects folder Entities or some-such might be more appropriate, and rename Stationary to Objects. I think it would fit in more with how they are referenced elsewhere. I see you've updated the OP. Neat!

I'll update the OP with that, makes sense to me.

I was thinking about how badly this would impact other contributors, you'd definitely need a code freeze for a short duration. I think this change could probably be done relatively quickly in an afternoon (the broad strokes anyways - if there were refactoring to do it could be saved for last after the major reshuffling has been done and wouldn't require the code freeze really)

I think it would be best to do it after we push the next build, a new build hasn't come in ages because the builds kept breaking and we've only managed to push them to staging recently. If we fix the nasty bugs and the maps, then push it, contributors and players wouldn't mind if you moved all the code around into their new folders.

Maybe if it syncs up well with the new build it could be done immediately after the build is published since i'm sure there will be an effort to close out a bunch of features for said build. So it would put the project in a good place for a very brief code freeze.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

krille90 picture krille90  Â·  4Comments

Destrolaric picture Destrolaric  Â·  7Comments

DooblyNoobly picture DooblyNoobly  Â·  7Comments

Destrolaric picture Destrolaric  Â·  5Comments

NoooneyDude picture NoooneyDude  Â·  4Comments