Using a scripting language to write gameplay code has traditionally been a delicate proposition. Scripted code is faster to iterate but a lot slower. Scripted code can be modded easier but hard to debug. In the past few years, a lot has changed.
My first program was written in machine code. Later, I upgraded to Assembly which I later taught in college. Today, I mostly write in C++ but that is starting to change. In a world with lots of CPU cores to play with, scripting languages and their performance limitations are on the table.
Stardock uses Nitrous. Built by Oxide Interactive, Nitrous is a high performance engine for developing software. It has no concept of a "main thread". APIs like DirectX 12 and Vulkan are ideally suited to it because it is core neutral and thus any thread can process and present based on which thread is least busy. It's pretty magical really.
Over the past couple of years, we've built a game engine on top of Nitrous called Cider. Cider takes the power if Nitrous and puts a bunch of tools and systems that take advantage of the core neutral way it handles tasks and graphics.
For the purposes of this article, I'm going to focus on one of the more notable features of Cider: A thread-safe Lua implementation.
If I were to develop a game engine from scratch in 2020, I'd be inclined to make a high level scripting language (Lua, Python, whatever) be the primary way I'd have the games be made. I'd need to make sure it can be debugged and make sure it can hook up with intellisense but after that, you'd have something that makes iterating on gameplay much easier.
The project I'm currently working on is mostly handled via Lua. It's pretty crazy to do a big checkout and the compiler doesn't need to run. As I work on the game, I can write new Lua code for making screens or doing AI work or implementing gameplay and just hit F5 to see it in action (or more often to tell me what line I screwed up on).
Using Lua (or Python) isn't new. What is new, is its viability. In a world where there are 6+ CPU cores available you can send out a lot of scripts to be executed simultaneously. This squashes a lot of the traditional perceived performance hit of using scripts.
As more and more developers embrace using scripting languages you open the door to a lot of new people to game into game development. In an environment where writing small, simple scripts is the goal, it becomes much easier to recruit people from around the world to help because it's a lot harder to "break the build" (because they aren't part of the "build" process). A bad script can easily be ignored by the engine and continue on.
When we look back at how much Unity changed the industry it's natural to wonder what the next logical step will be. I think the answer will be in scripting languages.
Read more about:
BlogsYou May Also Like
