Where do we go from here?

[Roody_Yogurt]

The Hugo Open House Competition was a great success. We received several more entries than I expected and the level of quality was very encouraging. All in all, I was really impressed with how people rose to the challenge.

That said, not everyone who wanted to partake in the competition was able to, and even those of us who finished a game might want some kind of other deadline to help motivate us to keep going hard into 2012.

ICJ has been talking about the Spring Thing ( http://www.springthing.net/2012/ ) game he is writing on his twitter feed. Royce Odle recently decided on the premise of his next game, too. I plan to finish the game I meant to write for the Hugo Comp that didn't make it, and if I have enough time, I'd like to whip a larger piece into shape for the Spring Thing, too.

This year, the Spring Thing Comp will have a crazy amount in cash prizes, if anyone needs that kind of incentive. Plus, this is just another venue where it'd be great to give Hugo a strong showing. The only thing to keep in mind is that Spring Thing is for games that are larger than "IF Comp"-sized, taking more than two hours to beat, so writing a Spring Thing game will be no small task.

So, I'm not really going to suggest that we all enter the Spring Thing Comp, but if anyone wants to, they should post to this thread with their personal IF goals for the year or offer an idea to challenge/motivate all of us. Someone is even welcome to announce another Hugo Minicomp if they want, as long as they do it with the understanding that some of us won't be able to partake.

I welcome your ideas!

[Flack]

Here's my thoughts.

Until the Spring Fling is over, I'd suggest not holding any more mini-comps. I think the forum would be best served for technical support questions and answers between now and then.

After that, I would like to see another mini-comp, but maybe we could do some themed ones? Like, let's all write a space game, or a horror game, or a game with graphics ... stuff like that. Each theme could potentially push people outside their comfort zone a little and give them a new angle to think about. Just a thought.

[Bainespal]

So, I'm not really going to suggest that we all enter the Spring Thing Comp, but if anyone wants to, they should post to this thread with their personal IF goals for the year or offer an idea to challenge/motivate all of us.

My "longer" Hugo project is nearly done, and there are many reasons why I should complete it. Beyond that, I'll definitely announce it on Intfiction and list it on the IFDB, as well as upload it to the Archive to score another point for the Hugo games directory. I'm undecided about trying to enter the Spring Thing.

If I really wanted to, I could probably release it soon, after testing it. But I'm not in a hurry at all. I want to take the time to add some polish, like a full-screen, colored ASCII art, retro-style.

Until the Spring Fling is over, I'd suggest not holding any more mini-comps. I think the forum would be best served for technical support questions and answers between now and then.

After that, I would like to see another mini-comp, but maybe we could do some themed ones? Like, let's all write a space game, or a horror game, or a game with graphics ... stuff like that. Each theme could potentially push people outside their comfort zone a little and give them a new angle to think about. Just a thought.

This minicomp was a huge success for me; I actually did something that other people were able to see. I like the idea of themed minicomps in the future.

("Spring Fling" is what my high school called its prom-like social event. *Ugh.*)

[Ice Cream Jonsey]

Short term, involving Hugo games and not, I want:

1) To write a review on IFDB for Hallow's Eve.
2) To finally finish Savoir-Faire.
3) To complete my entry for the 2012 Spring Comp.

I thought games were due May 31st. They are due April 2nd! So this means I really gotta get faster. No sweat. I am going to do the thing where you write your game as a text file and then implement it as a game. This resulted in a linear experience last time, but I will be writing the new one with interactivity in mind. In this way, it will be like how Mike Sousa and I collaborated on No Time To Squeal.

I will probably put a cash bounty on a Hugo web interpreter somewhere in all that.

[Roody_Yogurt]

2) To finally finish Savoir-Faire.

Savoir-Faire is a game I'm always fairly certain I've played to completion yet can never really remember what it was about. I think I'm due to replay it.

[loafingcoyote]

I have three IF goals for the near future:

