[Eoussama]

So, I wanted to give modular Programmation in making samp servers a try, and so I made a little work on a new project, but I'm still confused whether I am doing it right or not, so here are few pictures of it,







Please, guys, tell me if this is going in the right direction or not,
thanks in advance

Bump, please guys, I really really need a fast answer, kinda in a hurry,

[Gammix]

Not really the right way. If you understand includes, they are a form of a module to your main program.
So modules are usually made when you are using the functions or methods more than once in a script or more than one script.

And another form of modular programming can be plug'n'play scripts. Well for that SA-MP provides us "FilterScripts", "PVars", "SVars" etc.
But in case you have a situation where you want to integrate say login and register system, you should be able to disable that module whether in game or while compiling. That's how i find modular programming useful, or proper phrase is Object oriented programming.

So don't just make silly modules like these:

PHP Code:

// Modules/dialogs.pwn
House_Dialog(playerid)
{
    ShowPlayerDialog(...);
}
// Modules/house.pwn
House_OnConnect(playerid)
{
    // load house data
}
House_OnDisconnect(playerid)
{
    // save house data
}
// Main.pwn  <-- your main script
public OnPlayerConnect(playerid)
{
    House_OnConnect(playerid);
    House_Dialog(playerid);
}
public OnPlayerDisconnect(playerid, reason)
{
    House_OnDisconnect(playerid);
} 


That will really make your code almost impossible to read and understand plus hard to make changes.

[PrO.GameR]

I've wrote a huge wall of text but changing IP turned to be a bitch and I have to write all over xD

Basically your way while not necessarily wrong is a nightmare to work on, essense of modular gamemodes in sa-mp is that you'd find all there is about a module (systems like house, veh, etc.) under one file or multiple files under a folder so you won't have to find all little bits of a system in your huge wall of code when looking for a problem/bug.

Keep in mind there are a lot of ways and there is no 1 right way, most of them have advantages and disadvantages over one another.

for a good example of modular programming to cope take a look at Scavenge and Survive by Southclaw.

[SickAttack]

If you are going to follow this style, I'd advise you to lay out things to a point where you can disable a module with ease (by simply commenting it out in the source code).

Meaning, your modules would specifically be main (basically the core), vehicle system, house system, business system, Christmas add-on, etc.

That's the only use I see for modular programming here (disable modules for more efficient testing and debugging, or disabling/enabling themes/add-ons and anything similar to the previous).

[BiosMarcel]

If you'd like to experiment a little, you could try to look at Shoebill, since it is Java (object oriented) it might be easier to do Modular programming with, since you have interfaces, classes ... and so on.

[Sew_Sumi]

Shoebill doesn't quite fit this scenario, instead GrandLarceny has some of it implemented in the first place.

As PrO.GameR said, check Scavange and Survive.

[Dayrion]

Hey. I don't know if I'm late but I asked the same question there and I got really good answers.
I didn't follow every answer for my personnal gamemode and it's NOT the best way to do modular programmation but I'm okei with it :

player/commands is unused so commands are directly in the main file + OnPlayerCommandText + OnPlayerCommandPerformed are in the main file beaucause they can't be hooked. The name is too long.

[Sew_Sumi]

Just saying, naming them all the same name, will cause you issues in the long term, and I'm sure that was even mentioned somewhere recently as well...

[SyS]

Quote:

Originally Posted by Sew_Sumi Just saying, naming them all the same name, will cause you issues in the long term, and I'm sure that was even mentioned somewhere recently as well...

Yeah this is right especially when you have hooks for same callback in modules having same name.

[Yashas]

Why do you bother to find out if your code organisation can be called modular programming? If you are comfortable with it, then use it.

It does not matter if you are doing it right or wrong; do it how you like.

[Gamer_Z]

Quote:

Originally Posted by Yashas It does not matter if you are doing it right or wrong; do it how you like.

Except when at one point you decide to go on a joint venture with other scripters / make a team, adhering to well established principles and standards is a must to be able to quickly and efficiently progress forward. Else you'll be stuck with an unmaintainable mess. Good luck with that, especially with a "it does not matter" mindset. If you are sure that this will be a solo venture then yes, this might apply, but even then it's good to train yourself for team efforts.

As for the topic starter: Divide your source files according to functionality (components). This is exactly what you do when you bundle includes into your mode - each include you use has a different type of functionality. e.g. a_vehicles is for managing vehicles, a_players for managing players, you could make your own houses include which will contain all callbacks required for it to work, all commands, all dialogs, etc. Then you could make a vehicle ownership include where you do the same (again all commands/dialogs/other callbacks). And so on. Just to name some examples.

With this approach you try to make each component as independent as possible of each other (so you could basically drag and drop the files into another mode). Ofcourse this is not always 100% possible (well then your 'components' just gets bigger) but try to keep that in mind.

If some components have sub components then divide accordingly.

[Sew_Sumi]

Should almost avoid a_include names as those are what the native includes use...

Use something like the gamemode name or acronym _player to be clear, as messing up with those includes would be relative to the same as naming all the files the same, as in main.inc, in 6 different places where the folder is the only difference.

That's why the GL includes have gl_messages, and the normal includes have a_players for instance.