What is your folder structure for client/server games

[Jazcash]

I'm in the early stages of my project and things are starting to get messy but I have no idea how to separate concerns. I know MVC, but that's more heavily geared towards websites and apps, rather than games. My current structure isn't terrible, but could use some inspiration for how to set things up going forward. This is it currently: 

- dist/
- src/
    - assets/
        - fonts/
        - images/
        - sounds/
        - styles/
    - client/
        - entities/
            - board.ts
            - card.ts
        - misc/
            - supertext.ts
            - tooltip.ts
        - scenes/
            - boot.ts
            - lobby.ts
            - game.ts
            - ui.ts
            - debug.ts
    - common/
        - schemas/
        - utils.ts
        - player.ts
    - server/
        - main.ts

Now I'm starting to think about client<->server comms, state machines, models, database managers and so on. Any suggestions of how I can structure the folders would be helpful, and if people are cool with sharing their own project structures that'd be awesome. Cheers.

[geeksesi::javad();]

.
├── client
│   └── src
│       ├── game.js
│       ├── game_tools
│       │   └── mechanism.js
│       ├── languageMenu.js
│       ├── mainMenu.js
│       ├── playGame.js
│       ├── seasonMenu.js
│       ├── server.js
│       └── wordMenu.js
├── index.js
|
├── package.json
|
├── public_html
│   ├── assets
│   │   └── phaser.min.js
│   ├── build
│   │   └── project.bundle.js
│   └── index.html
|
├── server
│   ├── db
│   │   ├── Kalemat(1).sql
│   │   ├── knexfile.js
│   │   ├── migrations
│   │   │   ├── 20190702120831_words.js
│   │   │   └── 20190706124538_new_struct.js
│   │   ├── mongo
│   │   │   ├── insert.js
│   │   │   └── modules.js
│   │   ├── my.db
│   │   ├── mysql
│   │   │   └── mysql.js
│   │   └── sqlite_mysql.js
│   └── server.js
|
├── webpack.config.js
|
├── yarn-error.log
|
└── yarn.lock

 

i just working on a project and my struct is this.
and i build the client code first and run game (both client and server ) by start index.js ( run socket.io for server and express static for client )

[mattstyles]

This is a really tricky question for a generic answer as there are so many variables which _could_ dictate whether your project structure works well or not so well.
Personally, I'd take any answers with a pinch of salt i.e. there is no single 'best' structure, like, not at all.

Have a think about what the problems you are trying to solve are and how the processes and concepts you employ for organisation are going to solve that problem?

To the above question, the answer is usually 'I do not know'. This is fine.

With the above in mind it is usually better to follow this sort of process:

• Start the project.
• Put stuff anywhere, it does not matter at this stage.
• Get something working.
• Keep going.

Now you have a working product and you can start to identify what organisational problems you have and think about how to solve them.

Until this point you are largely guessing. If you have created several similar projects before your guesses are probably good, if not, then they might not be. It is relatively easy to apply some structure and organisation to a project that doesn't really have one, it can be pretty tricky to change organisational structure (can be, depends on many things again, you certainly should not be afraid to change later on if your current system turns out to be not very efficient).

There are some rules of thumb that might help you though:

• Small files and folders are easier to manage than larger ones i.e. small in scope, not necessarily small in lines of code.
• Decouple things as much as possible, this makes them easier to work with, and makes organisation easier to change. Tight coupling is a nightmare, avoid at all costs.
• Uber objects (and, similarly, uber-projects) are hard to manage, this is really the above concern worded differently. Divide and conquer.
• UI and logic (rendering and smarts) are good things to separate.
• Avoid logic duplication, if you end up writing similar logic in multiple places, consider generalising and abstracting it. Utility functions can form a huge part of your codebase and is _usually_ a sign of good organisation.

MVC is fine for games. As are other methodologies.

Go with what you think makes most sense for you (and your team) and the project.