I've added a number of things at Garynars wiki
Moderators: Ice Cream Jonsey, joltcountry
- Tdarcos
- Posts: 9556
- Joined: Fri May 16, 2008 9:25 am
- Location: Arlington, Virginia
- Contact:
I've added a number of things at Garynars wiki
I've added a bunch of things including improving some of the descriptions at gerynarsabode, like the Introduction, or the article on attributes. I'm having trouble posting, either his cheap-ass hosting isn't working, or if I can't post this message, then my internet service isn't. (It was my end; this message was delayed about an hour.)
"When I die, I want it easy and peaceful in my sleep, like my uncle.
Not screaming and crying like his passengers."
Not screaming and crying like his passengers."
-
- Posts: 2256
- Joined: Mon Apr 29, 2002 6:23 pm
- Location: Milwaukee
First off, thanks for all of the work on HxE. I especially like the “declarations” category. While not explicitly called that in the Hugo Book, that should help newcomers understand the construction of a Hugo file a bit better. Also, I had avoided making a category (and individual pages) for attributes in the past- as I didn’t think there was a lot to be said about any particular attribute- but creating one is probably a wise move in the long run, as there are some tricky special cases that could be elaborated on.
That said, I do have some reservations about some other things:
The globals page incorrectly implies that you can set one global to several values. You can only declare one initial value, if any. Actually, looks like the local variables page says it, too.
The “routines” section of the Introduction page implies that player.name usually holds the player’s actual name in it. In most games, the player object’s name property is “you”. In first person games, it’s “I”.
Also, in that same section, the “size” property is misrepresented. The size property is used for determining whether things fit into containers or are take-able. The example implies that it is used for actual lengths. Plus, it should be “print number table.size”, not “print table.size”.
Your “handler” pages describe what the Hugo Book (and Hugo code itself) refers to as “verb routines.” Hugo by Example is not meant to explain programming concepts to people; it’s supposed to complement the Hugo Book. Introducing completely new terminology like that is just going to confuse people.
The introduction page also shouldn’t speculate on why someone is using Hugo. I mean, some of us (like myself) use it just because we find it to be a nice mix of readability and program-y. Saying that it’s particularly used for multimedia games is somewhat presumptuous.
The Verbs page should probably link to the “grammar tokens” page, as that goes into detail about all of the various grammar tokens (even the more obscure ones).
That all said, I think things are off to a nice start!
That said, I do have some reservations about some other things:
The globals page incorrectly implies that you can set one global to several values. You can only declare one initial value, if any. Actually, looks like the local variables page says it, too.
The “routines” section of the Introduction page implies that player.name usually holds the player’s actual name in it. In most games, the player object’s name property is “you”. In first person games, it’s “I”.
Also, in that same section, the “size” property is misrepresented. The size property is used for determining whether things fit into containers or are take-able. The example implies that it is used for actual lengths. Plus, it should be “print number table.size”, not “print table.size”.
Your “handler” pages describe what the Hugo Book (and Hugo code itself) refers to as “verb routines.” Hugo by Example is not meant to explain programming concepts to people; it’s supposed to complement the Hugo Book. Introducing completely new terminology like that is just going to confuse people.
The introduction page also shouldn’t speculate on why someone is using Hugo. I mean, some of us (like myself) use it just because we find it to be a nice mix of readability and program-y. Saying that it’s particularly used for multimedia games is somewhat presumptuous.
The Verbs page should probably link to the “grammar tokens” page, as that goes into detail about all of the various grammar tokens (even the more obscure ones).
That all said, I think things are off to a nice start!
- Tdarcos
- Posts: 9556
- Joined: Fri May 16, 2008 9:25 am
- Location: Arlington, Virginia
- Contact:
If it has it that way, I'll fix it, I may have confused a global with a property, which does allow multiple values.Roody_Yogurt wrote:The globals page incorrectly implies that you can set one global to several values. You can only declare one initial value, if any. Actually, looks like the local variables page says it, too.
I was using the standard term, and the standard term is "handler" but if the book calls it "verb routine" I can change that. I have read the book but it has so much in it it's easy to miss something.Your “handler” pages describe what the Hugo Book (and Hugo code itself) refers to as “verb routines.” Hugo by Example is not meant to explain programming concepts to people; it’s supposed to complement the Hugo Book. Introducing completely new terminology like that is just going to confuse people.
It's more-or-less a straight "steal" out of Wikipedia (where I wrote the original article, more or less like it is now) in order to get around their "no original research" rule; now if someone on wikipedia complains or grumbles something about "original research", it can be pointed out the Wikipedia page is not original research, it uses this page as a basis.The introduction page also shouldn’t speculate on why someone is using Hugo. I mean, some of us (like myself) use it just because we find it to be a nice mix of readability and program-y. Saying that it’s particularly used for multimedia games is somewhat presumptuous.
You know, for minor items, you could simply put them in and tell me about it, that's the point of a wiki, that anyone (who is a registered user) can edit it.The Verbs page should probably link to the “grammar tokens” page, as that goes into detail about all of the various grammar tokens (even the more obscure ones).
I hope so, I'm thinking the manual is good but what the system can do is so comprehensive that extra documentation is despirately needed.That all said, I think things are off to a nice start!
"When I die, I want it easy and peaceful in my sleep, like my uncle.
Not screaming and crying like his passengers."
Not screaming and crying like his passengers."
- Flack
- Posts: 9090
- Joined: Tue Nov 18, 2008 3:02 pm
- Location: Oklahoma
- Contact:
One thing I was looking for in the HxE was a simple way to redefine a verb. In the original vision of my game, each verb would not require an object. I was able to do this with new verbs ("spin", for example, does not need an object) but for existing verbs ("push"), I could not get it to work. I realize editing the included grammar file is an easy way to get around the problem but in the end I just coded around it.
This is what happens with I give myself 24 hours to learn a new language and write a game in it while drinking hot chocolate mixed with marshmallow vodka.
This is what happens with I give myself 24 hours to learn a new language and write a game in it while drinking hot chocolate mixed with marshmallow vodka.
"I failed a savings throw and now I am back."
-
- Posts: 2256
- Joined: Mon Apr 29, 2002 6:23 pm
- Location: Milwaukee
With verb grammar, to replace existing verb definitions, you have to put your new ones before the ones you are replacing.
So, before the line '#include "verblib.g'", you'd put your own "push" definition:
Since it sounds like you have enabled verbstub, the existing DoPush routine expects an object. It might be smart to replace DoPush altogether and add a no-object case.
So, after "verblib.h" is included, you'd have:
Just to keep things organized (keeping grammar and verb routines together), I'll usually make a "newgrammar.g" file and a "newverbs.h" file. I'll #include the former before "verblib.g" and the latter after "verblib.h". This'll allow easy updating of standard behavior without cluttering up your main file.
So, before the line '#include "verblib.g'", you'd put your own "push" definition:
Code: Select all
verb "push"
* DoPush
So, after "verblib.h" is included, you'd have:
Code: Select all
replace DoPush
{
if not object
{
"<no>"
return true
}
if not CheckReach(object): return false
"Pushing ";
The(object, true)
" doesn't get ";
print player.pronoun #2;
" anywhere."
return true
}
- Flack
- Posts: 9090
- Joined: Tue Nov 18, 2008 3:02 pm
- Location: Oklahoma
- Contact:
I guess my logic was backwards -- I was thinking that my new definition would go AFTER the already existing one, so that mine would overwrite the default one.Roody_Yogurt wrote:With verb grammar, to replace existing verb definitions, you have to put your new ones before the ones you are replacing.
So, before the line '#include "verblib.g'", you'd put your own "push" definition:
I was surprised to see Robb's source code with separate files for objects, characters, etc. From a programming point of view it makes total sense, I just wasn't aware you could do that. My source file is one long file, but if I end up writing a longer Hugo game, I'll definitely implement a similar structure.
"I failed a savings throw and now I am back."
-
- Posts: 2256
- Joined: Mon Apr 29, 2002 6:23 pm
- Location: Milwaukee
Well, especially since what you describe is how 'replace' works for both routines and objects, I can see how the grammar handling is counter-intuitive. In fact, the Hugo Book recommends putting all new grammar after "verblib.g" is included except for the rare cases you want to override something just to lessen the possibility that your grammar will break any of the standard grammar. I almost never follow this advice, but I'm sure I'll pay for it at some point.Flack wrote: I guess my logic was backwards -- I was thinking that my new definition would go AFTER the already existing one, so that mine would overwrite the default one.
As far as the organizing goes, yeah, as your game ideas get larger, it'll be more helpful. Plus, you'll find that it'll be easier to organize routines and things that you can apply to several projects, not just the one game.
-
- Posts: 2256
- Joined: Mon Apr 29, 2002 6:23 pm
- Location: Milwaukee
Also, Flack, I read your blog post about the writing of your game. You mentioned how one of the hurdles was changing the perspective from first to second. You know, Hugo does have first-person support, had you wanted to stick with that.
All one has to do is change the player_person global to 1 and change the player_character's name to "I", and you are good to go.
All one has to do is change the player_person global to 1 and change the player_character's name to "I", and you are good to go.
- Flack
- Posts: 9090
- Joined: Tue Nov 18, 2008 3:02 pm
- Location: Oklahoma
- Contact:
Yeah, I saw that option and considered it, but ... and this is mostly just me and my personal hang-ups, but I briefly tried and it and just didn't feel right in first person. No doubt, I definitely think there are games that could work in first person, but ... I dunno, it just didn't work here. Plus I really wanted to kill the player. :)
"I failed a savings throw and now I am back."