Jolt Country

This thread explains the implementation of a teleporter in Hugo. Due to lack of means to create tables, code is marked in yellow, file names in violet.

Now, the first thing to ask is, how do you do an immediate move from room to room. Well, it's really simple. You call moveplayer(I) [hugolib.h] where I is the room to go to.

Now, all you have to do is figure out how to determine what the room is. In Teleporter Test, I first had to decide how to do that. What I did was, I created the following attributes:

attribute Teleport_incoming ! Room can be teleported into
attribute Teleport_Outgoing ! room has a teleporter pad (can teleport out)
attribute roomtype ! to flag rooms for teleporting
attribute List_Incoming_Only ! can only teleport to an inbound Teleport_incoming spot
attribute List_Outgoing_Only ! can only teleport to another teleport pad

In the list of rooms, the first room that I want to be able to display is given the following attribute to its description
roomcount 1
the teleport lister ignores all rooms until it finds one with this value (this way it doesn't list or look at the nothing object). Roomcount 1 is only used once in the game.

A room that has a teleporter is an incoming only, outgoing only, or both. So you add one or both of the following to the room's description
is Teleport_incoming
is Teleport_outgoing
depending on whether you want the room an entry point, an exit point, or both.

The list routine will show all teleporters, incoming and outgoing. To restrict this, you put in one or the other in the room's description:
is List_Outgoing_Only
is List_Incoming_Only
Now, I could have had the room lister use the teleport pad in the room you're in to restrict what it shows, but because it was a demonstration and I wanted to be able to have a room that could teleport into both an outgoing only room as well as to a teleporter pad, I had to have the ability to show everything.

Now, the lister has to know when it's run out of rooms so that it isn't searching objects that aren't rooms. So, after the Main routine I have an empty room as the last declared room in the game (or at least, the last one that can be listed by the teleporter list routine):

room emptyroom "(empty room)"
{
roomcount 2
}

When the room lister finds a room with attribute roomcount 2 it stops listing rooms. Now, I had to add a teleport command, At the bottom of verblib.g I added the following:
verb "teleport"
* DoTeleport
* player_character DoTeleport
* player_character "to" DoTeleport

This allows the user to type teleport or teleport me

I'll continue this in the next message.

The room lister and teleport program is the routine DoTeleport.

First thing I check that the room the user is in is an outgoing teleport. If not, I tell them they're not able to teleport there, and quit.

I take advantage of a simple feature of Hugo, rooms are just objects, with a number like everything else. So I just start with object 1, check that the object is a room, then look to see if it has attribute roomcount 1.

for (i=1; I<objects;I++)
{
if I is roomtype
{
! list the room if allowed
showroom=false
! skip all rooms until the room has a roomcount property and it's 1
if I.roomcount = 1 ! can now list rooms
listokay = true
if I.roomcount = 2 ! stop now, end of list
break

I check listokay, then I look to see whether the room has either incoming or outgoing teleporter, and tne determine which ones I can list. I create an array of every room number that is a valid place the user can teleport and list that room along with its name.

At the end, I ask the user to enter the number of the room (which is the number it was listed, not its object number), then I use that to get the room's object number, and I pass that to moveplayer, which does the work.

Well, if you ask for input, and you try putting in a number, it's not in the list of commands, and the interpreter will give an error that it doesn't understand the input, so I add them as fake commands in verblib.g:
verb "0"
* "0" "1" "2" "3" "4" "5" "6" "7" "8" "9"
* "10" "11" "12" "13" "14" "15" "16" "17" "18" "19"
* "20" "21" "22" "23" "24" "25" "26" "27" "28" "29"
* "30" "31" "32" "33" "34" "35" "36" "37" "38" "39"
* "40" "41" "42" "43" "44" "45" "46" "47" "48" "49"
* "50" "51" "52" "53" "54" "55" "56" "57" "58" "59"
* "60" "61" "62" "63" "64" "65" "66" "67" "68" "69"
* "70" "71" "72" "73" "74" "75" "76" "77" "78" "79"
* "80" "81" "82" "83" "84" "85" "86" "87" "88" "89"
* "90" "91" "92" "93" "94" "95" "96" "97" "98" "99"
verb "1"
* "100" "101" "102" "103" "104" "105" "106" "107" "108" "109"
* "110" "111" "112" "113" "114" "115" "116" "117" "118" "119"
* "120" "121" "122" "123" "124" "125" "126" "127" "128" "129"
* "130" "131" "132" "133" "134" "135" "136" "137" "138" "139"
* "140" "141" "142" "143" "144" "145" "146" "147" "148" "149"
* "150" "151" "152" "153" "154" "155" "156" "157" "158" "159"
* "160" "161" "162" "163" "164" "165" "166" "167" "168" "169"
* "170" "171" "172" "173" "174" "175" "176" "177" "178" "179"
* "180" "181" "182" "183" "184" "185" "186" "187" "188" "189"
* "190" "191" "192" "193" "194" "195" "196" "197" "198" "199"

Notice none of these has a room to go to. As a result, it puts them in the dictionary but doesn't make them commands you can type. (The actual list goes 7 more to include all the way up to 999 so I can handle any 3 digit number.)

This should give you a general idea of how it is done, and the source code will be available shortly.

The entire source and compiled files for Teleporter Test, just basically a dump of the entire directory, is available at Teleporter_Test_Source.zip, some of it is redundant or duplicate because I just wanted to copy everything, it's 7.6 megabytes. Source, binaries, sounds, everything, including an HTML copy of the above messages in index.htm in the main directory in the zip file.

Thanks, I've been taking a look at this. There's still a lot that I have to look at closer, but I have some suggestions to get us started:

1. First off, you don't really want to edit the Hugo library files yourself. When you do that, your code becomes harder to share and is incompatible with all future releases of the library. Optimally, you want to use the replace function ( http://hugo.gerynarsabode.org/index.php?title=Replace ) if you need to tweak object and routine behavior. That way, everyone is using the same library and is at the same starting point.
2. Hugo already has a built-in method for determining if something is a room. That's what the "type" property is for. So, where you have:

   Code: Select all

   if I is roomtype
   

   , you could just have

   Code: Select all

   if I.type = room
   

   I understand that sometimes it's quicker to write your own functionality than to learn the language itself, but FYI, it's there.
3. Your grammar for "teleport" is wrong. It should be:

   Code: Select all

   verb "teleport"
   * DoTeleport
   * (you) DoTeleport
   * (you) "to" DoTeleport
   

   Hugo can only use a single object, not a class, as a grammar token (and it has to be in parentheses). You'll notice that if you move another object within scope using HugoFix with the original code, it'll allow "teleport any-object-that-is-within-scope".
   
   Also, I'm not sure exactly what you're doing with that last line. Maybe originally, you were going to accept "teleport me to ###" but forgot to add the "number" token?
4. Lastly, I noticed that you gave the game a new IFID for the latest version. I go over the rules for IFIDs here: http://hugo.gerynarsabode.org/index.php ... at_IFID.21 (the gist is, new versions do not get a new IFID number).
5. Instead of adding all of those numbers to the dictionary table, you could use StringToNumber to translate parse$: http://hugo.gerynarsabode.org/index.php ... ngToNumber

Anyhow, thanks again for sharing this. Always interesting to see how others do things.

[quote="Roody_Yogurt"]but I have some suggestions to get us started:

1. First off, you don't really want to edit the Hugo library files yourself.
   I was kind of in a hurry. Besides, it wasn't intended to be a serious game (other than I threw the actual puzzle where you had to find the mallet and smash the meter in the upstairs room in as an afterthought so someone could do more than just demonstrate the teleportation system.)
2. Hugo already has a built-in method
   if I.type = room
   Again, the reason I did it was in response to Jonsey's message 5605 about implementing a teleporter, I wanted to do it as a "proof of concept." Had I spent more time reading the manual I might have spotted a few things. Plus, the manual isn't really known for its sterling levels of clarity and exposition, either!
   http://www.joltcountry.com/phpBB2/viewtopic.php?t=5605
   
3. Your grammar for "teleport" is wrong. It should be:

   Code: Select all

   verb "teleport"
   * DoTeleport
   * (you) DoTeleport
   [color=yellow]Yadda, yadda, yadda, I was in a hurry, I could have done better if I'd known more, I only spent about 2 hours writing it, etc. (Slinks off in shame.)[/color]
   
   Also, I'm not sure exactly what you're doing with that last line. Maybe originally, you were going to accept "teleport me to ###" but forgot to add the "number" token?
   [color=yellow]Sounds like the case.  Again, a lot of what I did was kluges just to get it to work so that at least it was a proof of concept that it could be done.[/color]
   [*] Lastly, I noticed that you gave the game a new IFID (the gist is, new versions do not get a new IFID number).
   [color=yellow]Yeah, I know, I found that one out later on, I hadn't seen the "no new number" rule and misread it into thinking you [i]do[/i] get a new number when it's changed.[/color]
   [*] Instead of adding all of those numbers to the dictionary table, you could use StringToNumber to translate parse$: http://hugo.gerynarsabode.org/index.php?title=StringToNumber 
   [color=yellow]Yadda, yadda, yadda, I was in a hurry, I only spent 2 hours on it, whine, whine, whine...[/color][/list]
   Anyhow, thanks again for sharing this. Always interesting to see how others do things.[/quote]
   
   I felt it was a pretty good result for a first try and that I only spent a couple hours doing it.  
   
   Since you mention it, when I do another one I'm going to see about using pristine system libraries and figure out where I have to include what I need to insert for the particular program's functionality.  I'm still trying to figure out from reading [i]Guilty Bastards[/i] how it's supposed to be able to have an image for each new location, how that's done.  I think I'll play the game a bit then come back and look at the code, I might understand what's going on better that way.

I would like to make a science fiction game with teleportation some day. Knowing me, I'll probably never get to it. But your code is there, and I would very much like to try it some day. Maybe if we have another Hugo Speed IF/mini-comp.

Although I feel guilty about allotting time away from my works in progress, last year's HugoComp was such a success that I'd like to do another one at the end of this year, too, but that'll only happen if there's enough interest for it. What do people feel about that?

I feel it is a delightful decision. I'll try to not just convert a story into game this year. :)

Roody_Yogurt wrote:Although I feel guilty about allotting time away from my works in progress, last year's HugoComp was such a success that I'd like to do another one at the end of this year, too, but that'll only happen if there's enough interest for it. What do people feel about that?

You certainly shouldn't feel obligated to step back from your projects for Hugo Comp, and I know the feeling of not wanting to work on something new when I still have old projects undone.

For me, though, I never finish anything at all without a deadline and without people to hold me accountable to that deadline. I cranked out "World Builder" quickly for last year's comp, and the only reason that I put out a half-baked update was because you encouraged us all to bugfix and re-release our entries. I had meant to release a third version, but after having fixed at least one major bug, I stalled out and lost motivation. Then, I decided to do Marco Innocenti's Andromeda Comp, so I again cranked out a crude game far too fast. I've fixed some things and added new code to "Tree and Star," and my plan was to release the next version as a public beta. But now I'm running up against the big Comp; I don't want to distract betatesters and authors from their work before the Comp, and of course, everyone will be busy during the Comp.

I would kind of rather finish my updates for "World Builder" and "Tree and Star" before starting a new project. However, I would never have written either of those without the deadlines, and I know it's only my own fault that I haven't finished my new versions yet. I know better than to second-guess an opportunity to actually make a game and release it. On my own, I never get anything done.

So, yes, I'd be interested in another Hugo Comp. However, I also want to fix my existing Hugo games, and I wouldn't be particularly disappointed if there were no Hugo Comp, either.

I think I'm also am more likely to finish a small game for a minicomp than I am to make great strides in my WIPs; I only feel bad because my WIPs are like neglected children (that isn't to say that none of my WIPs are small enough to easily pass for a minicomp submission, though, so there's always that).

So I personally am in the let's-do-this camp. I mean, a well 'attended' HugoComp will increase the number of Hugo games released this year by like a third. I just didn't want to suggest something if we people found it more of a hindrance than anything.

We've already rallied enough enthusiasm that I feel this should happen. That just brings about the question, how do we want to do this? Do we want another theme? If so, do people have suggestions? Also, heh, I just remembered that my robot-themed game from last year is one of the WIPs I've been working on...

There's also the timeline. I'd like to start a bit earlier this year so we can be harder about the end-of-the-year timeline. Maybe we could start it on November 2nd, the Day of the Dead (Thanksgiving is too close to the end of the month, and I just like the Day of the Dead, is all), with the final deadline being January 31st... Or possibly we could have an earlier deadline with the betatested-games-release being the 31st.

November 2nd will still be in IF Comp season, but it'll be mostly over by then and I see no harm in a little overlap.

Bainespal wrote:But now I'm running up against the big Comp; I don't want to distract betatesters and authors from their work before the Comp, and of course, everyone will be busy during the Comp.

I wouldn't worry about this kind of thing. I think people like to use the Comp as an excuse for things not getting done (or posts going ignored or whatever), but if your game is fun and/or intriguing enough, people'll find time to look at it.

Bainespal wrote:I would kind of rather finish my updates for "World Builder" and "Tree and Star" before starting a new project. However, I would never have written either of those without the deadlines, and I know it's only my own fault that I haven't finished my new versions yet. I know better than to second-guess an opportunity to actually make a game and release it. On my own, I never get anything done.

So, yes, I'd be interested in another Hugo Comp. However, I also want to fix my existing Hugo games, and I wouldn't be particularly disappointed if there were no Hugo Comp, either.

I've started "Tree and Star" but still haven't played too far into it, as I decided I should play the original Andromeda game first, and I find that one as kind of inaccessible for my tastes.

Still, I'd really like to help you iron out those daemon/response problems with "World Builder" at some point.

I cast my vote strongly in favor of another Hugo comp.

Last year was a huge success and apparently the only way that anyone will actually play a Hugo game is if it's entered as part of a comp so, yeah, count me in.

Roody_Yogurt wrote:Do we want another theme? If so, do people have suggestions?

Yes, although I'm not sure what. I have some one-room game ideas but those are hard to do well, so I'm not sure that's a good idea. A theme really helps me focus though, so I would like to see one no matter what it turns out to be.

Roody_Yogurt wrote:Maybe we could start it on November 2nd, the Day of the Dead (Thanksgiving is too close to the end of the month, and I just like the Day of the Dead, is all), with the final deadline being January 31st... Or possibly we could have an earlier deadline with the betatested-games-release being the 31st.

I think the timing is just fine. Two months should be plenty of time to make a decent mini-comp game, and that leaves time in between now and then for unfinished projects and the annual comp.

I'm just glad to be getting back into IF. My summer work schedule was brutal!

loafingcoyote wrote:I'm just glad to be getting back into IF. My summer work schedule was brutal!

Awesome, glad to hear you're in. The comp will be much better for it. I was worried that your silence these past months was due to some disillusionment, but I am glad to hear that it was just life.

I shall endeavor to work on a game.

Roody_Yogurt wrote:I was worried that your silence these past months was due to some disillusionment, but I am glad to hear that it was just life.

Certainly not disillusionment with IF or IF'ers; no way. I was a bit drained after writing some extensions and a couple of small games in a short period of time, but that had little to do with my absence. It was almost totally work related.

You(Roody)may remember that I mentioned, several months ago, about having major conflict with a new supervisor at work. The situation deteriorated to the point that, after numerous verbal death matches between him and myself(and all my coworkers too), the offending supervisor became no more than an irritating figurehead. I've never been in a situation where one person was so universally despised. He's a tremendous pariah, most of his power has been stripped, and yet somehow he still finds a way to hinder us at every step. I'm convinced he's the stupidest person alive and.....my direct supervisor.

The situation isn't even close to being resolved, but at least our bosses have stopped trying to work us to death(for now).

Anyway, I'm sorry for ranting like this on the Hugo base, so I'll stop. The important thing is that I'm back and have time for IF again.

I think the first thing I'll do is to write a proof of concept game for a reactive agent planner extension I wrote last spring. It works but needs to be tested with a proper proof of concept game. It would be simple enough to write my own version of "Battle of Walcot Keep", but I wanted to do something a little more original.

I also need to familiarize myself with Roodylib. I can't believe all the great work you've done!

loafingcoyote wrote: You(Roody)may remember that I mentioned, several months ago, about having major conflict with a new supervisor at work .... The situation isn't even close to being resolved, but at least our bosses have stopped trying to work us to death(for now).

Oh yeah, now that you mention it, that rings a bell.

loafingcoyote wrote:Anyway, I'm sorry for ranting like this on the Hugo base, so I'll stop. The important thing is that I'm back and have time for IF again.

No worries. Good to have you back.

loafingcoyote wrote:I think the first thing I'll do is to write a proof of concept game for a reactive agent planner extension I wrote last spring. It works but needs to be tested with a proper proof of concept game.

Wow, sounds ambitious. Looking forward to that.

loafingcoyote wrote:I also need to familiarize myself with Roodylib. I can't believe all the great work you've done!

Well, Roodylib is very much a WIP (I update it far more often than I'd like), but each routine and object is commented with the reasoning for its existence but everything is very much up to debate. Feel free to share your thoughts here or at the Not Dead Hugo blog ( http://notdeadhugo.blogspot.com ).

loafingcoyote wrote:I think the first thing I'll do is to write a proof of concept game for a reactive agent planner extension I wrote last spring. It works but needs to be tested with a proper proof of concept game. It would be simple enough to write my own version of "Battle of Walcot Keep", but I wanted to do something a little more original.

Ok, now I have to admit that I didn't understand the phrase "reactive agent planner" when I read it. I initially read it as some kind of alchemical reagent-mixing deal, although "Battle of Walcot Keep" was a big clue that it was something else.

Anyhow, for anyone who was in my boat but did not yet look up the topic, here is a good page about it: http://www.ifwiki.org/index.php/Reactive_Agent_Planner

Sounds like the task has a lot of challenges to it. Some that I see:

• Writing efficient code- It seems that some variations of Nate Cull's original code runs slow on some computers, as this review by Emily Short can attest: http://www.ifreviews.org/index.php?analise=970
  Of course, it's harder to check for code efficiency as our computers get faster and faster, but it's still a nice goal to shoot for.
• Making the output prose pretty- Ideally, an extension would have several options on how the text is presented, like whether the player can be appraised of the actions of NPCs both in and out of scope, whether you can group the description of NPCs who share the same current action (so instead of "An archer aims at you. Another archer aims at you.", etc., it could be "A group of archers aim at you. Some barbarians run at you." or whatever), and whether you can, of course, randomize how certain actions are described (knowing your Hugo Clock code, I'd guess you have this one covered).
  
  Lastly, there's...
• Coming up with a good game idea for RAP- To be honest, I haven't heard of most of the games that use this system, and having opened "Battle", it's pretty easy for me to guess that most of them aren't especially entertaining. The idea is definitely a lofty goal, but I can imagine that coming up with the right game idea for it might be as hard as writing the extension itself.
  
  I was thinking that, since the NPCs' motivation is re-calculated every turn, it especially lends itself to a simple-minded-enemy-games like zombie invasions where, for the most part, they only pursue what they see (you'd have to increase their scope a bit more just to keep things interesting).

Anyhow, I'm not trying to be dismissive. I look forward to trying whatever you put together. I definitely see the goal as a challenge, though.

Roody_Yogurt wrote:Writing efficient code- It seems that some variations of Nate Cull's original code runs slow on some computers, as this review by Emily Short can attest: http://www.ifreviews.org/index.php?analise=970
Of course, it's harder to check for code efficiency as our computers get faster and faster, but it's still a nice goal to shoot for.

Yeah, I had heard about this problem and believe it too. I don't read I6(or T3) code very well, but I have had a good look at his RAP code. It didn't strike me as being very efficient, with a lot of duplicate code that runs in a roundabout way. After very little time studying the code I realized that it would have to be completely redone. All I took from Nate Cull's code are a couple of concepts and some naming conventions.

I don't mean any of this to be disparaging of his work, by the way, since it inspired me to do something similar. I just tried to make it more efficient and flexible.

Speaking of which, it may surprise you to find out that I already used the new RAP in my last game. I developed a version of it just as I was finishing Escape from Ice Station Hippo and used it to control Findbot's behavior while he was acting independently. The amount of code needed was tiny and the overall increase in the final size of the game was negligible. This was because my RAP is made up of two parts. The first is the core of the extension, which shouldn't be modified but is very small and (I hope)efficient. The second part can be as small or large as needed, depending on how complex you need your characters behavior to be. What I really like is that you can drop the RAP into the middle of a game and have it control all or just some of your npc's behavior(easily). Therefore it made sense for me to include it in a game with a single character.

Roody_Yogurt wrote:Making the output prose pretty- Ideally, an extension would have several options on how the text is presented, like whether the player can be appraised of the actions of NPCs both in and out of scope, whether you can group the description of NPCs who share the same current action (so instead of "An archer aims at you. Another archer aims at you.", etc., it could be "A group of archers aim at you. Some barbarians run at you." or whatever), and whether you can, of course, randomize how certain actions are described (knowing your Hugo Clock code, I'd guess you have this one covered).

This is a real problem but I like your suggestions. Adding switches which would tell it to not report certain actions or to group types of actions when a lot is going on might be the way to go. My RAP is in an early stage of development, so it's a good time to start considering these things.

I especial like what Emily Short had to say about it in the review you referenced above:

Emily Short's review wrote: I think the solution probably involves representing all the actions that are going to occur in a given turn as data, then running some algorithms on that data to discard anything too ineffective to be worth reporting, cluster related actions together into compound sentences and related sentences into paragraphs, introduce variations of phrasing, etc. Which would be a massive undertaking to write, frankly, even after you have a fully functional set of RAP routines for your NPCs.

This is a brilliant idea and I think she's a bit too pessimistic about how hard it would be to pull off. It would be a lot of work, but it could be as simple as assigning values to character properties. I'll give an example:

There are three characters in a room with the player. The RAP determines that two of the characters want to move north and can legally do so, while the third character moves east. It doesn't move them yet, it just assigns a value to a predetermined property. The character property misc #2 could be used for moving, with 1 representing a move north, 2 east, 3 south, ect...Therefore, the first two characters misc #2 is assigned to 1 and the third is given a 2. After the rap has finished assigning all values, it then calls another set of routines. These determine what characters are acting that turn, which ones are acting within the scope of the player and what messages should be eliminated or grouped.

Thus you get:

• Tom and Dick move north. Harry moves east.

As opposed to:

• Tom moves north.
  
  Dick moves north.
  
  Harry moves east.

Roody_Yogurt wrote:Coming up with a good game idea for RAP- To be honest, I haven't heard of most of the games that use this system, and having opened "Battle", it's pretty easy for me to guess that most of them aren't especially entertaining. The idea is definitely a lofty goal, but I can imagine that coming up with the right game idea for it might be as hard as writing the extension itself.

This is my biggest problem right now. I need to make a proper proof of concept game, but it's hard to avoid the zombie attack/rpg battle genre. I have a couple of fairly original ideas already, but they don't stray too far from the lots-of-npcs-wandering-around-attacking-each-other strain.

What doesn't bother me, though, is whether anyone will actually use it or not. I know that very few Inform and Tads users have made use of Nate Cull's RAP, so the prospects for anyone using mine are slim. I really don't mind, since I believe that the mere existence of a RAP for Hugo is just one more thing to make it a more attractive option for future IF authors, even if they have no plans to use it.

Roody_Yogurt wrote:I was thinking that, since the NPCs' motivation is re-calculated every turn, it especially lends itself to a simple-minded-enemy-games like zombie invasions where, for the most part, they only pursue what they see (you'd have to increase their scope a bit more just to keep things interesting).

All of your points are valid and I appreciate them, but you have to admit that this sort of game, done well, would be pretty cool :)

Anyway, Friday night I decided to write a small sample game to demonstrate where the project is at the moment. I meant to have it ready today but was diverted, so it should be ready tomorrow(Sunday). It isn't a full blown game; just a toy to be played with and hopefully fun too! I'll introduce it in a new thread. This one has gotten slightly off topic!

-lc

Jonsey, shouldn't this thread on the IF comp be split off? This has nothing to do with my example teleporter implementation and how I did it, and I think it's confusing to keep it as part of that.

Jonsey!!



SPLIT THAT SHIT!

Tdarcos wrote:Jonsey, shouldn't this thread on the IF comp be split off? This has nothing to do with my example teleporter implementation and how I did it, and I think it's confusing to keep it as part of that.

TDarcos, asking for off topic comments to be removed from a thread? Oh that's fucking RICH.