Mini world follows an event-driven architecture. What this means for us is that scripts are centered around events. The basic structure goes as follows.

[INSERT IMAGE HERE]

Where: callback receives additional info from the engine, for example. The position of the event, the player or actor who triggered it and many more variables.

In the FIX REFERENCE (PREVIOUS) part of this series. We explained the basics of how to register events with the listener ¹⁾ function. In this article, we will focus specifically on the data that events pass to the callback function and how to handle it safely.

[INTRO TEXT, ADD LATER]

Event-driven programming is an alternate style of coding where the flow of the program is determined by events. An event can be anything, a mouse click. A key press. Or in the case of mini world, a player moving, placing a block, or spawning something. This instead of the normal flow where the program runs the same instructions over and over.

A good analogy for it can be a shopkeeper who instead of walking around all day looking for clients, stands at the counter, and responds only when someone walks in.

A constant loop (or polling) is when a program checks for conditions like this:

while true do 
    -- something
end

Here, the program is always running, that, checks the same conditions, even if nothing happens. This lowers performance because it wastes processing power, due to the program being busy checking conditions instead of doing useful work.

Event-driven programming replaces this unefficient constant checking with listeners or handlers that automatically respond when an event happens:

(Pseudocode)

on_key_press(
  do_something...
)

This is efficient, especially for games, where power, memory and CPU may be limited, for a variety of reasons such as:

• Less CPU usage: This due to not running every frame, but only when stuff actually happens.
• Better responsiveness: This links to the point before. As it reacts instantly to events instead of waiting for the next loop cycle.
• Simpler code: Logic is separated for each event, making the program easier to manage overall.
• Modularity: Events are independent, and one failing doesn't affect the codebase as a whole. Making it safer.

[INTRO TEXT, ADD LATER]

If an event uses multiple parameters, the function structure is rigid:

Example:

(Pseudocode)

onPlayerHit(player, damage, pos)

Here, the order matters, which means that the meaning of each value depends on the position of it. Which in turn makes adding or removing anything a pain, as it would require changing the function definition everywhere.

Now, comparing to tables:

(Pseudocode)

onPlayerHit({
    player = player,
    damage = damage,
    pos    = pos,
})

With a table:

• Order doesn't matter
• You can add more, or less data without rewriting everything
• The meaning is explicit (event.player instead of parameter X)

This makes the system far more flexible overall.

Tied to the reason before, is scalability. Everything grows, events become more complex, at the start we may only need one parameter to pass, if we were to rely on positional parameters, the function would become very long, extremely hard to read, and prone to errors.

TBA. short summary, signal end of theory and that what we learned will be useful on next part of the series.

List Of All Event Here

In the previous section, we focused on the core ideas: how the system works, why it’s structured that way, and the logic behind its design.

ScriptSupportEvent:registerEvent("Game.Start", function()
    print("The game has started!")
end)

In this example, every time the game starts, the message “The game has started!” will be printed.

• Event Name: “Game.Start”
• Function Parameter: None (no parameters are passed to the function in this case).

The “Player.ClickBlock” event is triggered whenever a player clicks on a block in the game. When this event is fired, it passes a table as a parameter to the function, which contains the following information:

• eventobjid: The object ID of the event.
• x, y, z: The coordinates of the block the player clicked.
• blockid: The ID of the block that was clicked.

Example:

ScriptSupportEvent:registerEvent("Player.ClickBlock", function(eventData)
    local objid = eventData.eventobjid
    local x = eventData.x
    local y = eventData.y
    local z = eventData.z
    local blockid = eventData.blockid
 
    print("Player clicked block at position:", x, y, z, "with block ID:", blockid)
end)

In this case, every time a player clicks on a block, it will print the coordinates and the block ID to the console.

• Event Name: “Player.ClickBlock”
• Function Parameter: A table containing the details of the block clicked.