Some general ill-informed questions about IF directions

Authoring General Design Discussions
21

Clearly this wouldn’t be useful behaviour in all games. But, again, I think that part of the problem here is that, in the IF world, ‘normal application behaviour’ remains grounded in a 1980s programming model.

From an OO perspective (for example), it seems to me that the concept

player.go_to (drugstore)

(or wherever) is always semantically meaningful, so long as movement of any kind is a valid concept in the game. Of course, it may be impossible to make this movement, and there may be side-effects of making it even if it is possible. But it seems to me that it should be possible to conceive of such an action, at least. But if your programming model is such that, at some particular point in time the only valid user interactions amount to ‘yes’ or ‘no’, and you enter the equivalent of ‘go to drugstore’, then I can see how there comes to be a problem.

As for Windows and menus and whatnot: I can see the benefits of operating within the lowest-common-denominator of user interface features. But I can see the costs, as well. Whether the benefits outweigh the costs, I don’t know.

I’m pretty sure a lot of that was wrong in 2006, and I’m certain that most of it is wrong now. It’s always been possible to save a game state (or any kind of state) in Java by serializing an object tree to file, and it’s always been possible to implement an undo, of any depth, by doing this for every turn. Even in 2006 I doubt this would have created much of a memory or storage burden.

Java doesn’t have run-time typing of primitive types, because primitive types are type-immutable. This is feature, not a failure. But it is possible, and was possible in 2006, to wrap up primitive types inside objects which are type-able at run-time, and the machinery for doing this was partly automated. Now it’s fully automated – which I disapprove of, but that’s a different matter.

I presume by the different object model what they means is that Java lacks built-in operators to express concepts like ‘an instance of X is included in an instance of Y’. I’ve used TADS a bit, and it’s OO model is, indeed, well suited for modelling simple relationships between real-world objects and doing the right thing when these objects are operated upon.

But, honestly, these things are not hard to implement in Java. Or, indeed, in any reasonably competent OO language.

22

I doubt that MJR was right about the JVM even in 2006, and probably underestimated the performance benefits of Java’s JIT hotspot optimizations (like just about everybody did for most of the last decade). Nobody’s object model is exactly like anybody else’s object model, but lord knows TADS’ object model is nothing like C’s “object model.”

shrug It’s water under the bridge now that we have reasonably high performance Java interpreters.

23

I don’t think you answered this question, which is pretty important.

The browser isn’t the “lowest common denominator;” it’s the primary way newbies start playing IF these days. (Because the alternative is telling them to download an interpreter and a gblorb file.)

How would you implement custom menus in a browser?

FWIW, IMO the right way is to ditch the parser and run the entire game with menus. But my views are heretical. :slight_smile:

24

That’s exactly my point. It seems to me that the only elegant way to handle menus, buttons, etc., is to have them implemented as native elements of whatever user interface model you’re working with. That is, native Windows menu elements in MS Windows, native GTK widgets (most likely) in Linux. And so on. It’s like trying to implement drop-down menu bars in JavaScript within a Web browser – you can do it, but nobody’s going to be fooled, and users are still going to wonder why they’re looking at a window with two menus, in contravention of most modern UI practice.

Such an approach – the use of native interface elements – is really only practicable if your VM and your underlying programming model has support for it built right in. Or so it seems to me, anyhow.

Don’t know – they don’t usually even have menus :confused: Not in the Linux world, anyway. I’d bet I could implement an out-of-game File|Save operation in a Z-code interpreter – there’s not a huge amount to save. I seem to recall that Frotz had a hot-key for it, but I could never remember what it was. The point is, the missing functionality is (I think) in the UI, not in the VM. I presume that glulx works the same way as Z in this respect. Whether this is the case for other VMs, I really don’t have a clue.

My point is that providing File|Save (or Edit|Undo, or Font|Select typeface…) or whatever, is really (I think) a matter of interpreter design. I would guess that an interpreter author could, if he or she so wished, provide most of these meta-actions without tinkering with the VM internals at all.

It would even be possible for the interpreter to provide a clickable, dockable compass-rose navigator independent of the VM or the game simply by translating clicks on that UI element into keyboard input. I mean, most (English-language) games that understand movement at all understand ‘north’, ‘up’, ‘in’, ‘out’, etc, no? But what an interpreter writer couldn’t do (I think) is link the display of a compass rose to the directions that are actually legitimate at some point in the game. That would require decoding the game state in a way that I’m sure Z (and guess glulx) would not provide hooks into.

