Page 1 of 1

ZIL Comp (tangent from Hugo Open House Comp 2012 reviews)

Posted: Wed May 08, 2013 10:57 am
by Roody_Yogurt
Last year, the ZIL-curious among us agreed to postpone a ZIL comp until sometime this year. Well, I have both good news and bad news about that.

With how fast the year is flying by and the state of my own projects, I can't say I would ever have gotten around to setting up a proper ZIL comp. That said, I was recently informed that the "@ party demo scene" convention still has an IF category:

http://atparty-demoscene.net/competitions/

I think such a setting calls for old-school games, so piggybacking onto that might be a good way to get our ZIL-writing out of the way. The deadline for this year's games is June 10th, which I think is too close to start making a big deal about it now, but if anybody wants to write something, well, great. Then, next year, we can give several months' notice and make a big deal.

While most (if not all) won't be at the convention itself, at least we'd have the assurance that people are checking out what we have written. Another perk is that they are specifically looking for games that take 5-10 minutes to get through, so it wouldn't be a big obligation on our part.

Anyhow, I think @ party sounds like a good idea, but there are also other competitions we can piggyback onto. For instance, there's that Saugus.net (some city in MA, I think) Halloween IF contest. I believe it only accepts z-code games, but hey, ZIL -> z-code!

Posted: Sat May 11, 2013 1:53 pm
by loafingcoyote
Hey Roody, this is a great idea! I hadn't heard of @ party before but it looks like the perfect venue to unleash new ZIL games onto an unsuspecting world.

I've been in a serious IF funk lately and have been looking for an excuse to mess around with ZIL anyway, so I think I'm going to do it. I want to write one...this year. Surely a decent 5-10 minute game can easily be written in one month.

Do you think that you will make one too? Two games wouldn't exactly make a comp but it might foster momentum for next year. And, who knows, maybe one of the more knowledgeable ZIL guys will join us. The code and insight provided by jjsonick last year was very helpful.

-lc

Posted: Sat May 11, 2013 3:00 pm
by Roody_Yogurt
Cool, glad you are in. My tentative idea still needs some work, so maybe I'll soon send you a message and we can bounce ideas off of eachother. The intent behind my idea is to specifically target demo culture, but I guess there's always the fallback to do something that would have felt at home with the original batch of Textfire games. Most of those were only 5-10 minutes long.

Anyhow, I'll try to put aside some time this weekend to stare at some ZIL stuff in get my head in the zone.

Posted: Sat May 11, 2013 4:59 pm
by loafingcoyote
Roody_Yogurt wrote: The intent behind my idea is to specifically target demo culture, but I guess there's always the fallback to do something that would have felt at home with the original batch of Textfire games. Most of those were only 5-10 minutes long.
Having a well thought out theme or directive sounds like a good way to get some extra attention. I'm looking forward to brainstorming on this.

Roody_Yogurt wrote:Anyhow, I'll try to put aside some time this weekend to stare at some ZIL stuff in get my head in the zone.
Yeah, having not coded anything ZIL related for months has set me back a little. The first stage of my re-assimilation plan, where my own code doesn't look like something incomprehensible that someone else wrote, is done; check. Now I'm working in a small project that uses as many ZIL elements as possible. After I've re-read part of the manual I'm going to start creating unimplemented common verbs and useful objects. Expect code very soon!

-lc

Posted: Sun May 12, 2013 5:00 pm
by loafingcoyote
A couple of issues and a little code:

At first I couldn't get the LOCAL-GLOBALS to work at all, which was frustrating, since they obviously work in the extended "Cloak of Darkness" game. I finally figured out that the problem when I switched from z3 format to z5 and it worked fine. I had thought the different z formats had mostly to do with game size, but obviously I was wrong. By the way, for the masses of Hugonauts reading this, LOCAL-GLOBALS are the Hugo equivalent of scenery objects assigned the "found_in" property.

The other issue is that the ADJECTIVE property isn't working properly. If you have a "palm tree" object you can refer to it as a "tree" or "palm tree". But if you just use the adjective "palm", then the parser will respond with, "You don't see that here."

Relearning ZIL has been a pretty slow process. Here is a first attempt at a simple "talk to" verb:

Code: Select all

<SYNTAX TALK TO OBJECT = V-TALK-TO>
<SYNTAX TALK WITH OBJECT = V-TALK-TO>
<SYNTAX TALK = V-TALK-TO>
<VERB-SYNONYM TALK SPEAK>

<ROUTINE V-TALK-TO &#40;&#41;
	<COND &#40; <OR <NOT, PRSO>
				<EQUAL?, PRSO, PLAYER>>
				<TELL "Talking to yourself is a sure sign of impending mental collapse." CR>&#41;
			&#40;<NOT <FSET?, PRSO, PERSONBIT>>
				<TELL "You will accomplish nothing talking to ">
				<MATCHPRSO "a " "some ">
				<TELL D PRSO "." CR>&#41;
			&#40;ELSE <COND &#40;<NOT <FSET?, PRSO, NARTICLEBIT>>
					<TELL "The ">&#41;>
				<TELL D PRSO>
				<MATCHPRSO " isn't" " aren't">
				<TELL " much of a conversationalist." CR>&#41;>>
				

