15

I'm currently working on a space-based sandbox game which will heavily feature the ability to custom program your systems. I want to implement this in a way that is both

  1. accessible,
  2. powerful (bare minimum would be turing-completeness)
  3. fast to code in.

Text-based languages generally only satisfy the latter two requirements, and while it's not to difficult to design a visual language which satisfies the first two, visual languages are a pain to program in due to requiring extensive mouse use. While there are some very accessible text-based languages, I want complete non-programmers to be able to ease themselves into programming.

Dimitriye98
  • 153
  • 1
  • 7
  • I'll be surprised if anyone can actually give you an example. Cause I really do think this needs some extensive research ( such as how humans apply logic and what not, psychological factors whatever and all these human centered stuff) – Sidar May 30 '13 at 05:51
  • 2
    No one mentioned Scratch? – Russell May 31 '13 at 05:06
  • 2
    I'm not going to suggest a close vote, but I want to point out that this falls pretty handily into the "If you can imagine an entire book that answers your question, you're asking too much" category of questions not to ask from the FAQ; this is a Very Hard Problem, and while people here can offer advice, this is a problem that's likely beyond the bounds of an SE site to solve. – Steven Stadnicki Jun 06 '13 at 23:07
  • It's worth noting that Turing-completeness can be achieved by Conway's game of life, Minecraft and other such systems not designed for programming. – Will Oct 28 '17 at 15:21

5 Answers5

10

Really, the only way to have all the features is to implement multiple interfaces. Accessible and powerful are often two ends of a spectrum. The easiest way to do this is to implement a powerful system, that has an additional interface to allow beginners to interact with the system in a intuitive way.

Allowing for a system that allows beginners to program visually, perhaps something similar to the Lego Mindstorms programming tools:

enter image description here

Where there are drag/drop components. The components have inputs and outputs. Components can be simple things like AND, or OR gates, or more complex like a test for nearby enemies.

Ideally the visual representation should be compiling a written language script in the background. This offers a powerful tool for learning the language too. If a beginner can "write" their program visually, then read the code it produces they're far more likely to understand it and be able to modify the code produced. Eventually being able to write more powerful code than the visual tools alone allow. This fulfills the requirement of easing users into programming.

The backbone of the system, of course, is a written language. The visual tools are just to give users a fast way to program something simple, and allow for beginners to get started.

The written language allows for advanced users to do advanced things. And you can even allow users to create their own components, by making custom scripts. Then they can re-use components they made in a quick and easy interface for fast programming.

Good luck! Sounds like a fun project.

House
  • 73,224
  • 17
  • 184
  • 273
  • Thank you for the explanation. I was actually thinking of doing something like NXT-G myself, only I know from experience how difficult it is to make complicated programs in a language like that. I love the idea of converting visual programs to code, allowing players to go back and edit their programs textually when they're more experienced, so I'll likely use that. – Dimitriye98 May 30 '13 at 18:51
  • 1
    Beware that its easy to generate some script code out of a graphical representations but very hard to generate a (meaningful and readable) graphical representation out of a script. So you will probably end up with a very restricted own scripting syntax. – Imi May 30 '13 at 19:28
  • 1
    It's unlikely you'd want to implement script->visual for that exact reason. Stick with visual->script. – House May 30 '13 at 20:51
  • Macro blocks (blocks which provide inputs/outputs and the ability to place abitrary blocks inside) can be used to provide hierarchy, encapsulation and reuse to ease the creation of complex programs. Just make sure you can't place macros inside macros or you detect such cases... I know at least one progam which fails to detect such infinite loops. – Exilyth Jun 01 '13 at 13:08
5

You might want to have a look at Google's blockly, they combine the visual elements with recognizable programming terms whilst maintaining a fairly decent level of accessibility.

enter image description here

You can have a look at the Maze demo for inspiration, many of my non-programmer friends were capable of getting most of the way through the puzzles using it, satisfying at least some of your criteria in effect.

Quetzalcoatl
  • 196
  • 2
  • 8
  • Interesting language from accessibility point of view, however programming in it is very slow (I just tried)... – Pasha May 30 '13 at 18:22
  • @PashaS Indeed it is, I guess thats part of the price you have to pay to try and get the best of both worlds. – Quetzalcoatl May 31 '13 at 09:22
