FAQ Search Memberlist Usergroups
Jolt Country Forum Index
Register Profile Log in to check your private messages Log in
Log in Log in

Hugo Homework
Goto page 1, 2  Next
 
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.    Jolt Country Forum Index -> Hugo's House of Horrors
View previous topic :: View next topic  
Author Message
Roody_Yogurt



Joined: 29 Apr 2002
Posts: 1993
Location: Milwaukee

PostPosted: Thu Jan 31, 2013 12:55 pm    Post subject: Hugo Homework Reply with quote

It occurs to me that there are things that'd be nice to have in Hugo but aren't enough of a priority for me to do right away. Also, hey, why should I get all the fun coding challenges?

This'll be our thread for requesting Hugo code for this or that.

I'll start us off with two requests. First off, Inform and TADS both have "bag of holding" objects- containers that the player automatically stuffs things into when picking stuff up when already carrying a full load. A lot of time, this container can hold an endless amount of stuff, making inventory management a lot easier. Inform 6 called it the SACK_OBJECT, Inform 7 calls it the player's holdall, and TADS calls it the BagOfHolding.

Now, I've never written a game with a lot of takeable objects, and Hugo authors often just give the player a huge capacity, but just the same, it'd be good if we had our own version of this functionality.

So, who wants to write a bag of holding object class??

The other coding challenge would be to do a keyring object like in Anchorhead that automates a lot of key-related messages. Here's a clip from Anchorhead:
Quote:
>get key
(the old-fashioned iron key)
(slipping the keyring into the pocket of your trenchcoat to get a hand free)
You pick up the old-fashioned iron key. It's an old key, the kind with a round
barrel about a quarter-inch in diameter and flat, square teeth.

Your score has just gone up by one point.

>put key on keyring
(the old-fashioned iron key on the keyring)
The old-fashioned iron key is now on the keyring.


If we wanted, our version might put new keys on the keyring automatically. Just a thought.

Anyhow, no worries if these examples don't sound appealing to anyone else. If no one wants to do it, I'll get to them eventually.

EDIT: I forgot to add that there is most definitely Inform code out there for the bag of holding stuff if you want to see how others do it, and I wouldn't be surprised if there is keyring code out there, too.
Back to top
View user's profile Send private message AIM Address
Roody_Yogurt



Joined: 29 Apr 2002
Posts: 1993
Location: Milwaukee

PostPosted: Thu Jan 31, 2013 6:15 pm    Post subject: Reply with quote

I forgot to say that it's kind of interesting with the bag of holding issue, you'd have to decide that when the player automatically puts stuff in the bag of holding to make room for things, does it choose the eldest/youngest child? Does it choose the first by object number? Does it choose randomly? Can some items be safe from being chosen?
Back to top
View user's profile Send private message AIM Address
Roody_Yogurt



Joined: 29 Apr 2002
Posts: 1993
Location: Milwaukee

PostPosted: Thu Jan 31, 2013 8:10 pm    Post subject: Reply with quote

Actually, I was meaning to write some object-children-sorting for Roodylib anyway (to go along with my ListChildren routine which uses objest hierarchy for lists), so these are a bunch I threw together tonight (and the TakeRandom one could easily be used towards the bag-of-holding problem), in case someone wants them:

Code:
object temp_bowl
{}


!\ MovePosition - moves object "obj" in parent "par" to position "pos"
( pos = 1 makes it the oldest child, bigger numbers make it younger) \!
routine MovePosition(obj,par,pos)
{
   local n = 1
   while child(par)
   {
      move child(par) to temp_bowl
   }

   while child(temp_bowl)
   {
      if n++ = pos
         move obj to par
      elseif child(temp_bowl) = obj
         move obj to temp_bowl
      else
         move child(temp_bowl) to par
   }
}

! MixObjects - Randomizes order of children of parent "par"
routine MixObjects(par)
{
   local n, obj

   while child(par)
   {
      move child(par) to temp_bowl
   }

   while child(temp_bowl)
   {
      n = children(temp_bowl)
      n = random(n)
      n--
      obj = child(temp_bowl)
      while n
      {
         obj = sibling(obj)
         n--
      }
      move obj to par
   }
}