;	Matches verb and subject for PRSO		
<ROUTINE MATCHPRSO &#40;S P&#41;
	<COND &#40;<FSET?, PRSO, PLURALBIT><TELL .P>&#41;
	&#40;ELSE <TELL .S>&#41;>>
-lc

Posted: Sun May 12, 2013 6:50 pm
by vaporware
loafingcoyote wrote:At first I couldn't get the LOCAL-GLOBALS to work at all, which was frustrating, since they obviously work in the extended "Cloak of Darkness" game. I finally figured out that the problem when I switched from z3 format to z5 and it worked fine. I had thought the different z formats had mostly to do with game size, but obviously I was wrong.
This is a library bug: the GLOBAL property has a different format on V3, but parser.zil isn't aware of that. I've filed the bug, but for now you can patch your copy of parser.zil easily enough. Search for the 3 occurrences of "P?GLOBAL", find "<GET .H .X>" a few lines below each one, and change it to "<GET/B .H .X>".
loafingcoyote wrote:The other issue is that the ADJECTIVE property isn't working properly. If you have a "palm tree" object you can refer to it as a "tree" or "palm tree". But if you just use the adjective "palm", then the parser will respond with, "You don't see that here."
This is by design: ZILF's parser mercilessly distinguishes between adjectives and nouns. You can use any number of adjectives to refer to an object, but there must be exactly one noun. I believe this is consistent with Infocom's games, although it feels quaint today and might be worth changing.

Posted: Sun May 12, 2013 9:06 pm
by loafingcoyote
Hi, welcome to the discussion! Any input you can provide will be greatly appreciated =)
vaporware wrote:This is a library bug: the GLOBAL property has a different format on V3, but parser.zil isn't aware of that. I've filed the bug, but for now you can patch your copy of parser.zil easily enough. Search for the 3 occurrences of "P?GLOBAL", find "<GET .H .X>" a few lines below each one, and change it to "<GET/B .H .X>".
Yes, this works perfectly. I suspected that it wasn't specifically related to the z format, but that was reasonable at the time considering how little I know about it. I don't think I've ever played a z3 game before and was hoping to release my little work as one. Now, hopefully, I can. Thanks!
vaporware wrote:This is by design: ZILF's parser mercilessly distinguishes between adjectives and nouns. You can use any number of adjectives to refer to an object, but there must be exactly one noun. I believe this is consistent with Infocom's games, although it feels quaint today and might be worth changing.
This is interesting. I can see how it would help reduce disambiguation issues, which are not fun at all. The more I think about it, the more I like it. It would be nice to have a way to let the player know that it's intentional and not a bug, but yeah, I wouldn't change it.

-lc

Posted: Wed May 15, 2013 11:41 am
by Roody_Yogurt
I also think I am fine with Infocom's behavior, as far as the adjective-without-noun stuff goes.

I finally got around to setting up my text editor's user tools to handle ZIL and ZAP compiling. As I told vaporware, I'd like to also see environment variables supported at some point (like Hugo does) since I personally like to send my compiled files to a different directory than my source files.

Reacquainting myself with the ZIL manual, I am reminded by several things I like-
  • Conceptually, I like that rooms are kept in a rooms object. I've sometimes thought that it's a little inelegant to keep room objects as siblings to all other parentless objects. Of course, I say "conceptually" since I'm not entirely wild about having to add "(LOC ROOMS)" to every room object (or "in rooms" if I were to do this in Hugo). Ideally, I think it'd be cool if an object class could inherit object placement, but when I think about it, I realize that this might be more complicated than its worth.
  • You have to love a system where you end the game by calling something like "JIGS-UP."
  • The Find feature is pretty cool. It's like Hugo's FindObjectofType and FindObjectofAttribute routines, except a bit simpler and more powerful, it seems.
  • As something that Hugo can't do, I have to be impressed that it can handle >VERB OBJECT XOBJECT (like, >GIVE TEACHER APPLE), even if Inform can also do this.
  • Not having any experience with LISP, I have to appreciate commands like GETP, since it's the closest I'm going to get to understanding Lurking Horror lingo like "Foodp?"
Other Hugo comparisons:
  • ZIL's WINNER global variable is equal to Hugo's actor global variable. It is set to whomever-is-doing-the-current-action (so it can be used with NPCs, too).
  • Furthermore, what Hugo calls characters, ZIL calls actors.
  • Interrupt routines are basically daemons. Instead of being Deactivated, they are dequeued.
  • The P-CONT global variable is like Hugo's event_flag global variable, used to interrupt game play at important points.
  • Took me a while to realize that the last part of a conditional like:

    Code: Select all

    &#40;T
    <SET FOOD <>&#41;>
    Is basically the last "case else" command.
