Wednesday, June 4, 2014

Programming in Space Engineers (programmable blocks and HUD)


Some time ago I was playing with the idea of adding “programming” into Space Engineers. Today, I would like to share with you my design document - still in its early version.

Please keep in mind that everything that is mentioned below is in a very preliminary stage and is subject to change.

This is a first “design draft” that needs to be specified in higher detail before we start the implementation (e.g. we need more specific GUI and HUD drawings, we need to design how the copy-pasting of programs will work, etc.).

This feature is not about modding. Programming and HUD customization will be a natural part of the game environment.

Programs could be edited, copied and pasted inside the game environment and also between players in multi-player – for example, one player writes a simple HUD program and he copy-pastes it to chat, so that others can integrate it to their HUD. A Similar idea will apply to all types of programs, but we should come up with a more user-friendly version, accessible even for the players who don’t have programming experience.

Lastly, this will be a great way for people who want to learn programming the entertaining and easy way!


Players will be able to write small programs that will be executed in computer blocks or computer components. This feature will be an integral part of the game’s environment, it’s not modding.

Computer Blocks versus Computer Components: I am still not sure if we should make a new computer block which will be the only entity where programs can run or allow programs to run in any computer component (if we allow the later, then players would write programs for doors, reactors, etc. and it could get messy).

Programming language: I would prefer some C# interpreter - instead of compiled code (DLL), mainly for security reasons. The interpreter should be object-oriented and support all standard C# features, perhaps .NET, LINQ, garbage collector, etc.

Editor: The program code can be edited from the Control Panel (similar to how we configure block attributes). Don’t forget that some blocks can have multiple computer components and player should be able to distinguish between them and program them independently.

Programs can be set ON / OFF.

Damage: when a computer component gets damaged (below operational integrity), its program is completely wiped out and lost and the program will not be executed anymore.

Execution:  these small programs can be compared to pixel/vertex shaders. They have a “main” function which is executed in every update (60x per second), on server or by object-owner. They can have variables/members that keep their value from update to update – so they can hold an internal state. These variables can be accessed from other computer components (they are public by default). Each computer component is an instanced object, not a class.

Access: programs can access attributes and methods of other blocks and components, but only within one grid (station or ship). Wireless connection is not available yet. Computers within a grid can be searched by a block name (e.g. GetByName(“rotor_on_the_left”))

Code editor:
  • Syntax highlighting
  • Syntax check
  • Suggestion wizard (e.g. after writing a dot it will offer all available members)
  • Text copy-paste-delete
  • Other features which are standard in code editors
  • Programs can be copied to/from blueprints (program is a special type of blueprint)

Exception/error handing: (examples: NaN, divide by zero, etc). In case of error, the interpreter will stop execution of the program in the current update, but it will not rollback to pre-update state. It will run the program again in a following update but it may end up with an error again. Error info is written to “program debug window” (see scheme above), but there are no runtime crashes and assert windows. (I remember that Visual Basic used to work this way).

CPU time and memory: we need to avoid situations where players create infinite loops, programs with extensive operations, huge memory allocations, etc. Is this possible? We don’t want network clients to run extremely complex programs on servers.

Replication: There can be a function for copying/replicating code to other computer components or block from within a program (code injection). Players could write viruses :-)

Classes & inheritance: my actual opinion is that these small programs are classes but not of the same type. I will explain it by using this example: imagine having two doors in the game (door1 and door2). You write one program for door1 and another program for door2. Even though you are still working with doors, these two programs you just wrote are two different classes – they may have different attributes, state, methods, etc.

Example code:
public float some_state_variable = 10;
private float some_other_private_variable = 20;

void main(void) // main function gets called on every update
var rotor1 = GetByName(“rotor1”);

var light1 = GetByName(“light1”);
light.SetColor(255, 255, 0);
Sample list of objects (computer components, attributes and methods):
  • base class for all blocks
    • IsPowered() // is electricity powering it now?
    • IsEnabled()
    • some access to block’s Inventory if that makes sense
  • Door
    • Open()
    • Close()
  • Light
    • Color (we probably have diffuse, specular, etc)
    • Radius, Falloff and other range parameters
    • Type
  • Thruster
    • AddForce() // or something like that

Examples in other games:

Possible visual/text programming language:

Proximity sensor

Proximity sensor is a new type of block that can be placed on top of other blocks (similar to how we put interior lights) that scans the cone area on its front side. Large and small block sensors will look the same and will have the same proportions.

Scanning: sensor keeps scanning a cone area in front of it with every update (60x per second) and whenever it detects an object (moving or stationary – this depends on the velocity threshold) - an event function on sensor will be triggered –> on_detect() –> this function is executed inside the movement detector computer component.

Detected objects: the sensor detects all types of objects - blocks from its own grid, asteroids, ore, small items, even animated doors or player or rotor or active thrusters... perhaps even particle effects.

  • Range - from 0 to 300 meters (Note: consider performance implications and decrease if necessary)
  • Angle - max 180 degrees
  • Laser projection of scanned area (player can observe the scanned area; transparent red polygons, similar to what we had in Miner Wars’s scanners)
  • Velocity threshold (if this is easy to implement) – if set to zero, even static objects are detected. If more than zero that only objects with higher velocity are detected.
  • Visual signaling – true/false – when true and object is detected, sensor will blink
  • Energy consumption – a little higher than spot lights; depends on angle and range

3D model: inspired by semi-spherical ceiling light; example:

HUD programs

This idea is very similar to “block programming” – however, instead of writing simple programs that run in blocks, HUD programming is about writing simple programs that run in the HUD and their output can be displayed on player’s HUD screen.

HUD programs can access (read and write) only the information that’s accessible to the player:
  • astronaut info (health, energy, velocity, etc.) – available at every moment
  • ship and station info – only when sitting in a cockpit or connected to terminal/control panel (although at this moment the player won’t see the HUD because the GUI screen will be on top of it)
  • remote – once we add wireless communications, players would be able to “communicate” with ships and stations even when not sitting in a cockpit

Current HUD: I am talking about displaying character and ship parameters such as speed, energy, etc – we need to redo them as a customizable program that players can modify. This should be easy and it will also show how to use this feature.

GUI versus HUD: In my opinion the difference between the GUI and the HUD is that the GUI is also for things that are not part of the game world (e.g. Save, Exit to Main Menu, Options, etc.). The HUD should be only for things that are an integral part of the game world.

Storage: HUD programs are per-world and per-player (so they are stored in the world file and are specific to player – even in multi-player). Example: if player wants to use his cool new HUD in some other world that runs on a dedicated server and where this player is not even an admin, he can copy-paste it there through the game’s GUI/HUD and use it.

CPU and Memory: HUD programs run in every update (60x per second) and there are no limits on how complex HUD programs can be written – if the player makes an error, only his computer will be affected by low performance

Errors and debugging: errors are ignored (no crashes) and error messages are written to the HUD screen so that player can instantly see if there’s a problem.

Example code:
public float some_state_variable = 10;
private MyGuiSlider slider1;
private MyGuiLabel label1;

// called only at start of HUD or whenever HUD program gets changed
void init()
slider1 = new MyGuiSlider(...position...default color...etc);
label1 = new MyGuiLabel(...position...default color...etc);

// main function gets called on every update
void main(void)
GetByName(“player character”).Color = slider1.Value * 100;
label1.Text = MyUtils.GetFormattedFloat(slider1.value, 2);

Editing: HUD programs are accessible from the terminal screen (control panel) under a new tab of HUD. The player can see a list of all active HUD programs there, modify the position, shortcuts, etc.

Focus: HUD screens don’t have keyboard/mouse focus unless player presses the shortcut key, after which everything under the HUD screen gets darker and player can access the GUI controls on the HUD screen (e.g. move slider). Player will leave this mode after pressing shortcut again (or ESC).

Controls: all standard GUI controls should be available for HUD programming: textboxes, sliders, labels, buttons, comboboxes, etc.


