Return to “Suggestions”

Post

Limit Theory Programming Language

#1
OUTLINE
My brain wouldn't shut up last night and kept me awake until 9 AM designing a programming language based on Josh's beyond-awesome node interface. It's sad that it's probably Turing complete. Honestly, his node interface is screaming for a language to built on top of it and I don't even know if Josh realises how much potential it has in that department.

Hardenberg told me that my recent idea about CPU Allocation wasn't very good, because it makes things too fiddly for the player. And he's right, unless Josh has any ideas about how to make his power allocation mechanism easy to manipulate quickly. If Josh can make power allocation easy to manage, I'm guessing that CPU allocation should be easy to manage as well since it can be designed in a similar way.

But in any case, Hardenberg brought up the idea of using presets. It's not a new idea but it got me thinking about programs. Programs are like an expansion on the idea of presets. All presets are programs but not all programs are presets. Programs are something the player will be able to write whenever he's not otherwise busy and will tell the ship how to behave in different circumstances. Before the obvious objection is raised about how this will lead the computer to play the game for you and suck the fun out of everything, I'm considering limiting programs to only being able to control the power and CPU allocations of the vessel (at this point). Everything else will still be handled by the player - navigating the vessel, targeting ships, evasive maneuvering, etc.

I will detail more how these programs will work in another suggestion thread that I'm not sure I will post today. But I think the design of a programming language warrants its own thread. The language I'm designing is a dynamically-typed graphical dataflow language vaguely based on LabVIEW and designed to work using Josh's node interface. At the moment I'm calling it ViTheory.

BENEFITS
I believe a programming language would be beneficial to Limit Theory for these reasons:
  • Many if not most of the people here have programming experience. A lot of you program for work if not as a hobby as well. You may find that writing programs in this language for your vessels is quite fun.
  • It opens up the opportunity to have members of the community share, discuss and collaborate on designing these programs.
    • "Hey, Cornflakes, what do you think of this program I wrote? It's designed to help improve the DPS of frigates against battlecruisers.
    • "That's pretty cool, actually, I just finished writing one that will help frigates tank better against bigger ships. Maybe we could try integrating them and see how that plays out?"
  • This idea is not unique and was the main feature of Notch's upcoming game 0x10c. Notch created an assembly language called DCPU-16 with which people could write programs for their ships. The 0x10c subreddit has over 6000 subscribers. That means at least 6000 people expressed some interest in a space-sim game whose primary feature is writing programs for your ship's main computer. After Notch cancelled development of the game, the community even proposed trying to finish the game themselves. These poor fellows are so desperate for a game like 0x10c that they're trying to delude themselves that No Man's Sky will be even remotely similar to it. If Josh adds a programming aspect to Limit Theory, he has the potential to attract a wider audience to the game.
  • The language I propose is graphical and relies on Josh's node interface. Not only will this make it visually appealing, it should also be pretty intuitive and easy to learn, potentially even for non-programmers. Anyone familiar with the usual procedural constructs such as conditionals, loops, etc. should be able to pick it up fairly easily. ViTheory is based loosely on LabVIEW, which is one of the easiest and most intuitive languages I've ever come across. It took only around two days of using it for me to be about as good at it as my dad, and I was able to begin using it for serious, practical work on the third.
  • Cornflakes_91 also suggested a pretty awesome idea that would rely on a dataflow programming language in Custom UI parts and macros.
LANGUAGE

