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]

List Of All Event Here

The “Game.Start” event is triggered whenever the game starts. You can use this event to run code when the game begins. In this case, the event does not pass any parameters to the function.

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.