Please keep posting your feedback and suggestions to the comments section below. I can’t reply to every comment, but I can assure you that I try to read as much as possible and your comments will influence how Space Engineers develops.
Marek Rosa


  1. that sounds awesome! and also complex... looking forward to see how the release results will be...

    Maybe a nice way to me finally learn programing

  2. Go for it! Thats an perfect concept!

    1. Can I make a suggestion? Can you make it so that any computer terminal can have an antenna put on it, which can link back to a station terminal? That way I can edit the programming and turn a program on and off via a station terminal even if it's on a ship? I'm hoping this would be possible because then I try to build some automated mining vessels that I can adjust the programming on etc to tell them to return to base / go mine 'iron/gold/silver etc..." / Dump cargo at co-ordinates... etc..

  3. I'm so glad you're actually working on this. :)

    You should consider capping the performance of the computers, as-in make them be very low-performance emulated computers. Similar to what Notch was going to do with his 0x10c. This way players would also have to consider the performance of their programs, and servers would not need to worry about infinite loops and such, since only the virtual machine would be affected. The slower the emulated processor, the better it'd be for the actual real-world server.

    I've no experience of making all this happen, though. It could be way too complex to even implement in the foreseeable future.

    1. Bump. Best part about robotics was high efficiency programming.

  4. Interesting Ideas, I like the idea of "Computer Blocks" but also like the idea of being able to program doors directly - Perhaps you could use the Idea of Processing Power to Limit the number and size of programs on a block/component so that both are needed, I.e. doors can handle simple programs like "Only open Door A if Door B is closed" and Computer Blocks are needed for more complex automation such as automatic ship docking.

  5. This comment has been removed by the author.

    1. Cool idea with a storage block or drive or something like that. I would also prefer that it is possible to delete all data using a virus and/or using a wireless network to transfer data between ships and stations.

    2. I like the idea of a size limit for the programs based on the individual blocks. And using a storage block for overflows. One idea I had was a code limit storage per computer component used to construct the block, maybe even allowing the block to hold a variable amount of computer components depending on how complicated the instructions are for each block. In that case you have basic mechanical functions for the blocks such as for doors you would have two control panels(one for each side of the door), motors that open and close and networking for accessing other controls on the ship through the door control panel. Then you write the code to the control panels and automatic functions. For that to work you would need a couple buttons on the control panel that functions could be assigned to, functions like open, close, lock, etc...

    3. I had the same idea. Mainframe and certain number of slots of programs running. Different sizes of "computer". With 1 to n numbers of programs running, if you need more slots then you need more "mainframes"/"computers".

  6. add an option in settings for easy programming (select the block and it tell what to do and how often etc.)

  7. Awesome, but I would like to suggest some more features:
    - Make ship-specific keyboard shortcuts
    - Give us the ability to lock the terminal with programmable blocks
    - Create an antenna API to communicate with other ships (even automatically)

  8. Awesome! Will we be able to make a sort of radar with this stuffs?

  9. Looks awesome and great to see concept/idea getting more serious.
    My 2 cents on the programming language. I's prefer a more simpler way to program sucha block. More like:

    on[element]( action )do[element](action)

    Where "on" and "do" are fixed syntax, "element" are the object identifiers and "action" would be a list of predifined actions. So for example:

    on[main_button]( "activate" )do[main_door](open)

    that way with almost no programming skill its still be pretty programmable.
    .... just 2 cents. ;)

    1. This post gave me cancer

    2. in no way does this even simulate programming, completely going in the opposite direction of the developer

    3. Whatever... I hope it is something like that! With icons, too... And an advanced "console" for the savvy nerds, or for the rest of us who would eventually have the time to bother learning.

  10. Could we create our own faction chat with the ingame programming ?

    1. I think we will can if they make the antennas actually work...

  11. Having a text based environment makes a lot of sense. Running small programs on each component will make programming in SE more accessible to beginners as opposed to a monolithic piece of code which would be daunting.

    The other thing you achieve by forcing the code on small blocks is modularity. Pieces of code will be more reusable and shareable on the workshop.

    I'm really looking forward to playing with this.

    Have you thought of embedding a Python interpreter? Python is a very accessible language, often recommended to beginners, but can be very powerful.

    Another source of inspiration for you: check out some sample arduino code. Arduinos are often configured to work on sensors and the programming is made as simple as possible, with just two default functions, setup() and loop().

    Thank you for working on this!

  12. Too complex, lego ev3 programming style would open this up to everyone not just the hardcore fans.

    1. It doesn't matter how big a fan you are. If you can't program you can't program.

    2. dumbing it down to that level is a bad idea. as simple as it is, the power and elegance if classical text based coding will give players way more power and allow for much cooler stuff on the workshop!

    3. But, what about the players that don't know how to program? If this gives a major advatage to players that know how to program, it should be at least simple enough to someone begin to learn instead of taking classes of C# to play the game.

      For me, the game needs to add thing without excluding players that are still learning, wether physics or programing.

    4. I like the idea of having a Lego Mindstorms type of programming Players can drag and drop code blocks that are associated with whatever is attached to the ship. Then, for the advanced players, have custom blocks that allow them to create their own code. That way people who just want to make basic programs can, and advanced players can make advanced programs.

      As for keeping code within reasonable sizes, I would suggest that each block should have a size. The collection of code blocks for each set of code are added together, and take up a certain amount of space on the "hard drive". Basic code blocks would be 10 each, medium 25, advanced 50, and 100 for custom. Lets say that a ship could hold 1000 blocks of code. So, 10 blocks of custom code could be used.

    5. You have never tried programing in lab-view (the real Mindstorm language) Great or data acquisition but horrible for anything else. Runs Incredibly slow and consumes ram. The idea is to not lag servers or murder your own computer by having multiple translation programs for a simple piece of code. Honestly C is not that hard and adjusting for C# is easy.

  13. Maybe LUA? It's probably the most common and simply language. At least I think so...

    1. yeah, it is very simple. Like I've easily learnt lua just so a can play with a minecraft mod(computercraft). Like it's just something like maybe
      if buttonPressed() then

    2. oops, I almost forgot, Java seems a bit complicated for something so simple

    3. To my mind c# is better because in c# we have many usefull stuff like List<>,classes and etc.
      Lua is only script laungage

    4. I think e2 would be easy. Like in gmod, and you realy nead nothing to start.

    5. The fact that Lua is a scripting language is what makes it good for this. C# is not a scripting language, which means they're probably going to have to write their own interpreter or w/e to turn it into a scripting language for the game. Also Lua doesn't need a List<> class because it has tables.

  14. I would like to see such as programming flowgraph. in Cryengine 3. so simple, that I could even program the 10 year old child. and if it is writing code, so that the 10 year old child and was able to learn in the end. Office keyboard shortcuts components ship would like to see as a highly customizable, and it was even possible to run the program without opening the panel keys. and preferably the ability to output to the interface box which lists the functions and their key which they are activated. it's all my suggestions and desires. Thank you Marek!

  15. Apple Automator would also be good, you pick a part then the actions. It compiles the code.

    Sure some people will love writing code, but most people, like almost everyone in the world rather just play a game.

    1. "Sure some people will love writing code, but most people, like almost everyone in the world rather just play a game."

      totally agree

    2. the "almost everyone else" can still play the game! they can pick up ships made by the coders and designers that are LEAGUES more interesting due to their high level of coding complexity. They don't HAVE to design a ship if they can entice someone more code savvy to build them one. They even have the option of downloading really amazing ships from the Steam Workshop.

      Of course, knowing to code will give you the edge. Engineers code. and so it seems reasonable that those who excel the most at Space ENGINEERS would be actual engineers (and those with the savvy of an engineer).

    3. How "just player" must get "cool code piece"? From community? So he MUST go out from game, google SE code community, find there code, he want (and he don't even imagine, how it must look. Best chance he can type "some for airlock door code"). For right question you need to know half of the answer.

      No chances to be good for "just players".

      No, "they can pick up ships made by the coders and designers" will just kill the sense of this game for most. Why I should play construction sandbox, if personally I can't do cool things and must use someone else's?! It works in TES series, because players there USE things, not CREATE them.

      Neverwinter and Dragon Age has programming, and noone whine about it (AI combat triggers, simple variations). Let us some basics in such simple way and left low-level code for geeks. Creating new logical block for use by other players is not worse, then create unique code for damn unique rotor. I think it is better.

      Okay. I want create my OWN ships. Not redesign some default. That simple. Yes, it is IMO.

    4. Wait, whats the real problem here?
      Those people complaining about complexity (and therefore possibilities) of ingame programming just made me feel sad. Now you are just beeing not jelaous of somebodys (possible) constructions, you are beeing envy for them, and thats really bad thing.
      If you truly want to make good use of something you just go and learn yourself how to do so, instead of forcing anybody else to not use it.
      Would you like to see the following law IRL? "You cant run yourself when there are disabled people around you"
      Because thats what coding-complainers are trying to achieve right now.

  16. Great work!

    I love the idea of infecting an enemy station/ship with a "Virus". it adds a new dynamic to the game, one that would need to be balanced.

    I feel like there should be a master computer or mainframe, where the programs can only be added or modified through the mainframe, where slave machines can still trigger the programs.

    this means that you would need a spy to get in to the mainframe to insert the virus.

    There should also be blocks like HDD or program storage blocks, where X amount of programs can be stored on each block, giving you a computer room or server room where certain commands can be issued. so damaging the mainframe could damage enemy defenses.

    this should also allow HDD to have programs moved between, ie to move programs if an invader is detected.

    With blocks, you should also be able to see if a block is being broken, as long as it is above a certain integrity.

    foo = door2.GetIntegrity()

    if ( foo < 100 ) {
    MoveProgramsToBackup( backupServerNumber );

    just some Ideas... Hit me up on the KeenSWH forum if you want to pick my brain.

    I am listed under DeadWeight4U.

    1. Bump. (I am already having ideas of implanting a virus to self destruct ships on an automated mining ship that self replicates it via wireless onto the other ships of the faction)

      I like the idea of a master computer block to actually execute a program every that can trigger simple programs in computer components, which may have a processing limit.

    2. BUMP.

      The idea of having a dedicated "Computer room" to attack in an enemy ship is cool. I also like the idea of limiting the number of programs allowed in a block.
      For large ships, extra computing power could improve the operation of existing ships systems as well.

      It would be nice to have programs like "Defensive pattern beta" to execute in combat (think star trek people).

      In addition to this however, I'd like to see tactile switches and sensors that can trigger programs. I.e. a simple "button" block that when pressed in-game causes code associated with it to run. This would allow self destruct buttons, hell if I can change colour on blocks in code I could have massive red numbers counting down the time to detonation in the halls of the ship.

      It would also be cool to have a IFF (identify friend or foe) component so you can get some code to only execute in proximity of some players.

      Auto-cannons targeted and fired by user-defined code would be hilarious! This takes me back to hours of fun I had in Mind Rover.

      It would be cool to use the RF components to transmit messages/control signals to other ships. I can totally see me making defence drones controlled to patrol a mother ship in patterns shooting at enemies.

  17. Great ideas !
    Could the proximity sensor work as remote control for eg. a gate to the base? I'd have some special block on my ship that through the sensor gives the "green light" to the gate :)

  18. Love it. Make it so!!!

  19. for example, to automate a mining machine and a cargo hauler, the mining machines fill their cargo, then wait the hauler, the hauelr is programmed to go near the machine and wait till the machine start to unload cargo whit ejectors, and the hauler start collecting whit collectors then it goes to unload elsewhere [smile] programming automated pilots plus proximity sensors could be a really cool thing. We will be able to do sort of this, right?

  20. *thumbsup*

    I like the approach so far. I'm a robotics/AI programmer by education, so the ability to build and breathe life into autonomous drones is huge for me. People have been asking for NPC AI, but it looks like this system will let the players themselves create AIs to work and fight on their behalf.

    I look forward to working on a rogue drone hive to infect servers with. :D

  21. C# rules. Uh uh!

  22. I remember messing around with ComputerCraft in Minecraft. It really caught my attention. And it is the major reason I wanted to learn programming.
    I like this concept and I'm sure you guys will come up with a clean solution for code editing. This will be insanely awesome; especially with factions!

  23. As a programmer myself, I love to see in-game programming integration. I can't wait to see the start of this and get programming on my ships. I will be starting a group to do 'software' in game. It will be some awesome fun.

  24. i would like the programming but it should be made with the K.I.S.S. method in mind.
    I am thinking about hanger bays that have automatic doors like with rotors when they finally are bug free. and like Abdul mentioned automated mining.

  25. I can see a very high potential for this. Every player could have their own systems on their own ships unique to them. Those skilled in programming would begin to shine in this game. Watch out, Marek, you're going to educate people into REAL Space Engineers after this kind of thing makes it into the game.

    Don't get my comment wrong though. I wholeheartedly support this idea. An in-game HUD IDE for programming their ships would be amazing. This leaves the game open to electronic warfare, as well. Would the Antenna be used for connecting inter-ship programs, if so, then we'll see players attacking each-other's ships by exploiting bad programming.... just like in real life, (manipulating public variables, calling functions with weird pointers that go to other functions.)

    Garry's Mod had something like this, but they weren't using C#. They weren't even using Lua for in game programming, and this is a game that uses C# for in game programming. This is going to completely revolutionize the sandbox gaming genre.

  26. This comment has been removed by the author.

  27. Does this mean we can program a ship trajectory? or would that require programming the thrust or non-thrust of all the thrusters involved individually?

    if so maybe someone could make an add-on that records the motions relative to a ships thrusters then outputs the data the individual thrusters need to act in concert to produce that flightpath.


  28. All I want is conveyors functions:
    GetItemType() and SendTo()

    It can't wait being able to code somthing like

  29. Have you considered doing it as a statemachine? It might work better.

  30. Sweet mother of god, I get to program in SE? The gods have shown us favor!

  31. Might I suggest you take a look at the WireMod addon for Garrys Mod? It solves the infinite loop problem by giving each "Chip" a set number of operations per server tick, and if it exceeds this, that run though the chip's main loop is terminated.

  32. How main function could be void? Main should be int!!! Return program success or not.

  33. I have a (untested) idea about infinite loop : an execution of the main function may create a thread (#1) and later a second thread (#2) created (1/60 second later). If the thread #1 haven't encountered it's end, #2 would not begin. It could be simpler then to determine if the programme run for too long : if the game fail to run #X the program could be considered as too large and so being killed and ignored until some modification?

  34. Love it. For the ease, using some basic interpreter like IronPython, js or Lua or even a subset C# would be nice, please avoid inventing a completely new syntax (to compare: uo had multiple strong server emulators, and those with the most advanced language access had the hardest time; while the most successful was one with an easy to learn but not touring complete language, so actually the whole thing got stuck; there was so much potential which just died off in the process and lead to the downfall of uo scripting; also its now not the only game which allows modding access anymore). It's a hard balance.

    I prefer py, because it teaches people proper programming and looks like pseudocode. also the python effect is, that once the snake begins to devour you, you never want to look back, so i am biased.

    The GUI to program can be too helpful (see blizzards sc2 editor), but create a language which is hard to do in text; another hard balance act.
    Programs should be global, and owned, for data amount reasons, but instances should be editable (so somebody using the exact same program does not generate infinite amounts of the same basecode). Libraries are always a nice addition.
    On the sensor thing - i love it, but do not forget that every timer is a timer, every loop a loop.

    Generally, I like the first draft, even if it is very rough, and of course an event based language design with access to sensory stuff would be cool. In my own drafts for a similar game environment, I tried to modularize event givers, like sensors, and hinder too many of them (power supply), so that an event loop input could be coupled with more hardcoded features, or even create more cheap abstract sensors which unified other sensors or timers.

    It would be lovely, if we can even make AI like bots, and wireless comm would be great (with distance limits) to be even able to program remote controlled drones as small ships. So don't dismiss wireless too fast (it's after all also easing up the core code a bit)

  35. It's a great idea to make programming an essential part of the gameplay. I'm looking forward to all the fantastic stuff you could do with that!

  36. C# seems like an odd choice, wouldn't it be easier with a scripting language such as Python or Lua?

    1. It's not really an odd choice when you consider SE is written in C#, it would be the easiest to integrate.

  37. It looks quite complex for newer players to the game and programming, would it not be better to have more of a macro editor feel, with the option to go advanced?
    Eg dragable blocks of text (in the GUI not actual blocks) that have things like 'Wait []' etc. A bit like scratch?

    1. no!
      the game will still be playable to new players as it is now, and when they want to start making better ships with scripted functionality then they will learn to code, the basics of programing any language is pretty basic, even if you only learn how to make a simple function with 'if then else' statements you will still be able to made pretty decent programs for the ship, suggesting macros instead of c++ or c# or .net is like recommending to someone to play wolfenstein 3d from 1992, when they could be playing wolfenstein the new order from 2014, it just isn't done

    2. "We ship you car, that can move. And there is tools you can use to make this car comfortable, it is simple for learn and use. It is most modern and powerful tools, be happy". Great.

      Wrong assotiation with Wolf3D. Thing is that people need variable and customizable game, not a programming stuff with couple of books "for dummies". That simple.

    3. It's more like they ship cars with tons of features, then you learn to use the cool features, or if you don't want to, you don't. They don't go "well, some people aren't going to know how to set the clock, so we better just take that out of ALL the cars" or "some people aren't going to have a smart phone, so we better not put bluetooth in for anyone".

  38. Everything here is absolutely AWESOME. I'd just like to throw in two small, yet very useful additions:
    - A simple switch. Placed on top/side/bottom/whatever of other blocks, acting like a button or switch (depending on the setting it has in CP) and triggering its toggle/switch on/switch off events to be handled by a programming block, along with a switchedOn (or similar) state variable. Would be very, very useful. One example right off the top of my head - hangar door button :)
    - Some kind of code storage. Either in the programming block, or a cockpit, a place to store code that is not being used, but is ready to be copypasted to the same block, another device, or even another frame. Would be convenient to have a file system there, and be able to store code in the Steam Cloud (although not upload it to the workshop - let people figure out their solutions and learn to code! :)

    Once again, epic job you're doing there, Keen!

  39. For programming something between complex and accesible would be the Wiremod in Garry's mod (available on steam, test it out, especially the spacebuild mod : you could get some serious inspiration material).
    Blocks have an input, an output and a special function. It's possible to make very complex things. If you take the same system but you put the "blocks" in a simple interface inside a SE computer block, that could be easier to use than write code directly for a beginner.

    Sir Bulldozer - Krackers !

  40. Will there be a poosible way to Hack into other factions Ships or so?

  41. would love to see some kind of of DCPU-16-style computer. I think, it could save resources in a reasonable was(Just Limiting the number of programs seems kind of pointless, you would force the Coders to write really ugly code, if they want to safe space.) You could extend the DCPU a bit(Or use the CPU used in Trilliek, for example), and have some kind of BASIC running on it. (Or maybe a build-in basic compiler?) This way even Programming newb's could get into it, while the more advanced guys could write really performant programs in some kind of ASM. It aslo would be a more-realistic approach. And think about the possibility's with under/overvoltaging, RAM-corruption, that are easy to implement on a virtual CPU! And it could be more secure, since the code is running in a VM, not on the host computer! Peripherals could be implemented on the DCPU16 with the HWI-instruction, the Hardware-ID's could be gathered by the HWQ-instruction. Of course, I got nothing against other Implementations :D

  42. +1 for Lua!
    Maybe Java? Not really familiar with the differences between Java and C# (although I heard some things are pretty similar), but I learned Java for 2 years in university. Do you think it's a viable option? It might be a better choice for the gamers, I'm not sure.
    Either way, programming in Space engineers would be pretty awesome!!! ;-)


    1. -1 for Lua :D
      if you know Java then you automatically know c# :)

    2. +1 for Lua.
      C# is good, but will be harder to implement.

  43. This is awesome.
    Please consider adding current states to objects, so the program can check what the module is doing. For example a function to open and close doors when a player is close:

    void main()
    var _sensor1 = GetByName(“door1_sensor1”);
    var _sensor2 = GetByName(“door1_sensor2”);
    var _door = GetByName(“door1”);

    //assuming a detector can detect multiple items at once
    if((_sensor1.Detected.Contains("player") || _sensor2.Detected.Contains("player")) && _door.State != DoorState.Open && _door.State != DoorState.Opening)

  44. Really nice, looking forward to write some awesome skripts :)

  45. I freaking love this and i love you guys by far my fav devs of all time and prob the rest of my life keep it up you guys

  46. I'd prefer something similar to the language used on Texas Instruments' calculators: Ti-BASIC, a version of BASIC for calculators. In that language, since you might not be aware, basic If/Then/Else statements, display and input functions (:Disp, :Prompt), variables, and equations create a simple language that is extremely easy to pick up. Lines/commands are separated by a colon (:), and, although I really wouldn't know, I'd think that it would be easy to implement.
    As for the challenge level, I picked this language up in a week. A similar language would be good for Space Engineers.

    1. Actually I know TI Basic :)
      Texas Instruments calculator was my first "computer", that's where I started programming. Good old times :)

  47. You can compile and run any c# code with the framework programmatically. It isn't difficult to do.

  48. I'm exited about the "learning aspects" of it.

  49. This sounds amazing.

    Have you thought about mining drones? So you would need a function to list close ores with positions (through a ore-detector block), and then, most importantly, plot a path to that position in space the drone can follow. The basic algorithm should remain to the player, but you would some more tools than just a proximity sensor.
    I have to admit I can't come up with a good design for that, but drones are certainly something people will try to build.
    A random idea would be to make the proximity senor scan a 3D grid (the bigger the more energy is consumes), and through that grid the play could run a path finding algorithm. Basically something to give a drone awareness of its surroundings.

    I also noticed that you only have a update function in your example code for ship-programming. You may want to make a InitializeComponents function for the block reverences. Normally reverencing external components (in a complex system) is something that take a bit more performance, and doing that every frame could be a bit much. If you had a function that would only be called when the ship grid is somehow changed/damage you would have less to handle in normal frames.

  50. Amazing, looks really cool! I can't wait to experiment with this once it comes out, it looks like it's got a lot of potential.
    Pretty obvious question that is most likely "no" - can we expect a "beta" of this in tomorrow's patch, or will it be something else?

  51. I actually implemented exactly what you mentioned in a game I'm working on (Centration); programmable lua computers that control a spaceship like environment. As far as I know there is not a C# interpreter, so your best bet in my opinion is to go with Lua. If you need any help, feel free to contact me.

    1. Well, CSharpCodeProvider exists from .NET 3.5 - - there is a sample of using it to evaluate entered C# code.

    2. i am only 15 but i do know c# (only C#) so please use c#
      even if you do lua id be fine id just have to learn it

    3. frankly speaking c# is better choise.

  52. Please remember,
    that not all of us have programming knowledge..
    and in the end.. Space Engineers is a game..
    so, keep it simple to be fun and playable.

    1. I program for a living, and I support your comment. My feeling is C# would be difficult for a lot of people

    2. You can play the game and enjoy it without knowing jack poo about code. But learning to code and understanding code is really useful and enjoyable. I'm seeing people at high school, who are kinda "forced" into programming on IT lessons, and they start to like it very soon.
      And please... If you want an easy, casual game to sit back and jam the keys all the time, just go play Battlefield...

  53. Oh. my. god. THIS IS AMAZING!

  54. I hope we get this stuff as soon as it's ready. I want to see the ability to link the HUD screen to ship systems, or a sensor block. being able to keep tabs on Uranium levels of my ship when not in it or being able to see objects detected by the sensor would be fantastic.

  55. hmmmm, well personally i think rather than have a whole block committed to the sensor, maybe have something like the internal light, so it doesn't damage the look of a ship's internal corridors while still maintaining functionality

  56. Here are some of my opinions and ideas that I have:

    This is by the way one of the best features I have seen. I already hoped this would be possible in other games, e.g. Minecraft. I know there are mods for it but I don't like mods. Can crash the game.

    But now this happens in Space Engineers which I'm playing a while now and it's amazing.
    Apart from all the great ideas all the user have here.

    It would be then possible to create autopiloted ships. And we can go further. If we would get the functions we need and the blocks we need it would be also possible to code a script for automatic mining and another ship that can bring that to a station which is automated too. But this would require some special blocks and methods of course.

    One thing would be the proximity sensor and another thing that would be possible is communication between ships/station with a wireless network and a block that can give us the exact position in space.

    But that's not the only thing. It might also be cool to write scripts that are especially for combat, protecting, etc. For example if a ship is hit by an object (projectile, rocket, asteroid, etc.) it would be cool to be possible to recognise this and activate a script.
    So events that can execute special scripts.

    Or a block or scanner that can detect players inside a ship and this could be drawn on a HUD so we have a position for that.

    Or if someone wants to steal the ship and fly away that you have written a "drive-home" script flying to your home station or something like that.

    So some keywords:
    - detect players
    - have events that are triggered and can execute code (ship was hit, collision, intruder detected, energy above an amount of Watt)
    - a block for getting the position in space (and rotation)
    - a storage block that keep all scripts
    - aiming objects (ships, stations, etc)
    - a way to try to transfer viruses
    - a way to protect against viruses (preventive & maybe on an alarm call that could be triggered -> for example: shutdown all wireless systems when an intruder is detected)
    - a way to log everything using a wireless -> send logs to a "home" station, in case of ship is destroyed it would be possible to see what has happened
    - code with friends: some kind of rights management, so who's allowed to edit scripts?
    - a wireless system/block whatever: the farthest you are the more energy you need to hold the connectivity
    - encryption/decryption for transmissions
    - a way to download all data from a storage so you can steal the scripts that are maybe better then the one the thief had
    - a backup system that you can use for example after you were infected with a virus to try to eliminate it and get back your system up and running (humans always like backup systems and backup backup systems and so on ;))

    For all the guys & girls without programming skills:
    - maybe pre-written easy-to-understand scripts that are maybe not the best but working
    - I think there'll be a lot of articles, wikis and more with scripts from the users (I will also do that then)

    I have too much ideas to all write it and I'm still excited that you're going to do this ;) Sorry for that long comment, just want to share all my ideas and thoughts.

    1. These are some great ideas, thank you.

      I especially like the GPS block (position / orientation) and the direction you took with security, viruses and encryption/decryption - I will need to think this through before we start working on this.

    2. Cool ;) Good that I posted it and you're inspired by that :) I think you all will do it good. Can't wait to see implementation.

    3. On top of your wireless system/block suggestion? Might I add something?

      Frequency and Transmit power.

      Transmit power would play perfectly into your suggestion of "the farthest your are, the more energy you need to hold connectivity". You can set the transmit power to whatever want to throw at the wireless system, and that'll amplify the range of the signal. Solar storms would play a factor into this as well, as wireless links with high throughput would be able to (attempt) to maintain link through a storm.

      I want frequency added in there as well, so that one can have multiple, isolated channels of communication between objects. This would allow for communication between multiple systems of the same type without interference. (Can someone say semi-active radar missile homing system?)

      These two attributes of a wireless system would add so much to the game, because then there would be another dimension to eletronic warfare. Jamming, sniffing, and man-in-the-middle.

      Lets say someone launched another missile towards a ship, and it's receiving in-flight vectoring data, only vectoring data. There's no tracking code on the missile that allows it to make its own updates, so throwing code onto the missile wouldn't have that much of an effect. That's where jamming and man-in-the-middle would work. The defending ship could jam the missile to where it would just maintain its more recent vectoring update, so the defending ship can move and avoid the missile.

      This would play another role in the terms of drones. If your ship has enough power, you can throw a lot of power to your wireless system, and that would increase the Tx (trasmit) power, (Rx, receive, power is determined by the sender). Let's say there's an attacker ship using drones on a defending ship. If the defending ship has enough power, they could throw all their power into their wireless system and completely drown out the signal sent by the attacking ship, rendering the drones inert.

      There's so much application for a wireless system that involved encryption, Tx/Rx power, and frequency. I hope the development team puts something like that in.

  57. Very cool, I like this plan quite a bit.

  58. Dude, I am a C++ programmer and I say hell ya. If you could do this without making a server or client crash or hurt someone's computer I would almost pay for a DLC version (I stress almost though) Even though I own the game this would make skill and ability even more unique in a game thats closest equal are all 2D or 2.5D. Simply ON BOARD 1000000000000000000% Hell YES!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

  59. amazing, I just wish there was more decorative blocks for large ships to fill in empty space.

  60. Will you be able to manipulate vectors and such like? As I think it would be useful to players who wish to write autopilot or interceptor scripts. Also I hope you add some sort of radar - a device that would be able to detect distant objects and give a position vector and velocity vector output, I think this will lead to some interesting creations by the community, I had an idea of radar controlled cannons that were capable of knocking out an opponent ship many kilometres away.


  61. I love the idea. But after reading your design for the implementation and how mods would be made, I can't help but ask why use C#? Why not use Lua with bindings setup and ship some Lua libraries as your modding API.

    It would be easier to implement in the engine and be easier for people to work with, it could easily support hot-reloading and could be easily made to support multiplayer concepts. Could even make it so servers can send clientside files from mods to clients to support server huds etc.

  62. C# seems like a lower level language, Yes it is an excellent choice - but consider the people who will/can not learn the syntax. For the basic gamer I would recommend at-least have a gui similar to how the Vex robotics coder does it, while you can still do the lower level code.

    Anywho, Excellent work thus far. Defiantly hope to see this implemented soon.

    1. C# is a pretty high-level language as compared to C(++) or the one mentioned in my nickname :P I've started my programming adventure with C# and it's one of the easiest to learn, very logical and intuitive. In my opinion, they shouldn't choose anything else - C# is perfectly object-oriented, and people who want to code need to learn how to do it, not just type a few words in English and have the game understand them...

    2. +1 you're right ;)

  63. Will interrupts be possible with this method of coding, or some event listener so that programs won't have to check every tick if a button has indeed been pushed, and can just run on the ticks in which they are required.

  64. This is a really good moment not to use anything particularly C-syntax-derived. Seriously, the problems implicit in picking a language that's so inherently difficult to manage in terms of parallelization just scream out for borrowing problems you don't have to. There are plenty of other languages and VMs that are much more friendly for embedding and will work better for both newbies (who have nothing to unlearn) and the experienced (who don't need the headache of bad design).

    My personal feeling is that what SE needs is one of the broader visual programming architectures, maybe inspired by StarLogo or the like. Nice and container-focused, visual for clarity and to hook into the theme of visual construction in SE in general, and newbie-appealing. That kind of architecture is also going to be closer to the intent originally expressed for visual programming.

    If I were really devoted to shifting over to the context of a text-based language, I'd be looking at things which worked well in this kind of environment.

    Lua's already been suggested, for good reasons, but it doesn't really do a lot with parallelization.

    My personal preference would be Erlang, because the abstraction of "every object being a communicable process" is surprisingly easy to grasp for newbies and it's been built from the ground up as an embeddable, interpretable, parallelized language. It's also just one of my favourite clean syntaxes.

    Scheme might be an interesting choice for it's long-term stability and very, very lightweight core. Lots of embedability and the right distribution abstraction would make talking to/commanding parts of a ship pretty straightforward.

    If you really, really want to be outside ... No, no, I can't recommend Haskell with a straight face, nor OCaml -- though I can certainly think about them very loudly. They're the kind of thing you pick if you don't want the experienced programmers to have in-mind clashes with things they already know.

    Frankly, I think the abstraction which might work best for SE is having a single block which acts as a Computer Core with all of the blocks which can act as functional i/o operators, everything from doors to cannons and sensors, being directly accessible. In Erlang, each of those blocks would be treated as its own process which could have messages sent to them or send them themselves, and everything on the same ship counts as being directly addressable. That makes writing code mainly about sending and receiving appropriate messages, making it very, very easy to put programs on multiple CPUs. Only inter-process messaging has to break the context.

    Anyway, thoughts. (At least I didn't suggest FORTH. All old-school MUCK programmers are relieved.)

  65. Wow, I love the idea!

    Some Ideas for components which could be accessible from a main computer:

    - Ship Controller
    (MoveToCoordinates(...), Follow(...), FaceObject(...)), SetDodgeMode(float distance)).

    - Radar
    (FindObject(...), GetDistanceToObject(...), GetObjects(float distance)).

    - Combat Module
    (GetWeapon(...), weapon.Fire(...), GetTurret(...), turret.Attack(...)).

    - Comm Module
    (SendMessage(...), OnMessageReceive(...), Broadcast(...), OnBroadcastReceive(...))

    I like the Idea of having a main computer (instead of adding code to the components) because the components could be used together.

    - An attack drone requires the radar to spot enemies, the ship controller to chase them and the combat module to attack. The drone could be programmed to flee as soon as all weapon systems are destroyed/unusable.
    - A mining ship could use the comm module to broadcast an SOS signal to combat drones when attacked.

    Additional thoughts:
    - Computer components could be destroyed pointedly to disable specific functions of the ship.
    - Damaged components could be less reliable (a damaged radar will return inaccurate coordinates).

  66. I've been waiting for this announcement! :-) There are already some Mechs standing around in my hangar who are waiting to learn to walk. Therefore i would of course prefer the version where computer components would suffice to be accessible for programming. However, if computer blocks were able to access every connected component that would be fine, too. That said, rotors really really need to be conductive. That would open up so many possibilities. As for the programming language i was a bit surprised to read that C# is even on your list as i would consider it a rather beginner-unfriendly language. IMO Python would be the wiser choice in order not to scare a way a lot of people.
    Anyhow, great to see you working on this at all!
    Keep up the great work!

    1. "Mechs standing around in my hangar who are waiting to learn to walk" :-)
      That's why we are doing this. To bring life to your creations.

      BTW, computer blocks will be able to access other blocks (through the grid)

    2. Python is no simpler than C# in my opinion. It's just what you are used to.

  67. And how will, a zero programming knowledge guy like me will be able to learn the SE programming? I hope that this programming feature will be fun, and simple, and not too complicated. My knowledge of C is ZERO.

    1. "It's about ENGINEERS! If you're not - you shouldn't play this game! WOW This is amazing, best for all times brain-needed game!"... Something like this happy engineers can answer you.

      Why not create a GAME, for some PLAYERS, not only geeks? C#, oh yeah, dreamed for it whole my life, sure. I can use it. But it isn't my vision for FUN. It is WORK. Especially for EACH BLOCK. And destroy code with block contained it, oooh yeah. So i will play in "PROGRAMMER'S JOB"? And each damn tick (60 per second - WHYY?! Who need it that often?) someone with bad scripts will cause me troubles. No open game, no way, not me. Only single or chosen friends.

      Sorry, my optimism goes down with each hardcore geek-targeted feature...

    2. Are you serious that SE is for Engineers? lol. It is a lego game, not an Engineers one. You don't play lego to build a car. You don't do like what you do in SE to build a real jet plane. I'm not an engineer, and I can't build a car. But I can play SE without any trouble. So why should Marek build a feature that will make ordinary players like me (which is many) to not able to enjoy the game feature to it's fullest?

  68. I like the idea. I think, for simplicity's sake and speed of program creation, an interface like that used on Scratch, where you have literal programming objects to drag around and connect to each other to form the basic flow of your program would be great.

  69. Interesting. A few times in the comments it's already been mentioned that this could prompt some kind of cool technocracy where some people program and others purchase and use them. I'm definitely in support of that kind of direction.

    A simple implementation for the programs could be using the existing NPC ships as the sources of programs that could be valuable. That way the rollout of new programs could be controlled over time in a "realistic survival" story mode from simple to complex. The hope would be that these NPC ships would become more valuable objectives to take down, as through them you would get not only resources, but people could look at existing programs (in scanners, guns, etc.) and "reverse engineer" the language/syntax to make their own.

    It would be interesting if you could copy the code from an enemy block onto a handheld drive, but that you'd needed to take it back to a "decrypter" or server block to actually see it as readable code. Kind of like in Star Wars how R2-D2 could hold the Death Star data, but they needed that computer on Yavin IV to actually see the useful stuff.

    What if certain blocks (cockpits? servers?) could hold location data so you could figure out where the ship's been and where the base might be? Or even just what cargo it's been loading on and off? Like a blackbox.

    Btw it would be cool if Workshop ships could get into a contest where they'd get inserted into the pool of random NPC ship spawn.

  70. Two things pop into my mind:

    A full scripting component would be fun, but sounds like a lot of work before it could be viable.

    Saving all the variables of a component or group into a Named State would make programming a lot easier for the everyday tasks.
    While in the pilot chairs, buttons could be assigned from Groups, components or the Named States, using whatever logic is most applicable.
    The toolbar could look like:
    All Doors Open,
    All Doors Closed,
    Open Hangar Bay,
    Close Hangar Bay,
    Energy Saving mode

    Selecting an icon for a named state / group would be nice as well, just use what is already available.
    A grid like the 'g' construction inventory would be awesome as well, perhaps set it to an additional console for bridge crew where the full interface would be exposed.

    Later on add a "Named State Cycle" basically a list that cycles through the selected Named States.

    Exposing the variables of components in the script allows for maximum control, but using named states reduces the amount of code alterations required to tweak some values, just set the group to a state and watch the alterations take place while editing the named state.

    Structural Integrity block that can Save and Load blueprints in locally stored files.
    This would facilitate:
    - Copy/Paste without injecting free resources
    - Smaller Workshop downloads
    - No more loading different worlds to copy that one design
    - first step to automated 3D printing
    - Detecting damage

  71. Ive made an visual example of how the programming could be made more user friendly.
    Bare in mind that this is not focused on all the posibilities that could be done by real programming.

  72. Event-driven Scripting
    I'd much rather see an asynchronous (even parallel if possible) event based scripting system. Engineer would basically write couple of callbacks and register them as event listeners. Since I assume most programs will be reactions to some conditions, it would allow use of many such simple scripts without significant performance impact.

    For more complex programs, where simple listeners are not sufficient, "Modules" could be used. Modules would be classes implementing some interface containing their own logic. It would be useful for programs with some persistent state, especially if they need to do something every game cycle. Thou simple actions (e.g. updating HUD text) every frame would still be better of implemented as a listener.

    In fact why not use JavaScript for the notation? There are several C# JavaScript interpreter implementations (e.g. and many people are already familiar with it. They would only need to learn the API you provide for interfacing with blocks and/or other game mechanics.

    Debug console
    This is a must have for any scripting interface. In-game debug console would make debugging much easier (especially for you devs).

    HTML5-based GUI
    By implementing GUI in HTML5 you would make it easily extendable both by modders and using proposed scripting system. It would be invaluable for HUD scripting.

    In-game working
    I suggest that listeners for a block with computer component in it could contain only simple listeners (and only those registered to the blocks own events). For a general listeners (e.g. listening for all proximity sensor detected events) and Modules would require a Computer Block.

    Also program complexity could be restricted by some form of resource limits (computational power - execution time, memory - source code length, etc.). More complex programs could require cluster of connected Computer Blocks.

    1. Couldnt agree more with JavaScript

    2. Couldn't agree less. short of cobol

  73. so we are talking about programming a block in space engineers sound sounds like computer craft from mc which is nice to have.some thing like it in space engineers if you thinking of add programmes can u add a block the detector player than send info to the computer to active the program.

  74. I think the main challenge here is going to be making the programming features of the game accessible to the majority of people who play the game. Programmable blocks will probably be time-consuming to implement - will it easy enough for the majority of players to use? I like the idea of the suggestion wizard - I use it all the time in Visual Basic. Hopefully in addition to that you will have an awesome help file that is an encyclopedia of syntax and concepts. I think this will add a whole new layer of fun to the game though. I can just imagine it right now. Space Engineers cyber warfare. Can't outgun em? Sneak onboard and plant a virus. Fun!

  75. Great preview :)

    Some programmable signs would be nice too :)
    Maybe something that can be directly named but also programmed with programmable blocks? :)

  76. Infinite loops is a problem but there is a quite simple solution. Simply limit how many lines every block can execute each update. If you limit the computer block to say 1000 lines (just a number as an example) and someone want more complex programs they have to distribute the program over more blocks.
    The limit could be quite high on computer/mainframe blocks and low on simple blocks.
    Then it doesn't matter if someone make the mistake and does an infinite loop because the limit would be reached and the block would stop executing until the next update.

  77. It all sounds good, but the idea of a sensor that constantly collects all different types of data seems a bit cheaty! Perhaps limiting a sensor to monitoring any single set of data at one point might be an idea?

  78. While c# is the one "higher" programming language i know best, im more a web guy, i am not sure if its a good idea to really make it part of the game.
    A lot of players that dont have any coding skills wont be able to use this feature. And depending on the extend it might become a huge feature.

    If you really add a c# interpreter you should at the same time add a place where programs can be exchanged, maybe even add premade small programs there. So players without the required skills can c&p or download there.

    If you add any kind of ingame programming you should make sure that the performance of the game, singleplayer and dedicated servers, does not suffer. Not at all, it isnt the best yet already. I have my doubts that this is possible.

    Imho i would prefer to just add more logic. Combine elements, define stuff. Give sensors to doors, add switches and make them bindable to machines/lights. You could also add sensors WITH switches, or sensor with logic, Add machines/doors/lights to sensors, when activated by player or object or ship (selectable, maybe with AND or OR) do action like on/off, set speed (+ all rotor stuff), change color, etc. But Logic with premade options, limited.

    At least i can imagine a lot of stupid things that could be done with c#, timers, threading, can this really be implemented while keeping the game safe, stable and performant?

    I sugest that before just going for c# implementation you do a pro/con list comparing this way with others, like simpler language(lua), premade logic (as descripted above), pre-, selfmade api.

  79. Also, what about using Ladder Logic to provide a programming interface as it lends itself very readily to the type of application that will be developed in game?

  80. Why not make the cockpit be required to implement programming? It's available for all ship sizes/styles and would also help protect your programming in battle...

  81. Great idea and absolutely missing feature.

    It's a big job to be done. My idea is, graphical programming with blocks.
    So have a look at

  82. This sounds like CryEngine's Flowgraph system. I would be more than happy with that!

  83. Yeah plzz ;)) Add Programming to the Game Beste Idear EVER ;)

  84. Hi !

    I might have a solution to your programming level.

    Make it like Warcraft 3 trigger editor. It's simple. Very easy. And you can do some complicated (even very complicated) things with it.

    it's almost C (you know, C, C++, C#)
    In the trigger editor you always started with an event.
    -unit dead
    -unit pops

    Have a look ^^

    By the way, autopiloted ships are already possible now thanks to Artificial Masse.

  85. I'd love this idea, I would also suggest a kind of computer screen interface that we can use things like widgets/windows like environment for displaying information and controlling.

  86. Ahh, programming...

    If I were developing this, I'd create a domain-specific language for it. (IE, a language specifically for this program.) I know that at least one commentor above recommended against this, but I recommend it for the following reasons:

    1. It gives you complete control over the implementation of the language, instead of leaving it to some third party library. Yes it means more work up front, but it gives you the opportunity to thread in more control over the execution process, since you'll be interpreting/internally compiling it. And I would recommend internal compilation, since you're using .NET 4, which has much more support for generating code on the fly (System.Linq.Expressions) than 3.5 did. More control over the execution process means you can thread in yields, breaks, etc. so that the processed code does not cause game engine problems.

    2. You can make the language as simple or sophisticated as you think appropriate. If you're targeting non-programming users, you might even eschew text-based languages entirely and use a graphical paradigm (see also Mind Rover). You don't have to worry about the more sophisticated language constructs that might be provided by third-party languages like Python or LUA. (It's a space game, it doesn't really need higher-order programming features like lambdas or class inheritence or even really classes.)

    3. The UI will likely need to provide development support structures (formatting, intellisense-type-help, etc) and that would be easier for a language you designed rather than trying to support some third party language.

    I do agree with the above commentor who suggested it be event-oriented. That is likely to be the most efficient way of handling the scripts, since you only need to execute them in response to events instead of having to constantly run them while they check whether the event happened, and you can always provide a Tick event for scripts that need to run (relatively) constantly.

    On the subject of running potentially quite a few scripts (which might be fairly arbitrary in content) I am reminded of a talk I saw many years ago by the devs for Second Life, who as you might imagine have wrestled with the same issues you'll face when trying to implement this. I think this is the video but I haven't watched it so I'm not certain:

    (Real reason 0. I loved compiler design in college and think everything can be solved with it. :) I'd love to offer to write it, as it seems like every other major project I get involved in ends with me putting a DSL in there somehow, but I doubt I could devote the time to it :| )

  87. Asynchronous API (event driven) would give much more performance and let us achieve much more. Otherwise people will soon hit cpu bottleneck wall and every program will begin with a decrementing of counter and only if the counter is zero, then actually doing something.

    As much as I hate lua, it was born to be used like this.

    Autopilots. Fighters. Ship factories. This could even get competitive.

  88. One quick suggestion: run the main function 5 or 10 times a second, not 60. There are very few cases that need that kind of responsiveness and it adds a lot of overhead for not much gain.

  89. Marek, I think it is better if you avoid to use a professional programming language like C as a feature in SE. Because we play a game, not working on a program. But, there is a kind of fun programming script that maybe you can use. For the example is the script for Blizzard's Starcraft 2 map editor (and also Warcraft 3 map editor).

    In Starcraft 2 and Warcraft 3 map editor, there is a simple script (a kind of simple programming language) that help you to make a script for the map that you're building. This script will trigger the event in the game, etc. But it is not sooo hard core like C+ or C++. And it can be fun, because that script can be easily to learn. and no body need programming basic to build a good script for the map

  90. I would suggest developing two different ways to edit, Basic and Advanced. Basic, being an easy way for people with 0 experience coding to make very simple programs. You could use friendly dragable commands and place them in a precise order. For example, you could use simple logic commands such as if and or to make simple programs such as changing the color of lights when thrusters are activated. "If 'Thruster2' equals on, 'Light2' equals green" Very simple commands such as that.
    In addition, a more advanced and useful coding interface could be implemented along side this basic one. This advanced coding would be more traditional and similar to what you proposed and would cater to more experienced coders and dedicated Space Engineers.

  91. If you want a decent example of something like this, check out 'Wiremod' for Garrysmod in the source engine. It has many examples of wrappers for GUI, HUD creation, CPU emulation, and real-time physics effects on the environment.
    Also the way they have a thing called "Expression 2" which is a standalone, copyable, placeable, self-aware model that is object-oriented and has its own editing window. And it can save clientside and serverside.

    I know I sound like I'm gushing about some other project, but if you don't already know about it, it might give you a few examples to kickstart some brainstorming. It's also open source. Mind you it's in LUA, but considering what you're doing, I don't think you'd have a problem understanding it.

    If you don't check it out, thanks for taking the time to read.

    1. I agree with this, the expression2 gate, as they call it, is very versatile and the programming method is easy to get into (it uses mathematics and if-then-else statements as it's original base, augmented by many commands to allow complex operations on multiple objects). It's also handy that you can set it up to not fire it's script until certain requirements are met (like a sensor detecting a predefined object or player).

  92. I've enjoyed reading everyone's comments. I had an essary typed up to post, but Blogger ate it and wouldn't give it back, so I'll just summarize my thoughts

    * Love the concept
    * c# is as good a language as any as far as I'm concerned.
    * I learned Lua (which I'm not a huge fan of) specifically to use Computercraft and was taught by the community. Regardless of the language used, I think you need to foster community to encourage sharing code, teaching and learning.
    * I agree with Nighthawk's comments about rather than doing everything in a main loop, use an event driven model. It would definitely parallelize better and would make things much easier to keep track of how much time each event handler is being given.
    * I would love to be able to interface with my HUD and keybindings to control nearby functionality.
    * But I'd hate to see you spend weeks on end getting everything functional when the most fun I've had is in the main game itself, I would really like to see most of the focus kept on the main gameplay (which is my biggest concern with the suggestion of a domain specific language, there's a lot of power in that, but very time consuming to do properly.)

    Thanks for an entertaining read everyone!

    1. I agree with event-driven programming as well, but not for the idea of parallelization. I think it would be better for performance. Having it simply compare everything's state for an event trigger, so the code would only "fire" when the event is met in that update, (60x updates/sec), rather than having ALL the code execute at once EVERY update. (although, the same effect could be achieved with a series of if-then statements in the main loop, then treating those statements as event triggers)

  93. Outside my problem with coding, I think the programing feature should be put into a new block and have their own GUI. Don't put it to the current control panel GUI. Just like the cockpit which has it's own GUI (which is can't be accessed from the door or reactor),

    it should has it's own GUI which is can only be accessed at it's own block; just like cockpit. Maybe a kind of computer panel and chair like cockpit model block. This way, people will have a new reason to fill their empty bridge (rather than put a lot of the same cockpits in it).

  94. Pleeaaasee! There is just so much goodness!!!

  95. And the founding idea of programmable blocks was..

    "Simplicity is the ultimate sophistication."

    It was so. And God did grin..

  96. Please add a basic programming interface for people who don't know programming.
    Preferably a visual-only flowchart interface. A click and drag visual interface, using pictures/icons, to produce a flowchart; which then interprets into a text program.

    Leave the text interface for the people who want to write advanced programs; but that's not a good way to get people interested in programming, nor is it something a larger audience is even capable of.

    I know that this is more difficult to do, because you have to design and implement a visual scripting language, but this is the only way to attract the average player into programming.

    Without something of this level of ease, this low of a barrier to entry, the average player will want to stop playing the game because the programming intimidates them. This is true even if the programming is just a secondary aspect of the game.

  97. To add on to the above comment, something akin to the old yet glorious game PlayStation One game "Carnage Heart" ( ) would make for an extremely good visual interface. Some examples below:

    The above is from the original game and it is a decently in depth programming guide. The quality is extremely poor, but if you can get past that it is worth watching.

    The above is a small overview of one of the newer Carnage Heart games (this one for the PSP/Vita) which details some of the usage and functionality.

    If we started with a visual programming interface similar to the above, it would be functional enough for pretty much all users. From there the next step would likely be making an interpreter for the visual programming language into your choice of textual language.

    Visual programming has its own complications, such as limited versus unlimited grids, how to associate grids with computer blocks/resources, how to expand grids if limited in parts, and a plethora of things that would need to be worked out. But the increased usability for the average user more than makes up for this!

  98. Programming ships in space engineers, that's a great idea.

    Mabey with that you can create bots or something that can attack you or other players.

  99. I would suggest using something simpler, like Javascript for the programming language

  100. Since you mentioned computercraft, please see pneumaticcraft if you consider implementing visual programming akin to @Guswut 's suggestion.

  101. Hello Marek,
    Do you know Carnage Heart??

    This programing system is very nice for beginners.

  102. One thing that might be fun to consider is Node for the programming engine... It's light, fast, extensible, and lots and lots of people from various walks of life are familiar with JavaScript's syntax.

    C# is great but you'll have to write a second C# like interpreted language that's not really C# and not really a scripting language. Node would be as snap to embed.

  103. wow the carnage heart is really in depth! meh on the graphical interface but a programmability element in SE influenced by would be brilliant!!!

  104. Vote #1 Lua!

    Seriously though Lua is stable, compact, efficient and flexible. Additionally it is tried and tested for in-game scripting (see: Garry's Mod.)

    I've used it in a number of my own C/C++ projects as well, the native API is very easy to work with.

  105. Dude I love this idea so much I created a pseudo code virus and hack for the game when the feature comes out

  106. Thinking it through too... why not instead of "programmable blocks" more like a star trek system. Think computer core with much like the generator connection setup and consoles that could be laid down. The consoles themselves would be the interface components to the ship's "Computer core".... You could then use the Antenna blocks to communicate to the station's larger "computer core"... Losing the antenna block could cut access to things like blueprints stored station side or the team based communication systems in game.

    Compartmentalizing the programmed "code" into modules might allow users to build trade-able items (either through the workshop or in game)... For example:

    SlickChat v0.1 - my teams communications system

    I can download it to my station core and have it update all my connected ships.

    Each modeled computer core would essentially be a lite-weight virtual machine able to access all systems attached to it either physically in the case of the local ship or remotely in the case of a far away station.

    Damage would be a straight forward model...

    VM with 100% hit points = 100% speed
    VM with 50% hit points = 50% speed

    You can even put an randomizer in that

    proc = ship.VM.getRandomProc();

    And weight it according to damage... Maybe at full health there is a 1:100 chance that a process will go down and the chances increase as damage increases. At a certain damage threshold, like say 25% the system can be rebooted, but will behave unpredictably.

    This would simulate a failing computer system. Heck you could even build in waits for communication loops out to objects that don't exist.

    1. This is a good idea.

      For me, as long as it is not another version of Computer Craft Mod from Minecraft, I'm okay. Carnage Heart is also okay.

    2. Not familiar with ComputerCraft... looked it up and it looked like Logo for minecraft... that's just a cursory glance.

      What I am thinking is this... Assume we have the objects:

      + on()
      + off()
      + status()



      ....and we had a simple construction...


      Where B = block, T = thruster, G = generator, and S = spotlight...

      I could create the following simple methods....

      fire_thruster() {



      ....also assuming the object name in the ship = object name in the programming environment.

      If we then had some sort of interface analog log a button panel and a binding system... maybe like a system boot for the VM... we could....

      panel1.button1 = fire_thruster

      behind the scenes when the user pushes button1 the system would just call

      if( button1 != null ) {


      With that base more complex systems could follow as "sensing" block are developed, like the already existent "ore detector".

  107. Oh please! Being able to route stone to a rear ejector while bulk mining would be sweet.

  108. I love the idea of programming. In the context of a mining station, it would be really cool if custom programs could be written to tell different collectors to route ore to different cargo containers... or even a sorting program could move the ore itself from one big collector.

    The possibilities are huge and could mean a great deal of new game play when you consider how it could be applied to the different types (small, large ships, and stations).

    Please do add this! :) And keep up the great job!

  109. This idea is amazing and I would love to see this implemented but i have one request:
    Can other languaged be supported? C# is not an easy language to learn. Aswell, object oriented languages are even harder and are not beginner-friendly. Though doing it makes sense and would be easier to impliment than other languages, it is worth it to try to include other languages. For example, Python. It is simple to use and it does support some object oriented programming as well as simple normal type programming.
    Maybe you can choose which language you want to use (harder to implement).

    Other than that, this is a great idea and I hope it gets implement soon.

  110. A little late to the party here, but if you want inspiration, I always like to go back to the classic tabletop RPGs like Traveller and Star Frontiers, since they actually figured a lot of this stuff out already! RPG mechanics that work in a desktop/tabletop setting are almost always perfect for sandboxed computer games as well because the people who "write" the programs in these games don't actually have to know the first thing about real-world programming languages. They just select the desired "program" from a list and go to it.

    Another excellent source that you might want to look at is something like Carnage Heart, which builds all programs out of chipboards -- a program is a simple Logo-style that walks across the chipboard, executing chips as it goes, with a directional arrow to control program flow and branching chips that allow certain conditions to take place. The huge advantage is that it is 100% sandboxed and guaranteed to proceed no faster than you allow the chips to execute, and yet appears to the end user to execute quite fast.

  111. Make a program block that is able to attach to thrusters. This way you could have a central control platform which you could set coords for and then remote control your ships. Would be very useful for miners and decoy ships. Also if you want to see if an enemy has weapons activated you could send in a small probe.

  112. Im going to ask this here, because I dont want to go anywhere near whats going on in the forums, but anyways, what will the inputs for the programs be? Obviously it will have things like the grids power usage, thruster output, ect, as well as details in your own HUD program, like you mentioned, but what about things that are input by players directly?

    You could make it so players can edit variables by going into the control panel, finding the program, and changing it there, but I would personally have a dedicated "interface block" which lets you copy paste HUD code into it, letting you make better use of the sliders, and lists and toggle-able options, by superimposing them over the face of a block. it would be like a player that was server-side, always in a cockpit, and let other people use his code.

    Thats just me guessing, but I am curious what youre thinking about doing with it for inputs.

    Cant wait for this to become a thing, though :)

  113. How about using LUA for scripting ?

    1. NOT LUA.
      C# is better,C# as the only launguage has delegates and events(it's awesomes)

    2. Yeah, Lua is very expandable and easy to learn.

  114. I think it would be best to keep the language flat an simple so that lots of people can understand it. Perhaps lua would be a good choice. Also a nice on-screen list of things my script can use/change in a list would be good, so you can click the list item to include it in your script.

    It would be nice to save scripts into loadable modules so that complex things can be abstracted away for most simple operations. It would still be possible to do complex things, just don't require complexity by default.

    Speaking as a programmer, I'd love to get others involved in code and I think it would be a great way to teach coding to others however, I'd avoid needless complexity at all costs as it may frighten off some (but not me)

  115. why can i only use 1 block? like its stuck on 1 block and i cant move it by hiting 1,2,3,4,5,6,7,8,9,0

  116. Very nice ideas coming up here... like it.
    Some kind of math-library, for doing some tricky vectormaths-stuff, would be nice.

  117. Second Life uses a Scripting Language very similar to Javascript (with some engine specific changes to it), since it is an Event based, object-oriented Language it has everything you would need. (Including an existing V8 Engine available on all platforms, open-source and with hooks for all C languages from Google)

  118. hey wouldn't something similar to scratch ( or stencyl ( be better as its more friendly to those who cant code and it would be quicker than typing code out.

  119. Something I'm noticing on the forums. Code. People are attempting to make code for this. Personally, I'm holding off until you release an API or some sort of documentation of the methods and fields that'll be present in every module (block) before I generate code. Documentation of this kind would be highly valuable.

    1. Sometimes by giving the developers psudeo-code (or even real language code concepts) it helps developers develop API's by getting an idea for "how" consumers would like the API's to flow.

      The "how" people are going to use it is often neglected when API's are designed.

  120. You should check out the Dart VM instead of a C# interpreter. Might be easier to integrate since it's already designed for embedding into a web browser or running raw source files with a JIT compiler. Similar syntax to C#/Javascript, and might be easier to work with as the typing system is completely dynamic as opposed to static, and it is optionally verbose to have more simple scripts. Garbage collected, managed memory, easy concurrency and futures. I'd be ecstatic to have such a thing included into Space Engineers!

    As for the UI, I think the scripts should be an inventory item that can be traded as such. Like a page of code that you set into an inventory slot in a block.

  121. Might I suggest using Neko?

    I think it would work really well as then you could potentially open the doors to allowing multiple languages to be used.

    Its supposed to be really light on resources on its own. All that would be needed is something to convert different languages to Neko, or just use Neko itself.

  122. Seeing how the game has sometimes trouble handling single ships way below "capital" size, Im intersted to see if the game has the potential for such reserves as to allow such stuff like programming next to all the physics and whatnot thats going on already behind the scenes.
    I can just speak for my group of buddies, but what were looking to is multiple capital ship size, fully manned spaceships slugging it out with manned smallblock-turrets, repairteams running around and welding conveyors back together, boardingpartys grinding their way to engine rooms, and all that with at least semi-lag-free 30 fps.
    the ability to mod my gui ingame or missuse my interrior lights as flasing christmas decoration is something i could happily live without for the next 3-4 years.

  123. Just revisited the page to see so many nice comments and new ideas. I love them all.
    For posteriority, my preference in lingo is Py > JS > Lua = C#.
    Taking JS would be the middle way, and might be the best world of all. Newcomers might find C# overwhelming, many very old ones however would find it overengineered.

  124. I'm kind of in the camp of something like the original Visual Basic. Object oriented, simple to learn, and easily related to specific objects or as you call them "blocks". It has all the basic programming functions and can be quire complex if required while still being fairly easy to learn. It is a true programming language. I have nothing against scripting languages though for the ease of implementing simple functions like opening doors etc. Perhaps this can be the difference between the "mainframe" concept using something like Visual Basic, and local computer blocks using a scripting language enabled for that by the mainframe so beginners can get something going. Whatever you decide on, coupled with the appropriate "sensors" this is going to be great! I look forward to learning to use whatever you finally decide on and can implement without getting grey hair.

  125. Ok first off, I lvoe all these ideas and I'm not just saying that. Secondly, I've had a lot of experience with creating in-game programs, such as ComputerCraft for Minecraft. I've never had as much fun with that game until I was able to make computers do crazy things, especially to little worker drones called Turtles.
    So here's my thoughts as far as the execution and usage of computers and programs. I'd say programs can only be edited on computers, to prohibit confusion. As far as the transferring of programs, I'd say the computer can send the program to any device within a decent radius. However, computers cannot send programs to other computers without first knowing the computers ID (created upon placing the computer) so people don't start hacking eachother elft and right. Or maybe that's a good thing, but I'd go on the side of caution and not start everyone off by being able to be screwed over, or maybe make that a server option.

    I'm also thinking any device can simply end or start a program but not open or edit it. This would stop a garble of messes from being created.

    I'm also thinking things like sensor information and batches of programs can all be stored in folders, accessable to the players. So if I'm working on my ship, and I want the readout on if engine X is recieving enough power or even reaching it, I can go into the folders in my helmet, select the "Sensory" folder, and select the sensor program I created and ahve it displayed on my HUD.

    Also a programs ability to control ship functions would be ideal. For instance, I hhave a large ship, and a smaller mining/repair ship. I open up my docking bay by running my "Docking bay open" program, fly out, do what I need to do, then ahve a sensor pick me up and automatically open the door upon picking up my ship. The possibilities could be endless when combined with rotors.

    As far as a friendly version of coding, Starcraft Campaign editor had a VERY good system of If, then, or, and, except lines, that made it easy for anyone to get into it.

    Keep up the good work!

  126. Also I might suggest the option to allow your computer to network. Like if you don't want to have a computer open to being hacked, you set the network to off, and it can only interact with components attached to the ship it's on, and not other computers. Perhaps creating a wired connection that can allow any computer to interract with one another without outside influence. The downside is that sometihng as simple as damage could completely disrupt your network. however if your computers are set to use their own version of wifi, this allows the ability for other players to hack into your stuff, but provides the convenience of wireless access and communications.

  127. As a programmer my opinion may be a little biased but i do not think limiting the programming language for unskilled programmers is a good idea. Rather, introduce makros or prefabs to help them ease in - make learning the language part of the game's experience.
    Of course, you could always define everything for an intermediate language and provide (or let the community provide) different frontends for different tastes in programming languages.

    Whatever the language will be, may i suggest supporting external editors? I think it would be a simple feature to implement (just check a file for changes) and it would offer a way to use more than one screen and allow for editing even when you have a low framerate.
    Speaking of additional screens: I think it'd be awesome to allow for the HUD code to open another window, put it on another screen and render basic stuff on it.

    Lastly - even though it is not intended as a modding system - i'd like to see the ability to spawn / modify blocks in sandbox mode. (Looking forward to fractal stations..)

  128. Hello Marek,

    I have a suggestion for how to do a first implementation of this: Programming loops are not permitted. No FOR loops, No DO/WHILE/UNTIL statements, built-ins like SLEEP, etc.

    This may sound a bit crazy. But the intent is for any program to be able to execute and complete within one update. State variables, like you said, will be maintained through updates. Conditionals like IF/THEN/ELSE, CASE, etc. can check the state variables or objects' properties, and then react appropriately within that one update. Next update, they can react differently based on updates/changes to the state variables or to objects' properties.

    Yes this could make iterating through a large array variable very code wordy. Do players really need large arrays in the first place? By encouraging complete execution within one update, you are also encouraging program efficiency mindset. And there will have to be a maximum number of code lines available in each computer block, so this supports my idea.

    Look at the alternative that unrestricted looping allows - a loop that iterates through a large multidimensional array which calls a function for each element which calls a subroutine which waits for updates on other properties which calls another loop that calls another method.. yes, programmers will do this, because they are clever.. but they are not thinking about impact on the game.

    1. Hello hellokeith, this is actually a very good idea. I will think about it. Thanks!

    2. My pleasure Marek, thanks for making a great game. I'm really looking forward to the computer blocks. Even with various restrictions and limitations, I think some very amazing things can be done in the game with your SEscript. ~Keith

    3. I feel mixed about this. While this would have guaranteed performance, it would reduce the capabilites of programming. My suggestion would be to allow scripts to "leak over" into the next game logic/physics update if it isn't fast enough. This would encourage players to build their code to be more optimized to the task.

      If you're building some custom turret tracking code, it would be wise to make it simple to run. Code that would allow it to do extraneous things like being able to hop between targets every bullet would just be too wasteful on resources, and that should be punished by making the code run across multiple physics updates. This would cause the turret to target slower and fire slower.

      The same could be said for the opposite side of the optimization route, If you're building retractable landing gear, or a retractable gun pod pylon, you don't necessarily need it to run that fast, and that could mean that players could be a little more sloppy with their code.

      I could be biased in saying this, as I've taken a few Systems Programming courses that focus on optimization, but I'd like to have full creative power in my creations.

  129. Two suggestions:

    Reactive Extensions:
    Maybe imperative programming isn't the best fit for this kind of needs. If you haven't already, I deeply encourage you to have a look at what the Reactive Extensions do in .NET 4 and consider implementing something like that, or directly that if the game runs on .NET. That would even allow for a graphical code block system, as everything or almost everything is made by concatenating extension methods that filter, project and reduce data streams.
    Several commenters have said an event based paradigm would be more proper. This is the evolution of event based programming. It would also help controlling the CPU use of programming blocks, as everything could be conveniently "Throttled" to the most appropiate pace.

    Inverse Kinematics:
    Whatever you do, please allow us to implement some IK so that I can, if I want, program some arms and rotors so that I can move the "hand" freely with WASD+QECSpace and that is translated to rotations for the different rotors.
    It would be like having a cockpit-like block move "freely" with the keyboard, but instead of using thrusters and gyros, it would be attached to a robot arm with just armor and rotors. We could use that to build welder/grinder/miner/melee/ranged robotic arms, either fix or built on some large or small ship.
    Of course, the number crunching could be left to the players-programmers to program. But at least give us the chance to have some kind of Player-Controlled block that generates inputs or events from when the movement keys are pressed, that can be consumed by some other program, that in turn rotates the rotors to make the "hand" block go where the player wants it to go.

  130. I think that to make the system easier to work with, you could have multiple separate types of "Programming Station" that are like small desks for programming, and with different types for each of the more common languages. Also a mass sensor and programmable turret would be great for keeping your turrets only killing certain targets. This might even allow advanced players to make basic autopilot systems. Also, to keep from accidentally killing your own ships, a transponder system where you can identify your faction through sending a code, would be good to have programs be able to interact with. This would make use of antennas, larger ones being able to transmit farther.

  131. Hi,

    It's very similar to the concept used in Blackvoxel for the programmable robot :


  132. .NET Developer here,
    If you're still looking for some kind of C# Interpreter, you may want to look into the Roslyn compiler. It is basically the next gen compiler from the .NET team. It is fully managed and is able to execute new code at run time, even in a sandbox context. You could basically use that and allow any of the .NET languages since it interprets them all the same (it can convert between VB and C# with nearly 100% fidelity).

    If you're open to suggestions for the object model, you may want to consider a composite design. Essentially, you would have the 'base' block, and for each component that it needs to handle, you just add them to the base object. EG:
    class Block Entity
    List Components;

    class InventoryComponent : IComponent
    class ProgrammableInventoryComponent : InventoryComponent

    You could then have the logic that handles each of these components as its own little class that only gets invoked if the object in question has the correct component. This is just something I thought of in a few minutes so it will definitely need more work to get right, but I thought you might appreciate one possible solution.

  133. I see a lot of discussion about languages, advanced programming, interpreters, code/size restrictions, looping limitations, iterations per tick and others, but people are forgetting that this is a game, and must remain accessible to a wide range of users.
    If you want to encoutrage learning, remeber this: before there is programming, there must be logic. Loops badly programmed can do more evil than good. I suggest a construction block system akin to simple algorythmic chart, or a flow chart (something i see a lot of even programmers having difficulty to do correctly). A display with the "logical blocks" to "assemble" a program can be versatile, fun and teach basic logic too.
    There is also the question of case-sensitiveness (or lack thereof), typos, errors in punctuation, language barriers, amongst others. If you provide the basic programming blocks, along with block/game specific "items" (such as a doors states and actions (open, close, display_color, status, locked, powered)), the game will have a much easier time with than with a full-blown programming language, that would require variable initializing, function coding, etc..
    Think the current terminal: you want to program an airlock, so you select both doors and a sensor, and in the program screen would be avaliable the basic programming blocks, along with the items corresponding to the components selected. It would be a lot less error-prone than typing it all (and probably faster too).

  134. I think, this is great idea, i'm new (i saw this game yesterday), but after playing few hours I loved its basic concepts and wanna make something like that (because at this time its not exactly what I want, but best of what we have).
    For this game, I advise to look at X-tension game series - there is internal script for on-board ship computers. Cool idea, except that there it's not "safe" because you can easily do simple script like "Give money to Player 1000000000000000;".
    For safety consept, I thing, great example is World of Wracraft - i think its a perfect addon system, where its not hard to make very complex UI addon, but cannot cheat. And only a few can do addons. And there more simple, but powerful macros, which can be made by more ppl. They make your life simpler, but absolutely cannot win the game for you.

    Sorry for bad English.

  135. There are a few things that people keep saying something that I don't think is a good idea. Programing Drones. It would be really neat but I think the key to take away from this is SIMPLE CODE not make an AI. Simple code to streamline the efficiency of a ship or to have better control over the ship. Not to create drone armies or mining facilities because you are too lazy to do it yourself.

    I know people will hate me for this but the idea of simple code is to control your ship.

    For example if you have a torpedo launcher that auto reloads you can make a code that when executed opens the torpedo door, turns on gravity generators, releases torpedo, turns off gravity generators, closes door, lower next torpedo, ect...

  136. I wouldn't find the C# approach difficult, but it might offer a fairly steep learning curve for the average player (i.e. no programming experience). A two-level approach akin to RPG Maker (which my non-programmer wife can design in) could work. In that case you have discrete options offered in menus that build and structure scripts without typing the actual lines of code, and then the ability on top of that to write out scripts by hand.

    I really like the proximity sensor idea. It also opens the doors too all kinds of other sensory devices, such as for light, energy output, radiation, radar, radio signals, pressure, heat, damage, etc. It would be fantastic if there were such an array of sensory options that you could plausibly build a dedicated "scout" or "research" ship.

    I think computer blocks opens a large opportunity for cool design considerations for a ship. i.e. a small/large block differential with the larger being able to store more programs, more lines of code, more sensors/blocks, more variables, etc. You also have territory for customizing your computer cores, i.e. by having small blocks for processors, memory, etc.

    I'd love to see computer power as a resource, such that a design consideration might be whether to attach additional defensive turrets or additional sensors, or expend additional resources to increase the ship's available CPU power. Or perhaps have to decide whether to write an "airlock control" program or a program to fire your torpedos... or install an additional memory/control/etc block so you can write both.

  137. Much talking about the language, but what if computers are made similiarly as IRL, meaning the block works as case, and you can then expand it/install parts. There can be:
    - multiple CPUs with only difference being speed(instrunctions per second or something).
    - multiple RAM sizes limiting how big programs can be loaded for execution.
    - multiple mass storage sizes for storing said programs and data.

    Better component costs more of course, and server admins could make restrictions to use of top components to make sure there isn't much lag.

    And of course, PCs could have extension ports for other stuff for future as well, like networking module, encryption module, control module, ai module etc.