This is just one example where I believe the game authors might benefit from a completely different way of thinking about the user interface. Of course, it won’t always be necessary or even helpful.

Just my $0.02, of course.

25

MJR is talking about the state of the JVM rather than game state; are there any Java implementations that let you snapshot the entire JVM and switch between states with save / restore / undo?

The TADS 3 compiler works in a series of passes, the penultimate of which involves actually starting up the game and running a lot of potentially slow pre-initialization code. The state of the VM is then saved to the game file, so that what players ultimately run picks up from that point.

Whether the compiler “should” work that way is obviously going to depend on your perspective. In the world of IF virtual machines, it’s a logical choice because all the VMs offer the ability to save state. But if your goal is to write an IF language that runs on the JVM, you would probably not make the same choice since it would mean forking and maintaining a Java runtime that offered that capability.

In MJR’s defense I would argue that the JVM has never been all that appealing as a target for desktop applications, and it looks like it may be DOA on newer mobile devices (my beloved Kindle notwithstanding). The T3 virtual machine is at least theoretically portable to those architectures; there are significant financial and legal barriers to doing the same with the JVM.

26

Um… I’m probably missing the point, but it’s not difficult to implement menus in JavaScript. What is difficult is integrating them with the browser’s native menu. If you don’t mind having two menus in view – one for the browser and one for the game – I don’t think there is any particular problem. But perhaps I misunderstood the question?

In my view, it would be handy to be able to specify broadly what menu actions you require (which might vary as play progresses) and have the interpreter take care of doing what it can to make them look nice. On a browser-based interpreter, that might mean building a specific menu within the Web page somewhere, and in a native-code interpreter it might mean popping the menu elements into the native menu.

I suppose you run up against a thin-end-of-the-wedge argument here. If you’re prepared to control the game by using menus, the logical next step is to steer the player character around with a mouse, and before long you’ve got Quake. :wink:

But I have to confess that, with many of the IF games I’ve played, the ability to enter natural language adds little to what could be achieved by having menus like ‘Look at->Hedgehog’ or ‘Hit->Monster->with->Banana’ or whatever. I’d bet that if windowing systems had been more prevalent in the Infocom days, the idea of controlling a role-playing game by parsing text would simply never have occurred to anybody.

27

I doubt there are any – I certainly don’t know of any. But if your game world is implemented as a nested tree of object instances – and I imagine that many would, in practice – then getting the state of the entire game world as a flat block of memory reduces to a couple of lines of Java, which is (I think) as near as makes no practical difference. For there it’s only a couple more lines to write it to disk, or buffer it in memory for an undo operation. I confess I’ve never tried this for an IF game – I’m more familiar with these techniques for passing JVM object trees over a network – but the serialization technology is entirely commonplace.

I remember the days when we used to start a slow program up and let it initialize, then force a core dump to disk. That way you could start any program in the time it took to read the core back into memory. Ah… those were the days.

It hardly seems to be necessary any more – computers are just too fast. Whether what TADS3 does is replicable in a JVM, I don’t know. There is more to the state of a JVM than the state of the objects in the heap, but often there isn’t much more. I’m not sure what benefit one would get from this sort of thing.

I’d love to discuss the financial and legal implications of porting Java to other devices, but unfortunately I have this employment contract… :wink:

Legal issues aside, I think that most of the purely technical issues that made Java unappealing for the deskop have long been overtaken by events. Compared to the time it takes to play an IF game, the JVM is quick to start. Compared to the amount of memory that most desktop computers have, its memory usage is slim. Sure, it’s slow and fat compared to C, and hugely slow and fat compared to a Z-machine. But, as you say, the real pragmatic limitations are now legal ones :confused:

28

Has anyone here tried ZPlet? It seems to pertain to this discussion. http://sourceforge.net/projects/zplet/

As for Java, it was designed from the start to be incapable of saving files locally, for security reasons. I don’t know how this was overcome, because I know I’ve seen java programs that could do that. As far as interface goes, java never had the best font usage.

Now, considering that the z-machine is in itself a virtual machine, if we had a java implementation like zplet, wouldn’t that be redundant, since it would be a virtual machine inside a virtual machine?

29

A few comments:

Glulx is event-driven (when used with Glk at least).

If having two sets of menus would be confusing in a web browser it wouldn’t be hard to go to fullscreen (F11). In a year or two we can probably force the browser to go to full screen via Web GL. The bigger question is why would you want that? Most people don’t seem to want lots of menus. Otherwise they’d use the menu-driven IF systems.

