Well, it’s like saying that the C source code of a DSL implementation looks like typical C, not that the DSL syntax itself looks like C.
tayruh was responding to pdxiv, who said “that’s what web code should look like (in my opinion)”.
And the point was that tayruh did not find it obvious why pdxiv considered this JS code especially exemplary in distinction to usual JS code.
With “web code”, pdxiv was not referring to Gruescript, but to the JavaScript source of the Gruescript system. He said that directly in response to Robin’s post about the repository containing the JavaScript source for the Gruescript system.
And pdxiv actually agreed with tayruh’s assessment and further explained what he had meant, by following up the “web code” comment with “It’s enjoyable when something is quick to read and that runs quickly without many external dependencies. It’s a work-related injury. I’m used to seeing heavy frameworks”.
And the later, closely related discussion also mentions jQuery.
All these comments refer not to the Gruescript syntax, but to JavaScript.
I really thought they were talking about the Gruescript itself. Sorry to everyone involved if it came off as some kind of knee jerk defense of OP. I truly wanted to understand.
that colon/ternary debate is akin to a debate about Fortran and C… separating greater and lesser (with an equal in the middle…) with a colon is the syntax of Fortran’s arithmetic IF:
IF (X) 100,200,300
incidentally, Fortran IS the very first IF programming language…
Fortran does? I don’t remember it. It’s all about .ne. .ge. and all those dotted operators. If then else endif is the structure. In fact, I don’t know any language that works like you say.
It’s more logical/consistent to say
IF (X) LESS, ,GREATER
Instead of using colon. If that’s the structure you want.
Edit:
Speaking of which, Level9 has something like this:
(var,str1,str2,str3)
Where the variable determines the string displayed, and it can be more than 3 as well. I don’t remember the exact syntax, but I think that’s pretty neat.
Make an “admirable” game in the system (not just a technology demo). Historically, the first “admirable” story for each now-successful IF platform was typically either written by the platform authors themselves, or directly funded by them. (Twine’s first admirable story by Anna Anthropy is the only exception I’m aware of.)
Make it work on the web, and especially on mobile web. People keep sending around systems that only make games that work on desktop PCs; this is especially bad for IF systems developed in Python. (It’s even more rare to have a game development system that lets you develop on mobile.)
Make a tool, not just a language. “You can implement your game in any text editor” is not as appealing to IF authors as some people seem to think it is.
Nothing about Graphic and Sound? Even with Inform, people keep asking about showing graphics, maps or otherwise. Certainly Twine features graphics as well.
As far as Tools go, I sense there’s a preference for Graphical Tools. Even mapping, where it used to be just index cards suffice.
That’s an interesting point! I recommend that @robinjohnson port Detectiveland fully to Gruescript, including graphics and sound and whatever else would be required to make it work.
(I assume that today you’d have to do that with the js “cheat” command…? But anything Detectiveland does should be doable in Gruescript without cheating.)
Interesting problem. As soon as you’re telling Gruescript to refer to something external like an audio file, or an image, or a font, the author is going to have to upload their music/images/fonts somewhere. This probably also means they’re going to want to do their development offline. (Unless Gruescript, and the games it produced, lived on a server that they could upload the music/images/fonts/ to… which I’m not doing.)
I could put in some commands that play a sound or show an image, using a relative url (probably declared in the header-ish “game block”.) My reservation is that I have trouble knowing what someone without a technical background is going to think of that. As you’ve said to other tool creators, nobody’s going to learn technical skills in order to use my system. As soon as I write “put your files at this relative path, and set your browser to allow local file access, and develop offline” in the manual, suddenly it feels like I’ve made Gruescript less accessible. And the people who could do that can probably do it anyway by saying raw HTML, or cheating with js, or just hacking around in the exported file.
Maybe the answer is to make those commands and document them in a technical appendix. Hmmm.
I would definitely recommend adding those commands.
As for how they would work in the tool, the ChoiceScript IDE “solves” this problem by asking the user to login with Dropbox and synchronizing files with Dropbox. You can then provide a UI to upload an image that just drops the file in the Dropbox folder; when running the game, you serve it directly out of the Dropbox. When exporting the game, you can generate a zip containing all of the files, or you can a single-file HTML file containing all of the assets embedded as data: URIs.
EDIT: Dang it! I opened Detectiveland one too many times today and now I’ve got the Main theme thoroughly stuck in my head.
Harry, the .ne./.ge. you cite is the logical IF, the one I cited was the arithmetic IF, now deprecated (don’t ask me why, but I have around 1960s Fortran IV/66 listings…)
This is an awesome tool as I said in Twittter, finally someone that gets what we need nowadays on the mobile world.
But I wonder why the menu is below and the in game texts above, as in the old scott adams games is the other way, I used to think about the menu as the image of the game room and the menu words are the objects inside, in all images the text is below the images. Maybe add the possibility of moving the menu up as an optional user costumization?
Also when running the games some messages are duplicated like the “you are in…”, “you can also see” which is redundant and it would be cleaner and less cloggy if it shows only in the menu. That might be because of the game design though.
So, I modified the HTML to see how it would look like on Scott Adams classic style with its traditional line break separating the history from the menu. What do you think? The “You’re” is a little to the left and I couldn find how to move it to the right for alignment:
Nice work M4u! It occurred to me that it might be an interesting exercise to port one of Scott Adams’ games to Gruescript. He’s just come out of hospital though, so it might not be a good time to ask him…
I made a similar port before, so I can tell you the result is very nice. However, it is necessary to redesign some parts of the games in order to “hide” the verbs, not giving away the answers. For instance, a trick, in Adventureland, instead of showing the command “say bunyon” on screen, put the word “bunyon” in the axe and add the verb “read” to the object, so when the player reads it in the right moment will solve the puzzle by reading “aloud” the word. Same with the magic carpet. Meaning the commands must be linked to the objects for the game to look nice. That being said, a better implementation of “Cloak of Darkness” would be to add the verb “hang” to the cloak and when the player clicks on it, the word “in/at” be shown next to the all visible objects and then implement the “in/at” action. On similar fashion all objects that can be hanged should have the verb “hang”. That way you give real options to the players and the world would be relatively “open”. By putting the entire command in the hook you are giving away that answer. We used to have “pixel hunters” with graphic games and with some underimplementation like this we might face a “clicking hunter” with IF games where you click on everything without thinking in order to solve the game. Cheers!
Hello! I’ve had various Stuff On recently so haven’t been a very active maintainer, but it’s great to see people appreciating Gruescript.
You can mess about with this in HTML/CSS, as you’ve done (although I could have Gruescript make it easier for you.) I’ve alternated a few times between “room on top, scrolling text underneath”, “room underneath, scrolling text on top” and “room and scrolling text side by side” as in Draculaland and Detectiveland (in landscape windows). They all seem not quite right for different reasons. I think the reason I’ve settled (for now) on room-underneath is that the room pane has a variable height, depending on how many things are in it, but the scroller is a fixed height, so this way the divider between the two panes stays still. It also keeps the player’s eyes at around that point oi the window, which I think makes them less likely to miss messages. (Several players thought that Draculaland had a bug with the castle gate keys spontaneously vanishing, because they weren’t seeing the message about the magpie stealing them.)
That’s configurable by the player in the game’s options, though I think Gruescript ought to make it possible to at least set the defaults. I suppose I wanted the room description to show up in the scroller when you change rooms, partly so that the scroller output looked like a traditional text adventure, and partly so that if you scroll back through the text, you can easily see what room you were in at what time. And I wanted it in the room pane because there’s no “look” verb, so you always need to be able to see what room you’re in.
I don’t think this is a problem unless pixel-hunting becomes more desirable to the player than playing normally - which is a failure of game design. It does mean that the interface is placing constraints on game design, but that’s true of all authoring systems.
That implementation of prepositions is interesting. I think you could do it in Gruescript as is, with some mucking about:
game Fun with prepositions
room bedroom
thing bed
loc bedroom
tags tiable_to
thing sheet
loc bedroom
tags tiable
setverb tie
has $this tiable
eq $tying 0
verb tie
assign tying $this
say To what?
setverb tie_to
!eq $tying 0
!eq $this $tying
!has $this tied
rule
!eq $tying 0
!eq $verb tie
assign tying 0
verb tie_to
display to
prompt to {$this}
say You tie {the $tying} to {the $this}.
assign $tying.tied_to $this
tag $tying tied
tagdesc tied tied to {$this.tied_to}
(Of course, your game then has to deal with the combinatorial explosion of being able to tie any tiable object to anything else - and getting rid of that combinatorial explosion was supposed to be one of the advantages of Gruescript!)
Thank you very much for the explanations and code. Yes, it would be great if the interface order can be optional. Regarding prepositions I think they are mandatory if you want to create a game where you have commands with more than two words, otherwise the tool will be very limited or as it happened with the Cloak of Darkness the command must be on plain sight.
Edit: a middle ground without using preps is to put the verb hang in the cloak, the verb will be only shown and succeded in presence of the hook. When the player click it the cloak will move automatically to the hook, meaning the player only executes half of the action but if he knows the other half it won’t be a great loss. That will keep the things simple as intended and hiding the answer at the same time.
It’s currently only shown if you’re holding the cloak and in the presence of the hook, so the “hiding” effect is the same, if I’m understanding correctly. (Not that there are any other portable objects in Cloak of Darkness, which is why you might not have noticed that.)