! ReverseOrder - Reverses the order of parent's (par's) children
routine ReverseOrder(par)
{
   while child(par)
   {
      move child(par) to temp_bowl
   }

   while child(temp_bowl)
   {
      move youngest(temp_bowl) to par
   }
}

! TakeRandom - returns a random child from parent "par"
routine TakeRandom(par)
{
   local n, obj
   n = children(par)
   n = random(n)
   n--
   obj = child(par)
   while n
   {
      obj = sibling(obj)
      n--
   }
   return obj
}

!\ "floats" objects in parent "par" to the top as determined by rules
   returned by routine "arg" (see sample below)  \!
routine Float(par,arg)
{
   local obj, qualify
   while child(par)
   {
      move child(par) to temp_bowl
   }

   obj = youngest(temp_bowl)

   while elder(obj)
   {
      qualify = call arg(obj)
      if qualify
      {
         move obj to par
         obj = youngest(temp_bowl)
      }
      else
         obj = elder(obj)
   }

   while child(temp_bowl)
   {
      move child(temp_bowl) to par
   }
}

!\  Sample routine call and argument routine:
routine DoFloat
{
   Float(basket, &IsEdible)
}

routine IsEdible(obj)
{
   return (obj is edible)
}  \!
Back to top
View user's profile Send private message AIM Address
loafingcoyote



Joined: 04 Jan 2012
Posts: 89
Location: Texas

PostPosted: Fri Feb 01, 2013 8:52 pm    Post subject: Reply with quote

Here is my attempt at a bag of holding:

Code:


attribute unstowable

class holdall
{
   type holdall
   before
   {
      xobject DoputIn
      {
         if object is unstowable
         {
            MatchPlural(object, "That", "Those")
            " wont fit in ";
            The(self)
            "."
            return true
         }
      }
   }
   capacity 300
   holding 0
   is container
}


replace Acquire(newparent, newchild)
{
   local p, i, carryall, flag

   CalculateHolding(newparent)

   if newparent.holding + newchild.size > newparent.capacity
   {
      flag = true
      
      for i in newparent
      {
         if i.type = holdall
            carryall = i
      }
   }
      
      if flag = true
      {
         if carryall
         {
            if StowObject(newparent, carryall, newchild): flag = false
         }
          if flag = true: return false
      }

      p = parent(newchild)
      move newchild to newparent
      CalculateHolding(p)
      newchild is moved
      newchild is not hidden
      newparent.holding = newparent.holding + newchild.size
      return true
}

routine StowObject(parent_object, carryall, newchild)
{
   local i, biggest_item

   for i in parent_object
   {
      if i is not unstowable and i ~= carryall
      {
         if i.size >= biggest_item.size or not biggest_item
         {
            biggest_item = i
         }
      }
   }
   
   if biggest_item
   {
      CalculateHolding(carryall)
      if carryall.holding + biggest_item.size > carryall.capacity: return false
      
      "(first putting ";
      Art(biggest_item)
      " into ";
      The(carryall)
      ")"
         
      move biggest_item to carryall
      parent_object.holding = parent_object.holding - biggest_item.size
      
      if parent_object.capacity < parent_object.holding + newchild.size
      {
         StowObject(parent_object, carryall, newchild)
      }
      return true
      

   }
   
   return false
}


I replaced Acquire and added one attribute and a class. Define a "holdall" object like this:

Code:

holdall ruck_sack "rucksack"
{
   noun "sack"
   adjective "ruck"
   article "a"
   is clothing
}


Default capacity is 300. Here are a few objects to experiment with:

Code:

player_character you "you
{
   in startlocation
   capacity 20
   holding 0
}

object coin "coin"
{
   nearby
   noun "coin"
   article "a"
   size 2
}

object soda "soda can"
{
   nearby
   noun "can"
   adjective "soda"
   article "a"
   size 5
}

