Should I use OOP for a quest system?

Greetings, I’m working on a quest system for my game but was wondering if I should concider looking into OOP for it. I’ve never used it on roblox but have worked with python classes on a very baisic level.

A mission may have one objective or several sub-objectives. They would give certain rewards and code would have to be executed for more complex, story-based quests.

I’ve not really learned how to decide weather or not to use OOP for things, for example an inventory system. Do you think it would be easier/worth it to create quests/a quest system using OOP? And what are some examples of how I could use it in a more efficient way than without it?

1 Like

Depends on how you wanna utilize and implement OOP. For sure you’re gonna use tables for storing inventory and sub-objectives for objectives. If you wanna use cleaner OOP I’d suggest you trying Typescript with roblox-ts and Rojo. However if you wanna make it in LUA, then just simply make functions as your “classes” and return a table of other functions and properties. Important to mention than Typescript and Lua won’t give you any functions/methods which tests for class or subclass. You’d have to implement such features yourself by adding a property for example “className”.

2 Likes

For branching objectives, maybe a node based data structure will help

2 Likes

one way would be to have modules inside each quest object and when someone interacts with the quest object you call a function inside the module

something like this (this is not working code its just to demonstrate my point)

-- modulescript inside quest instance
return function(player, ...)
    local arguments = {...}
    print("Hello", player, "this is quest part 1" arguments[1])
end

-- script inside server script service
local remoteEvent = game.ReplicatedStorage.RemoteEvent
local modules = {}

remoteEvent.OnServerEvent:Connect(function(player, module, ...)
    if modules[module] == nil then
        modules[module] = require(module)
    end
    modules[module](player, ...)
end)