This is a response to a blog post Michael put on Gamasutra. This may not be the original:
http://gamasutra.com/blogs/MichaelSamyn/20150612/245971/Infinite_machinations.phpIncidentally I found this link because lately Michael decided to upend his new Patreon page (I'm never quite sure what to call these) and lamented that he was swiftly brow beaten upon publishing his first short article ... which seemed very tame to me. Time will tell what will become of his Patreon, but if anyone saw evidence of a real backlash, please PM me (The links that is. I couldn't find anything that would cow me in his position.)I develop a "platform" called Sword of Moonlight. It lets inexperienced people make games as easily as possible. It's on course to be the 3D equivalent of "RPG Maker" only I think the level of quality it represents will outshine the video game industry itself.
In Michael's post he wants graph based visual programming. 3D design tool suites have always provided something like this. I've worked on things like this more than once in my life. Not with them (I've done that too) but on such systems. They may be of some modest use to highly experimental game developers. But I think it's almost too soon for real "experimental games". And I don't think these kinds of systems are what we should be striving for.
I make immortal software. I want to share how SOM (Sword of Moonlight) works, and invite everyone to propose other/better/counter ideas in the same vein, without getting too deep into gory details. SOM was originally a product of From Software, but I guess it is abandon-ware... still I wouldn't be surprised if it is the most beloved thing to come out of From Software to many of the people who worked there... especially in the 90s. From Software is presently well-known for "Dark Souls". So expect a kind of mainstream crossover to come out of it. We have a strong opening game for it, made by an artist that I have difficulty communicating with, but it looks very good, and plays amazingly, both thanks to myself and his strong artwork (it looks like Ico/SOTC, which looks a lot like King's Field IV, except for the eyes are like in Etruscan frescoes, whether intentional or not. It's set in ancient Scotland; historically accurate customs wise but with added fantasy elements. Maybe I can get him to make a game set in an Etruscan fresco world next!)
How SOM originally worked is dead simple. I've added some conceptual layers to it. It has a 3D world of course, conceptually built out of 2D tiles. I don't think it has to be that way (using the same proprietary file formats) but that is so simple for people to use that I'm very fond of this approach. I intend to add a way to link the worlds so the tiles can be built up vertically in layers, but not as a 3D cube-grid, just arbitrary layers of interwoven 2D grids. The tiles can rise and fall...
And on the tiles that have landscape/architecture like models built into them you can place interactive elements, and then associate one or more programmable "event" with an element (it's also possible to not associate an event, and I've added the ability to setup worldwide (trans-tile-grid) events, which was kind of a glaring omission from its original repertoire.)
This is fairly bog standard. Each event can be activated in any number of ways. This is a high-level system, so these rules are built into the software itself and you need only select them from a menu. An event has multiple loops, and inside the loop the event can switch to a different loop, or it can switch another event to a different loop...
The basic unit of the loop is a program. It can contain IF/ELSE style branches, but that's all. There is a battery of numbers that can be modified inside the loops and represent the state of the game's scenario. How this may be different from a graph based visual programming system is the "events" are embedded in the world, and the system is essentially flat. It has to be welcoming to newcomers who are afraid to death of programming!
Here is where things get interesting. The program is built up by dropping modules into a sequential stack. There is no way to jump around the stack, only to advance to another stack by the event switching to one of its other loops (a loop can be a character that repeats themselves for instance)
Originally all of these modules were specialized to perform predetermined functions. However this approach doesn't scale well. So what I've done is to take the first two modules, which are used to output text, and to output slightly more customized text, and said that from hereon out a loop just outputs text, and the secondary text module is used by macros (ie. a template) which is text that you can define drop in inputs for, that are defined/imported as needed on a macro definition screen (so that the original instruction set can be emulated by macros)
Best practice now is to not output text, but to output a link instead, just like a WWW hyperlink only just any text will do. Although not any, because the link system works around a legacy condition, namely that the link-text has to be Shift-JIS, which is a kind of text that was used by the Japanese WWW for a long time.
The link text can be a simple description of a scene, like in a screenplay. But like a hyperlink it needs to be permanent. Even if it has typos it isn't a big deal, because it's a link into a transcript, or what I call a gameplay (think screenplay) which is a gettext MO file, that is the standard for translation used on Linux and by most websites on the WWW. How gettext works is it takes a bit of text and uses that as a key to look up the translated text. So this way your short description of what the scene is about, or what the text is supposed to do, is expanded to reveal the real text that appears in-game.
Late last year I began work on what is really just an elaborate gettext MO file editor. I won't get into the details, but it's now the core/main tool of Sword of Moonlight, and it has a heavy focus on literature and translation. It organizes the MO file like an outline, like we are taught in the United States, how to plan an essay or story...
It also optimizes the MO file for memory-mapped-file access, which is a nonstandard feature, and makes it so that users only have to work with one file instead of the PO->compiler->MO file approach promoted by gettext. PO remains an exchange format.In fact, every step of the way I've based my systems to help people make games on things that we are taught in primary school, so that everyone who graduates high school in the United States should already have all of the skills they require. This breaks down in three basic ways:
1) you have the outline layout. The built-in hierarchy is very loose, so you can decided how to best organize for yourself. The editor also functions a lot like Windows Explorer so you can attach dates and names to individual items in the outline, any kind of meta data you can think of, and collate the items that way like the details view in Explorer. You can even use this as a planner and way for collaborators to communicate since it's a lot like an email client as well.
2) the text is actually XML. Which is like HTML, which I assume people at least have the option to learn in high school. If children are given any exposure to programming, I'm assuming it's in the form of HTML, which is really more markup than programming. Because of the confederated nature of a MO file, the XML is actually called EXML, or Embedded XML (Ex is used to denote extensions for SOM, so this is an in joke) which is optimized for having lots of micro-XML documents instead of one big EXML document owing to how each micro-document is pulled up by one of the links initially embedded within the 3D world itself. Like HTML there is both text and markup, and so its possible to make a pure-program block of text by simply only including markup, so that no text is emitted, and so no text appears in the game, just as how text works in HTML/on webpages.
EDITED: The meta data goes into the head of the XML and doesn't appear in the editor. I just want to stress that inserting/defining meta data isn't the body of the text that is edited. Although there is markup for inserting figures, pronouns, names, etc. into the item body.
3) like HTML has JavaScript, I've developed a much simpler system better suited to high-level game development that works like a calculator. It's a purely functional programming language making it ideal for game software, and keeping the games in order (I'm always thinking about how to tie the authors' hands so they can't make something broken even if they try to.) Of course we're all taught how to use a calculator in school. This form of programming lets authors define complex mathematical functions (everything a calculator can do is there, so even complex numbers, and it uses calculator syntax.) Just like the basic single dimensional bank of numbers used by the event system, the calculator system lets you define banks of numbers/functions, so that a lot of the time it's best to think in terms of "lookup tables" and it exposes the game scenarios internal state as one such table (SOM calls these "counters" based on the description of the simple computer:
https://en.wikipedia.org/wiki/Counter_machine)
The calculator like formulas are defined inside the extension files, which are INI files, in the [Number] sections or directly within the HTML like parts of the game script like embedded JavaScript. HTML isn't used for text formatting since it's really bad at that. Microsoft's Rich Text (RTF file) is (think like Wordpad.)
I believe this is the ideal context for artists programming game scenarios. The problem is this is all very high-level, and it needs a basis that is high-level to strap onto. Much more high-level than Unity or Game Maker or anything like that. Every kind of game really needs its own high-level framework (or at least one to choose from) although there's probably no reason you couldn't use Unity or Game Maker to make a higher-level platform than they themselves are. Either way the core MO editor I described is completely independent of everything else Sword of Moonlight does (that's kind of the point, to be language neutral text-wise) and I'd recommend it to anyone making a literary game... although fair warning: I've pumped six months into it, and it can probably use another round of upgrades before it's ready for everyone to adopt it wholesale (ie. it's PO-edit on steroids. Source code for using the MO file in-game is tiny.)
In conclusion, a flow chart might look alright, but simple markup embedded within a literary structure is probably much easier to work with, especially for novices. Lines flowing everywhere like a circuit board isn't anymore intrinsically human than a corpus of written code (I'd wager it's less so, which is why programmers mainly work like book writers, even though it doesn't appear that way from the outside to non-programmers)
EDITED: For what it's worth, the text editor provides a text-server, so the text can be edited without closing out the game play session. Changing the events in the level-designer (not the script) requires a game restart, but I think just reloading the current map/level should also work (it would be an improvement to have something always on like Quest3D.) Using links, if some text appears more than once throughout the game world, the link can take its place in all instances so the real text only appears in the script in one place (this was another problem with the original system, as well as arbitrary limits on text lengths.)
The same text is reinterpreted every time it appears/is accessed by the game. There's no real overhead to that. The calculator like formulas are compiled/reduced (so that only variable terms remain. Extensions also use these to change themselves on the fly, for custom game-y formulas, or changing fundamental parameters like the dimensions of the avatar Alice in Wonderland style.)
(The MO file not only translates the game, but the entire project itself, so that combined with language packages for the stock text that tools use, even the text that doesn't appear in the game gets translated, so that there can be collaboration between people without a common language, or people who prefer different languages/jargon/writing styles--not limited to teammates since players/would-be-authors are also encouraged to pick up and run with the projects themselves (SOM is neither commercial nor non-commercial. It's just there and you can do anything you want with it whoever you are.))
