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

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.

• Well, probably "Writing interpreters"? – MatthewRock Sep 26 '16 at 14:43
• I answered a similar question recently, discussing "Virtual Machine" as the term for the system that runs the user code, and also referencing the Game Programming Patterns article on the Bytecode Pattern as a means of implementing this faster than a conventional interpreter. – DMGregory Sep 26 '16 at 14:57
• It's usually called "scripting". You'll find plenty of materials on how to implement scripting in a game, as well as plenty of (variously) open source sample and real code. In broader scope, there's the whole field of compiler programming (which includes lexing, parsing, compiling, linking, interpreting...). In the broadest scope (not necessarily useful), this entails pretty much any user interaction your application has - a scripting engine is really just a much more complex way to select from a menu. – Luaan Sep 26 '16 at 15:49
• A Python program can host Python scripts. That's called metaprogramming. Most interpreted languages have that. – user6245072 Sep 26 '16 at 16:28
• AFAIK in Space Engineers, the code is compiled C# code in a sandboxed environment (the game went open-source, so you could check how that works online : github.com/KeenSoftwareHouse/SpaceEngineers ). Basically the game ships with a C# compiler and the code only allows access to the game's API functions, so that the scope of the program is limited to you only. And if you are playing multiplayer, then the code only runs on your machine (other players / the server just see the ingame consequences) – Florian Castellane Sep 27 '16 at 8:48

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.

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

• I would be careful when calling something "interpreted language". At best it is very disputable term. – wondra Sep 26 '16 at 14:22
• Computercraft (minecraft mod) uses LUA as a scripting language to program tasks within the game. – Tikeb Sep 26 '16 at 14:41
• I don't really understand the fuss. Lisp can be both interpreted and compiled. We aren't here to disucss how to classify the languages and whether interpreted is a good clasisfication; we're telling OP who is unaware of this fact that language doesn't need to be compiled, but can be interpreted - and we give some languages as an example. Is Lisp interpreted? Yes. Is it compiled? Also yes! But that's outside of the scope. The answer might be inaccurate with wording, but it's fine for the purpose; it pushes OP in the right direction, and that's what counts. Here, take my +1. – MatthewRock Sep 26 '16 at 15:30
• Well even if a language is compile-only, what stops you from embedding an IDE, compiler and runtime into your game? Except the budget, that is. – Ordous Sep 27 '16 at 13:29
• @DanielJour While I would agree that theoretically a language can be distinct from its implementation (compiled to machine code vs compiled to bytecode for a vm), it's still a usefully time-saving assumption that C is compiled unless otherwise specified (and can you imagine the looks you'd get if you asked, "wait, compiled C or interpreted C?" every time). For the OP's purpose, he needs to look at languages that support interpretation; whether or not they can also be compiled is a non-issue because that's not how he would use it. – Blackhawk Sep 27 '16 at 18:50

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".

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++).

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.

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.

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.

• There's a common misconception that a language that is interpreted must be slow. It's not true. Depending on the various factors that make this discussion too broad for the comments, interpreted language can be a magnitude or less slower, as fast as, or even for some operations faster than control language that's considered fast (usually C). The example with socket would probably work more or less like in C, so the example is misleading. You can also redefine compiled functions at a runtime in some languages, and interpreting doesn't simply mean "going one instruction at the time". – MatthewRock Sep 27 '16 at 10:36
• Sure, an interpreted language may perform faster as well - after all it's bytecode that executes, and the execution may be much better optimised, depending on the interpreter's automation. Additionally, some interpreters can compile, from code, parts of the code into bytecode (and execute), ad hoc The example is just an example of the freedom, "Going one instruction at time"? Well that's an oversimplification, maybe add "while the future code is flexible". – Stormwind Sep 27 '16 at 22:09
• Think of "script" more like a movie script - you still need actors, and these are defined directly in terms of biology and sociology, not theatre sciences (though these in the end are based on biology and sociology), because these languages are more suitable for that purpose but not the other :) – rackandboneman Sep 28 '16 at 11:16