Programming for Optimized Design

This week I’d like to take a detailed look at the programming behind The Forbidden Arts when it comes to level design and structure. I always enjoy sharing parts of our development in that I hope other developers can benefit from some of what we do. Let me start off by explaining why I find this important. I started writing code in 2011. I spent my mornings and evenings traveling to/from my day job (doing accounting / clerical stuff) on BART (a local metro in the San Francisco Bay Area). I realized I wanted to do more with my life and felt like making games could be something I’d really enjoy. I knew it would be a lot of work to teach myself anything, but I was determined. On BART I would read programming books every day, back forth, 5 days a week. The ride took me an hour each way so I got about 2 hours of reading in every day. After about 6 months of this I started writing code in X-Code, the development environment for Mac OS. I couldn’t do anything fancy, and my code was quite bad, but it was a start! I didn’t want to just learn the Objective C language though, even though iPhone was what I originally wanted to develop for. After doing some Google searching for Game Engines I discovered Unity, and my entire world was opened to new possibilities. Even as early as 2011, Unity had a great community. I began watching YouTube videos on how to write code, and one team particularly helped me learn a lot: Tornado Twins. These guys really helped me get started with the engine. I would practice what is shown in their videos and then I started to make modifications based on their examples. From there I downloaded tutorial code packs from the Unity Asset Store, and example projects from Unity’s own website. After months of experimenting, watching videos, and messing around with tutorial projects I felt I was ready to begin work on my first project. To this day, if I hadn’t discovered Unity and had the large community available to assist with my learning, I don’t know if I would be developing games for a living today. It’s quite amazing what kind of support is available within a community and I’m very thankful for it. Even though not all our Blogs focus on game development, I do like to write about various aspects from time to time as it’s my way of giving back to the game development community, as well I love to share the inner workings of The Forbidden Arts. I mean, surely you have seen some of those “How it’s made” TV shows before. I think those are entertaining to watch so now I’m going to talk a little more about how The Forbidden Arts is made. And today, I’m going to focus on my primary development job: programming.

In a previous Blog Marcy had posted on the details of level design, how she goes about optimizing the setup etc. Today I’m going to dive in deeper in that. There are several reasons we set up scenes to be the way they are. First off, the least number of active objects in a scene at any given time, the better. Not every machine is a powerhouse and this must always be considered. When developing I constantly focus on ways to improve performance and optimize the game for the best results.

Above is a screenshot from one of our scenes in Unity. You will notice each part of the game world is separated into sections that seamlessly connect to each other. Combining this with occlusion culling and we have a very optimized scene. Digging deeper you can see inside of each section includes environment assets, enemies, and colliders, each organized into their own folders. Upon initializing a scene there are a few important things I do to optimize and organize. In this case let’s discuss the enemies. Each enemy runs lots of code in the Update and Fixed Update Functions. These functions call an action every frame or every physics frame and thus they can be very processor intensive, especially when having loads of enemies in the scene. It is important I activate only what needs to be activated and then I disable the rest. There is no need to activate instructions when the enemy can’t be seen right? In a general game management script I first activate only the necessary enemies within the visible sections of the game, and I disable the rest, so no code is processed on those enemies until their section is activated. In a quick step-by-step guide: I check if there are enemies, I gather the total number of them, and then I activate or deactivate them based on their section they belong to.

Another thing I do is I set the waypoints to the enemies. Each section holds a specific number of arrays for waypoints that the enemies use to move to/from throughout the game world. There is not a specific way to apply a waypoint, but for our game, it made the most sense to define the waypoints in the section script because of our enemy prefab system we created. We use a base enemy and apply lots of different scripts, but we must be careful not to overwrite prefabs, otherwise public variables such as waypoints can be affected. We define our waypoints that correspond to each enemy in an array and then apply the waypoints to the corresponding enemy upon initialization of the scene.

Optimizing and organizing is something that any smart developer should be doing when writing code. It’s good practice and in the end your game will benefit from the extra work you put into it.