Overview
Everything you program will involve adding, editing and connecting nodes together. Nodes can accept inputs from other nodes, carry out some kind of processing and potentially modify the state of its inputs, and may also produce outputs. All nodes have a "hidden" input that accepts what is called flow. Flow is used to control the order of execution of components within the program where sequential execution is necessary. The flow input can be left unconnected, and when this happens the node will attempt to execute as soon as the conditions for its execution are valid. This leads to massive parallelism which is a common feature among graphical dataflow languages. I propose seven types of nodes:
Image Figure 1: Node types in ViTheory (direct link)
  • Constants can be any base type: strings, integers, floats, etc. Like their name implies, their value cannot change. Because this language is dynamically typed, their type is determined at run-time.
  • Variables are like constants, but their value is able to change. Variables must be identified by a string of numbers and letters, and this string must begin with a letter of any case. Uppercase and lowercase letters are allowed.
  • Program flow are nodes that control which paths of execution a program takes. These include conditionals and loops.
  • Functions are sections of the program that perform specific tasks. They can be specified to accept any number of any types of input as parameters and return any number of any types of output. They can be called recursively. All the nodes that comprise the signature and definition of a function act as sub-nodes to the function node and occur at the next depth layer in the program node tree. This makes identifier scope extremely intuitive in ViTheory. All the nodes that are children of the same node as a variable node is are the siblings of that variable and together constitute its sibling space. The scope of a variable is just its sibling space. In other words, variables you declare inside functions will be limited to the scope of the function and not beyond it.
  • Objects are entities comprised of constants, variables, functions and other objects.
  • Arrays are collections of constants or objects that are all of the same data type.
  • Generic nodes are used where no other nodes are appropriate. They provide the backbone of the language.
Assignment
Any variable can have assigned to it a constant, another variable or the output from a function.

Objects can be assigned to other objects that expose the same number and type of constants, variables and functions (see below).
Image Figure 2: Assignment in ViTheory (direct link)

Arithmetic
Arithmetical operations can be performed using arithmetic functions on constants, variables or the outputs from other functions.
Image Figure 3: Arithmetic in ViTheory (direct link)

Objects
Objects expose their constants, variables, functions and child objects as shown below. If objects have the same numbers and types of constants, variables, functions and child objects, they are considered to be of the same type.
Image Figure 4: Objects in ViTheory (direct link)

Arrays
Arrays can be used to store an ordered collection of constants or objects of the same type. Array nodes expose a length variable that is equal to the number of items stored within the array. Array elements can be accessed through an integer input to the array node that specifies the index of the element. Arrays are one-indexed in ViTheory.

Arrays can be appended to and have elements from them removed, among other things.
Image Figure 5: Arrays in ViTheory (direct link)

Conditionals
You can cause a program's execution to branch along different paths by using conditionals. ViTheory contains one kind of conditional node: IF.

The IF node accepts a boolean value, typically from a conditional function (">", "<", "==", etc.). It provides two outputs - program flow moves along one of these outputs if the conditional value is true and moves along the other if the conditional value is false.

One IF node alone corresponds to the standard "if...else" constructs of procedural languages. IF nodes can be chained together to produce constructs analogous to if...else if...else if...else. This is done by connecting the false output of an IF node to the flow input of the succeeding IF node.
Image Figure 6: Conditionals in ViTheory (direct link)

Loops
Loops are useful when you wish to execute the same kind of behaviour from a program multiple times. FOR nodes are used when you want to execute behaviour a specific number of times, whereas WHILE nodes are used when you want to execute behaviour until some condition is satisfied (or not).

FOR nodes accept an integer input (from either a constant, variable or function output) that specifies the number of iterations to go through. They also accept two sources of flow: one from the node triggered just before the for loop is entered, and another from the last node in the body of the loop. When the current iteration of the for loop is less than or equal to the total number of iterations set for it, the node will output flow to the first node in the body of the loop. When the current iteration exceeds this value, the node will output flow to the next node its connected to outside of the loop body. FOR nodes also expose the current iteration count as an integer value.

WHILE nodes are similar to FOR nodes but accept a boolean input rather than an integer one. The WHILE node will continue to iterate while the boolean value is true.
Image Figure 7: Loops in ViTheory (direct link)

Function definitions
The player will be able to define his own functions by adding a Function node to the program and specifying its identifier (name), and then entering into the node (going one level deeper into the program tree) to define the signature and behaviour of the function.

The signature of a function is a specification of the parameters that the function accepts and the outputs it will return. When you traverse into a function's child-space, you will see the function node but with two generic nodes attached to it. One of these is called Parameters and the other is called Returns. You can specify the parameters of the function by connecting variable and object nodes to it - these variables and objects will be bound to the state of the arguments passed to the function when it is called, and will have a scope that encompasses the entire child-space of the function node. You can similarly specify variables and objects to return from the function by connecting the appropriate nodes to the Returns node.

