[Suggestion] Get away from those single file gamemodes

[Double-O-Seven]

I just check out Github and saw that even the 3 example gamemodes are single files. I think you should lead as an example and implement examples in a modularized manner, no matter how small the gamemode. I think if SAMPs example had been more modularized from the beginning we wouldn?t have as many 60k line single file?abominations as we have today.

[DTV]

I think they're doing it that way to be similar with SA-MP and how they provide their example gamemodes so its familiar to new and old players alike. It all boils down to personal preference though, some people won't follow suit regardless of what you suggest.

[Manyula]

Even if you compel people to write modular scripts, everyone has an individual take on "modular" - at least when it comes to Pawn, imho. And, as far as I can see, this is due to a couple of reasons:

1. People get confused because there is no uniform approach to modular programming in Pawn and they're afraid to make things wrong.
   
   
2. People think that due to the increased length of the script when modularizing the gamemode, this somehow negatively affects performance, readability and their ability to find things in their gamemode.
   
   
3. People get confused as to how to break things down and which order to include them in. They think that if two or more systems interact or rely on each other, they may as well merge them into one file.
   
   

Bottom line is, these people need to be taught, and that's a community effort. There's a need for a first and foremost SIMPLE approach to modular programming in Pawn. Here's how I do it:

• Hooks of natives are included on the very top of the main script.
  
  
• Systems are broken down into two files:
  
  1. Data Getters/Setters to access the data?(if necessary)
  
  2. Implementation (functions and callbacks)
  
  
• In case some data is needed in a file that was included after the file that accesses it (and this forcing a reparse), I just forward the particular function in the file that tries to access it.
  
  

[JustMichael]

I think somewhere down the line, we might make a proper tutorial with proper script examples that not only explain how modularised programming works, but how to use it properly with good and bad examples.



It would probably be included in a full strip down of how Pawn works ins and outs and even explain's style guides and the differences between Pawn and other languages.



This would probably be a public repo based guide where anyone can contribute to.

[Pinch]

Even if you compel people to write modular scripts, everyone has an individual take on "modular" - at least when it comes to Pawn, imho. And, as far as I can see, this is due to a couple of reasons:

1. People get confused because there is no uniform approach to modular programming in Pawn and they're afraid to make things wrong.
   
   
2. People think that due to the increased length of the script when modularizing the gamemode, this somehow negatively affects performance, readability and their ability to find things in their gamemode.
   
   
3. People get confused as to how to break things down and which order to include them in. They think that if two or more systems interact or rely on each other, they may as well merge them into one file.
   
   

Bottom line is, these people need to be taught, and that's a community effort. There's a need for a first and foremost SIMPLE approach to modular programming in Pawn. Here's how I do it:

• Hooks of natives are included on the very top of the main script.
  
  
• Systems are broken down into two files:
  
  1. Data Getters/Setters to access the data?(if necessary)
  
  2. Implementation (functions and callbacks)
  
  
• In case some data is needed in a file that was included after the file that accesses it (and this forcing a reparse), I just forward the particular function in the file that tries to access it.
  
  

I'm always afraid that I won't call function correctly or just forget to call it cuz I have bad habbit of fast writing and I'm kinda dyslexic so I have problem there, that is the only reason why I prefer single file more, but I'm doing my best to get used to modularized way

[JustMichael]

Even if you compel people to write modular scripts, everyone has an individual take on "modular" - at least when it comes to Pawn, imho. And, as far as I can see, this is due to a couple of reasons:

1. People get confused because there is no uniform approach to modular programming in Pawn and they're afraid to make things wrong.
   
   
2. People think that due to the increased length of the script when modularizing the gamemode, this somehow negatively affects performance, readability and their ability to find things in their gamemode.
   
   
3. People get confused as to how to break things down and which order to include them in. They think that if two or more systems interact or rely on each other, they may as well merge them into one file.
   
   

Bottom line is, these people need to be taught, and that's a community effort. There's a need for a first and foremost SIMPLE approach to modular programming in Pawn. Here's how I do it:

• Hooks of natives are included on the very top of the main script.
  
  
• Systems are broken down into two files:
  
  1. Data Getters/Setters to access the data?(if necessary)
  
  2. Implementation (functions and callbacks)
  
  
• In case some data is needed in a file that was included after the file that accesses it (and this forcing a reparse), I just forward the particular function in the file that tries to access it.
  
  

I'm always afraid that I won't call function correctly or just forget to call it cuz I have bad habbit of fast writing and I'm kinda dyslexic so I have problem there, that is the only reason why I prefer single file more, but I'm doing my best to get used to modularized way

Don't worry too much about that, it's all about learning from the right place. If you join our discord you will find many people there that will help guide you in writing much better code. We can help you in becoming a better programmer in general, it's what we do ;)



Also don't let your disability stop you, I suffer from Autism, Dyspraxia and HDHD, and I too once thought it was impossible to improve, but with the help of people from the discord, I have improved a lot and that has helped with me diving into other programming languages.



Keep pushing yourself to do better :)

[Livio Miranda]

Do you guys have an example of a nice modular GM? Or at least some hints on how to do it, I'm a newbie here.

[Manyula]

Do you guys have an example of a nice modular GM? Or at least some hints on how to do it, I'm a newbie here.

Here's a guide on how I do it:?https://github.com/TheManyula/Modular-Pawn

Hope this helps!

[Torque]

It all compiles to one amx file. Makes no different whether it's singular or modular. That's down to the preference of the scripter.

[Manyula]

It all compiles to one amx file. Makes no different whether it's singular or modular. That's down to the preference of the scripter.

The amx has nothing to do with the gamemode layout whatsoever. Single files are okay for small or high-performance applications but not for SA:MP gamemodes. Going modular is also beneficial if you plan to have more than one person working on the gamemode.

[Torque]

Why? When you compile the gamemode into a .amx file, how does singular or modular effect it?

[Banditul]

Why? When you compile the gamemode into a .amx file, how does singular or modular effect it?

It will not effect it. But code is written by people for people to understand and easy modify (most cases) so would you rather have a piece of code that is easy to understand and modify later on? Or spaghetti shit that if you take a break from it will take more time to understand it again?