Skip to content

Quick Overview

Fabian B edited this page Jan 27, 2020 · 1 revision

This page covers why you should make all your future gamemodes modular as well as general concepts and some basic terminology.

Motivation

When you started out scripting with Pawn, you probably didn't care much about code architecture as long as the code did what you wanted it to do. For the purpose of learning, you're actually encouraged to get your hands dirty writing some really shoddy code that you will look back on with shame one day. At some point, you may have decided to write your own gamemode and started out by putting everything into one single file simply because you were used to it or didn't know any better. Many have held onto this style and chances are you have too.

As your gamemode kept growing in size, you have probably noticed that things started to get messy. Adding new features, removing old ones or even fixing bugs became harder and harder. God forbid you have to work with someone else's spaghetti code. Luckily, there is a solution to this - and it's called modular programming.

Concepts

In software development, there is this notion of tightly coupled and loosely coupled code which indicate to what degree individual components rely on each other. This translates directly to how easy it is to replace or change them.

  • Tightly coupled code is rigid and highly cohesive. Every part of the code makes assumptions about every other part of the code. On paper, this can sometimes result in slightly more performant code.
  • Loosely coupled code by contrast is separated. Every part of the code communicates with other parts through more or less standardized and neutral interfaces. This makes the code much easier to understand and maintain.

At first glance, a monolithic approach might look easier. After all, everything you need is in one place. Popular gamemodes like "The Godfather" did it this way which is probably one of the reasons why people are still structuring their code by declaration type. It may look clean but actually just causes a huge mess in the long run as logically related code parts are scattered everywhere. This keeps getting worse as your gamemode grows in size.

Modular programming seems pretty intimidating at first since there are a couple of things to learn and to get used to. But don't worry, it's not as hard as you may think and once you get the hang of it, you'll never go back if you don't have to. In the context of SA:MP/open.mp, the increased readability and maintainability of a modular gamemode completely outweigh the tiny performance increase in a monolithic one (which you and your players probably won't notice anyway).

Terminology

Module

A module is a logically seperated software component that ideally provides only one single functionality. It typically consists of one or more .pwn files that interact with each other through an API (Application Programming Interface). An example of a module would be a house system or a race system.

Interface (API)

An interface denotes a set of functions in a module that is meant to be accessed by external modules. These functions play a major role in the interaction between modules. An example would be getter and setter functions to access or manipulate data from another module.

Clone this wiki locally