What's the technology that allows programming inside a game?

Question

There are some games which allow the player to write/create scripts in-game, for example: Space engineers or Psi.

I want to use something similar to either one, but I've had a hard time finding information so my question is:

Is there a branch of programming that covers the ability of a software once compiled to run new code created by the user?

By branch of programming I mean something like PTG (Procedural Terrain Generation).

To avoid the too broad of a question or opinion based, let me clearly state that I'm not looking for guides or places to learn, I want the name or definition (if one exists) of the technology involved.

Answer 1

Scripts written in scripting / embedded / interpreted languages such as "Lua", "Lisp" or "AngelScript" (more here) can be updated during the game [*] and then are interpreted (= executed) on the fly.

You can bind elements from those scripts to your native compiled coding (C++, etc.) so that the scripts can then execute logic from your application. E. g. a specific command that the user can put in the script, as a result moves the in-game character by a given distance in the game world.

Some relevant linked questions:

• What scripting language should I choose for my game?

• What do you look for in a scripting language?

• How do you add a scripting language to a game?

---

[*] either by the user as part of the game play or also by devs for fast iteration/testing without restarting the application

Answer 2

Embedded language is the proper technical term. In practice, languages which are used inside other applications (such as games) are often referred to as scripting or even interpreted languages, although they should not necessarily be interpreted or used for automating routine tasks. Googling "scripting languages for games" would probably yield more useful results than searching for "embedded languages".

Answer 3

You are looking for a way to change the code into some actions. This is precisely what interpreters are doing.

Take a look at Python. You run it, and bam! You land in REPL(Read Eval Print Loop).

You define a function "hello" which prints "Hello, world". And there you have it!

Notice that you didn't compile anything; interpreter did some magic to create function on the fly (during the runtime) and now you are able to call it.

The same applies to games. Instead of having a REPL, you have a game with REPL module. The game probably starts the REPL and then runs everything else in this REPL, so you have access to the data and can actively modify it.

If you are working with huge languages like C++, they tend to be less dynamic and probably compiled. You want some easier. You either create your own language, or use some existing(like CoffeScript, Squirrel, Lua, Scheme, ...)

These are often called scripting languages, since you use them to write scripts that are built upon the game engine developed in some other language(e.g. C++).

Answer 4

If the in-game programming language was only designed for the purpose of the game, then it is a domain specific language.

The advantage (and disadvantage) of domain specific languages is that the language itself can limit what the user can do (i.e. you can disallow connecting to the internet). You could design a language that makes typical game tasks more easy than in a general purpose language. The disadvantage is that the user has to learn a new language.

Just running unsanitized user code in a general purpose language (like python or perl) from within your game, could allow the user to mess with things he shouldn't mess with. But it depends on your game. If you don't mind users doing stuff like opening new windows from within your game or whatever they like, you can use a general purpose language and expose bindings to certain features of your game world.

Answer 5

There are two examples that I can think of off the top of my head. Both seem to do exactly what your asking for.

The first is screeps. https://screeps.com/ You can read alot about how it accomplishes this goal at http://support.screeps.com/hc/en-us/articles/205960931-Server-side-architecture-overview

The second is ComputerCraft http://www.computercraft.info/ They don't go into as much detail as to how it works but a little can be seen at their wiki http://www.computercraft.info/wiki/Main_Page

In essence, the main game runs an interpreter in a separate thread, then allows that thread to manipulate the game world through API calls.

In both examples, while the language is nearly unlimited (only some calls blocked for security reasons) manipulations are limited by API calls that can be made.

Usually very little work is required to get something like this started. You need

• a thread manager that protects your game's loop (doesn't let a thread lock up the loop or consume to many resources). Both examples use a time based limiter.
• a interpreter to run a language. LUA is pretty common these days.
• a set of API calls that modify the game world. What fun is a programming language if you can't do anything with it.
• a resource management implementation. In other words a way to store code files and reference them in game.

There is no single branch of programming that handles all these concerns. But you will need a strong foundation in multi-threading, and a general knowledge of how an interpreter works.

Answer 6

The compiled executable must contain a parser that is able to read external program code. The program code need not look like C or Python or xyz - it can be any kind of descriptive data that is suitable for the purpose in question. For example swedish, or morse.

The external program code needs to have a syntax, so that the parser understands it as it reads it character by character. The syntax may describe (and code may contain) identifiers, numeric values, operators etc.

The parser is fixed (compiled) but it works on flexible, external code.

The compiled executable must have an internal API to it's relevant functionality. so that the parser can perform actions. Most likely there must be (bi-directional) access to the executable's internal data as well, or the parser must provide some kind of data storage and housekeeping.

The parser can read the external program code at executable's startup, or it can read (parts of) it ad hoc, or it can re-read it per each frame (would be inefficient), or the code can even be hand-typed and posted to the parser as it gets ready (like: "move unit X forward 5 steps"[enter]).

Essentially, the external code is not fixed - it can change any year, day or minute, but still the executable need not be re-compiled. Only the resulting behaviour, hosted by the executable, changes.

The text you are reading right now is (kind of, and even more if it was spoken) interpreted because you "execute" it in your brains while reading it, without knowing what next sentence says (or even if it possibly, sneakily changes right now). As opposed to Stack Overflow (pre)compiling the entire story into bytecode in your brains, which then executes it - and ofc then it could not change any longer.

The phenomen ongoing is interpretion. Scripting is only the act of creating a deSCRIPTion, or writing. All computer coding is imo scripting - we describe what we want to happen. The word "scripting" has got a somewhat tilted meaning, but so be fine. We know what we mean.

There is absolutely nothing extraordinary with interpreted languages, and it is in no way a disputable term. A multitude of them exist, and some of the very oldest ones are interpreted as opposed to compiled. In an interpreted language one might for example type by hand:

sock = Socket.New(AddressFamily.InterNetwork, SocketType.Stream ProtocolType.Tcp) [ENTER]

... and then go for a 30... no, 45 minute coffee break :-). When returning, "sock" exists and is ready for further use by typing more by hand, or letting the interpreter's automation continue with it.