object cup "cup"
{
   nearby
   noun "cup"
   article "a"
   size 5
}

object pillow "pillow"
{
   nearby
   noun "pillow"
   article "a"
   size 7
}

object rake "leaf rake"
{
   nearby
   noun "rake"
   adjective "leaf"
   article "a"
   size 10
   is unstowable
}


The leaf rake has the attribute "unstowable" and can't be stowed or put into the rucksack.

Notice that this chooses the largest item in the players inventory to stow. If stowing just one item will not free up enough space to pick up the intended object, then a second object will be stowed. If the player's inventory is taken up by objects that can't be stowed then they wont be able to pick up more objects, even if the intended object is stowable. You can see this behavior if you are holding(not wearing) the rucksack and the rake and attempt to pick up another object. You will not be allowed to pick up the new object even though you could stow it.

One last thing. Roodylib replaces CalculateHolding but I'm not sure it works properly. My experiments showed that the replaced CalculateHolding routine was returning the players holding property as "0", no matter what they were holding. I could be wrong about where the problem is but just be aware that it may not work with Roodylib at the moment.

-lc
Back to top
View user's profile Send private message
Roody_Yogurt



Joined: 29 Apr 2002
Posts: 1993
Location: Milwaukee

PostPosted: Fri Feb 01, 2013 10:06 pm    Post subject: Reply with quote

Awesome, I look forward to checking this out further in depth. Good work.

As far as CalculateHolding goes, yeah, looks like there's a problem there. I took the code directly from Merk, who noticed that "worn" is aliased to "mobile", so things like ropes weren't counting towards a player's inventory capacity. So, I'm thinking it's supposed to be this:

Code:
replace CalculateHolding(obj)
{
   local i

   obj.holding = 0
   for i in obj
   {
      if not (i is worn and i is clothing) and obj ~= player
         obj.holding = obj.holding + i.size
   }
}


Conditionals can be a pain in the ass, so let me know if that still doesn't solve the problem. I'll change that in Roodylib, too.
Back to top
View user's profile Send private message AIM Address
Roody_Yogurt



Joined: 29 Apr 2002
Posts: 1993
Location: Milwaukee

PostPosted: Fri Feb 01, 2013 10:23 pm    Post subject: Reply with quote

Another Hugo Homework Challenge!

I was thinking today about the annoyance of making lots of objects for certain tasks and how a good Hugo challenge would be to create a deck of cards (or, at least, a card game) that adequately represents a full deck (like, a four of clubs can only exist once, and so on), but do this with as few objects as you can.
Back to top
View user's profile Send private message AIM Address
loafingcoyote



Joined: 04 Jan 2012
Posts: 89
Location: Texas

PostPosted: Fri Feb 01, 2013 11:29 pm    Post subject: Reply with quote

Roody_Yogurt wrote:
Conditionals can be a pain in the ass, so let me know if that still doesn't solve the problem. I'll change that in Roodylib, too.


Unfortunately this doesn't work either. The holding property is still not being updated properly. I played around with it a bit myself but I'm just too foggy right now to deal with it.

I was able to fix something with my holdall class. I realized that if the player removes a holdall object with a full inventory then his holding limit would be exceeded. The following replacement of the holdall class fixes that.

Code:

class holdall
{
   type holdall
   before
   {
      xobject DoputIn
      {
         if object is unstowable
         {
            MatchPlural(object, "That", "Those")
            " wont fit in ";
            The(self)
            "."
            return true
         }
      }
      object DoTakeOff
      {
         if self is clothing and self is worn
         {
            if Acquire(player, self): return false
            else
            {
               "You'll probably have to drop something to do that."
               return true
            }
         }
         else
         {
            VMessage(&DoTakeOff, 2)  ! "You're not wearing that."
            return true
         }
      }
   }
   capacity 300
   holding 0
   is container
}
Back to top
View user's profile Send private message
Roody_Yogurt



Joined: 29 Apr 2002
Posts: 1993
Location: Milwaukee

