How do you decide what your file structure should be?

[ackkracck]

For example, I am trying to make a Stardew Valley clone.

However, I am stuck on how I should lay out my scripts and objects, i.e. should I have one script only dedicated to movement? Should the player animator script be within this script or should I make a new script file? When implementing a farming system, should one script do it all or should I have multiple scripts to compartmentalise the function?

I hope you get the gist of my question, this is really really bugging me and is the one of 2 biggest issues I’m facing right now.

Any help would be appreciated.

Thanks!

[spiney199]

I organise first by editor or runtime code, then by each major feature, and then by Assets or Scripts:

But really your file organisation should change as needed by the project. Start with whatever works, then it it starts to be cumbersome, work out a better system and change it.

As for how many scripts… as many as necessary.

For example:

@ackkracck

When implementing a farming system, should one script do it all or should I have multiple scripts to compartmentalise the function?

This could easily be dozens of classes. But you really only get a sense for that after coding for a while, alongside working out your coding style. Some people really don’t like making too many classes/scripts. Others like myself has no problems making lots of classes; very often with nested classes.

My current project has… 950 scripts files currently, a number of which will have more than one class inside them.

Just be aware that a Stardew Valley clone isn’t a simple project. Concerned Ape spent about a solid 5 years working on it, and I bet a lot of that was spent refactoring old and bad code. If you do try to jump right into it… prepare to throw out a lot of code at the beginning.

[CodeSmile]

The question shouldn’t be about one or two scripts, but rather what the architecture and data design will be.

A script is as class is a method and for all of them there’s the general rule: it should do one thing, and one thing only. Hence the idea of a “GameManager” is appalling to me and most seasoned developers. By its name already it implies that it is, or will be, doing way too many things in one class.

Anyhow, movement is one thing. Input is another. Input state is passed into movement for processing because Input state may also be what the AI decides to do. Animation is also separate and relies on the movement state.

[meredoth]

When it comes to file structure, I follow a similar approach to what @spiney199 suggests. For small projects, I organize files into folders based on type, such as scripts, sprites, and so on. As projects grow, I transition the folder structure to focus on features rather than file types. File structure should be like your code, refactor as needed.

What you’re asking, however, seems to be more about code architecture. This is an incredibly broad topi, so much so that countless books have been written on the subject, numerous principles have been established, and yet, there’s no definitive “right way” to do it. It’s a discussion that could span thousands of pages and years of debate without arriving at a single conclusion.

The reason for this is that code architecture is highly contextual. It depends on the project’s requirements, purpose, and target audience. It’s also highly subjective, shaped by each programmer’s knowledge, experience, and preferences.

That said, there are certain practices that are should be universally accepted. However, these are often overlooked due to lack of experience or because their benefits only become apparent as a project grows in complexity and size.

As @CodeSmile advises, for large projects, it’s best to avoid approaches like “global singletons” or overly broad “GameManagers.” Instead, focus on adhering to principles like the Single Responsibility Principle. I would say that is not so much of a class doing only one thing, reserve that for methods, but more of a class having only one reason to change. Defining what constitutes “a reason to change” can be challenging, but I find Bob Martin’s definition and the SOLID principles to be particularly helpful. And that’s where the proverbial rabbit hole begins.

If anything, when tackling the architectural aspect of your question, it’s essential to understand that architecture is far more challenging than coding or learning a new language. It’s a skill you never fully master, instead, you continuously improve throughout your life.

Personally, I’ve found the SOLID principles invaluable. They help me break down complex architectural decisions into five manageable principles, allowing me to build a solid foundation and work upward from there.

If you’re interested in learning about SOLID principles, I recommend avoiding YouTube videos or blogs (including mine) as your primary sources. There’s a lot of misinformation out there, and summaries often lack the necessary context to fully understand the concepts. Instead, start by reading the book Clean Architecture. Once you’ve built a solid foundation, you can supplement your knowledge with reliable information from the internet.