First, I want to maintain momentum built up during the Hugo Comp by entering the Spring Thing. I wonder, however, if it's possible to write a longer piece in two and a half months? Having never written one, I wouldn't know. Conceiving an idea, writing it and having it beta-tested in that time sounds like a hard pace. I think I'll start a game and then if I'm not far enough along by march 1st(one and a half months away!), I'll save it for the annual comp.

Second, I would like to learn more about the inner workings of Hugo. The Hugo comp was a great way to get back into Hugo but I have a lot to learn. I wish I could get my hands on a physical copy of the Hugo manual. I wonder if anyone has ever printed out a hard copy of the library and if that helped?

Third, I need to catch up with contemporary IF. That means playing all the Hugo games that I haven't gotten to yet and some of the better offerings in other languages.

[Flack]

I'm one of the least qualified people present to chime in, but 2 1/2 months for a medium-sized game is definitely doable, but if you're talking about, what, 10 weeks total, I'd shoot for something like 6 or 7 weeks for development and 3 to 4 weeks for beta testing the game, fixing bugs and adding features, and then re-testing to make sure that you didn't introduce any new bugs while fixing the first ones.

One thing I found with beta-testing ... well I found a couple of things, actually, but one thing I found was that even when people have good intentions, they can drag their feet when it comes to playing your game. I think I sent Hangar 22 out to a dozen or so people and got comments back from three or four. Another thing ... man, I think the coolest part about writing a text adventure is reading through people's transcripts and seeing exactly how they've been interacting with this world you created, but you'll find all kinds of weird things that people try that you'll need to account for. Sometimes it's simple things like adding synonyms to objects or adding different ways to interact with objects. In some cases though you'll find that players got stumped, or confused, or ran around in circles for far too long. Puzzles you thought were hard can end up being easy, and puzzles you thought were easy can end up being difficult. You might see your testers flounder, get frustrated, get the game in an unwinnable state ... and at that point you've got to fix stuff and get them to test it again. After all the hell I put my testers through, I felt like next time I might actually pay people to test my game or something, hah.

[Roody_Yogurt]

Second, I would like to learn more about the inner workings of Hugo. The Hugo comp was a great way to get back into Hugo but I have a lot to learn. I wish I could get my hands on a physical copy of the Hugo manual. I wonder if anyone has ever printed out a hard copy of the library and if that helped?