PostPosted: Fri Feb 01, 2013 11:50 pm    Post subject: Reply with quote

Heh, you're right. Looking at it one more time, it should be:
Code:
      if not (i is worn and i is clothing and obj = player)
Back to top
View user's profile Send private message AIM Address
loafingcoyote



Joined: 04 Jan 2012
Posts: 89
Location: Texas

PostPosted: Sat Feb 02, 2013 12:09 am    Post subject: Reply with quote

Yeah, that did it!

This may just be end-of-the-week exhaustion talking but, after writing that last bit of holdall code I got the strong impression that writing IF is like trying to hold the world together with duct tape.

Anyway, yeah, it must be lack of sleep.

-lc
Back to top
View user's profile Send private message
Roody_Yogurt



Joined: 29 Apr 2002
Posts: 1993
Location: Milwaukee

PostPosted: Sat Feb 02, 2013 2:09 pm    Post subject: Reply with quote

Heh, while trying to figure out the other way the CalculateHolding conditional could be expressed, I realized that, ok, the original suggested like was correct. I just had copied it wrong to Roodylib, so Roodylib had this:
Code:
if i is not worn or i is not clothing and obj ~= player

when it should have been:
Code:
if i is not worn or i is not clothing or obj ~= player


Having you lay the groundwork first, I took my own swing at the problem. In doing so, I especially like how your method provides an easy way to provide special messages for unstowable objects.

Code:
global hold_object

! just a constant to make it easier to have unlimited-space
!  holdall objects
constant INFINITE -1

!\ I'm using after routines to set my global variable, but it's
a really unrefined way to do so.\!
class holdall
{
   is container
   after
   {
      object DoGet, DoTakeOff
      {
         hold_object = self
         return false
      }
      object DoDrop, DoPutIn
      {
         hold_object = 0
         return false
      }
   }
   holding 0
   capacity INFINITE
}

replace Acquire(newparent, newchild)
{
   local p

   CalculateHolding(newparent)

   if (newparent.holding + newchild.size > newparent.capacity) and
      newparent.capacity ~= INFINITE
   {
      if hold_object and newparent = player and parent(hold_object) = player
      {
         if not CheckHoldAll(newchild)
            return false
      }
      else
         return false
   }
      p = parent(newchild)
      move newchild to newparent
      CalculateHolding(p)
      newchild is moved
      newchild is not hidden
      newparent.holding = newparent.holding + newchild.size
      return true
}

routine CheckHoldAll(newchild)
{
   local obj
   if (hold_object is openable and hold_object is not open) or
   FindObject(hold_object, location) ~= 1
      return false
   while (player.capacity < (player.holding + newchild.size))
   {
      if obj = youngest(player)
      {
         return false
      }
      obj = PickObject
      if obj ~= hold_object
      {
         if Acquire(hold_object, obj)
            print "(moving "; The(obj);" to "; The(hold_object);" to make room)"
      }
   }
   return true
}

routine PickObject
{
   local obj
   obj = child(player)
   while true
   {
      if (obj ~= hold_object and not PickRules(obj)) or
      obj = youngest(player)
         return obj
      else
         obj = younger(obj)
   }
}

!\ This is a routine to have it ignore certain items that you
don't want being stowed away. \!
routine PickRules
{
! example: key objects are ignored
!   if obj.type = key
!      return true
}


So, my version takes the oldest child of the player that isn't the holdall object (or something disallowed by PickRules) and puts it in the holdall object.

It'd be cooler if I set it up so the method-of-picking could be more interchangeable, and even though I put infinite-space support in there, it'd be nice if with limited-space holdalls, I added everything the player is holding first just to make sure there will be room for the new item before I start moving stuff.

Looking at yours again, that's cool that it goes by biggest-items-first. Also, your version can technically handle multiple bags of holding, which might be very appealing to some others. I figured most games have one holdall, and I'd try to capitalize on that fact but the resulting code wasn't quite as simplified as I was hoping for.
Back to top
View user's profile Send private message AIM Address
loafingcoyote



