Tool Instances vs Pseudo Tools: Aiming to find a reasonable preference

Help and Feedback Game Design Support
#1

I am currently refactoring an old game of mine from ground up and a design question regarding tools popped up in my mind. I understand that this is purely preferential, but there may also be some merit in one system over another which is why I’ve taken to the DevForums to inquire.

The game I am working on is an RPG, which means that a lot of its activities are heavily dependent on the tool system first before anything else. That means that crafting the tool system is of utmost importance in order to determine how further I can progress with the rest of the game.

The dilemma I’m facing is whether I should use tool instances or set up a custom tool system. I’ve thought of a few points for each side - obviously it’s not everything, but it’s most of what is relevant to know about each system.

Tool Instances:

  • Pre-coded behaviours interfaced in CPP/backend (e.g. methods of Tool)
  • Simple setup, much of tool behaviour automatically handled
  • Widely known for games based on tools, straightforward process
  • Room for external behaviour (e.g. sheathing swords)

Pseudo Tools:

  • Complete control over tool behaviour, written majorly in Lua
  • Easier to handle when it comes to external logic (i.e. weld models on avatar)
  • Ignore Tool instance behaviour (backspacing, user input, …)
  • Must account for state typing (equipped, unequipped, debounce, …)
  • Must handle all behaviour alone (equip logic, unequip logic, networking, …)
  • Custom inventory to allow access to these items

tl;dc;dr: I want to make a tool system. Should I use tool instances, or should I code the entire system without the use of tool instances? What are the benefits of one system over another, both developer and UX wise? What are your preferences for tool stuff?

3 Likes
Should I be using tools anymore?
Preventing player from unequiping tool
How to make Pseudotools (UPDATED)
#2

I feel like you have quite comprehensively answered your own question. The tool instances I feel are too outdated compared to the quality expected of roblox rpg games these days (polished inventory ui, welding gear to players) although the built in networking of tool instances is nice. Perhaps roblox can revisit tools and the player backpack feature.

#3

I haven’t answered my question at all. What I have listed is the potential capabilities of each system, though I would be able to create either system with or without a tool instance facilitating tool behaviour.

Tool instances do not need any kind of update that I know of except for transforming RightGrip to a Motor6D, so I wouldn’t really can’t them outdated. Tool objects are still used quite prominently in other games as well, including RPGs.

Again, like before, tool instances can merely be used to facilitate tool behaviour but any kind of tool system can be accomplished with or without tool instances. From a technical comparison, the above lists are available. From a player standpoint, it’s a difference between use of the core backpack or a custom method of receiving and equipping tools.

I want to know which one is better from a developer and UX standpoint and why. I’d like to know the benefits of one over another, if any. Finally, I’d like to hear preferences regarding this kind of system.

#4

If I were you, I’d use psuedo tools because you have a LOT more control over them if you know qhat youre doing.

Tools are good when it comes to their built in functions which can make scripting a lot easier. But their reliability isnt as good. If theres a bug/glitch introduced by Roblox (not likely, just a scenario) with their api and it breaks your scripts, you’d probably lose some players and have to wait for engineers to fix or you got to find a workaround. Meanwhile, psuedotools can have their bugs fixed by you in a snap of a finger.

Also, many front page games as far as I know are moving to psuedo tools.

And performance wise, it probs won’t make a differnce.

#5

The same amount of control that I can achieve without tool instances, I can with. The only difference in one model is that a chunk of behaviours are facilitated for me via CPP and Core Scripts, with methods exposed to help me integrate functionality.

Tool reliability is fine because the majority of issues with tools stem from either the Humanoid or the code added to tools - the instances themselves have never had issues as far as I’ve known. The tool object itself breaking on the backend won’t affect my game unless I explicitly reference something related to the tool (e.g. Tool.Equipped magically stops working). Pseudotools can have as much, if not more, to account for. Bugs don’t get fixed with a snap just because of using one system over another (I’m aware its a metaphor and not meant to be taken literally, but even then it’s a poor metaphor to use).

Lots of games still use tools. Some games don’t have tools at all and have varying systems. What other games use doesn’t matter.

Let me reiterate what I’m looking for:

  • Which is better from a developer standpoint and why
  • Which is better from a UX standpoint and why
  • If there are any other benefits to picking one over another - I haven’t compared the lists yet
  • What preferences you hold and potentially some backing to it (e.g. “I like pseudo tools because of their intuitive feel and customisability” or something)
#6

For the sake of simplicity I’d like to use Tool instances, however I can also consider pseudo tools for full control of the API. Really, there is no good answer for this question, now that I’ve thought thoroughly about it. It’s really all preferential.

The game currently sports a pseudo tool system, however it is faulty due to the majority of it’s code demanding consolidation. The code isn’t all that reliable either, since I didn’t modularise it properly.

I will probably create a custom Tool class module that replicates the behaviour and exposed API of Tool instances to make it easier on me and more approachable for collaborators. This is if I proceed with pseudo tools.

local Tool = {}

function Tool:Equip()
    -- Equip state true, equip logic, send back mouse
end

function Tool:Unequip()
  -- Equip state false, unequip logic
end

-- etc

function Tool.new()
    -- Instantiate a tool
end

return Tool

The only real difference that would have any significance between paradigms is accessibility, even though that’s a non-problem since I can make Tool instances accessible like pseudo tools. It really honestly doesn’t make a difference since I can create the same functionality both ways. I suppose I’m just conflicted on a design that feels appropriate.

3 Likes