I think the manual was originally printed by cafepress.com or somebody. In any case, it was a site where it didn't actually cost Kent anything to set up. We've requested that he put the book back up for sale. I imagine, given enough time and enough prodding, he will. Personally, other than the first read-through, I find all of my research goes to the electronic version (in fact, I lent my book to pinback). Only in the last couple years did I realize that Adobe Reader allows you to make comments on PDFs. I use the comment system to mark passages I want to remember (occasionally, I'll even find a mistake in the book!). Anyhow, you can download a version with some comments already-in-it at: http://roody.gerynarsabode.org/hugo_book.pdf

As far as the library itself goes, I've never printed it out. It's just been a lot of text searching. It's helpful to have a text editor that does the multiple-file-search thing (or an external program like TextCrawler) to pull instances up quickly. Currently, in my copy of EditPlus, the Hugo Library is its own project since the built-in "find in files" lets my search by project.

Anyhow, the most important things I've learned about dealing with the library have been:
1. Learning the importance of the "replace" function
You've written enough Hugo code that I assume you are well familiar with replace, but it was a big step for me when I realized that Hugo was designed with this feature so you didn't feel like you're almost "ruining" the library for every game as you modify each little thing to do what you want. Using and understanding "replace" helps you write better code. I'm sure there was an equivalent in Inform 6, but when I wrote in I6, I didn't know it and my first game was much worse for it.

2. Learning how the message system works
It's only been in the last several months that I really noticed how Hugo so consistently separates routine "machination" code from their messages. Now I'm starting to do the same thing with my own utility and verb routines, which I imagine will help anyone who uses my code one day. I wrote an entry about messages at our Hugo By Example site here: http://hugo.gerynarsabode.org/index.php?title=Messages

But yeah, there's really no substitute for looking at the code itself. Only in the last couple months did I realize that before and after properties were called by the routines BeforeRoutines and AfterRoutines. Up until that point, I thought it was some mystical engine-based thing.

Going through your game line by line with the debugger really helps towards those kinds of revelations, too.

Third, I need to catch up with contemporary IF. That means playing all the Hugo games that I haven't gotten to yet and some of the better offerings in other languages.

Some noteworthy games from the last several years-

I would check out ICJ's games to see the games that have been carrying Hugo's reputation for the last number of years. He does a great job of telling stories not told in IF with a presentation style that no one else matches.

Violet by Jeremy Freese- The actual puzzles in the game are basically old school, but this game uses narrative voice just awesomely- so well done it's hard to believe it was Mr. Freese's first game.

The C.E.J. Pacian games, Rogue of the Multiverse and Gun Mute-
Both of these games have really interesting takes on the action genre, IMO.

King of Shreds and Patches-
There are some things about this game that bug me, but what really impresses me about this game is how it handles the ASK/TELL convention. I really think its handling is basically perfection (as far as ASK/TELL goes).

The Jim Munroe games, Everybody Dies and Roofed-
Both of these have interesting settings/premises.

(There are probably other awesome games I haven't yet played myself.)

[loafingcoyote]

I'm one of the least qualified people present to chime in, but 2 1/2 months for a medium-sized game is definitely doable, but if you're talking about, what, 10 weeks total, I'd shoot for something like 6 or 7 weeks for development and 3 to 4 weeks for beta testing the game, fixing bugs and adding features, and then re-testing to make sure that you didn't introduce any new bugs while fixing the first ones.

I was wondering exactly how to budget my time so this is a big help, thanks!

Another thing ... man, I think the coolest part about writing a text adventure is reading through people's transcripts and seeing exactly how they've been interacting with this world you created, but you'll find all kinds of weird things that people try that you'll need to account for. Sometimes it's simple things like adding synonyms to objects or adding different ways to interact with objects. In some cases though you'll find that players got stumped, or confused, or ran around in circles for far too long.

Yeah, I'm totally sold on transcripts. Bainespal sent me some transcripts of Hugo Clock last week and they were pure gold. I corrected tons of errors this way. For instance, I wondered why he kept bumping into walls when I realized that I hadn't given exit descriptions to 4 or 5 rooms. An amazing oversight that I probably wouldn't have caught otherwise.

It was also very entertaining. When I saw him literally banging his head against the machine when it spit the blocks back onto the floor for the 50th time; well, I laughed till I cried!

[Roody_Yogurt]

As far as the Hugo Library goes, I forgot to also mention that I've been trying to explain the more obscure hugolib routines at Hugo by Example ( http://hugo.gerynarsabode.org/index.php ... y:Routines ). We still have a long way to go (the biggest instigation for me to write new pages is when I run into things I need clarification on, like, exactly what is the difference between WhatsIn and ListObjects? ), but there might be something there that can help.

[Roody_Yogurt]

Other personal IF goals this year:

1. Play through, map, and review Peter Killworth's Doom series: http://ifdb.tads.org/search?searchfor=s ... oom+series
2. Despite having enough on my plate IF-writing-wise, if there is another Indigo Comp type minicomp ( http://ifwiki.org/index.php/Indigo_New_ ... e_Speed-IF ), I'd like to try my hand at writing a game in ZIL.
3. Generally, I'd like to get better about contributing reviews and such to http://ifdb.tads.org .
4. Write some more extensions. Next, I'm thinking of doing one that fakes the Inform cover art system.
5. I hope to make it to at least one IF-related gathering this year. I figure I'll probably shoot for the Boston gathering, whenever it ends up being, but no matter where, it'd be good to make one.

[loafingcoyote]

Personally, other than the first read-through, I find all of my research goes to the electronic version (in fact, I lent my book to pinback). Only in the last couple years did I realize that Adobe Reader allows you to make comments on PDFs. I use the comment system to mark passages I want to remember (occasionally, I'll even find a mistake in the book!). Anyhow, you can download a version with some comments already-in-it at: http://roody.gerynarsabode.org/hugo_book.pdf.

As far as the library itself goes, I've never printed it out...

I'm sure you're right; the digital version of both the book and the library are far more functional. I'm mostly interested in the book because it would be cool to own and I occasionally like getting away from a computer screen.

Anyhow, the most important things I've learned about dealing with the library have been:

1. Learning the importance of the "replace" function
You've written enough Hugo code that I assume you are well familiar with replace, but it was a big step for me when I realized that Hugo was designed with this feature so you didn't feel like you're almost "ruining" the library for every game as you modify each little thing to do what you want. Using and understanding "replace" helps you write better code. I'm sure there was an equivalent in Inform 6, but when I wrote in I6, I didn't know it and my first game was much worse for it.

2. Learning how the message system works
It's only been in the last several months that I really noticed how Hugo so consistently separates routine "machination" code from their messages. Now I'm starting to do the same thing with my own utility and verb routines, which I imagine will help anyone who uses my code one day. I wrote an entry about messages at our Hugo By Example site here: http://hugo.gerynarsabode.org/index.php?title=Messages

These are good points. I was aware that most routines could be replaced but I hadn't considered that this was true for any routine. The only routines I've replaced, up to this point, are verb and message routines. Modifying other types of routines with "replace" opens up some interesting possibilities.
Concerning the message system. You know, at first this annoyed me, since I saw it as another hurdle to learning the language. Now I think it's brilliant, since you can change either one without affecting the other, and it really isn't that complicated. It'll take a little while to get used to it, but I'm going to start doing this(for verbs, routines; everything).

But yeah, there's really no substitute for looking at the code itself. Only in the last couple months did I realize that before and after properties were called by the routines BeforeRoutines and AfterRoutines. Up until that point, I thought it was some mystical engine-based thing.

This is a great point. My understanding of what is done automatically by the Hugo engine as opposed to what is handled by the library is still too fuzzy. I suppose that studying the manual and library closely is the best way to deal with this.

Some noteworthy games from the last several years-

I would check out ICJ's games to see the games that have been carrying Hugo's reputation for the last number of years. He does a great job of telling stories not told in IF with a presentation style that no one else matches.

Violet by Jeremy Freese- The actual puzzles in the game are basically old school, but this game uses narrative voice just awesomely- so well done it's hard to believe it was Mr. Freese's first game.

I'm starting with Necrotic Drift. I was blown away by the opening scene this evening. I'm very excited!

My first non-Hugo will be Violet. I like what the IFDB has to say about it.

As far as the Hugo Library goes, I forgot to also mention that I've been trying to explain the more obscure hugolib routines at Hugo by Example ( http://hugo.gerynarsabode.org/index.php ... y:Routines ). We still have a long way to go (the biggest instigation for me to write new pages is when I run into things I need clarification on, like, exactly what is the difference between WhatsIn and ListObjects? ), but there might be something there that can help.

Hugo by Example is a tremendous help. Those obscure routines that you refer to can be tricky to figure out how to use properly. Having examples makes all the difference to me.

Believe it or not, between what I've read here and in the library, as well at Hugo by Example; I've made significant strides toward a more fundamental understanding of Hugo. Thanks for the help!

[Roody_Yogurt]

I was very curious to hear if you found HxE to be any help, so I am pleased to hear that. If you come across any routines or anything not covered and want us (me) to look into it, I'd be happy to write something up.

re: replace. Interestingly, replace can be used for object classes, too. It doesn't come up often, but it can save you a little effort when it does.

As far as messages go, I just recently decided that I'm going to handle messages like this in my extensions from now on:

Code: Select all

if not NewMessages(&CoolPause,1)
	"PRESS A KEY TO CONTINUE";

Instead of having all of my extensions fighting over one NewMessages routine, from now on, I'm just going to check for the existence of a new message before I go with the default. This should keep the code both self-contained yet easy to customize.

This kind of thing does not work with Hugo Library message routines like Message(), VMessage(), and so on, as those routines don't actually return true.

[Roody_Yogurt]

Besides those other things, there are some other pages on Hugo By Example that the mere writing made me learn something (or I'm just proud of):

Grammar Tokens- It took me writing this page to learn how to use routines as grammar tokens, and it can be a useful trick from time to time.

ASCII values- As someone with limited programming experience for coding in Hugo, it took familiarization with ASCII values before I could properly read capitalization, decapitalization, and alphabetizing code.

Sort.h- Sort.h is a library contribution written by Christopher Tate some years ago, but it really is just a super-useful utility routine. It doesn't take much modification to sort just about whatever you want. I've used it in the past for both the alphabetization of strings, and I use it in my WIP for sorting some property elements.

CheckReach- I got a lot of satisfaction writing this one just because CheckReach was one of those routines where my first understanding of the routine was totally wrong, so it was just good to clear that up.

text to- "text to" is a super-useful command. Originally, I researched it just because I wanted to be able to be able to count the characters used in the "SCORE / MOVES" section of the statusline (so they were always correctly positioned), but once you know how to use it, you'll find uses for it pop up quite enough.

Context Menus- Context menus are basically the most work you can put into the game that 99% of people will never notice (I personally never use them), but learning how to do them was still kind of fun.

Configuration files- Learning to do configuration files was also kind of fun. I wrote a joke game last year where text entered in one game showed up in another game with it.

Lastly, one of the better things HxE does, IMO, is that it emphasizes the difference between HugoFix and the Debugger. Personally, I went a long while before I learned that, and the debugger's seemingly-complicatedness kept me from using the much-more-straightforward HugoFix debugging suite.

[Roody_Yogurt]

Oh yeah, one other thing...

Loafingcoyote, I was very impressed with the automaton in your game. You don't have to share any code, but I'd love to hear about the design behind it. Did you use character scripting?

That said, if you are especially proud with the coding behind any mechanics in your game, yeah, feel free to share.

[loafingcoyote]

Oh yeah, one other thing...

Loafingcoyote, I was very impressed with the automaton in your game. You don't have to share any code, but I'd love to hear about the design behind it. Did you use character scripting?

That said, if you are especially proud with the coding behind any mechanics in your game, yeah, feel free to share.

Probably the aspect of IF that I love the most is complex NPC behavior. It's an area that I plan to explore in depth later.

At first I did use character scripting, but removed it since I thought it was contributing to a problem that was actually something else. By the time I had figured out the problem, I had already implemented the automaton's movements another way.

Most of the code used to move the automaton was written in a 14 hour coding marathon. I thought everything was ready to go when the code was written for him to find the waste baskets in the proper order and then find his way back to the trash receptacle. I wept bitter tears when I realized that he would have to take the waste baskets back to their original spot.

At hour 11 I again thought everything was ready to go. I put the trash receptacle in the reactor and set the automaton to emptying waste baskets. Apparently the reactor reminded him of home because he refused to leave. A couple of terrible hours later I hacked together a routine that moved the automaton out of the reactor if he was there more than two turns(called, fix_my_bug, by the way). Later I found the simple solution; I had been lazy coding something that I had thought wouldn't be needed.

The code...well, it was written hastily, so it's not commented and pretty rough around the edges. I tell you what; its not ready for the public, but I'll add a few comments and send you a pm with a link to it. After the Spring Thing I'll clean it up and release it for public scrutiny.

Also; about the message system... I've been experimenting with this and am beginning to really like it. I also glanced at the source code for Tales of the Traveling Swordsman and, I must say, this is some elegant code. I didn't want to ruin the game experience so I didn't study it too closely yet. It seems to be the gold standard for how to use the message system correctly. Needless to say, TTS has now moved up to #2 on my play list!

[Roody_Yogurt]

At first I did use character scripting, but removed it since I thought it was contributing to a problem that was actually something else. By the time I had figured out the problem, I had already implemented the automaton's movements another way.

I figured this was the case, as designing for character scripting wouldn't have been any easier. Character scripting, as it exists in Hugo, is best for NPC movements that are already set in stone. Your automaton would involve writing character routines and character scripts that are much more adaptive than what has been presented before. Still, the result might have been pretty to look at, and I look forward to the day that a Hugo game pushes those limits.

Also; about the message system... I've been experimenting with this and am beginning to really like it. I also glanced at the source code for Tales of the Traveling Swordsman and, I must say, this is some elegant code. I didn't want to ruin the game experience so I didn't study it too closely yet. It seems to be the gold standard for how to use the message system correctly. Needless to say, TTS has now moved up to #2 on my play list!

Yeah, Merk's code is a marvel of organization, and TTS is a very nice game to boot. He really takes separating-messages to its limits; when trying to figure out the mechanics of one scene in "Trading Punches," it was a little hard for me to even find the code for the scene as the printed text was so far away from everything else. So I have mixed feelings about that, but I'll agree that his code is very elegant.

I'd also suggest looking at his Distress game, as he has a computer in that (and I find computer interface interpretations in IF interesting).

TTS also helped bring a couple other things to my attention. Merk was the first to have code that checked if an interpreter used the glk api (like the Gargoyle interpreter). Without that, it probably never would have occurred to me to try to check for anything, and I would have no idea how to optimize games for multiple kinds of interpreters. Merk's method involves using a function from system.h, but I've found through experimentation that all you really need to do is check display.windowlines in the main window.

Some of his string-oriented routines helped prompt me to get a better understanding of strings, too.

[Alan Parsons]

Where do we go from here? It's hard to say, with these games people play.

[loafingcoyote]

He really takes separating-messages to its limits; when trying to figure out the mechanics of one scene in "Trading Punches," it was a little hard for me to even find the code for the scene as the printed text was so far away from everything else. So I have mixed feelings about that...

It's funny that you should say this, because my first inclination was to say that he uses the message system "to a fault".

TTS also helped bring a couple other things to my attention. Merk was the first to have code that checked if an interpreter used the glk api (like the Gargoyle interpreter). Without that, it probably never would have occurred to me to try to check for anything, and I would have no idea how to optimize games for multiple kinds of interpreters.

Thanks for the heads up on glk. I checked out Gargoyle and, there's no way around it; I'm underwhelmed with its interpretation of Hugo story files. I dug around and found an ini file for TTS. It does look better but is still not as good as the Hugo Engine or Hugor. I also found the ini files on HxE but they didn't seem to change anything(the problem could very well be on my end though, given my unfamiliarity with the interpreter).
I can see the advantage of having an interpreter that can handle many different formats. It's just disappointing that it doesn't seem to take advantage of all the neat things Hugo can do.

Merk's method involves using a function from system.h, but I've found through experimentation that all you really need to do is check display.windowlines in the main window.

I'm going to have to learning more about this. It appears to be something all Hugonauts should know.

[Roody_Yogurt]

The thing that bugs me most about Gargoyle is that, for games like TTS that show graphics in the main window, Gargoyle rips the file from the resource file and dumps it in the working directory. I just find the effect distasteful.

As far as the .ini files go, they should work if they are in the same directory as the game file (and have the same name). garglk.ini (in the Gargoyle directory) explains where it looks for configuration files and which ones override other ones.