Coder.Haus | Developing a Roblox Game In Thousands of Little Steps
We're a family of geeks who live to design scalable software and hardware solutions. We focus on solid, simple designs focused on industry good standard practices.
ITIL, SLA, Service Level Agreement, Change, Change Management, Development, Coding, Programming, Javascript, Java, Kotlin, Arduino, RaspberryPi, RPi, Android, VSCode, Hacker, Maker, Infrastructure
16108
post-template-default,single,single-post,postid-16108,single-format-standard,ajax_fade,page_not_loaded,,qode-title-hidden,qode_grid_1300,qode_popup_menu_push_text_top,qode-content-sidebar-responsive,qode-theme-ver-17.2,qode-theme-bridge,disabled_footer_bottom,wpb-js-composer js-comp-ver-5.6,vc_responsive

Developing a Roblox Game In Thousands of Little Steps

I’ve built my career on my adherence to process and policy, my ability to detail the development and delivery of solutions that support operational needs, and my deep technical knowledge. My kiddo shoots from the hip. He does what feels right. He has no worries about building something up, then tearing it all down and starting over.

We are in many ways the same, but still very different people.

One of my kiddo’s joys is playing Roblox, but also in developing small games and assets for games on Roblox. My joy is spent learning new technologies and finding ways of using those in new and old projects. This past month, he and I have spoken a lot about collaborating on a personal project. We’ve decided to dedicate the next few months developing a Roblox game. For me this is an opportunity to teach my son how the software development life cycle (SDLC) works, to show him how program and project managers think about product, and how developers meet the needs of a specification and provide a product that can “flex” to the needs of the user. I get to learn Lua, dive deeper into Blender (something I’ve wanted to do for ages), and spend “learning” hours playing a game he and I build.

Also, my goal is to learn how to work off-the-cuff. I want to be able to find joy in the moment when we decide to throw it all away and just do what feels right.

World Architecture

When deciding to build our Roblox game, we wanted to base it on a story. My son sat down and wrote a chilling story of humans being hunted by some type of creature. We used that to come up with the overall architecture of the game, in order to support its development and expansion.

There are five distinct story lines in the game – Intro, The Hunt, The Chase, The Search, and Boss Battle. When thinking about how we could design the game, we spoke about the ability to release incrementally, expand the game, playability, and ease of support (bugfixes). Two architectures came to mind with this, the monolith and the microstory.

The monolith is one large game, all coded in a single releasable package. With this, we would have the benefit of all assets and code in one place. On the downside, expanding the game would mean navigating the entire code base to find where we wanted to update, and introducing those updates without breaking other parts of the game. This also meant that if the game became large, it would become difficult to support.

The microstory is breaking the game into multiple subgames, and transporting players between those subgames. Benefits include the ability to release each sub-game as it becomes ready to get something in the hands of players sooner. Updates could target a single sub-game, without potential to introduce a breaking change to the other sub-games. We could also expand, adding sub-games and linking to those, more easily than in a monolith. Bugs could be more easily squashed as we would be able to target the location. Code size for each game would be a fraction of the whole, and make it easier to support. If one game needed more resources, it could be moved onto its own server. Downsides would be that there might be duplication of code and assets, making maintenance of duplicated code and assets difficult.

In the end we decided on the microstory path. During development, we will research ways to use shared assets and code, in a safe way.

Asset Development

While I like to stand on the shoulders of giants, and license content to use instead of building everything ourselves, to gain an understanding of all of the tools around standing up a roblox game we are going to mostly build our assets ourselves. We will use some licensed content, and in the future might replace our own content with licensed content.

Our tool set will start with the following
Music – Google Song Maker, Apple Garageband
World assets such as weapons, creatures, and NPCs – Blender, Gimp
Buildings, cars, etc – this will probably be the largest area where we use licensed content

Scripting

Scripting within Roblox uses Lua. Lua is a portable, embedded scripting language. It is used as a glue language, that is code that is an adapter between other pieces of code that might not be compatible. It is used largely in the embedded and game development worlds. I’ve written a few scripts to help understand the language, and am enjoying it so far.

I’ve looked a bit at the Roblox API, and this will be the largest learning curve when it comes to writing code. Their documentation seems good, it not only discusses the elements of each call but provides examples. Where our time will be spent is finding the calls we need to use, and understanding best practices to use them. And here’s where there are some things that might not be intuitive. For example, NPCs (non player characters) often use the Humanoid object. This will be awkward from a naming perspective when we build animals or non-human creatures.

Release Cycle

We are going to develop each story line as its own sub-game, so we can incrementally release the game. There are five story lines
Intro (Lobby/Cutscene)
The Hunt
The Chase
The Search
Boss Battle

Development and design will be incremental. We will release each sub-game every 25% of development, and round robin development. So what we’ll see is when the hunt is at 25%, we will release. When the chase is at 25% we will release. When we release boss battle, we will go back and release the next 25% of content to the hunt. Depending on how development of each sub-game goes, one of us might begin work on the next 25% of a sub-game before the last sub-game is completed.

What is 25%? That remains to be seen. This might look like the baseplate populated with the “map”, some buildings and interesting assets, a few NPCs, then release. Enough to get started playing, but not a deep level of detail in the assets. Buildings might be boxes with windows but not much else, and in later releases we might add interior and exterior detailing.

Design will be done prior to any incremental development start. We will not do “big up front” design for the game, and will review and update our overall design after each release.

Wrap up

My kiddo and I are looking forward to collaborating on this game, and getting it in the hands of players. We’ve incited some excitement among friends, who will be testing our build as we move through the development process. I will be writing posts during the development of the game, detailing the process. While we learn and grow with this project we will also release posts detailing our learning on specific technologies releated to develpment with Roblox.