Question Reading txt file and executing what's inside

I had the idea of creating a games that is based all around the computer. And now I had an idea that I wanted to realise, but I don't really know, how or where I should exactly begin. My goal is to have a .txt file from which the game reads from. In that .txt a simple code could be written with some instructions given, which would then be read by the game and executed accordingly. I have figured out the creating, reading and writing part, but I'm not sure yet of how I should do the "decoding" part of it. With that I mean reading the code and executing based on the functions, loops, variables and such. For example, the code in the .txt could look like this:

int loopings = 5;

Forward();

repeat(loopings) {

     TurnRight()

     Backward()

}

while(True) {

Forward()

TurnLeft()

}

 

So you're looking to implement a runtime scripts interpreter.

There are already several packages that do this, and for different scripting languages (Javascript, Lua, C#...)

- Moonsharp (Lua): https://www.moonsharp.org/ (I recommend this, lot of modders are familiar with Lua scripting)
- Unity-jsb (Javascript): https://github.com/ialex32x/unity-jsb
- C# Interpreter for Unity (C#): https://github.com/keyworq/CSharp-Interpreter-for-Unity-3D (check especially https://github.com/keyworq/CSharp-I...ster/Source/Assets/Plugins/CSI/interpreter.cs)
- and many more (just Google).

TLDR: don't try to implement one from scratch, it's not that easy.

Important: Think about the security aspect too, you don't want your users to be able to do "Directory.Delete(@"C:\Windows", true)" right?

 

Hey, thanks for your suggestion! But what if I would have a VERY simple programming language like I wrote in the example, how could I work with that?

 

Then be prepared to deal with Regex inferno.

 

Ngl, Regex looks fun (for now) and probably exactly what I need. Will look into it. Thank you!!!

 

Ugh, regex will just get you in bug hell even for something simple.

The proper way is to write a parser/lexer:
https://en.m.wikipedia.org/wiki/Parsing
https://en.m.wikipedia.org/wiki/Lexical_analysis

Since that‘s still a lot of work and potential for issues even for some trivia language you are better off and will make progress quicker by just writing Lua scripts, for example.

 

Will look into that as well. Thanks!

 

I don't really think you have the full picture of what makes a "VERY" simple language. lua is one of the simplest high level languages out there. The only datatypes it knows are:

• number (which is a double)
• string
• boolean
• function
• table

That's it. This makes the language extremely simple. In your "example" code you seem to have written some sort of C-style language which are quite complex. Especially since you seem to define an "int" type. C# on the other hand has those primitive types:

• bool
• byte
• sbyte
• char
• decimal
• double
• float
• int
• uint
• nint
• nuint
• long
• ulong
• short
• ushort

In addition those reference types:

• object
• string
• dynamic

On top of that the language has keywords to create new types. Also the above mentioned types are the built-in types of the language C#. However there's also the .NET framework that brings a lot of extra types / classes that are actually intertwined with the language C#.

Parsing a programming or scripting language is extremely complex. I have years of programming experience and I've had all sorts of attempts to create a scripting language. They did work to some degree but weren't really efficiently implemented and a lot of the syntax was awkward because it made the parsing easier.

Just as an example, I've written a logic / number expression parser in a non-traditional way. I just had the idea doing it this way when I realised that an expression tree is actually the other way round when it comes to order of operation in math. Since you do addition and subtraction last, it would be the first / top most node in the expression tree. Parenthesis are an exception and have to be handled first. However the unusual way of parsing the string has a limitation. You can't have unary minus inside an expression without parenthesis. So

-5 + -7

can not be parsed but

(-5) + (-7)

can. Note that for math operators I only have 5 actual expression nodes (sum, product, power, negate and reciprocal). I do have support for custom functions. However keep in mind this only deals with a single type: "double". Every "function" takes a list of doubles and returns a double. This makes thing much easier. Though it's still 1k lines of code. Every new type can make things much more complex

Actual programming languages have several different control blocks which work fundamentally different. In pure math you can express everything as a tree of simple function. However in programming languages you may have control flow structures, data types, variables, methods and everything may be interleaved in various ways.

That's why most compilers and interpreters parse languages in several steps like CodeSmile explained. For anything slightly more complex you probably want to do a lexer phase before the actual "compiling" / parsing.

Just defining a consistent language syntax is not easy as well. You have to avoid ambiguities so the compiler / parser has only one way to interpret the code.

Personally I love lua for it's simplicity but it is still very powerful, even though it is so simple. lua only has 21 keywords and 26 operators. The list of keywords and operators in C# is a lot longer. I can also recommend moonsharp. I'm in the process of creating a "computercraft emulator" from scratch and I also use moonsharp because it's a 100% managed implementation of lua and is actually more complete than many other implementations. Since it's 100% managed code it even works in a WebGL build which is really funky ^^.

I would not recommend implementing your own language. You said you want a very simple language, however languages that may look simple are sometimes even more complex when it comes to the parsing part. The more ambiguity there is, the more context has to be taken into account when parsing the code.