Joined: 04 Jan 2012
Posts: 89
Location: Texas

PostPosted: Sun Feb 03, 2013 2:22 am    Post subject: Reply with quote

Alright, I finally got a chance to check this out. It's interesting to see how different your approach was and I think the PickRules routine is a great idea. I played with this a little and noticed a couple of things.

First, without an "unstowable" attribute it's obvious that such restrictions should be implemented with PickRules. What I did was this:

Code:

attribute unstowable

routine PickRules(obj)
{
   if object is unstowable
      return true
}


This works fine most of the time. However, if the only items held are restricted by PickRules and space needs to be cleared in the players inventory, then one of those objects will be stowed anyway. The only time this isn't true is if the player is holding the holdall and it was the last item to be picked up.

Another thing I noticed was that if the player is wearing the holdall object and removes it, then his inventory limit can be exceeded, since DoTakeOff doesn't check that. This made me wonder; since a worn object doesn't count against a players inventory, why doesn't it call Acquire before allowing the player to remove it? This simple fix seems to remedy that:

Code:

replace DoTakeOff
{
   if not Contains(player, object)
   {
      ! So >REMOVE LOCK will >TAKE LOCK, etc.
      return Perform(&DoGet, object)
   }

   if object is not clothing
   {
      VMessage(&DoTakeOff, 1)         ! "Can't do that..."
      return false
   }

   if object is not worn
      VMessage(&DoTakeOff, 2)          ! "You're not wearing that."
   else
   {
      if Acquire(player, object)
      {
         object is not worn
         if not object.after
            VMessage(&DoTakeOff, 3)  ! "You take it off."
      }
      else: NewVMessages(&DoTakeOff, 4, object)   ! You're carrying too much.
   }
   return true
}

replace NewVMessages(r, num, a, b)
{
   select r
   
   case &DoTakeOff
   {
      select num
      
      case 4
      {
         CThe(player)
         MatchPlural(player, "are", "is")
         " carrying too much to take off ";
         The(a)
         "."
         return true
      }
   }
   return false
}




Roody_Yogurt wrote:
Looking at yours again, that's cool that it goes by biggest-items-first.


Yeah, I chose the biggest item since it seemed logical. That way I could avoid the need to stow multiple items too often.

I always thought carryall items were pretty slick but never considered making one until this coding challenge. I'm sure there are even more features available that we haven't thought of. I'm definitely going to incorporate some version of PickRules into mine. It will be similar to yours, but I think that instead of restricting certain items entirely, it may just make those items less likely to be selected.

-lc
Back to top
View user's profile Send private message
Roody_Yogurt



Joined: 29 Apr 2002
Posts: 1993
Location: Milwaukee

PostPosted: Sun Feb 03, 2013 12:02 pm    Post subject: Reply with quote

I think a lot of games have the remove-a-worn-item-despite-your-inventory-is-full loophole, and personally, I'm okay with that. Still, besides your solution above, I imagine you could provide an over-burdened state for the player, where he can't move until he drops an item, or possibly just make him drop something at random. One definitely has a lot of options for how to handle these things.
Back to top
View user's profile Send private message AIM Address
Bainespal



Joined: 09 Jul 2010
Posts: 151

PostPosted: Tue Feb 05, 2013 8:26 am    Post subject: Reply with quote

Here's a very rough, very minimal attempt at coding a keyring, based on the latest version of the Roodylib shell:

https://dl.dropbox.com/u/101625269/keytest.hug

The main code is this:
Code:
player_character you "you"
{
  after
  {
    actor DoGet
    {
      if object is keyclass
      {
        if not Contains(self, KEYRING_OBJ)
        {
          return false ! Just print default message
        }
        else
        {
          move object to KEYRING_OBJ
          print "(adding "; The(object); " to "; The(KEYRING_OBJ); ")"
          return false ! print defaul TAKE message
        }
      }
      else ! The object isn't a key
      {
        return false
      }
    }
  }
}


