About game development systems
Posted: Fri Dec 16, 2016 4:36 pm
In the op-ed supporting keeping Hugo in Wikipedia I took an educated guess and said there were four problem-specific languages for implementing Interactive Fiction. So, I can say that there are (in alphabetical order) ACK, AGT, Hugo, and TADS. Have I missed any?
I noted that before you had these problem-domain specific languages all you had were using General Purpose langiuages (usually C, Fortran and Basic) and writing the adventure game as, essentially, a data-driven application. And I suspect a large part of the game has to do with handlng the parsing of the command input. If you've ever done text processing in a language that doesn't do it well you can know how painful it is., The first two biggest developments in IF were Colossal Caves and Dungeon (which spawned Zork) and both were written using Fortran (the former having lots of ports to other languages including finally to Hugo and possibly other IF authoring systems.
This is the real benefit that a problem-domain specific system gives to the designer of something that uses it: the system/language, and to some extent the support libraries, do a great deal of the "heavy lifting" of the mundane tasks, allowing the game writer to concentrate on the story they want to tell as opposed to the mechanics of handling the implementation of the command processor and verb logic.
Note that I said "problem-domain specific system" and not "problem-domain specific language." Application program themselves are tools to handle a problem in a specific domain, but a system - a tool that provides multiple features to solve multiple problems in that domain - can be extremely useful to someone who wants to solve some problem in that domain. Even if the problem is only "killing boredom" or "having fun" or it's "assisting in writing something" whether that something is a piece of Interactive fiction or merely a non-interactive work of fiction.
Having written two complete books and partially finished half a dozen, I note that the word processor - a problem-domain specific system/application for producing documents - performs the functions of providing fonts, sizes, formatting, paragraph alignment and printing of the document. All the person has to do is write, and occasionally mark the text for special handling.
This is far better than it was late 1970s when all you had was Runoff, where you typed in text, then you put dot codes like .BR, .P and so on to mark text, similar to the way people wrote HTML by hand when they first started creating websites. And that too, is another place where problem-specific domain applications like, well, BBS software and web publishing applications like Wordpress made that job easier.
Point remains, that seriously writing a good Interactive Fiction story is still quite a bit of work, but if an IF domain language takes up about 25-50% of the work of implementing an IF game, that's still a lot of work the game's writer doesn't have to do.
I noted that before you had these problem-domain specific languages all you had were using General Purpose langiuages (usually C, Fortran and Basic) and writing the adventure game as, essentially, a data-driven application. And I suspect a large part of the game has to do with handlng the parsing of the command input. If you've ever done text processing in a language that doesn't do it well you can know how painful it is., The first two biggest developments in IF were Colossal Caves and Dungeon (which spawned Zork) and both were written using Fortran (the former having lots of ports to other languages including finally to Hugo and possibly other IF authoring systems.
This is the real benefit that a problem-domain specific system gives to the designer of something that uses it: the system/language, and to some extent the support libraries, do a great deal of the "heavy lifting" of the mundane tasks, allowing the game writer to concentrate on the story they want to tell as opposed to the mechanics of handling the implementation of the command processor and verb logic.
Note that I said "problem-domain specific system" and not "problem-domain specific language." Application program themselves are tools to handle a problem in a specific domain, but a system - a tool that provides multiple features to solve multiple problems in that domain - can be extremely useful to someone who wants to solve some problem in that domain. Even if the problem is only "killing boredom" or "having fun" or it's "assisting in writing something" whether that something is a piece of Interactive fiction or merely a non-interactive work of fiction.
Having written two complete books and partially finished half a dozen, I note that the word processor - a problem-domain specific system/application for producing documents - performs the functions of providing fonts, sizes, formatting, paragraph alignment and printing of the document. All the person has to do is write, and occasionally mark the text for special handling.
This is far better than it was late 1970s when all you had was Runoff, where you typed in text, then you put dot codes like .BR, .P and so on to mark text, similar to the way people wrote HTML by hand when they first started creating websites. And that too, is another place where problem-specific domain applications like, well, BBS software and web publishing applications like Wordpress made that job easier.
Point remains, that seriously writing a good Interactive Fiction story is still quite a bit of work, but if an IF domain language takes up about 25-50% of the work of implementing an IF game, that's still a lot of work the game's writer doesn't have to do.