Unsure of how I should structure my mission system

I’m currently working on a mission-type game for my studio group, SummerJay Studios. I’ve already made the acrobatics system and think I’m going to start working on a mission system. Said system will handle stuff like which levers have been pulled, which doors have been opened, and which areas have been cleared. This is where I’m a bit stuck. I don’t know how I should structure this system (and how to possibly implement oop) I’ve been thinking of a basic system where a mission is just a table with more tables and I have no idea if this is even ethical.

local mission = {}
mission.Doors= {}
mission.Areas = {}

I need pointers for how to properly and neatly (and efficiently) create this mission system. If you find this a bit vague and need a bit more info kindly ask for it. Thanks for the help!

(PS - I’ve only recently learned oop, and I’m struggling with implementation - help with this, if possible in this scenario, would be great!)

Interesting question! I personally organize my data for games and other player information in the format of tables, tables within tables, dictionaries within tables… But when you are new to this, it’s best to make sure you leave yourself some notes in your code for how your data is structured.

For example, I have a module script that contacts my player data, similar to your first post. You have to assign an identifying key, but if you would like for your example, you can wrap it all up in the same Dictionary. You could set all relevant doors into one array, and then assign it in your dictionary by using: mission["Doors"] = DOOR_ARRAY or while using a for loop to go through your doors, mission["Doors"][for_loop_index] = Door1. Same goes for mission[“Areas”], etc…

To read back from this dictionary, you would use an index or you can use table.find() on mission[Doors].

Your dictionary entry, [“Doors”], is thus handled just like any other array.


The example data structure you provided works to the extent that it gives the player something to do, but using an object orientated approach may not be the best way to approach this problem considering you are just starting out with OOP. This isn’t to say that you can’t do it with OOP, but it’s just something for you to consider. You also have to keep in mind that OOP is something that should be used in moderation and won’t be the best thing to use for every project you encounter.

You might have an easier time creating a system like this using universe places for each mission. For example let’s say I have a heist mission. I can teleport the player to the heist game where the rules are specifically written in a regular scripting style (event based, etc.)

Think of how Dungeon Quest handles their dungeon system for reference. Hope this helps.


It kind of depends on what a mission is, at least in your terms.

Is a mission the place the mission is taking place, it’s objective, its status, and anything that has to do with it (like npcs), or is it just the objective and status?

You have to decide what it is and what it means.

You have to take everything into consideration here, meaning your other scripts and modules. Who manages what? You have to decide what is the most efficient for you.


I agree with this for if you’re just starting out, although OOP is a great habit to get into and develop as early as possible. :grin:

1 Like

As for data structuring, I would suggest OOP. By making an instance of a base class mission, you can include functions and data all in the mission that you have. This makes it easy for you to centralize the scripting for this, and not have to use too many external scripts. Objects are good for reusable things that have a base of attributes and functionality to them, like a car or a person. In the case of missions, they are certain actions or a sequence of actions a player must take to complete, for maybe some sort of reward. They can be given many times and all have essential properties like the resources (stuff needed), the goal, the reward. They fit the requirements to have an OOP data structure, so if you want to, I think it is worth pursuing.

1 Like