I made "keyclass" an attribute. I know that in any real game or extension, the key objects would have a class, but I didn't have any particular code requirements for the object being taken in this example. Also, I forgot how to test for what class an object comes from.

There are at least two obvious problems. I mean for the text explaining that the key is being added to the key ring to be printed before the standard "Taken" message, but it appears after it. More importantly, it's impossible to remove a key from the key ring, because doing so triggers DoGet and re-activates the code that puts the key into the key ring container.

This strategy defines KEYRING_OBJ as a global, so I think there could only be one key ring object at a time. That is consistent with the way Inform 6 used to do the holdall, however.
Back to top
View user's profile Send private message
Roody_Yogurt



Joined: 29 Apr 2002
Posts: 1993
Location: Milwaukee

PostPosted: Tue Feb 05, 2013 6:41 pm    Post subject: Reply with quote

Sorry, just had some time to look at this; it's been a busy day.

Funny, when I initially envisioned this problem, in my mind's eye, there were some additional steps, but you're right, combined with Roodylib's functionality, that should be fine.

On the other hand, it does draw attention to some behavior on Roodylib's behavior that I'm not entirely happy with. For instance, Roodylib's DoUnlock currently allows the usage of any key object within any parent the player is holding, but it really should only allow platforms or open containers. I should do something about that.

Also, when the player doesn't specifiy a key, it'd be nicer if DoUnlock printed a "(using the skeleton key)"-type message before it goes on to unlock the locked item.

In any case, good work, and thanks for contributing!
Back to top
View user's profile Send private message AIM Address
Roody_Yogurt



Joined: 29 Apr 2002
Posts: 1993
Location: Milwaukee

PostPosted: Tue Feb 05, 2013 8:14 pm    Post subject: Reply with quote

Ok, I updated Roodylib to do these things. Actually, it already was supposed to do the second thing, but my call to RLibMessages was messed-up argument-wise so the messages weren't getting printed.
Back to top
View user's profile Send private message AIM Address
loafingcoyote



Joined: 04 Jan 2012
Posts: 89
Location: Texas

PostPosted: Fri Feb 08, 2013 4:56 pm    Post subject: Reply with quote

Hey Bainspal! You have a nice start to a key ring object here. I got a chance to test it today and, building on your code, was able to flesh out the concept a bit:

Code:

!!! be sure to include grammar before verblib.g
verb "lock"
   *                                            DoVague
   * lockable "with"/"using" object             DoLock
   * lockable                                   DoLock

verb "unlock"
   *                                            DoVague
   * lockable "with"/"using" object             DoUnlock
   * lockable                                   DoUnlock
!!!
   
global KEYRING_OBJ

object keyring "key ring"
{
   in you
  is platform
    article "a"
    noun "ring", "keyring", "keys"
    adjective "key"
    long_desc
    {
      "A simple, flexible metal loop.";
    }
    before
    {
       xobject DoPutIn
       {
          if object.type ~= key_class
          {
             "You can't put ";
             Art(object)
             " on ";
             The(self)
             "."
             return true
          }
         
          return false
       }
    }
   
    capacity 50
    holding 0
}

class key_class
{
   type key_class
   before
   {
      object DoGet
      {
         if Contains(KEYRING_OBJ, self)
         {
            if Contains(player, KEYRING_OBJ)
            {
               "You don't need to take ";
               The(self)
               " off ";
               The(KEYRING_OBJ)
               "."
            }
            else
            {
               "(taking ";
               The(KEYRING_OBJ)
               ")"
               Perform(&DoGet, KEYRING_OBJ)
            }
            
            return true
         }
         
         return false
      }
   }
   after
   {
      object DoGet
      {
         if Contains(player, KEYRING_OBJ)
           {
             move self to KEYRING_OBJ
             print "(adding "; The(object); " to "; The(KEYRING_OBJ); ")"
           }
           
           return false ! print default TAKE message
       }
   }
}