Anyhow, I'm not in love with every name Infocom chose for globals and stuff, but it's interesting to think that if the ZIL manual was leaked a decade earlier, all of the big IF systems might have adopted their terminology just because they were motherfucking Infocom.

Looking over the ZIL manual is a revolving door of feelings of "Hey, I think I can do this!" and "Actually, no, I can't!" Right now, I'm just going to shoot for coding a couple rooms and objects with correct spacing.

Posted: Mon May 20, 2013 11:48 am
by Roody_Yogurt
In the other ZIL thread (at some point, I think I'm going to ask Recchi to put all of ZIL stuff into one sticky-d thread in here- JC has enough bases as it is), I re-found jjsonick's enhanced-cloak sample. When compiling it as a Z5 game, I was surprised to see that there wasn't any status line.

I asked vaporware about this, and he said that was because how Z3's engine draws the status line. Z5 games need the routines the ZIL manual refers to as INIT-STATUS-LINE and UPDATE-STATUS-LINE.

I tried writing my own but am currently at a standstill, as I don't know if ZIL has an equivalent to Hugo's "print to" or display.linelength. I haven't seen vaporware for a couple days so I haven't been able to ask him yet.

Anyhow, this is my code so far:

Code: Select all

   <ROUTINE INIT-STATUS-LINE &#40;T&#41;
   	<COND &#40;<0? .T> <CLEAR 0>&#41;>
		<SPLIT 1>
		<CLEAR 1>		
	>
   <ROUTINE UPDATE-STATUS-LINE &#40;&#41;
   	<SCREEN 1>
   	<HLIGHT 1>   ;"reverses the fg and bg colors"
   	<CLEAR 1>
   	<TELL " " D HERE>
   	<SCREEN 0>
   	<HLIGHT 0>
   >
(edited to fix some non-working conditional code in INIT-STATUS-LINE)

Posted: Mon May 20, 2013 3:19 pm
by Roody_Yogurt
As far as the thing comparable to Hugo's "print to" function, vaporware pointed out CURSET (well, actually, it's more like Hugo's locate function, but whatever). He gave me some info on getting the screen width with op codes and header stuff, although I didn't really understand so I'll have to get back to that later. I think that if it were available in ZIL right now, it'd be with the WINGET command which is not yet supported.

Here is a version that always prints the score and turn counters at column 60:

Code: Select all

   <ROUTINE UPDATE-STATUS-LINE &#40;&#41;
   	<SCREEN 1>
   	<HLIGHT 1>   ;"reverses the fg and bg colors"
   	<CLEAR 1>
   	<TELL " " D HERE>
   	<CURSET 1 60>      
   	<TELL "Score&#58; ">
   	<PRINTN SCORE>
   	<TELL "   ">
   	<TELL "Moves&#58; ">
   	<PRINTN TURNS>
   	<SCREEN 0>
   	<HLIGHT 0>
   >
Think I'll go back to playing around with ZIP coding now!

Posted: Sun Jun 02, 2013 1:55 am
by Roody_Yogurt
Ok, I have to admit that things aren't looking great for the comp submission. I started to think, hey, instead of coming up with my own idea, maybe I'll just code one of those Infocom sample transcripts that came along with the games. Of course, it turns out that all of these games are way more complicated than the ideas I had for comp games in the first place.

Still, applying ZIL to the sample game transcripts has done a good job of showing me things that weren't yet available in parser.zil. First off, I noticed that parser.zil didn't accept DESCFCN, the routine for allowing objects to have routines that determine their room-listing text. Secondly, the ZIL manual refers to DESCRIBE-ROOM and DESCRIBE-OBJECTS routines that are called by V-LOOK, while parser.zil had one big V-LOOK routine that handled everything. Thirdly, parser.zil didn't support LDESC being used as the short_desc-esque thing it's supposed to be; V-EXAMINE treats it like Hugo's long_desc. I think non-default object descriptions are supposed to be handled by the object's actions routine.

So, I've gone and coded all of these things. I don't think there's a real benefit to splitting V-LOOK up, but hey, in the least, I changed them so they don't have to be used with the current location... And now it's more like Infocom did it. I haven't yet coded a brief/superbrief/verbose mode system. That'll probably be next. Anyhow, here are my changes so far:

Code: Select all

<ROUTINE V-LOOK &#40;&#41;
	<COND
     &#40;<DESCRIBE-ROOM HERE 1>
		<DESCRIBE-OBJECTS HERE>&#41;>
>

<ROUTINE DESCRIBE-ROOM &#40;RM "OPT" LONG "AUX" P&#41;
    <COND
        ;"check for light, unless running LOOK from NOW-LIT &#40;which sets NLITSET to 1&#41;"
        &#40;<NOT <OR <FSET? .RM ,LIGHTBIT>
		<AND <SEARCH-FOR-LIGHT>>
	          <EQUAL? ,NLITSET 1>>>
	      <TELL "Darkness" CR "It is pitch black. You are likely to be eaten by a grue." CR>
	      <RFALSE>&#41;
		  &#40;ELSE 
		  		;"print the room's real name"
				<TELL D .RM CR>
				<COND
					&#40;<AND <NOT .LONG>
							<FSET? .RM , TOUCHBIT>>
					<RETURN>&#41;>
				<FSET .RM ,TOUCHBIT>	
            ;"either print the room's LDESC or call its ACTION with M-LOOK"
            <COND
                &#40;<SET P <GETP .RM ,P?LDESC>>
                    <TELL .P CR>&#41;
                &#40;ELSE
                    <APPLY <GETP .RM ,P?ACTION> ,M-LOOK>&#41;
            >
         &#41;
     >
     <RETURN>
>
   
<ROUTINE DESCRIBE-OBJECTS &#40; RM "AUX" P F N S&#41;
	<OBJECTLOOP I .RM
		<COND
			;"objects with DESCFNs"
			&#40; <SET P <GETP .I ,P?DESCFCN>>
				<CRLF>
				<APPLY .P>
				<CRLF>
			&#41;
			;"un-moved objects with FDESCs"	
		   &#40;<AND <NOT <FSET? .I ,TOUCHBIT>> <SET P <GETP .I ,P?FDESC>>>
		                                    <TELL CR .P CR>
		   &#41;
		   ;"objects with LDESCs"
		   &#40;
		   <SET P <GETP .I ,P?LDESC>>
		                                    <TELL CR .P CR>&#41;>
	>
		    ;"use N add up all non fdesc, ndescbit, personbit objects in room"
		    <OBJECTLOOP I .RM
		    		 <COND
		                    &#40;<NOT <OR <FSET? .I ,NDESCBIT>
						<SET P <GETP .I ,P?DESCFCN>>
		                    			<==? .I ,WINNER> 
		                    			<FSET? .I ,PERSONBIT> 
		                    			<AND <NOT <FSET? .I ,TOUCHBIT>> <SET P <GETP .I ,P?FDESC>>>
		                    			<SET P <GETP .I ,P?LDESC>>
							>>
		    									
		    									<SET N <+ .N 1>>
		    									<COND &#40;<==? .N 1>
		    												<SET F .I>&#41;
		    										  &#40;<==? .N 2>
		    										  		<SET S .I>&#41;>		
		    				&#41;>>
		    ;"go through the N objects"
		    <COND &#40;<G? .N 0> 
		    	<COND &#40;<FSET? .F ,PLURALBIT>
		    				<TELL "There are">&#41;
		    		  &#40;ELSE <TELL "There is">&#41;>
		    	<COND
		        	&#40;<==? .N 1>
			    		<ARTICLE .F>
		            	<TELL D .F>&#41;
		        	&#40;<==? .N 2>
			    		<ARTICLE .F> 
		            	<TELL D .F " and">
			    		<ARTICLE .S>
		            	<TELL D .S>&#41;
		        	&#40;ELSE
		            	<OBJECTLOOP I .RM
		                		 <COND
		                    		&#40;<NOT <OR <FSET? .I ,NDESCBIT> 
		                    				<==? .I ,WINNER> 
		                    				<FSET? .I ,PERSONBIT> 
		                    				<AND <NOT <FSET? .I ,TOUCHBIT>> <SET P <GETP .I ,P?FDESC>> >>>
		                    					<ARTICLE .I> 
		                						<TELL D .I>
		                						<SET N <- .N 1>>
		                						<COND
		                    						&#40;<0? .N>&#41;
		                    						&#40;<==? .N 1> <TELL ", and">&#41;
		                    						&#40;ELSE <TELL ",">&#41;>&#41;>            
		           		>&#41;>
		          <TELL " here." CR>&#41;>
			;"describe visible contents of containers and surfaces"
		 	<OBJECTLOOP I .RM
		      			<COND 
		      					&#40;<AND <FSET? .I ,CONTBIT> 
		                              <AND <FIRST? .I>>
		                        	  <OR <FSET? .I ,SURFACEBIT>
						    			  <FSET? .I ,OPENBIT>>
						         >
		                                	<DESCRIBE-CONTENTS .I>&#41;
		                >
		   	>
		   	;"Re-use N to add up NPCs"
		    <SET N 0>
		    <OBJECTLOOP I .RM
		    		 <COND
		                    &#40;<AND <FSET? .I ,PERSONBIT>
		                    	  <NOT <==? .I ,WINNER>>> 
		    							<SET N <+ .N 1>>
		    							<COND &#40;<==? .N 1>
		    										<SET F .I>&#41;
		    							    	&#40;<==? .N 2>
		    										<SET S .I>&#41;>		
		    				&#41;>>
		   ;"go through the N NPCs"
		    <COND &#40;<G? .N 0>
		    	;<TELL CR>
		    	<COND
		        	&#40;<==? .N 1>
		            	<TELL D .F>
		            	<TELL " is">&#41;
		        	&#40;<==? .N 2>
		            	<TELL D .F " and ">
		            	<TELL D .S>
		           		<TELL " are">&#41;
		        	&#40;ELSE
		            	<OBJECTLOOP I .RM
		                		 <COND
		                    		&#40;<AND <FSET? .I ,PERSONBIT>
		                    	  		  <NOT <==? .I ,WINNER>>> 
		                						<TELL D .I>
		                						<SET N <- .N 1>>
		                						<COND
		                    						&#40;<0? .N>&#41;
		                    						&#40;<==? .N 1> <TELL ", and ">&#41;
		                    						&#40;ELSE <TELL ",">&#41;>&#41;>            
		           		>
		           		<TELL " are">&#41;>
		          <TELL " here." CR>&#41;>
			<SETG NLITSET 0>
>

<ROUTINE GOTO &#40;RM&#41;
    <SETG HERE .RM>
    <MOVE ,WINNER ,HERE>
    <APPLY <GETP .RM ,P?ACTION> ,M-ENTER>
    ;"moved V-LOOK into GOTO so descriptors will be called when you call GOTO from a PER routine, etc"
	<COND
     &#40;<DESCRIBE-ROOM HERE>
		<DESCRIBE-OBJECTS HERE>&#41;>
	<FSET ,HERE ,TOUCHBIT>
>
I didn't include it, but V-EXAMINE would also need to be edited to omit the LDESC stuff.

Posted: Mon Jun 03, 2013 12:48 am
by Roody_Yogurt
I actually added the BRIEF/SUPERBRIEF/VERBOSE stuff last night, but there's enough small changes here and there that I'm just going to share my current edited parser.zil:
https://docs.google.com/file/d/0B_4ZXs4 ... sp=sharing

Posted: Mon Jun 03, 2013 4:57 pm
by Roody_Yogurt
Here are some more implemented routines-from-the-manual (not yet added to that aforementioned parser.zil):

Code: Select all

<VERSION?
   &#40;ZIP&#41;
   &#40;T
<CONSTANT H-NORMAL 0>
<CONSTANT H-INVERSE 1>
<CONSTANT H-BOLD 2>
<CONSTANT H-ITALIC 4>
<CONSTANT H-MONO 8>&#41;
	 >

<ROUTINE ITALICIZE &#40;STR "AUX" A&#41;
     <VERSION?
     &#40;ZIP&#41;
     &#40;T
		<HLIGHT, H-ITALIC>&#41;
	 >
	<TELL .STR>
     <VERSION?
     &#40;ZIP&#41;
     &#40;T
	<HLIGHT, H-NORMAL>&#41;
	>
>

<ROUTINE SEE-INSIDE? &#40;OBJ&#41;
	<COND
		&#40;<OR <FSET? .OBJ ,SURFACEBIT>
		<AND <FSET? .OBJ ,CONTBIT>
		<OR <FSET? .OBJ ,OPENBIT> <FSET? .OBJ ,TRANSBIT>>>
		 >
		 <RTRUE>&#41;
	>
		 <RFALSE>	 
>
I spent a lot of time trying to implement THIS-IS-IT, the pronoun-setting routine, but man, I am seriously not understanding exactly what values are being stored in the applicable tables. That will have to wait until another day.

Posted: Mon Jun 03, 2013 6:48 pm
by Roody_Yogurt
Here is the manual's FIND-IN routine, which is like Hugo's FindObjectOfType. It checks the children of the given container. If there is exactly one match, it returns that object.

Code: Select all

<ROUTINE FIND-IN &#40;C BIT "OPT" WORD "AUX" N W P&#41;
	<OBJECTLOOP I .C
		<COND
			&#40;<FSET? .I  .BIT>
			<SET N <+ .N 1>>
			<SET W .I>&#41;
		>
	>
	<COND
	;"If less or more than one match, we return false."
		&#40;<NOT <EQUAL? .N 1>>
		<RFALSE>&#41;
	;"if the routine was given the optional word, print &#91;<word> the object&#93;"
		&#40;.WORD
		<TELL "&#91;" .WORD >
		<ARTICLE .W>
		<TELL D .W "&#93;" CR>&#41;
	>
	;"set P to W &#40;the object with the right bit&#41; so the routine returns that object"
	<SET P .W>
>

Posted: Tue Jun 04, 2013 1:12 am
by Roody_Yogurt
I coded one other thing from the ZIL/ZILF differences file. It's support for CONTFCN, a property to give to parent containers for ZIL's version of before rules. I'm not entirely sure this one doesn't have some logic errors, but it's a start:

Code: Select all

;"Handler order&#58; player's ACTION, location's ACTION &#40;M-BEG&#41;,
verb preaction, PRSI's ACTION, PRSO's ACTION, verb action."

<ROUTINE PERFORM-CALL-HANDLERS &#40;PRTN RTN "AUX" AC RM&#41;
    <COND &#40;<AND <SET AC <GETP ,WINNER ,P?ACTION>>
            <APPLY .AC>>
                <RTRUE>&#41;
        &#40;<AND <SET RM <LOC ,WINNER>>
            <SET AC <GETP .RM ,P?ACTION>>
            <APPLY .AC ,M-BEG>>
                <RTRUE>&#41;
        &#40;<AND .PRTN <APPLY .PRTN>>
            <RTRUE>&#41;
			&#40;<AND ,PRSI 
			<SET AC <GETP <LOC,PRSI> ,P?CONTFCN>>
			  <APPLY .AC>>
			  <RTRUE>
			 &#41;
        &#40;<AND ,PRSI 
        <SET AC <GETP ,PRSI ,P?ACTION>>
            	<APPLY .AC>>
                <RTRUE>
 			&#41;
 			&#40;<AND ,PRSO 
        <SET AC <GETP <LOC,PRSO> ,P?CONTFCN>>
		  						  <APPLY .AC>>
						  <RTRUE>
 			&#41;    
        	&#40; <AND ,PRSO
        				<NOT ,PRSO-DIR>
            <SET AC <GETP ,PRSO ,P?ACTION>>
            <APPLY .AC>>
                <RTRUE>
        	&#41;
        &#40;ELSE
        <APPLY .RTN>&#41;>>

<OBJECT NULLTHANG
	&#40;SIZE 2&#41;
	&#40;ADJECTIVE NULLTHANG&#41;
	&#40;LDESC <>&#41;
	&#40;FDESC <>&#41;
	&#40;GLOBAL NULLTHANG&#41;
	&#40;TEXT <>&#41;
	&#40;CONTFCN <>&#41;
	&#40;DESCFCN <>&#41;
	&#40;TEXT-HELD <>&#41;
	&#40;CAPACITY 10&#41;>

Posted: Fri Jun 07, 2013 1:38 am
by Roody_Yogurt
So, one of the ZIL-ZILF differences is the addition of that OPENABLE bit (which I have renamed OPENABLEBIT in my parser.zil just to keep names similar). While considering adding LOCKEDBIT functionality to parser.zil, I didn't want to create a LOCKABLEBIT. I mean, Infocom obviously coded their games ok without these flags. The question was, how?

I finally figured out how tonight. This is the current V-OPEN routine:

Code: Select all

<ROUTINE V-OPEN &#40;&#41;
    <COND
        &#40;<FSET? ,PRSO ,PERSONBIT>
            <TELL "I don't think " D ,PRSO " would appreciate that." CR>&#41;
        &#40;<NOT <FSET? ,PRSO ,OPENABLEBIT>>
            <PRINTR "That's not something you can open.">&#41; 			
        &#40;<FSET? ,PRSO ,OPENBIT>
            <PRINTR "It's already open.">&#41;
        &#40;<FSET? ,PRSO ,LOCKEDBIT>
            <TELL "You'll have to unlock it first." CR>&#41;
        &#40;ELSE
            <FSET ,PRSO ,TOUCHBIT>
            <FSET ,PRSO ,OPENBIT>
            <TELL "You open the " D ,PRSO "." CR>
            <DESCRIBE-CONTENTS ,PRSO>
        &#41;>>
This mirrors modern IF language behavior, where the verb routine basically handles every instance (except for the few places you want to cut it off earlier). Instead of doing this, I figure Infocom did something more like this:

Code: Select all

<ROUTINE V-OPEN &#40;&#41;
    <COND
        &#40;<FSET? ,PRSO ,PERSONBIT>
            <PRINTR "What a grisly idea."&#41;			
        &#40;ELSE
            <PRINTR "That's not something you can open.">&#41;
    >
>
You'll notice that these are just failure messages. This is because the majority of objects in the game are unopenable.

Now, all success cases would be handled by the PRSO's action routines. Since there's a lot of similar behavior between them, they can probably all point to the same routine, like so:

Code: Select all

 <OBJECT BOX
     &#40;DESC "box"&#41;
     &#40;IN GRINDER_ROOM&#41;
     &#40;SYNONYM BOX&#41;
    &#40;FLAGS CONTBIT&#41;
    &#40;ACTION BOX-R&#41;
 >
 
 <ROUTINE BOX-R &#40;&#41;
    <COND &#40;<VERB? OPEN>
    	  <OPEN-RULES>
    	  &#41;
    >
 >
 
 <ROUTINE OPEN-RULES &#40;&#41;
    <COND
        &#40;<FSET? ,PRSO ,OPENBIT>
            <PRINTR "It's already open.">&#41;
        &#40;<FSET? ,PRSO ,LOCKEDBIT>
            <TELL "You'll have to unlock it first." CR>&#41;
         &#40;ELSE
             <FSET ,PRSO ,TOUCHBIT>
             <FSET ,PRSO ,OPENBIT>
             <TELL "You open the " D ,PRSO "." CR>
            <DESCRIBE-CONTENTS ,PRSO>
         &#41;
    >
 >
So I'm going to try to do things this way going forward.

Posted: Mon Jun 10, 2013 10:59 pm
by Roody_Yogurt
So, good news and bad news. The good news is, I finished a game, and it turns out that comp deadline isn't actually until the 15th or so, which means I'm technically early.

Still, between the fact that this is a bare-bones game and the fact that it is a port puts it into some grey area (the comp "general rules" page says you should own everything you submit), I'm not going to submit it. Well, that and the fact that without me there explaining why ZIL in itself is interesting, my game is too simple to show off. Still, it's code that I wrote that I otherwise wouldn't have, so it's still a good experience.

Just recently, I found another problem with my DESCRIBE-ROOM code that made some items be listed twice. I've fixed that and have updated the link to my parser.zil to reflect that. The whole routine probably could be written in a more efficient manner, but it should be working for now, at least.

Even though the game could use it, I haven't yet coded a LOCK/UNLOCK system. My game just kind of pretends that UNLOCK doesn't exist.

As pointed out to me, I forgot to take out some of the commenting from Jaybird's original file that I started with, so hopefully that doesn't confuse anyone too much.

Anyhow, my compiled game and source files can be downloaded here:https://docs.google.com/file/d/0B_4ZXs4 ... sp=sharing

Posted: Fri Jun 14, 2013 11:50 am
by Roody_Yogurt
Ok, I have uploaded some new files. The following zip contains my latest parser.zil, a "newverbs" file, and a stub file (I see now that there is an empty.zil file in the ZILF distribution, but this new one has AGAIN and UPDATE-STATUS-LINE support for XZIP games): https://docs.google.com/file/d/0B_4ZXs4 ... sp=sharing

Here is the code from the "new verbs" file:

Code: Select all

<SYNTAX LOOK IN OBJECT = V-LOOK-IN>
<SYNTAX LOOK INSIDE OBJECT = V-LOOK-IN>
<SYNTAX LOOK ON OBJECT = V-LOOK-IN>
<SYNTAX LOCK OBJECT = V-LOCK>
<SYNTAX UNLOCK OBJECT = V-UNLOCK>
<SYNTAX LOCK OBJECT WITH OBJECT &#40;FIND KEYBIT&#41;&#40;HAVE HELD CARRIED&#41;= V-LOCK>
<SYNTAX UNLOCK OBJECT WITH OBJECT &#40;FIND KEYBIT&#41;&#40;HAVE HELD CARRIED&#41; = V-UNLOCK>

 
 ; a routine to handle openable/closable items
 <ROUTINE OPENABLE-RULES &#40;&#41;
    <COND
    	&#40;<VERB? OPEN>
	    <COND
		&#40;<FSET? ,PRSO ,OPENBIT>
		    <PRINTR "It's already open.">&#41;
		&#40;<FSET? ,PRSO ,LOCKEDBIT>
		    <TELL "You'll have to unlock it first." CR>&#41;
		 &#40;ELSE
		     <FSET ,PRSO ,TOUCHBIT>
		     <FSET ,PRSO ,OPENBIT>
		     <TELL "You open the " D ,PRSO "." CR>
		    <DESCRIBE-CONTENTS ,PRSO>
		 &#41;
	    >
	&#41;
    	&#40;<VERB? CLOSE>
	    <COND
		&#40;<NOT <FSET? ,PRSO ,OPENBIT>>
		    <PRINTR "It's already closed.">&#41;
		 &#40;ELSE
		     <FCLEAR ,PRSO ,OPENBIT>
		     <TELL "You close the " D ,PRSO "." CR>
		 &#41;
	    >
	&#41;
	&#40;<VERB? EXAMINE>
		<COND
			&#40;<NOT <FSET? ,PRSO ,OPENBIT>>
			<TELL "The " D ,PRSO " is closed.">
			&#41;
			&#40;<FSET? ,PRSO ,OPENBIT>
			<TELL "The " D ,PRSO " is open.">
			&#41;			
		>
		<COND
			&#40;<OR <FSET? ,PRSO ,OPENBIT> <FSET? ,PRSO ,TRANSBIT>>
			<TELL " ">
			<DESCRIBE-CONTENTS ,PRSO>
			&#41;
			&#40;T
			<CRLF>
			&#41;
		>
	&#41;
	&#40;<VERB? LOOK-IN>
		<COND
			&#40;<NOT <FSET? ,PRSO ,OPENBIT>>
				<TELL "The " D ,PRSO " is closed." CR>
			&#41;
			&#40;<OR <FSET? ,PRSO ,OPENBIT> <FSET? ,PRSO ,TRANSBIT>>
			<DESCRIBE-CONTENTS ,PRSO>
			&#41;
		>
	&#41;
    >
 >
 
 ; a routine to handle always-open or surface objects
  <ROUTINE CONTAINER-RULES &#40;&#41;
     <COND
 	&#40;<VERB? EXAMINE LOOK-IN>
 		<COND
 			&#40;<OR <FSET? ,PRSO ,SURFACEBIT> <FSET? ,PRSO ,TRANSBIT>
 			<FSET? ,PRSO ,OPENBIT>>
 			<DESCRIBE-CONTENTS ,PRSO>
 			&#41;		
 		>
 	&#41;
     >
 >
 
  <ROUTINE LOCK-RULES &#40;"AUX" KEY&#41;
  	<COND
 	&#40;<VERB? UNLOCK>
 		<COND
 			&#40;<NOT <FSET?,PRSO,LOCKEDBIT>>
 			<TELL "The " D, PRSO " is already unlocked." CR>&#41;
 			&#40;<AND <NOT ,PRSI> <SET KEY <FIND-IN, WINNER, KEYBIT "with">>>
 				<TELL "You unlock " D ,PRSO " with the " D .KEY "." CR>
 				<FCLEAR, PRSO, LOCKEDBIT>
 			&#41;
 			&#40;<AND, PRSI <FSET? ,PRSI ,KEYBIT>>
 				<TELL "You unlock " D ,PRSO " with the " D, PRSI "." CR>
 				<FCLEAR, PRSO, LOCKEDBIT>
 			&#41;
 			&#40;T
 			<TELL "You don't have a key that fits the " D, PRSO "." CR>
 			&#41;
 		>
 	&#41;
 	&#40;<VERB? LOCK>
 		<COND
 			&#40;<FSET?,PRSO,LOCKEDBIT>
 			<TELL "The " D, PRSO " is already locked." CR>&#41;
 			&#40;<AND <NOT ,PRSI> <SET KEY <FIND-IN, WINNER, KEYBIT "with">>>
 				<TELL "You lock the " D ,PRSO " with the " D .KEY "." CR>
 				<FSET, PRSO, LOCKEDBIT>
 			&#41;
 			&#40;<AND, PRSI <FSET? ,PRSI ,KEYBIT>>
 				<TELL "You lock the " D ,PRSO " with the " D, PRSI "." CR>
 				<FSET, PRSO, LOCKEDBIT>
 			&#41;
 			&#40;T
 			<TELL "You don't have a key that fits the " D, PRSO "." CR>
 			&#41;
 		>
 	&#41; 	
  	>
  >
  <ROUTINE V-LOOK-IN &#40;&#41;
  	    <COND
 	        &#40;<FSET? ,PRSO ,PERSONBIT>
 	            <PERFORM ,V?EXAMINE ,PRSO>&#41;			
 	        &#40;ELSE
 	            <PRINTR "You'll have to tell me how to do that.">&#41;
         >
 >
 
 <ROUTINE V-LOCK &#40;&#41;
    <TELL "The " D ,PRSO " does not have a lock." CR>
 >
 
 <ROUTINE V-UNLOCK &#40;&#41;
    <TELL "The " D ,PRSO " does not have a lock." CR>
>
So, I lump always-open containers in with surfacebit objects, as I thought the determining factor was whether the game needs to print "The [x] is open." The main drawback to my handling, I think, is that the CONTBIT is not very important, but I think doing things this way has its benefits.

Here is some example code that uses the new verbs above:

Code: Select all

 <OBJECT BOX
     &#40;DESC "box"&#41;
     &#40;IN STARTLOCATION&#41;
     &#40;SYNONYM BOX&#41;
    &#40;FLAGS CONTBIT&#41;
    &#40;ACTION BOX-R&#41;
 >

 <ROUTINE BOX-R &#40;&#41;
    <COND &#40;<OR <VERB? OPEN EXAMINE CLOSE> <VERB? LOOK-IN>>
    	  <OPENABLE-RULES>
    	  &#41;
    &#40;<VERB? UNLOCK LOCK>
    <LOCK-RULES>
    &#41;
    >
 >
 
  <OBJECT DOLL
      &#40;DESC "doll"&#41;
      &#40;IN BOX&#41;
      &#40;SYNONYM DOLL&#41;
     &#40;FLAGS TAKEBIT&#41;
 >

 
 <OBJECT RED_KEY
     &#40;DESC "red key"&#41;
     &#40;IN PLAYER&#41;
     &#40;ADJECTIVE RED&#41;
     &#40;SYNONYM KEY&#41;
    &#40;FLAGS KEYBIT TAKEBIT&#41;
 >

Posted: Sat May 03, 2014 7:00 pm
by Roody_Yogurt
Recently, I was given help by vaporware so I could get better status line drawing in XZIP (z5) games going. Here are some updated ZIL files with the new code:
https://drive.google.com/file/d/0B_4ZXs ... sp=sharing

In the good news front, vaporware has been working on some opcode stuff lately, and some other interested parties are starting to take a look at ZIL. Progress!