Functions in ViTheory are pass by value. They cannot modify the state of inputs passed to them. If you want a function to change the state of its inputs, you can make the function output a copy of the input with the appropriate modifications made and then assign the copied input to the original input.

Functions are called by including the function node in a program and passing flow to it. The function will not execute if any of its inputs are invalid at the moment flow is passed to it, and will block execution until its inputs are all valid.

Functions terminate when no more flow is possible within its child-space i.e. there is no more flow occurring between the nodes that comprise its definition. At that moment, the state of any variables and objects used within the function definition that are also connected to the Returns node of the function signature will be returned as the output of the function. Flow will then pass back to the node following on from the function node.

If the player has multiple nodes in his program corresponding to the same function, editing any one of them will cause the changes to be reflected in all of the nodes within the same scope.
Image Figure 8: Function definitions in ViTheory (direct link)

EXAMPLES

Hello World
Image Figure 9: Hello World function definition in ViTheory (direct link)


Fibonacci (loop)
Image Figure 10: Loop-based implementation of the Fibonacci function in ViTheory (direct link)


Fibonacci (recursive)
Image Figure 11: Recursive implementation of the Fibonacci function in ViTheory (direct link)
Last edited by ThymineC on Thu Jan 02, 2014 1:15 am, edited 8 times in total.
Post

Re: Limit Theory Programming Language

#3
Slymodi wrote::shock: This is insane, how much time do you have? looks good though :thumbup:

~Sly
Let me put it this way - Limit Theory is completely frakking over my education. I am going to graduate from one of the most impressive universities in the world with one of the least impressive, shitty, third-class degrees. :D

It's fine because it would probably be like that anyway.
Last edited by ThymineC on Wed Jan 01, 2014 4:19 pm, edited 1 time in total.
Post

Re: Limit Theory Programming Language

#5
Cornflakes_91 wrote:Im missing array-type variables (or at least efficient ways of accessing them)

Besides of that i like that proposal, it ties very much in with my Custom UI Parts idea.

But im not sure if it is feasible inside the scope of LT...
Yeah, I was going to mention that, actually. It's missing array-type variables because I'm not totally sure how Josh is planning to do this in his own interface. I mean, I have ideas for how it can be done, actually. Yeah, I'll update it in a second.

By the way, awesome suggestion man! This increases the scope of usefulness for a dataflow programming language.

Edit: Okie dokey, I designed arrays. I arranged the elements of the array similarly to how Josh had the contract nodes arranged within the contracts board he showed in the latest dev video. Other layouts are possible.

Edit 2: Also, I included a reference to your suggestion under my "Benefits" section. :)
Post

Re: Limit Theory Programming Language

#7
Hart of Lions wrote:1 - Crazy good post as always

2 - Hope that Josh drops by and deposits his 2 cents :thumbup: :)
Cheers, and I hope so too! I don't even care if he doesn't actually incorporate my gameplay ideas, I just want to see a programming language based on his awesome interface.

Actually designing a programming editor shouldn't be that hard for him, now that he's got such wonderful things as node drag-&-drop and window splitting. Also you know the electric arcs that flit between nodes in Josh's data editor? A while back in the Dev Update #11 thread, Flatfingers said:
4. I wasn't sure, but at times I think I saw little flashes of light among the nodes. I'm hoping that this is a very early example of the node UI in "dynamic" mode, where changes to data are represented by visual effects among the nodes and connections. The idea of seeing the LT universe in a schematic view alive with fireworks of AI activity is extremely appealing. I would really, really like to see that -- a sort of game version of Indra's Net.
To which Josh replied:
4. Yes! Courtesy of graphics Josh :monkey: Each node can find itself randomly subject to an "eletrical impulse" that will travel along connected nodes, ultimately decaying. But it provides a lovely yet subtle feeling of life and electricity. These impulses could definitely be queued to events like damage, firing, etc. That's an awesome idea and I hadn't considered it! Graphics Josh is pleased to be of functional service :geek:
I propose that the programming editor has a "debug" mode where you can visualise the flow between nodes as these electrical impulses. This is actually very similar to how debugging works in LabVIEW - on each "step", you see pulses moving along the connections between VI's.