Since we removed the "held" token from the verb grammar, it's necessary to replace DoLock/DoUnlock to check if the player actually has the key object. The following code should be added to each.

Code:

   ! This is here since we replaced the "held" token with "object"
   if xobject and not Contains(player, xobject)
   {
      ParseError(15, xobject)
      return false
   }


Using the DoLock/DoUnlock verb routines from Roodylib, put the preceding code in near the beginning of each, right before this:

Code:

   if xobject ~= 0
   {
      a = InList(object,key_object,xobject)
      if not a
      {
         VMessage(&DoUnlock, 1)  ! "Doesn't seem to work..."
         return true
      }
   }


You'll recognize plenty of your own code here. The above modifications print the "(adding the brass key to the key ring)" message before "Taken" and keeps the player from being able to take a key and add it back to the key ring over and over. I don't think that's a big deal but, knowing the IF community, they would probably consider it a bug.

It was necessary to replace the grammar since, although the commands "lock door" and "unlock door" work fine, the command "unlock door with brass key" didn't make it past the "held" grammar token.

Something else this modification does is to redirect the command "get brass key" to the key ring if the brass key is on the key ring and the player doesn't have it. Before taking the key ring it will print "(taking the keyring)" so the player doesn't think he's only taking the key object.

The last thing this does is to allow keys to be manually added to the ring. This is only possible when the player picks up a key while not holding the key ring.

-lc
Back to top
View user's profile Send private message
Bainespal



Joined: 09 Jul 2010
Posts: 151

PostPosted: Thu Feb 14, 2013 5:34 pm    Post subject: Reply with quote

Thanks for fixing and extending that code! I think the solution strikes the right balance between a realistic implementation and meeting the IF community's standards of parser automation to make things easier for the player.
Back to top
View user's profile Send private message
Roody_Yogurt



Joined: 29 Apr 2002
Posts: 1993
Location: Milwaukee

PostPosted: Sat Feb 23, 2013 4:14 pm    Post subject: Reply with quote

If you guys think your code is "ready for primetime", I think it'd be good to make pages for them over at Hugo By Example, in the Tips category. LC, I know you have an account, but Bainespal, if you sign up, let me know and I'll give you edit rights.
Back to top
View user's profile Send private message AIM Address
loafingcoyote



Joined: 04 Jan 2012
Posts: 89
Location: Texas

PostPosted: Sun Feb 24, 2013 10:35 pm    Post subject: Reply with quote

Roody_Yogurt wrote:
If you guys think your code is "ready for primetime", I think it'd be good to make pages for them over at Hugo By Example, in the Tips category. LC, I know you have an account, but Bainespal, if you sign up, let me know and I'll give you edit rights.


Hey Roody, I just saw this and think it's an excellent idea. I've been meaning to contribute more at HbE for a long time now anyway.

It's been a few days since I've looked at my code, so I'll take a little time to make sure it's ready and then most likely put it on HbE sometime tomorrow.

-lc
Back to top
View user's profile Send private message
Roody_Yogurt



Joined: 29 Apr 2002
Posts: 1993
Location: Milwaukee

PostPosted: Wed Feb 27, 2013 2:55 pm    Post subject: Reply with quote

Nice updates, lc.

Anyhow, I'm also writing here just to share a new "homework" idea. This next one should be fairly easy but should be kind of fun to see down in code.

Now, mazes are considered fairly passe, but one of the least-hated methods for dealing with a maze is that of the "enchanted wobblefiend." Enchanted wobblefiends are objects or characters that lead you through a maze, like the voodoo head in the Secret of Monkey Island.

So, for this assignment, code a maze (or just a maze room template) and an enchanted wobblefiend object that informs the player where to go in each room (preferably with the use of an event- not room long_desc text).
Back to top
View user's profile Send private message AIM Address
Display posts from previous:   
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.    Jolt Country Forum Index -> Hugo's House of Horrors All times are GMT - 7 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001 phpBB Group

Theme by Kage Musha - RPG Garden

Copyrights and trademarks are all of the belonging company. No copyright Infringement intended