4

I'm surprised this hasn't been mentioned before, but MIT's Scratch uses a block interface that is fast to code in. It allows users to create their own functions and can get surprisingly complex for a language that was built to teach kids how to code.

Stencyl is another example of block coding that does something more similar to what you're wanting. Coding with blocks like these is much more efficient and less time-consuming than visual programming interfaces like those used by Lego NXT. Stencyl allows users to code in either Actionscript or blocks.

I apologize for the lack of pictures, I don't have enough reputation to post images yet.

Flaxbeard
  • 141
  • 2
2

BPEL programming language has visual representation and many tools that work with it. It is a workflow language, not a programming language, but it is turing-complete. It is verbose, but it is easy to write for both programmers and business people and it's easily translatable from visual to textual form. I don't think it would make a good game-language, but it can serve as a source of inspiration. And given the amount of BPEL engines and tools, it should be possible to reuse some ideas and/or code.

BPEL-like language will not feel like programming, more like routing and connecting systems. So you can have a targeting system connected to a gun system with some logic in between.

MartinTeeVarga
  • 2,839
  • 20
  • 48
  • +1: While I wouldn't advocate BPEL itself, its approach is exactly the answer I would've provided. Highly regular language that is both easy to represent in text or visually and which focuses more on event routing/response than more "normal" programming paradigms. – Sean Middleditch May 30 '13 at 17:21
1

Consider this approach:

  1. Make sure, your script logic is expressable in simple rule-based mechanics. For example, you have "Trigger" that occur during gameplay associated with "Conditions" that must be fullfilled and then "Actions" are executed (shamelessly stolen from Starcraft 2 Editor).
  2. Then provide an UI where you can drag'n'drop some predefined Actions/Conditions/Triggers around and so construct 90% of the use cases people usually want to do.
  3. Now get some powerfull and popular scripting engine integrated like Lua, Python or C#
  4. Finally write a couple of dozends of these Actions/Conditions/Triggers yourself in that language. Make sure the customizing user can copy-paste, edit and integrate these and new Actions within your drag'n'drop editor easily.
  5. You probably want to be able to parametrize your Triggers, Conditions and Actions and so you need a couple of more primitives than these three, e.g. "GameObject", "Position", "Number" or "String". In the UI, you'll need some dialogs to assign these parameters, but that's still a lot less work than if you would have to be able to construct whole scripts via UI operations.

That's about the quickest way I can think of to get all the candy with no too much pain. You get the click'n'drag noobs as well as the vim-geeks on board. And if you keep the mechanics simple (e.g. Trigger -> Condition -> Action), then you don't have to spend the man-years in developing an UI for an powerfull and still easy-to-use graphical script editor.

Some examples to clearify what I mean:

  • Trigger could be: "Game Framework Initialized", "Game loaded", "Unit created", "Unit destroyed", "Player damaged" and so on. Triggers usually have some parameters (e.g. Unit created gets the GameObject that has been created)
  • Conditions are all standard boolean and basic arithmatic conditions (and/or/not/equals/greater...) plus some typical conditions you find in your game like "Unit is at full health" or "At least two Player are connected". Conditions usually have parameter which the user need to fill in (using UI)
  • Actions are scripts that also may take some simple parameter. like "Pan the camera to XXX", "Kill Unit Y", "Game over", "Execute Trigger" and "Call Actions X, Y, Z... in a sequence"
Imi
  • 1,134
  • 1
  • 8
  • 13
  • Note that the programming is for computers IN the game, not for plugins. Thank you anyway though. – Dimitriye98 May 30 '13 at 18:52
  • I see.. that sounds like an interesting game approach ;). Have you looked into similar games like "Code Hero" or "Garry's Mod" which try to provide coding capabilities without breaking game immersion? Anyway, you can still salvage my basic advice and split the problem into scripting and UI parts. Good luck with your game. :) – Imi May 30 '13 at 18:59
  • Well, coding will be done on in-game computer consoles, which shouldn't break immersion too much. Though users who want to will be able to code out of game then import the code to their save or the server they play on. – Dimitriye98 May 30 '13 at 19:03