Inventory Engine

[Ando]

Could somebody tell me how to do an inventory engine in ZZT? Because it's important and such.

[Zenith Nadir]

Code: Select all

@inventory
#cycle 1
:arg
/i#if not i #arg
#clear i
:inv
$
INVENTORY CODE HERE
!arg; Exit
$
/i#inv
#arg

[Commodore]

each item then has the code like this which you need to change for every board depending on what item can be used where.

#if key1 !1; Brass Key
#if key2 !1; Iron Key
#if key3 !2; Gold Key

:1
That does not work
#restart

:2
' send message to door to check for contact
' if contact door opens and sends its own message
' otherwise:
#1

you could also have the flag "i" set and check if it's turned off meaning accessing the inventory uses -i instead of +i and thus requires one less keypress where shift has to be held.

[JDMSonic]

Fun fact: I invented the ZZT inventory engine (I think). ;p My only claim to fame!

One improvement to the traditional inventory engine that I'd like to see someone do, if your game allows for it - a clear way of letting people know which objects are at all affectable by inventory objects and which aren't. +I sending out a 'sparkle' message to all potentially inventory objects in the room, or something like that.

Sort of like the searchlight in Ned the Knight.

The challenge in inventory based games should be figuring out what goes to what, not essentially knowing what you need to use but having to retry 20 times to get the exact right spot.

For instance, Burglar! is one of my favorite ZZT games of all time - but the mission where you have to use the hologram gave me about 20 minutes of undue frustration even though I knew the hologram was what I should be using.

[Ando]

Fun fact: I invented the ZZT inventory engine (I think). ;p My only claim to fame!

We owe you a lot then! It's a very nice addition to games.

As for your challenge or whatever, I'm afraid that I'm just not the person to do it. Programming has never been my forte, even with ZZT-OOP.

Anyways as a further edit I was finally able to make a working inventory engine thanks to you guys. Thanks!

[Commodore]

his challange means that you shouldn't have to use a item over and over again just so you can find the right square to use it in. It should be pretty clear to the player if they can figure out the clues you give them.

[JDMSonic]

Even if programming isn't your forte (It isn't mine, either!), it would be pretty easy to code.

Basically, you'd add another option to the inventory menu: Something like > "Where should I be looking?"

When the player hits that option, it does a #send all:sparkle

And each object you might want to use an inventory item on has:

:sparkle
#lock
#char __
/i
#char __
/i
#char __
/i
#char (whatever the original char is)
#unlock
#end

With the __'s being whatever will give you a starry effect.

[VinceP]

That sounds like a good idea, but a little too obvious.

Evil Sorcerers Party was cool because it came with a walkthrough - giving hints on what to use and where.

[TTTPPP]

I don't think it would be too obvious, JDM's right. I think the challenge of an inventory based game should be similar to the point of a text adventure - to work out how to use each object. Otherwise you could just be searching round everything in the room that remotely looked like an object. There should be enough objects so you can't easily try each of them, instead you should have to think about what works with what.

[Ellypses]

like swordquest?

[Dr. Dos]

If the theme allowed for it I think that would be a neat special revealing item.

Link's Adventure 3 has a radar that reveals all the secrets, but to get it you need the rope at the entrance to the final level, so normally you won't get it until the very end but it's always the first thing I do.

Those games rocked so much. I should play them again.

[wil]

A better solution to the sparkle would be having the object sparkle on its own by having an object nearby to colorsparkle it every bit of a while at random, maybe every 8-10 seconds so as to not entirely disturb the player, or to have every object on which an inventory object is used be a unique color - like dark purple. Or have it stand out by being a capital letter, preferably the first letter of the kind of object it is. typing ?+I and selecting "sparkle" seems superfluous. If you want people to know where to use their objects, make it easy.

In addition, if you're not worried about the flag limit, setting variable "I" at the beginning of the game and using ?-i to activate it is a much better solution. That way if people frig it up by typing p, for example, instead of i, it doesnt' set an extra variable that is likely to foul things up later.

In addition, if you're willing to do a bit of shit for it, the following are invaluable tools when developign unique inventory engines:

First: the "I know when you re-entered the board" trick. This trick is very useful because it uses the "time" variable, which nobody uses anyway.

Code: Select all

@checkingobject
#cycle 1
:enteredboard
#give time 16300
You have entered the board!
Whee!
Execute valuable entered board code here.
:loop
/i/i#take time 1 enteredboard
#loop

This code is most valuable because it happens completely behind the scenes. If you don't want to tell them, people won't even know their progress across boards is being tracked. Combine this with a simple inventory engine and you have the ability to turn the ?-i engine on and off at will - for example, only allowing you to use items when you have a Backpack object. (using the "i" flag to indicate that you have a backpack is easy, as shown below. Simply instruct users to type ?-i to activate the inventory engine and no extra flag is needed!)

Code: Select all

@inventory
#cycle 1
:enteredboard
#give time 16300
'sets the initial time condition
#if i loopB
'if you have the backpack, check for ?-i
:loopA
/i/i#take time 1 enteredboard
#clear i
'clears the backpack variable to prevent
'cheating. when picking up the backpack,
'use #inventory:loopB first, then #set i.
'If anti-cheating isn't your thing, then
'just remove the above line and have
'picking up the backpack be #set i only.
#loopA
:loopB
/i/i#take time 1 enteredboard
#if i loopB
#set i
$INVENTORY OBJECT
What do we do with it?
#take gems 1 moneyB
#give gems 1
!moneyA; stick a gem in it.
:moneyB
#if foo !bar;Stick a foo in it.

... and so on ad infinitum.
!;Do nothing. (default)
:z
/i#loopB
:moneyB
#others:checkgem
#z
:bar
#others:checkfoo
#z
... and so on and so forth.

The inventory object responds just about instantaneously, and if you so choose several other objects could be warned of re-entry by adding #others:enteredroom to the :enteredroom code.

Something else useful that could happen is this: If you want a small market economy in your game, you can check if someone has entered a board that has a market where they can sell items they may have picked up. When they enter the market board, thery check to see if a flag, "marketAPPLE", has been set that indicates this market, Apple Market, was the last market entered. If marketAPPLE is not set, fluctuate the prices because it means that a different market was entered last, and if you have placed your markets far enough away that means the player has been on a journey to get there. Then, to re-mark apple market as entered, use the following sort of code:

Code: Select all

#clear marketBERRY
#clear marketCITRUS
#clear marketDRUPE
#set marketAPPLE

So that if a player goes back to the other market, he will be welcomed there with different prices. This means that the player can speculate on which products are likely to net him the most profits buying at one market and selling at another, and he may be pleasantly or unpleasantly surprised when he gets there and sees the prices are different, and have either boosted or eaten away his profits.

So this is one way to add some interest and depth to an existing inventory engine. But please take this advice with a grain of salt. I have several sucessful examples of on-enter engines and none of the games i made that used them were popular at all. Though if ando is doing a sort of longer, inventory-driven game, some of these innovations might give him some additional versatility.

[MadTom]

Hail WiL.

[Swashbuckler]

what about that BAG program or whatever

[wil]

iBag would be really useful if there were a lot of people making inventory engine games and wanted to share each other's objects, or if you were making a slew of inventory engine games and wanted to share items between files, or if you had an inventory engine game that spanned several files and used many items, and you didn't want to have a programming bug ruin the fun. None of those three conditions has EVER come up since iBag was finished.