AFAIK having clickable compass roses etc is possible with hyperlinks in Glk. Possibly this just needs a bit more extension code before it starts taking over the world.

My biggest criticism of Glulx is its dependance on numbers. If I had a time machine, I’d go back and try to convince zarf to use strings as identifiers rather than numbers. For now I’ll just have to figure out a way to use string identifiers in the extensions I’m planning for Glulx.

One last issue that hasn’t been mentioned is sandboxing: the three most popular IF VMs are all sandboxed. Using standard VMs would make it harder to write secure interpreters, instead games would be individually transmitted. This is similar to the situation with Parchment currently: anyone can use a custom version of Parchment that lets them do anything in javascript that they like, but those storyfiles won’t run on the official Parchment, and never will. Eventually I may include a JS sandboxer in Parchment so that JS files could be included in Blorbs, but that’s a while off.

Lastly, running a VM inside another VM is actually a very good strategy, and that’s exactly what all the JS terps do. It’s a good strategy because the browser makers all have a lot more resources to devote to making their VMs super fast than any of us do. I expect that one day we will have a Javascript Glulx implementation that will be faster than Glulxe.

30

Mouse-driven IF is not a new idea. Legend Interactive’s games in the early 90s had a bunch of windows in the UI with clickable lists of verbs, items, and inventory as well as a compass rose and illustrations. Nowadays Quest (http://www.textadventures.co.uk/quest/) comes with these kind of features out of the box. Although mouse controls have been available, I have a gut feeling that most players still prefer to use the text prompt instead. People who want to play games that are mostly or only text don’t mind typing either. If typing is not your thing you’ll probably want to play a graphical game anyway. (Comparison to a command line shell is apt in that regard: People who are willing to use the shell are ok with typing in the commands. If you don’t like to use the shell it wouldn’t make any difference if the shell commands could be entered by clicking on them in a menu.)

I think the biggest problem with using both mouse and a text prompt is that it brings more instead of less complexity. Having a clickable compass rose doesn’t do much to help new players to play the game when they still have to use the text prompt to interact with the game (in most games you need to do more than just move between the rooms). And since you have to learn the commands to play the game anyway, it’s much faster and easier to type N than to move your hand from the keyboard to the mouse, move the pointer on top of the compass rose, click, and move back to the keyboard. Picking the commands from menus or lists is cumbersome and limits both the author’s and the player’s freedom.

This is not to say that mouse interaction would be useless in IF. I think there just hasn’t been enough experimentation so we just haven’t found a good way to integrate mouse controls with the parser. Also, touch screen devices like smartphones and tablets have changed the game in this regard as well. What doesn’t work with a mouse might feel very natural with touch controls and vice versa.

I’ve often wondered how a system like in the early LucasArts games would work: you’d have a small fixed list of verbs and you could first click on a verb, then click on a word in the story text. The available nouns might be highlighted in the text. (If someone knows of a game that does something like this, I’d be interested to know. Many games have a huge list of verbs or a context-sensitive verb list; this would have somewhere around 6-12 fixed verbs.)

31

I don’t think I’m suggesting running a Java-based IF interpreter via the Web. At least, not embedded in a Web browser as an applet. I suppose the ability to do this would potentially be an advantage, but I’m really thinking more of a desktop application, run the same way I’d run, say. Gargoyle. Such an application would have no difficulty in managing local files. An application of this sort could be delivered from a Web page using the Java Web Start mechanism, or just delivered as a file with the usual instructions “download and double click”. Both mechanisms would require the end user have a Java JVM installed, or be prepared to install one. It’s not a no-installation option like something based on JavaScript could be, but it’s no more an end-user burden then installing any other desktop-based IF interpreter would be.

To be honest, it hadn’t occurred to me before this discussion that the need to install desktop software (or mobile software, or whatever) would be off-putting to users. As others have said, a no-installation requirement pretty much limits development to JavaScript, or to something backed up by an application running on a web server. Parchment gives an idea what can be done with JavaScript in this area but, being tied to Z-code, it’s still based on a 1980s user interface model (for better or worse).

32

I think that’s right – I don’t think there’s necessarily any advantage to being able to click menus to do ‘Ask->Fred->About pony’ rather than simply typing ‘Ask Fred about pony’. There may even be a disadvantage. Except in systems that don’t have a keyboard, or where keyboard-style entry in inconvenient. Um… which increasingly means just about all commonplace computing devices :wink:

Is it possible to envisage IF that uses no keyboard entry at all, and still falls into the category of things that IF enthusiasts are prepared to regard as IF?

But that, I think,is a different matter. I’m really thinking of ways a more modern user interface could support text-based entry, rather than replacing it. A good example, I think, is that map-based navigation that many of the old Infocom games had – both the genuinely graphical in Zork Zero, and the text-based in Beyond Zork. It surprises me how difficult this seems to be t implement with the systems that are currently available (unless I’m missing something, which would hardly be unusual). This existence of features like this in the old games like this did not mean that they weren’t primarily text-based, and you could play the games without using them.

I’m speculating here, but I wonder if people who play and write IF a lot develop cognitive skills that render these graphical aids unnecessary? Personally, I find it difficult to read a textual description of an inter-connected set of locations, and build a mental model of how to get from one place to another. Mind you, I have this problem in real life as well. :slight_smile:

33

Except that Parchment also supports Glulx. And in the future it will support Vorple too (or something like it.)

Also are you aware of Glimmr or some of the automapping systems?

34

But glulx also follows an 1980s model of user interaction. There is (so far as I know) no way to make glulx create or use any of the native user interface elements that most modern graphical environments provide. Case in point – many glulx games provide help menus and such-like, where the menus are actually drawn on screen in text, like a 1980s console applications. But most modern computer operating environments have menu support. Why should a game engine have to draw them on screen and end up with the look-and-feel of a Commodore 64, when everything that’s needed to make a nice job of this kind of thing is built right into the OS? There’s no way using glulx (so far as I know) to pop up a dialog box with a couple of text entry fields in it. I don’t believe it’s straightforward to draw any graphics on screen other than what are provided as image files.

The great thing about glulx/Glk is that it can be implemented on just about anything with a CPU and a screen. But that generality is achieved at the expense of ignoring everything that’s happened to user interface design since the early 80s. To assume that there is a more sophisticated user interface available does, of course, limit the system to environments where that is the case. I can see how many people involved in IF might think that the costs outweigh the benefits.

I’m aware that they exist. Coming at this from the outside, and as a programmer, my initial impression is that I could implement something myself in Java, or even C, more efficiently than I could learn to use any of that stuff. I’m not knocking it – the point is that I know Java and C already.

I can throw together the user interface I (think I) need in Java or C in about ten minutes. What I can’t do in ten minutes is implement all of the actual IF stuff – I can’t code a world model or a natural language parser in a lunchbreak. What would suit my purposes would be a stable, well-documented, Java class library for doing that stuff. I guess such a thing doesn’t exist, and I guess that if I developed it myself nobody but me would be interested.

35

If it turns out to be much better than what we have now, I’m sure people would become interested. I say go for it.

36

Is there any desire for this? Native UIs aren’t exactly known for their good typography…

It would actually be very easy to add in an API to customise the terp’s menus. As Juhana said, go ahead. But don’t be upset if no one wants it… maybe wait until someone else has expressed interest?

However I wonder if all UIs are rather antithetical to IF in general.

37

I know Quest has already been mentioned, but I thought I’d point out that the Javascript in the UI is completely customisable per game.

The “out of the box” implementation uses this to implement hyperlinked object names showing drop-down menus, but you don’t have to enable this.

I have created a demo here: play2.textadventures.co.uk/v5/Pl … tyle=fluid

This shows another use of the HTML/JS interface - this time it implements two input boxes, one for each character in the game. It also has custom output, as the response must be written to the correct half of the screen.

This two-way interaction between the game and the HTML/JS means you could create any type of UI you wanted. I’ve not really had time to fully explore the possibilities of this yet, or to make any of this look particularly stylish, but I think all the fundamentals are in place to create something interesting.

38

Check out Glimmr Form Fields – I don’t think the example Erik provided is a pop-up dialog box, but I think it wouldn’t be too hard to adapt it once you know how to do things with multiple windows. (Which I don’t.) Though as Erik says, the problem is coming up with a context in which this is actually useful.

Anyway, though I really don’t follow a lot of this discussion, I agree with others that this is very worth pursuing. A new idea can take off in the IF community – look at how quickly Parchment has spread.

39

I guess they’re antithetical to the way IF tends to be currently understood.

40

Just invent and program your new system and then bring it back to this forum, post-haste!