Last week, we encouraged users to send in their ideas for blog articles. We received a wealth of submissions and have already started working with a few potential authors on articles that leverage their unique expertise’. Crazyman32 is a name which which we’re sure you’re familiar. Creator of Perilous Skies and overall ROBLOX innovator, crazyman32 jumped at the chance to write about the design and development of Perilous Skies: New Horizons, the official sequel to his popular ROBLOX title.

First, a quick word:

ROBLOX has always been medium to allow me to let my creativity flow freely. I express myself through the art of game making—a skill I am always working on improving. During my time on ROBLOX, I’ve managed to create some games that have been favored among the community. Perilous Skies, a game that thrusts you into the cockpit of a fighter jet to fight off enemies with homing missiles and machine guns, is my favorite creation. Unfortunately unsafe programming practices, like implementing many preliminary features that have since changed, has caused my favorite title to fall from the soaring heights it once reached. This didn’t discourage me in the least; it inspired me to begin work on my newest title, Perilous Skies: New Horizons.

I usually start with game ideas that are simple and broad. For instance, the original Perilous Skies was developed around a simple premise: a game where planes dogfight in the sky.That broad idea was more narrowly defined as I started to build the game. This puts me in a unique position with New Horizons—for once, I’m starting a game with a ton of specific details already mapped out. This allowed me to rethink my approach to developing the title—I had to sort of force myself to start simple. I’ve talked with several game developers outside of ROBLOX and adopted their methods to developing software: taking things one step at a time, and making multiple iterations of each step. The act of repeating each step, I came to realize, is extremely important. Like editing a paper, there are two important factors to consider: is it grammatically correct? Does the text actually mean something?

Terrain looks different when you're pulling Gs in the first person

I’m going to use this article to outline the steps I took to create my new game, completely from scratch. I’m in no way claiming that these are the right or wrong steps to take—each builder has their own process. These are the steps that have worked for me so far, and hopefully they can help you from a game-design perspective. I came to learn that organization is key. Without organization, the whole design of the game can become cluttered, ambiguous, and inefficient. The majority of these steps relate to ROBLOX programming, but that doesn’t mean that building doesn’t play a huge role either. What you build is what players will see, after all.

Step One: Creating a Foundation

A foundation is the most important part of any given structure, and you can’t even see it. The foundation of your game should include scripts that handle players entering and leaving the game, scripts that control main functions of the game (like a map-changing script), and scripts that act as libraries in-game.

Utilizing the Catalog: I’ve developed my own Catalog system that is able to organize a bunch of different plane parts that can be added to your plane. I built it in a global table, with assistance from an additional metatable for added functionality. The Catalog automatically organizes plane parts based on type (wing, fuselage, or tailwing) and pricing. It also keeps track of everything you buy–thanks to ROBLOX’s built-in JSON feature in the utility library (which I stumbled upon in the ROBLOX Wiki while researching the RbxUtil library), it’s easy to save and load the Catalog to keep track of items you’ve purchased. The Catalog also tracks the current “build” of your personal plane design while simultaneously serving as an interface, where users can customize their planes.

Population Control: In my game in particular, it’s extremely important to ensure that when a player leaves, his or her plane disappears from the virtual world. This is obvious, but often overlooked. Every time a player leaves, my game scans through all the in-flight planes to see if there’s an even ratio between operating and non-operating planes. This keeps the game from lagging due to overpopulation. The scan removes unmanned planes in a matter of milliseconds.

Missiles and Terrain: A custom script steps in and creates missiles for each wing design at the start of every single game. The terrain is also generated when the game starts, which is a crucial design choice that directly affects the overall look and feel. The terrain generator is an open-source script from ROBLOX user Stravant. The position of each triangle is determined by a diamond-square algorithm that I found open-sourced on the internet.

Worth the Time and Effort: When developing New Horizons, I spent ten hours designing, writing, and debugging the foundation of the game. The time was well worth it—creating a fully functional, dynamic and efficient foundation is crucial to the overall development. That’s because you can always go back to your foundation and make changes. Think about building a house. If you wanted to move a large support beam, you would have to do so very carefully to ensure that the rest of the structure doesn’t collapse.

Step Two: The Main Course

Start Simple with Templates: With a foundation in place, it’s time to start building the main parts of the game. It probably won’t come as a surprise, but the main components for New Horizons were planes. I built a simple plane template that I knew I’d be able to expand upon to create different types of planes later. I also built the framework of other structures that would populate the game. Then, I moved on to non-necessary structures like scenery, which can drastically affect the look and style of your game. I also started thinking about GUI components—menus, loading screens, and the in-game HUD. Again, these don’t need to be super detailed at first; worry about the infrastructure, and add detail later.

Step Three: Make the Game Playable

The Simplest Hypothetical: This is one of the most pivotal steps, so really take your time. Slowly add details. My first step to making New Horizons playable was as simple a task as I could imagine: spawning a plane in the air and having it fly around. Start at the simplest hypothetical. I worked to ensure that each and every plane could get into the air and fly around with no problems, and built the code in a way that lets me program around it easily. Once I was able to do this, I started adding more detail–more complex animations, tweaks to the physics, crash effects, and homing missiles.

Maps: If you plan on randomly generating maps, that’s something you’re going to have to take into account. For New Horizons, I had to develop a system that handles changing maps quickly and flawlessly, while also spawning players in the right areas. A common problem I see on ROBLOX is that scripters neglect to think about spawn points, often leading in spawn kills or this bizarre glitch that launches users hundreds of feet across the map.

Step Four: Complex-ify Gameplay

This is the step I am currently on as I write this piece. This is where you head even deeper into the details. If you were making an RPG, for example, this is where you would begin to develop functional stores where players could shop, as well as upgrades and quests players could achieve and unlock. With New Horizons, the fourth step involves the creation of a points system (they’re called “credits” in New Horizons, and can be used to buy new parts for your plane), a catalog of custom items for each of the planes, and particle effects that occur in-game. Within my development process, this is the longest and most painstaking step there is. Each little addition must be vigorously tested and debugged to ensure that gameplay remains stable. That means taking the time to thoroughly test every single inclusion, not just to make sure that the feature works, but to ensure that the implementation of the feature didn’t change some other part of the game (this happens more than you’d think).

Now What?

This article is about developing, not popularizing, but I could write miles about promoting your game once you’ve finished building it. To keep it short, listen to what other people have to say about your creation. Constructive criticism has carried me a long way. Be sure and test every single new feature you add, even after the game is released to the public. Put your game through the ringer, and simulate every catastrophe that could feasibly happen in-game. Because if your game picks up traction and starts to get popular, these will likely be issues you’ll need to address. Thanks for reading, and good luck!

Are you working on something interesting that you’d like to share with the ROBLOX blog? Fill out this survey and pitch us your blog article ideas, now!