Add comprehensive 6-week tutorial series for learning Roblox game dev…#1
Add comprehensive 6-week tutorial series for learning Roblox game dev…#1
Conversation
…elopment Created a complete educational tutorial series that teaches students how to build the Steal a Brainrot game from scratch, focusing on concepts and principles rather than providing exact code. Tutorials included: - Tutorial 1: Map Building & Environment Design (Week 1) - Tutorial 2: Understanding the Core Game Loop (Week 2) - Tutorial 3: Server-Authoritative Combat Systems (Week 3) - Tutorial 4: Implementing Abilities & Cooldown Systems (Week 4) - Tutorial 5: UI/UX Design & Player Feedback (Week 5) - Tutorial 6: Testing, Balancing & Security (Week 6) - README.md: Master learning guide index with complete series overview Each tutorial teaches: - WHY systems are designed a certain way (design principles) - HOW to approach problems (learning methodology) - Research tasks (where to look up Roblox APIs) - Experimentation exercises (find your own balance values) - Testing checklists (validate functionality) - Skills being learned (transferable knowledge) Total learning path: 60-72 hours over 6 weeks Target audience: Students learning game development Approach: Educational, conceptual, hands-on
Summary of ChangesHello @jsonify, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request delivers a complete educational tutorial series designed to guide aspiring developers through the process of creating a multiplayer Roblox heist game from the ground up. The content is structured over six weeks, progressively introducing fundamental game development concepts, Roblox-specific tools, and best practices in game design, programming, and project management. The goal is to empower learners with a deep understanding of 'why' and 'how' systems are built, fostering critical thinking and experimentation. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a comprehensive 6-week tutorial series for Roblox game development. The tutorials are well-structured, cover essential concepts from map design to security, and are geared towards teaching principles rather than just providing code. I've identified a few areas in the documentation with minor inconsistencies or potential for confusion that could be improved to enhance the learning experience for students. Overall, this is an excellent educational resource.
| *End of Tutorial Series* | ||
|
|
||
| **Want to learn more?** Check out: | ||
| - [docs/steal-a-brainrot-complete-mvp-guide.md](../steal-a-brainrot-complete-mvp-guide.md) - Implementation reference |
There was a problem hiding this comment.
The link provided here points to a file that is not included in this pull request (docs/steal-a-brainrot-complete-mvp-guide.md). This will result in a broken link for anyone trying to access the implementation reference. Please ensure that all referenced files are included in the repository and that the links are correct.
| ``` | ||
| [NE Corner] [Guardian HQ - 50x50] | ||
| | | ||
| | | ||
| [Vault - 60x60] -------[THE CITY - 300x300] | ||
| | | ||
| | | ||
| [Drop-off] ----------[Rogue HQ - 50x50] [SW Corner] | ||
| ``` |
There was a problem hiding this comment.
The ASCII art sketch of the map layout contradicts the textual descriptions provided in this tutorial. The text specifies that Rogue HQ is in the SW corner and the Vault is in the NW section. However, the sketch places Rogue HQ on the bottom-right (SE) and doesn't clearly distinguish the NW position of the Vault. This discrepancy could confuse students trying to follow the map plan. I recommend updating the sketch to align with the text.
| ``` | |
| [NE Corner] [Guardian HQ - 50x50] | |
| | | |
| | | |
| [Vault - 60x60] -------[THE CITY - 300x300] | |
| | | |
| | | |
| [Drop-off] ----------[Rogue HQ - 50x50] [SW Corner] | |
| ``` | |
| [Vault - 60x60] [NW] [Guardian HQ - 50x50] [NE] | |
| | | | |
| | | | |
| +------------[THE CITY]-----------+ | |
| | | | |
| | | | |
| [Rogue HQ - 50x50] -- [Drop-off] [SW] |
| ``` | ||
| WeaponTool (Tool object) | ||
| ├─ Handle (Part) ← The visible gun model | ||
| ├─ FireSound (Sound) ← Gunshot audio | ||
| ├─ MuzzleFlash (ParticleEmitter) ← Visual effect | ||
| ├─ LocalScript ← Handles client-side shooting | ||
| └─ ServerScript ← Handles damage validation | ||
| ``` |
There was a problem hiding this comment.
The proposed structure for the WeaponTool suggests including a ServerScript inside the Tool object. While this works, it's generally better practice in Roblox development to centralize server-side logic in ServerScriptService rather than scattering it across many Tool instances in the workspace. This improves maintainability and security, as it keeps all sensitive server code in one protected location. A single script in ServerScriptService can handle the RemoteEvent for all weapons.
| ``` | |
| WeaponTool (Tool object) | |
| ├─ Handle (Part) ← The visible gun model | |
| ├─ FireSound (Sound) ← Gunshot audio | |
| ├─ MuzzleFlash (ParticleEmitter) ← Visual effect | |
| ├─ LocalScript ← Handles client-side shooting | |
| └─ ServerScript ← Handles damage validation | |
| ``` | |
| WeaponTool (Tool object) | |
| ├─ Handle (Part) ← The visible gun model | |
| ├─ FireSound (Sound) ← Gunshot audio | |
| ├─ MuzzleFlash (ParticleEmitter) ← Visual effect | |
| └─ LocalScript ← Handles client-side shooting & RemoteEvent firing | |
| -- In ServerScriptService: | |
| MasterWeaponScript (ServerScript) ← Handles damage validation for all weapons |
| | **Dash Speed** | 50 studs/s (weak) | 200 studs/s (overpowered) | 80-120 studs/s | | ||
| | **Duration** | 0.1s (barely noticeable) | 1s (too long) | 0.3s | |
There was a problem hiding this comment.
The table suggests a 'Sweet Spot' for Dash Speed between 80-120 studs/s. However, the implementation example in section C (line 170) uses a DashSpeed of 100. To avoid confusion, it would be clearer if the recommended 'Sweet Spot' in the table directly matched the value used in the code example, or if the code example was updated to reflect a value within the suggested range. I'd recommend using 100 in the table for consistency.
| | **Dash Speed** | 50 studs/s (weak) | 200 studs/s (overpowered) | 80-120 studs/s | | |
| | **Duration** | 0.1s (barely noticeable) | 1s (too long) | 0.3s | | |
| | **Dash Speed** | 50 studs/s (weak) | 200 studs/s (overpowered) | 100 studs/s | |
| -- In LocalScript | ||
| while true do | ||
| wait(0.5) -- Update twice per second (balance between smoothness and performance) | ||
|
|
||
| -- Update player's own dot | ||
| local myPosition = player.Character.HumanoidRootPart.Position | ||
| MyDot.Position = worldToMinimapPosition(myPosition, mapCenter, mapSize, MinimapFrame) | ||
|
|
||
| -- Update teammate dots | ||
| for _, teammate in ipairs(game.Players:GetPlayers()) do | ||
| if teammate.Team == player.Team and teammate ~= player then | ||
| local teammatePos = teammate.Character.HumanoidRootPart.Position | ||
| -- Update their dot | ||
| end | ||
| end | ||
| end | ||
| ``` |
There was a problem hiding this comment.
The example while true do loop for updating the minimap is a good starting point, but it could lead to performance issues in a real game, especially as the number of players grows. A more efficient and modern approach is to bind the update logic to the RenderStepped event from RunService. This ensures the UI updates smoothly every frame without the need for an arbitrary wait() and avoids potential performance degradation from many concurrent loops.
-- In LocalScript
local RunService = game:GetService("RunService")
local lastUpdate = 0
RunService.RenderStepped:Connect(function(step)
lastUpdate = lastUpdate + step
if lastUpdate < 0.5 then return end -- Update twice per second
lastUpdate = 0
-- Update player's own dot
if player.Character and player.Character:FindFirstChild("HumanoidRootPart") then
local myPosition = player.Character.HumanoidRootPart.Position
MyDot.Position = worldToMinimapPosition(myPosition, mapCenter, mapSize, MinimapFrame)
end
-- Update teammate dots
for _, teammate in ipairs(game.Players:GetPlayers()) do
if teammate.Team == player.Team and teammate ~= player and teammate.Character and teammate.Character:FindFirstChild("HumanoidRootPart") then
local teammatePos = teammate.Character.HumanoidRootPart.Position
-- Update their dot
end
end
end)2 participants
…elopment
Created a complete educational tutorial series that teaches students how to build the Steal a Brainrot game from scratch, focusing on concepts and principles rather than providing exact code.
Tutorials included:
Each tutorial teaches:
Total learning path: 60-72 hours over 6 weeks
Target audience: Students learning game development
Approach: Educational, conceptual, hands-on