Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
July 4, 2020
arrowPress Releases







If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 

Developing games in Lua or another scripting language

by Brad Wardell on 05/27/20 02:48:00 pm   Expert Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

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.


Related Jobs

innogames
innogames — Hamburg, Germany
[07.03.20]

PHP Game Developer - Grepolis
Remedy Entertainment
Remedy Entertainment — Espoo, Finland
[07.03.20]

Programmer (Character Technology team)
Square Enix Co., Ltd.
Square Enix Co., Ltd. — Tokyo, Japan
[07.03.20]

Experienced Game Developer
Remedy Entertainment
Remedy Entertainment — Helsinki, Finland
[07.01.20]

Technical Director





Loading Comments

loader image