The hard part will be actually compiling the player's program into a form where it can properly affect gameplay. I wrote a compiler last year and may be able to help Josh out in this aspect if he needs it. Maybe, I don't know.
Post

Re: Limit Theory Programming Language

#9
I think I could find this useful and perhaps even fun.
Hmm, yes, I think I might. *ponders*

Isn't this how the entire modding of the X series started, except with a much more basic language? I mean, if you want to program your own spaceship and want to do it now... go play X3 already.

Add some networking to this and I can see really interesting options. Enemy detection grid operated by player owned transporters. Automated ring of fire deployers...
But, how much dev time would something like this take? I have no clue how complex it is to add something like this over the visualized data layer. All I'm thinking is that it will definitely need a scheduler to make sure player scripts with infinite loops etc aren't crashing the entire game. Or that variables that are used while a function is running isn't changed by some other thing happening in some other thread.

For instance, in the minecraft mod "computercraft" this issue is solved by blocking and non-blocking commands, and division of limited cpu time to possible unlimited scripts.
What happens is that each script can put itself in a queue, computercraft checks the minecraft ticks (20/second) and determines how much free cpu time there is. It then tries to fill up this time executing the scripts in its queue.
These scripts can have blocking or non-blocking commands. Turtle.forward() is a non-blocking command. It will let the turtle move forward (which takes a couple of ms), in the meantime another script can run and the first script gets continued whenever this script is non-blocking, and so on.
But, this relies on a minecraft second being divided in 20 ticks. I don't know how it compares to a real real-time game that's operating at 60Hz?
Beware of he who would deny you access to information, for in his heart he dreams himself your master.
Post

Re: Limit Theory Programming Language

#10
Katorone wrote:I think I could find this useful and perhaps even fun.
Hmm, yes, I think I might. *ponders*

Isn't this how the entire modding of the X series started, except with a much more basic language? I mean, if you want to program your own spaceship and want to do it now... go play X3 already.

Add some networking to this and I can see really interesting options. Enemy detection grid operated by player owned transporters. Automated ring of fire deployers...
Yeah, I like these ideas. There's a lot of room for extension on this suggestion.
Katorone wrote:But, how much dev time would something like this take? I have no clue how complex it is to add something like this over the visualized data layer. All I'm thinking is that it will definitely need a scheduler to make sure player scripts with infinite loops etc aren't crashing the entire game. Or that variables that are used while a function is running isn't changed by some other thing happening in some other thread.
The easy part will be designing a basic programming editor. Since Josh is designing a ship editor, this wouldn't be too far off that, in that it would (in its most basic state) just involve dragging, dropping and editing nodes. It'd need a button to compile the program as well. I'd estimate that Josh could make something like this in a week.

The hard part would be writing a compiler for a language. Last year, we spent a term writing a compiler, so around 3 months. Josh is a lot smarter than me and more hardworking as well, so I would guess that he could do it in 2 weeks to a month, especially if he's had experience writing a compiler beforehand. However, this is a graphical dataflow language and not a procedural, text-based one as I was working with. I would guess it would take Josh between three weeks and two months to do this.

However, this is one of those areas where you spend ages and ages and ages making a really robust, solid foundation and then it becomes trivial to build stuff on top of it. I think this is how Josh likes to work - he spends ages building a robust foundation which then simplifies the process of building things on top of it. Once Josh has cracked the compiler, all he will need to do is expose parts of Limit Theory to the player in the form of objects and event handlers, which the player can then incorporate into their programs.
Katorone wrote:For instance, in the minecraft mod "computercraft" this issue is solved by blocking and non-blocking commands, and division of limited cpu time to possible unlimited scripts.
What happens is that each script can put itself in a queue, computercraft checks the minecraft ticks (20/second) and determines how much free cpu time there is. It then tries to fill up this time executing the scripts in its queue.
These scripts can have blocking or non-blocking commands. Turtle.forward() is a non-blocking command. It will let the turtle move forward (which takes a couple of ms), in the meantime another script can run and the first script gets continued whenever this script is non-blocking, and so on.
But, this relies on a minecraft second being divided in 20 ticks. I don't know how it compares to a real real-time game that's operating at 60Hz?
I really don't think infinite looping and such will be a problem. It certainly shouldn't cause the whole game to crash, it will just make the program freeze up so that the player's ship behaves as if it's not running one. You'd still be able to fly it as normal, it just might not react to situations as you'd expect it to.

