Sunday, May 29, 2016

"sandbox" modes

After completing Michael Berlyn's Suspended, a player is given a special command that allows configuration of the main game- moving robots here and there, changing the timer, etc.  I heard about this feature many years before I actually beat Suspended.  At the time, it sounded like overkill for a game that I had bashed my head against (although in hindsight, it's really not the Herculean effort I thought it was).

I have to admit that, having beaten the game and finally being familiar with how things fit together, the extra challenge mode seemed like a cool idea.  Wow, a player could really make this game as hard or easy as they want to; I could see a fun optimization puzzle emerging.  I have to admit that I never actually played much with this extra mode, but it was cool to see and finally understand.

I've pondered nice ways to provide a similar experience for players, and the easiest answer I came up with was to give the player a magic word when the game is completed that turns on debugging mode.  They'd be able to look at the object tree, move objects or the player around, or even control how daemons run.  I thought this would be a fun way to share the innards of the game with the player; for some reason, having game source available doesn't provide the same thrill unless it's, say, in Hugo and I'm applying new Roodylib functionality to it or something for my own curiosity.

Today's code sample supplies this magic word debugging system.

Now I just need to write a game that players would want to dig into!

Saturday, May 28, 2016

general update and "bags of holding"

Some interesting news in Hugoville.  Nikos Chantziaras has added an opcode system to Hugor, allowing for some special behavior here and there.  Unfortunately, along with posting here about stuff more often, I've been meaning to update the Roodylib documentation to cover all of the new stuff and put out a new release.  So, more news down the road!

In the meantime, I thought I'd share some code examples I put together the other month; well, one now, one next time I write here.

Today's bit of code will be for what IF lingo calls a "bag of holding."  I'd say they were first popularized in late era commercial IF although they first showed up a bit earlier than that.  Players still had set carrying capacities so object-management was required, but one object in the game- usually a bag or knapsack- could carry a limitless number of objects.  As soon as you couldn't pick up anything more, you'd stick stuff in the bag of holding and, yay, looting can recommence!

Bags of holding got even cooler when the game would automatically stick stuff in them for you.  Today's code sample will be an automatic bag of holding system in Hugo.

Just set the bag_of_holding global to your bag of holding object, and there you go!  Now, admittedly, this system is pretty simple. It only allows for swapping one object that, when moved, will create enough space for the new object. I considered writing another pass if the first one didn't find a suitable most, but I figured that this behavior would fit most games.  If a game has large variance in object sizes, the large objects probably should get special treatment through before routines and such.  Plus, it's always kind of ugly when you try to pick something up and then half of your inventory is moved to the bag of holding so I didn't want to encourage that.