Revisiting Roblox

Game Dev Woes

Creating a game as an independent developer can be an incredibly daunting task. You need to learn the game engine, design assets (often in 3D), rig models, create animations, import materials, and so much more.

However, learning all of this doesn’t guarantee that your game will be fun. That’s where Roblox comes in. It makes all of these things much easier, and in my opinion, it’s an excellent way to prototype ideas, at the very least.

The Engine

Roblox’s game engine is very powerful and similar to many other game engines. It puts a strong emphasis on scripts. Scripts can be attached to any object, and the “Luau” (aka Lua) syntax used within them is very easy to read. You can create “Module Scripts,” which are great for reusable code, and “Local Scripts,” which are used for running code on the client-side.

The engine handles multiplayer for you, provides easy access to collision detection, offers a particle system, built-in physics (including ray casting), server-side and client-side scripting, a GUI system, a tween engine, a remote database, and much more. It’s mind-blowing how much they’ve managed to pack into their engine while making it easy to integrate all of these components.

Additionally, Roblox is cross-platform and supports mobile, desktop, and console. It rarely requires any code changes to support all platforms, which gives it an advantage over other game engines.

To give you an idea of how easy the Lua syntax is to read, here’s a snippet from a game I’m working on:

-- To add some context, this (server) function is called to trigger a transition
-- for all of the board game pieces. It checks if .Player.Value exists,
-- if it does, it triggers a client-side function to fade in/out the screen.
local function triggerFadeTransition()
  for _, v in ipairs(pieces) do
    -- v.Player.Value refers to the Roblox client that owns the piece
    if v.Player.Value then
      -- `TriggerFadeEvent` is a "RemoteEvent"
      -- think of it like RPC or a socket
      TriggerFadeEvent:FireClient(v.Player.Value, 1, true)

      -- wait 2 seconds before fading back in
      spawn(function()
        task.wait(2)
        TriggerFadeEvent:FireClient(v.Player.Value, 1, false)
      end)
    end
  end
end

In my opinion, the simplicity of Lua is one of the best things about developing in Roblox. It’s easy to read, write, and debug. Learning Lua is also straightforward, thanks to their high-quality documentation that provides guides and examples for everything you could possibly want to do. Additionally, their community forum is very active and has answers to almost any question you could think of.

The Catch

Before I inadvertently sell you on Roblox, I should mention that there is a catch. Roblox is a platform that takes a cut of your profits in exchange for handling the infrastructure, so they take 60% of your profits on average. While this might initially come as a shock, the more I think about it, the more it makes sense. Personally, I don’t see myself investing a lot of time into Roblox professionally, but as a hobbyist, it’s a fun way to prototype ideas and learn core game development concepts.

Compared to Godot & Unity

Having a few months of experience with Godot and Unity, I’d like to provide a quick comparison for those interested.

In my opinion, Roblox is most comparable to Godot. Lua is similar to GDScript in its simplicity, but Lua feels more integrated within Roblox. Out of the box, Roblox is also much more feature-rich than Godot, which starts with a relatively empty project.

Unity has several parallels to Roblox, but it’s undoubtedly more complex. Working with CFrames (position + rotation) in Roblox reminded me of working with Quaternions in Unity. Working with collisions is also similar between the two. If you have experience with Roblox but want to take your 3D game development to the next level, I think Unity would be a great next step.

There is one area where Godot and Unity objectively excel compared to Roblox, and that’s 2D games. Roblox is primarily a 3D game engine, and while you can make 2D games with it, you’ll be swimming upstream.

In Conclusion

I don’t have any groundbreaking insights to share about Roblox. I simply wanted to share my experience using it over the last few months. I have found it to be more enjoyable than difficult, and if you’re new to programming or game development, I think it’s a fantastic place to start.

Roblox is the perfect platform for rapid prototyping, and I believe it’s a powerful tool for any indie developer to have in their toolbox. Consider giving it a try.

Learning Links

If I’ve convinced you to give Roblox a try, here are some links to jumpstart your learning:

Videos

These playlists are brilliant, and I learned so much from watching them.

• GnomeCode - Making Doors (Doors is a popular Roblox game)
• GnomeCode - Making a Tower Defense Game

Roblox Guides

• RemoteEvents - Communicate between Client <-> Server. You’ll use these a lot.
• Services - Roblox’s API.
• GUI - GUI Layouts.
• Pathfinding - Pathfinding for NPCs.
• Events - Trigger this when that happens. Not for Client <-> Server.
• Client vs. Server - To replicate or not to replicate.
• Animation Editor - Create animations.
• Data Stores - Store data in the cloud.

Additional Notes

After spending a few months with Roblox, here are some additional notes I wish I had when I started:

• Animations should be done client-side. Doing animation on the server will cause lag.
• Use TweenService for simple animations as often as possible. It’s very performant and easy to customize.
  • When TweenService is not enough, I often use Lerps.
  • Complex animations should be done with the Animation Editor instead.
• I often check collisions on the server (workspace:GetPartBoundsInBox) and then replicate the result to the client(s). This is because the client can’t be trusted.
• Use spawn() for simple coroutines (async). It’s easier to use than coroutine.start().
• Use the Project Explorer as often as possible. It’s easier to see what’s happening in your game when you can see all of your objects rather than coding everything into scripts.
• GUIs can be a pain when you’re first starting out. Don’t invest too much time into perfecting your GUIs at first– you’ll likely have to redo it once you learn about UDim2, AnchorPoint, and AutomaticSize.
• Try to use ModuleScripts when possible. There is very little downside to using them, and they make your code more reusable and modular.