We’ve added a Best Practices section to the tutorials on the Wiki. We have a couple articles there, but we would love to expand that and share our communal knowledge with all the devs out there!
Please respond to this thread with suggestions, tips, and rule of thumb that you follow when developing. If you have an idea for a specific article, please contact myself or a writer. Otherwise, let’s brainstorm some good advice!
Games aren’t successful exclusively because of how pretty they’re built and how well they’re scripted. Sometimes challenges you may face may come from how you set up interaction in your game (i.e. this thread)
Some items that would be useful:
How to determine the best server size for your game
How to captivate your audience and keep them playing longer
Strategies for monetization - profiting while at the same time not making your players hate you for your “pay-to-win” game or whatever (I think it was Shedletsky who posted this article a while back – it, or a similar article tailored specifically to ROBLOX would be really useful)
Some best practices related directly to building scripting:
-Getting rid of “CFrame errors” (the cracks in the build) using Stravant’s plugins and whatnot
-How to transition from personal server building to edit mode building (I know a lot of people who prefer building with their characters + build tools, and being someone who used to think like that I know that Edit mode is much better and a tutorial on how to assimilate to Edit mode and how to make the most out of it would be handy)
-The dos and don’ts of GUI design (i.e. don’t clutter the screen, do make it useful, almost like an extension of the user’s arm, etc)
-Using modules to modularize your code
-Top-down programming to ease the design process
-Setting up mind maps / flowcharts so you don’t get off-track making your game
-How to use your future audience / livestreams / etc to keep yourself motivated enough to finish your game (I notice a lot of people on the ROBLOX forums talking about how they never have the motivation to finish projects and always switch between them - I’ve experienced the same problem, and it’d be super useful if there was something I could link them to that would help them force themselves to be motivated to finish their games)
[ul]
[li]Spam that save button.[/li]
[/ul]
[ul]
[li]Have a true source of inspiration, and keep yourself inspired by listening to the album of the movie that inspired you, or pictures that your game is inspired from.[/li]
[li]I strongly recommend grabbing a bowl of some fun snacks and listening to music if you’re a builder. Find something that won’t destroy your fingers. You don’t want Cheetos, only some potato chips apply. Grab a soda or something too. Keep yourself entertained.[/li]
[li]Try to make a ton of progress when you first begin your project without sacrificing quality. What you have done is a great way to make yourself realize why it’s past the give-up point. The “push on through” or “work on another part of this project while you think about the area you’re stuck in” point is here. “Just do it!”[/li]
[/ul]
Echo addressed a lot of good points.
One thing in particular I think should be addressed is server <-> client communication with FilteringEnabled. People should know how to safely use RemoteEvents without giving exploiters any way to exploit them. One example of this might be a “GiveMoney” RemoteEvent. Let’s say that, supposedly, it would only be called accurately by the client when the player gets money. However, let’s also say that an exploiter is in the game – he/she runs the GiveMoney event with some really large amount of money and has successfully hacked in money.
Another thing that users should be aware of is just getting faulty input via RemoteEvents; once again via exploiter. If an exploiter is trying to mess with things and sends you a value that you didn’t expect, make sure that it doesn’t cause some major server-side script to crash because of it.
Here’s a game design tip that goes for every game you will ever make :
If the game you made is hard for you, it’s impossible for others. Difficulty level is a hard thing to do in game development. Since you’re the one who made a level, it will be easy for you, but difficult for others. If a level is between fairly easy and medium difficulty for you, it will probably be pretty challenging for people who have never played it. This is why play-testers are really helpful in game development.
here’s another thing :
I recommend writing/drawing a list of story ideas and level concepts before making a game. I always have 1 idea that I try to make a game with, and it falls apart. Brainstorming ideas on paper before starting on a game always helps me realize what’s missing, so I don’t make a bunch of unfinished projects.
On paper I write all the ideas I have for the beginning, middle, and end of the game. It’s usually the middle part that I have trouble with, since that’s usually where there needs to be interesting gameplay mechanics that don’t get boring after too long.
Make editing and updating the game as easy and flexible as possible.
In my new games, I like to make it as easy as possible to add a new item or map. Whereas in my old games, I’d have to go in and manually change a lot of the code to get it to work.
In fact, my newest game I’m working on is so flexible that a single value can change the entire theme of the game, updating each map to (e.g. Christmas) themed without me having to build a special map a week before.
My two tips:
[ul]
[li]Never work alone[/li]
[li]Never be bored[/li]
[/ul]
Coding:
[ul]
[li]I also follow the DRY principal (don’t repeat yourself). (This can be seen in my use of NevermoreEngine)[/li]
[li]I write testable code, using this guide[/li]
[/ul]
Smaller notes:
[ul]
[li]I’m a heavy believer in testing and understanding the user.[/li]
[li]I always use FilteringEnabled[/li]
[li]I apply UX principals to my games[/li]
[li]I’m a big fan of building with a limited color pallet.[/li]
[/ul]
Make what you want to play
Not something you don’t mind playing; something you and your friends WANT to play
[size=2]The post below this one is really good[/size]
Pretty much my list:
Of course the stuff like DRY/consistent coding style/structured code/not too long and sensible functions/blabla matters too (it can be a huge boulder later on and thus demotivating), but they matter way less than the first four items above, in my opinion.
User Interface is incredibly important to creating a game that looks great, feels great to play, and is usable by it’s target audience. To this end, you should consider these things when creating your UI.
[ul]
[li]Do the colors go well together? See this website for ideas, and this website for guidelines.[/li]
[li]Does it look good, does it fit together well? Consider using icons from various resource websites to help you. The composition of your user interface should take into account the purpose of your game, for example if you are making an RPG there should be a clear area where you can access the most important functions such as inventory, friends, settings, character.[/li]
[li]Does it look good on all compatible devices? If your game is aimed towards both mobile and desktop then you must consider that when making your interface. ROBLOX Studio has a testing tool for this.[/li]
[li]Is it easy to use? If you ask a couple of friends to test your user interface, and they struggle to acomplish tasks that you set them, then it’s likely that your design isn’t going to be easy for other players too.[/li]
[li]Does your interface give feedback? It’s extremely useful for players when a GUI element responds to their input. It makes them aware that what they’ve just done had an affect on the game. If you purchase an item, then perhaps have a confirmation window to inform them exactly what they have purchased.[/li]
[/ul]
Other Tips
[ul]
[li]Take advantage of the ROBLOX engine. Experiment with different things until you can get the best possible outcome.[/li]
[li]Consider Lighting and Building to further engage/immerse your users into the game.[/li]
[li]Make use of plugins to aid you while developing. There are hundreds of useful tools at your disposal, why make things harder?[/li]
[li]Work with friends or other developers if you can’t do it yourself. People are talented at different things. If you’re an amazing builder and scripter, but you’re not great at graphic design, then get someone who is to help you out.[/li]
[li]Feedback and testing is very important. Make sure you get rid of any game-changing/breaking bugs as well as tweaking to make sure your game is as polished as it can be.[/li]
[li]Never stop developing, you can only get better.[/li]
[li]Consider new features such as Filtering Enabled and Physics Solver. These will change the way your game works massively.[/li]
[li]Make a game that you would enjoy to play yourself. It will motivate you and you will know exactly what you want to do.[/li]
[li]Not everyone has a super-computer, you need to take into account the varying levels of power your users will have. Don’t make something too intensive for low-end machines or they won’t play your game.[/li]
[/ul]
Design before coding. I never just blindly code anything without a game-plan. Otherwise the result is a bunch of spaghetti code.
Reuse working code from past projects/games. Don’t rewrite what you don’t need to. But always find ways to improve the code if possible.
Avoid optimization unless absolutely necessary. Everyone is obsessed by making code as optimal as possible, but sometimes you don’t need that and you end up just cluttering your code base. The only times I’ve ever ran into situations where I’ve needed to optimize code severely in ROBLOX is when dealing with terrain generation. But that’s because you’re doing millions of iterations as quickly as possible. Trying to do 100,000 cycles without yielding is tough, and sometimes requires that optimization. But usually your code isn’t doing thousands of operations at once.
Don’t copy-and-paste code from other people or websites without fully understanding what it is doing. Otherwise you’re cheating yourself and are not learning. You should understand how and why your code works.
Stress your code in all ways. Make sure your code can handle as huge of a load as it might experience with full servers and thousands of people online at once. Also, be sure to test as if you’re a 7-year-old user: Treat your program/game like a piece of junk; throw it into the ground and step on it; TRY TO BREAK IT.
Add comments. Oh my goodness, this is the most neglected coding feature of all time. WRITE COMMENTS. Please, just do it. You’ll be helping your future-self and anyone else who ever has to touch your code. This can be as simple as documenting what a certain object does, what its methods are, and what those methods return. It doesn’t have to describe what every line is dong.
Some thoughts on commenting and documenting code. Yes comments are important, particularly for complex code, but I generally fall into the camp that code should be self documenting. I’ll explain what that means with an example.
I’ve been working on some physics stuff for a top seceret ROBLOX game idea I have (It’s a fully 3D team based remake of the old Joust game. I’m terrible at keeping secrets). In my research I found some useful JavaScript code that is almost incomprehensible. It looked, in part, like this:
function a6(a){
vv0 = fh.v0;
fh.vf = vv = Math.sqrt(vv0 * vv0 + 2 * a * fh.x);
fh.t = (vv - vv0) / a;
fh.va = .5 * vv0 + .5 * vv;
fh.vf = v
}That nearly incomprehensible chunk of code works, and it sets the acceleration variable on an object and adjusts other values to reflect the change so that you can tell, for example, how long the object will move and how fast it’s going to be going over a set amount of distance. At first you’d think this code needs a ton of comments, and that would certainly help. But here’s my first pass at converting this mess to Lua:
function PHYTool:calculateNewAcceleration(newAcceleration)
local initialVelocity= self.initialVelocity
local finalVelocity = math.sqrt(initialVelocity* initialVelocity+ 2 * newAcceleration * self.distance)
self.finalVelocity = finalVelocity
self.time = (finalVelocity - initialVelocity) / newAcceleration
self.averageVelocity = .5 * initialVelocity+ .5 * finalVelocity
self.finalVelocity = finalVelocity
endAs you can see just by naming the variables sensibly and not even modifying the logic the function is much more understandable. This is the version that I used while verifying that the code was working and through testing of my object. Once I was satisfied that it was working, I rewrote it. Here’s the same chunk of code functionality (the ‘set’ functions live further up in the file so they can be used by other functions):
function PHYTool:setTime(acceleration, finalVelocity, initialVelocity)
self.time = (finalVelocity - initialVelocity) / acceleration
end
function PHYTool:setAverageVelocity(initalVelocity, finalVelocity)
self.averageVelocity = .5 * initalVelocity + .5 * finalVelocity
end
function PHYTool:setFinalVelocity(acceleration, initalVelocity, distance)
self.finalVelocity = math.sqrt(initalVelocity * initalVelocity + 2 * acceleration * distance)
end
-- Sets a new constant acceleration and recalculates a new finalVelocity, time, and averageVelocity accordingly
-- sets:
-- acceleration
-- modifies:
-- time
-- finalVelocity
-- averageVelocity
function PHYTool:calculateNewAcceleration(acceleration)
self:setFinalVelocity(acceleration, self.initialVelocity, self.distance)
self:setTime(acceleration, self.finalVelocity, self.initialVelocity)
self:setAverageVelocity(self.initialVelocity, self.finalVelocity)
self.acceleration = acceleration
endMuch better. The ‘set’ functions don’t really need comments because what they do is self evident given their names and parameters. The code in the ‘calculate’ function is also pretty self explanatory. The ‘calculate’ function itself needs documentation because it has side-effects, that is it modifies variables outside of it’s own scope which isn’t obvious by the functions name. By the rules of self documenting code the function would need to be called something like ‘calculateAccelerationAndUpdateTimeFinalVelocityAverageVelocity’ but that was just too wordy for me.
BUT, if I did use that long name then the code calling it could tell exactly what was going on. Compare what I have now:
local tool = libs.PHYTool.new(targetHeight - pos, velocity, acceleration)
[...]
tool:calculateNewAcceleration(newAcceleration)
if (tool.time < 0) then
-- do stuff
endwith
local tool = libs.PHYTool.new(targetHeight - pos, velocity, acceleration)
[...]
tool:calculateAccelerationAndUpdateTimeFinalVelocityAverageVelocity(newAcceleration)
if (tool.time < 0) then
-- do stuff
endIn the first example it isn’t obvious that tool.time is updated by calculateNewAcceleration(), but in the second one you know exactly whats going on. The important take-away being that information given in comments isn’t readily available in the code that’s using your functions. I should probably rename those functions to the longer form after all. (but I wont remove the comments even if I do, because of those side effects which need to be called out).
This doesn’t mean to not comment code. Complex code, code with side effects, and code that is doing things in non obvious ways should always be commented, if not for the benefit of other people then for your own good when you come back months (or even days) later and forget what you did and why.
I’m not kidding though. Deliberately work on your project. Deliberate practice is the only practice that works.
I suggest putting in a few words about how to properly split tasks between server/client. Especially in older models (but new ones as well), the server is doing all the heavy lifting and the client only changes the mouse icon. A lot of gear items are guilty of this as well.
There are also cases in which the client does all the work, which then doesn’t work with FilteringEnabled.
I would also mention that while code shouldn’t be optimized unless absolutely necessary, networking should be optimized as much as possible. People have horrible internet connections, especially on mobile.
Fantastic advice so far, keep it coming!
One thing in particular I’d like to bring up: are there any old habits that you’ve broken or dated practices that you see on ROBLOX that you have good solutions for?
One of the things I find particularly annoying with FilteringEnabled is the when people think they still have to store client-sided objects in the Camera.
It’s also best not to store client-side resources in Lighting, rather than ReplicatedStorage.
In addition, server-side assets intended for the server and the server only should always be stored in ServerStorage, otherwise they risk being found.
[quote] Fantastic advice so far, keep it coming!
One thing in particular I’d like to bring up: are there any old habits that you’ve broken or dated practices that you see on ROBLOX that you have good solutions for? [/quote]
Overcomplicating systems, creating too many functions that do everything and can be multi-purposed (Just made project more overwhelming to imagine as a whole in your head; keep it manageable and don’t worry about using one off functions or being not perfect in performance)
When it comes to building:
Uneven ground looks awesome.
Distribute detail effectively. Don’t have large flat areas of nothing, and then a fence that uses 3 new parts for a post + connecting pieces of wood that attach it to its neighbouring post.
DON’T start out with a giant baseplate and start building very delicately from one corner. Build the rough outlines. Like, if you’re making terrain, make the main big hills, mountain borders, landmarks… Once you’ve got that, slowly begin to fill in the details. With this method, you can, in theory, stop at any point once you’ve added in your landmarks and be done with it.
I don’t think I’ve ever seen a meticulous build finished to completion, besides a few showcase games. (Those come with their fair share of empty “WIP” areas however)
Focus on the big picture, get into the details after. Minimal viable product.
Make the most of plugins
Plugins like Crazymans Bezier curves, qCmdUtl, FromLegoUnivere’s Weld, Motor6D,and Prism creators and triangle plugins can dramatically increase the quality and speed of your building. It seems obvious to us, but alot of new builders don’t really use plugins.
Always practise good model grouping and naming, it can really help when going back to old parts of your projects for both building and script editing. Back in the old days I just stuck objects in lighting and rarely grouped anything. Everything is now an absolute mess and can really slow down development sometimes.
Lighting is a very tricky thing but even small changes can have huge impacts on the look and feel of your levels. Reading into general lighting theory is a fantastic thing to do. Lighting in game environments - the hows and whys tutorial - ModDB
CoughAxisAngleCough
Very nice, I particularly like the comments on game design, something we don’t have much mention of on the Wiki. Along with the above prompts, I think it would also be nice to have advice on organization. How do you organize your Workspace? RemoteEvents? ModuleScripts? Code in general?