Additionally, I really doubt that running programs on the ship will have any noticeable impact on the game's performance. The bulk of Josh's code will be processing 50 million matrix multiplications a second or carrying out gradient descent on 100 AI's, etc. In contrast, the player's program will be something like this (pseudo-code):

Code: Select all

# Event handler.
def enemyDetected(enemy):
    processor = Ship.getProcessor()
    reactor = Ship.getReactor()
    
    # Weapons, shields, engines
    processor.setCPUAllocation(0.6, 0.3, 0.1)
    reactor.setPowerAllocation(0.5, 0.25, 0.25)

# Rest of code.
Post

Re: Limit Theory Programming Language

#11
I recall it being very easy to break X3 with combat scripts that the AI had absolutely no capacity to respond to. Not even cheat scripts, just behavior scripts that used the tools at your disposal in a more intelligent way. I scrapped 3 different combat scripts I began making because they were blatantly OP and utterly trashed the AI by making intelligent use of weapons in ways it could not hope to effectively respond to.

Most combat scripts I saw were very similar.

Basically, how do you propose that this remain balanced? No matter how hard you try, the AI will never be able to match human designed tactics that can actually reason out the optimal use of weapons systems.

The Ring of Fire mod is a prime example. Utterly devastating, and due to the universe layout, largely without a counter. The AI never used it because it had no capacity to realize how OP they were and weren't programmed to use them intelligently(thankfully, since the game would have sucked if they had). The player, on the other hand, could set up blockades that no navy in the game could bypass, because we could see that laser towers were immense bang for the buck and utterly unparalleled for the role of gate defense. Granted, they were cheaty as hell, since a 150k lasertower gave you 1m worth of laser and shields.
Post

Re: Limit Theory Programming Language

#12
CutterJohn wrote:I recall it being very easy to break X3 with combat scripts that the AI had absolutely no capacity to respond to. Not even cheat scripts, just behavior scripts that used the tools at your disposal in a more intelligent way. I scrapped 3 different combat scripts I began making because they were blatantly OP and utterly trashed the AI by making intelligent use of weapons in ways it could not hope to effectively respond to.

Most combat scripts I saw were very similar.

Basically, how do you propose that this remain balanced? No matter how hard you try, the AI will never be able to match human designed tactics that can actually reason out the optimal use of weapons systems.
Well, the only idea I personally have in mind for how this will be used is for programming the ship to dynamically adjust its power/CPU allocations to adapt to different situations. Different allocations will work better in some cases and worse in others. How do you keep it balanced? Pretty easily, since I don't imagine it as being a human vs. AI issue. It's more of a human vs. human issue; I imagine that players will write programs for their own ships, and Josh will be able to write programs for LT's NPC's to use. In this case, I'm more worried about the advantage being on the side of the AI, since Josh is probably a better programmer than most of us. But whatever happens, this aspect of the game really shouldn't be that big of a deal, it's really just something that will help give an edge to those that like min-maxing. If a player wants to completely ignore power and CPU allocation, they should be able to do so and get through the game fine. It's just that they might not do so as well as they could do if they did take these things into consideration.
Post

Re: Limit Theory Programming Language

#13
Cornflakes_91 wrote:Why should arrays only be able to store constants?
Let them store variables and objects too
For making dynamic target analysis and other things possible
Objects - yes. Variables, no.

Arrays don't store variables in most programming languages I'm familiar with.

I'll update to incorporate objects, though, cheers.

Online Now

Users browsing this forum: No registered users and 1 guest

cron