Containers
kodrik
*** 1 ***
I am defining bags that you can take.
A container, as it presently stands, can be opened and it's elements
are then accessible. If there is a container inside and you open it, then
it's content is also accessible as well as the element of the container it
is in. Basically, content is accessible many levels down from the top level.
You cannot add a container to your inventory.
A bag is defined as a container that can only hold items or bags. To check
the content of a bag inside a bag, you must first extract that bag.
You can add bags and their content to your inventory.
Should I add a third class of element, box, that can be taken to inventory
and it's contents in sub-boxes can be checked if all the boxes are just
opened? So you can check boxes contents many level down from the top
level.
It will hurt my head to code this on top of everything I have to
incorporate right now. So my first question is, would it be useful to have
a box element or is it just a "nice addition" that will be rarely used.
*** 2 ***
I want authors to be able to set limits to inventory as well as containers.
* An obvious limit is number of items. If a bag has 20 items in it, it
counts as 1 item and its content is ignores regarding item number capacity.
* Another obvious limit is total weight, where you add the weight of all
bags and items, even ones in bags.
* If you can assign a single unit size to object, you could set a max size
to objects that can be added to inventory or put inside containers and bags.
* This limit, that I am not sure of, is total unit size: you add up the
size of all top level items and bags and it can't exceed the size unit
limit. This is poor representation because it doesn't represent the shape
of the objects but I don't see any other practical way of doing it.
* Finally, in real life, a bags size in relative to its content, so should
I add the total size of all items and ignore bag sizes. This could be
another difference between bags and boxes and another reason to incorporate
it.
Would that be enough, does it need more, to be different or is it too much?
***
Any opinions, comments and suggestions welcome.
David Welbourn
> Two questions regarding containers:
> [snip]
> So my first question is, would it be useful to have
> a box element or is it just a "nice addition" that will be rarely used.
I'm having such difficulty understanding what your questions are, that I'm
uncertain that my answers will be relevant, but here goes:
I've played a lot of IF games, and I've seen many kinds of containers. Some
are takeable, some aren't. Some are openable, some aren't. Some are
lockable, some aren't. Some are locked, some aren't. Some are transparent,
some aren't. And yes, some will let you view the contents of a contained
container, and some won't.
The default handling for open containers inside other open containers is
that you can see down all the levels. So yes, if there's an apple in a
(open) bowl inside an open refridgerator, I'd expect to see the apple.
Likewise, if there's a gold crown in an open treasure chest in a (open) hole
in the ground, I'd expect to see the crown. This, if I'm understanding you,
is your "box" version of a container.
And yes, I've seen the reverse: a seed in a packet in a pocket in a cloak.
You can't see inside the pocket until you're wearing the cloak. And you
can't see inside the packet until you've taken it out of your pocket. This,
if I'm understanding you, is your "bag" version of a container. But from
what I've played, this is the exception, not the rule. Most containers don't
have hidden depth handling, or whatever you might want to call it.
> I want authors to be able to set limits to inventory as well as
containers.
> [snip]
> Would that be enough, does it need more, to be different or is it too
much?
I can think of at least one more restriction: by object type. For example,
containers for liquids are often restricted to hold only liquids, and only
one liquid at a time. Other examples: only keys in a keychain, only money
and credit cards in a wallet, only magic control rods in the magic control
slots.
-- David Welbourn
kodrik
> uncertain that my answers will be relevant, but here goes:
You have to look at it from an authors point of view, what are the
properties it can set to objects and how they affect the game. Most of your
comment was from a player's point of view, a lot of what a player see is an
illusion, a container can some time be a nested room for example.
container ->
Can be opened
Cannot be taken
Content can be listed in room description
Content can respond to action if ascendants are all open
bag ->
Can be opened
Can be taken
Content can be listed in inventory decription
Content can only respond to actions if taken out of bag
Bag size is a variable based on total content size
box =>
Can be opened
Can be taken
Content can be listed in room description and inventory descrption
Content can respond to action if ascendants are all open
Box size is fixed regardless of content size.
> Some are transparent, some aren't.
That's an interesting one. What does transparent mean, they can be listed
in the room description and inventory description but cannot respond to
actions unless the container is opened?
> I can think of at least one more restriction: by object type. For example,
> containers for liquids are often restricted to hold only liquids, and only
> one liquid at a time. Other examples: only keys in a keychain, only money
> and credit cards in a wallet, only magic control rods in the magic control
> slots.
Yes, associate families with your elements and make it a prerequisit for
item manipulation with containers (put in container basically).
Garth Dighton
>
>> Some are transparent, some aren't.
>
>That's an interesting one. What does transparent mean, they can be
>listed in the room description and inventory description but cannot
>respond to actions unless the container is opened?
>
Transparent means you can _see_ what's inside, even when it's closed, but
you have to open the container in order to remove the contents.
Non-transparent means you don't know what's inside until the container is
open.
--
Garth Dighton
gdig...@yahoo.com
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
Check out our new Unlimited Server. No Download or Time Limits!
-----== Over 80,000 Newsgroups - 19 Different Servers! ==-----
fat...@attglobal.net
"kodrik" <kod...@zc8.net> wrote in message
news:ua5jtu2...@corp.supernews.com...
> Two questions regarding containers:
...
> So my first question is, would it be useful to have
> a box element or is it just a "nice addition" that will be rarely used.
This is a question for you, not for us! Will boxes that behave differently
than bags be important in your game? If you're not sure, plan out your game
a bit more. Only code what you will be using. For example, if there is
only one magic spell in the game, it probably (but not definitely) is not
useful to make an entire Enchanter-style spell system. In the game I'm
currently working on, differentiating bags and boxes would not be useful,
but differentiating dictionaries from encyclopediae might be.
...
> You cannot add a container to your inventory.
A container is anything that can hold other things. If there is a jar of
pickles in the game, the player will probably be surprised to find that they
cannot pick it up.
As an analogy, I make my living (as best I can) making 3d graphics. When I
make a scene, if the viewer will never see the back of the house, I don't
worry about what the back of the house looks like. I started out by trying
to be completely simulationist and model every object in every scene, but at
that rate, nothing ever gets finished. Decide on what you need, implement
that. If a simulationist system of it would help, great. If there's only
one instance of an item, it probably does not need any greater set of rules.
Hope this helps!
Joe Fatula
kodrik
> differently
> than bags be important in your game? If you're not sure, plan out your
> game
I am designing an engine, not a game. That's why I need to know what
author's feel is needed. Of course we need what I defined as bags and
containers, but do we need takeable boxes and transparant containers at
this point?
And of course, you can see what is in a transparant container and cannot
take it? What I am asking, is should all actions to affect the items be
blocked besides the descriptions that is in the box.
> A container is anything that can hold other things. If there is a jar of
> pickles in the game, the player will probably be surprised to find that
> they cannot pick it up.
I have containers, bags and boxes, all three are different. I should have
called it something else, I will call it "chest" from now one.
> If there's only
> one instance of an item, it probably does not need any greater set of
> rules.
I need to know what is generally used, I can make special functions later
for special cases. If bags are used 99% of the time over boxes, I will code
the GUI for bags and let the user define more complex stuff through a
tailored coding language.
One question nobody answered, is one unit size a good way to measure size
limitations or is there a better system.
ally
news:uaaqrd...@corp.supernews.com:
> I am designing an engine, not a game. That's why I need to know what
> author's feel is needed. Of course we need what I defined as bags and
> containers, but do we need takeable boxes and transparant containers at
> this point?
Uhm... yes. Think about it: there are cages, fishing nets, display cases,
semi-translucent envelopes, washing machines, microwave ovens, bottles...
all of which will reveal their contents (to some extent) even when they're
closed.
I haven't investigated your engine yet, but (as an author) I would prefer
it if the accessibility of an object would depend on the senses being used
to access it.
In a nutshell, my ideal engine would have to support...
* visibility
* audibility
* smellability (ahem)
* reachability (touching, tasting, taking, manipulating)
...not just for containers, but for doors, windows and other such
obstacles as well.
My *perfect* engine would handle this in an extensible fashion, that is,
authors should be able to add additional senses to an actor's sensorium
and to specify the acuity of each sense as well as the intensity of an
object's sense stimuli: Is it bright enough to illuminate adjacent rooms?
Is it loud enough to be heard from adjacent rooms or across several levels
of containment?
This would of course involve determining how much of an obstruction a
container/obstacle is to a particular sense, which takes us back to the
"transparency" question, except I'm applying it to the other senses now:
If an object is not totally opaque to a particular sense, how *much*
light/sound/smell does it block?
But no, that's definitely not something I'd expect of a newborn engine :)
--however, you might want to keep these things in the back of your mind so
as not to disallow them right from the start (again, I have no idea how
your world model works. I'm obviously a hopeless simulationism fiend)
> And of course, you can see what is in a transparant container and
> cannot take it? What I am asking, is should all actions to affect the
> items be blocked besides the descriptions that is in the box.
An actor might still be able to listen to or smell the item.
Could you assign senses to actions, that is, make the objects that are "in
scope" for a particular action depend on whether the object in question is
accessible to a particular sense (or combination of senses)?
That might involve new "I can't see that here" messages since an object
that cannot be taken might well be visible. Hum. Anyway, I feel these
things are important; if not from the start, then at least special-case-
able without requiring authors to devise major workarounds.
(--snipsnap--)
> One question nobody answered, is one unit size a good way to measure
> size limitations or is there a better system.
I think it's probably easiest to go with "size" (bulk), that is, the sum
of a container's content's sizes is tested against the container's
"maximum bulk" (I don't think players would notice if a container's
maximum bulk defaulted to its own bulk, but there might well be
exceptions, so I'd keep the two separate.)
Weight doesn't usually play an important part there. However, some authors
may want to code paper shopping bags, stockings, fish tanks or the like,
that is, containers that are likely to tear or break once their contents'
*weights* exceed a particular value.
Of course the size of bags (if we're talking about pouches, rucksacks,
etc.) will increase or decrease with the total size of their contents.
Just some off-the-wall thoughts from
~ally
kodrik
> semi-translucent envelopes, washing machines, microwave ovens, bottles...
> all of which will reveal their contents (to some extent) even when they're
> closed.
You are absolutely right, sometimes I can be very shortsighted. And you
can perfectly interact with the monkeys in the cage by throwing them
peanuts.
> I haven't investigated your engine yet,
It is completely undocumented, lacking library models and many other
features. Also, even if I made the ritual without anything that is not
accessible to authors using my engine, it is not the ideal way it
would be done in as few as a month from now.
Looking at it won't help you much at this point.
> but (as an author) I would prefer
> it if the accessibility of an object would depend on the senses being used
> to access it.
Yes, I agree very much and it goes completely with my philosophy. I
believe in general mechanism.
For example, I have no such thing as light, but you can define a power
"light", when it's on you see the room, when it's off, you can change the
room.
> My *perfect* engine would handle this in an extensible fashion, that is,
> authors should be able to add additional senses to an actor's sensorium
> and to specify the acuity of each sense as well as the intensity of an
> object's sense stimuli: Is it bright enough to illuminate adjacent rooms?
> Is it loud enough to be heard from adjacent rooms or across several levels
> of containment?
The way I defined powers, they have levels associate to them and you can
specify to have them burn specific fuels to be on.
Then keys can have powers set on them:
> Listen to music
if($power[hearing]>5) -> "You hear some music";
else "You hear nothing";
You can define anything as a power, whether it's actions in the game or
attributes of the character.
> This would of course involve determining how much of an obstruction a
> container/obstacle is to a particular sense, which takes us back to the
> "transparency" question, except I'm applying it to the other senses now:
> If an object is not totally opaque to a particular sense, how *much*
> light/sound/smell does it block?
Actually, that would not be too hard.
You would just set power permissions to your containers:
Container "Big Cage", let powers "look", "smell", "talk"
Then associate power types to actions:
Command "smell the flower" has power type smell
If the container is closed, the "smell the flower" key of the flower
(which is in the closed container) can still be activated because the
filtering of the container allows it.
So if the user types "smell the flower", then he will be able to smell the
flowers that's in the container but not take it.
Once a container is open, there is no more key filtering done and all
actions are considered.
This will require a little work in the container key status logic but it
will pay off.
I can just create two kinds of containers:
Chest: Cannot betaken and can hold anything
Bag: Can be taken and can hold only bags or items
Everything else can be properties of the containers.
> But no, that's definitely not something I'd expect of a newborn engine :)
> --however, you might want to keep these things in the back of your mind so
> as not to disallow them right from the start (again, I have no idea how
> your world model works. I'm obviously a hopeless simulationism fiend)
It is actualy less work and much more interesting for me to code what I
described above than to code diferent object with different characteristic,
what is what I would have done until I read your reply.
It is better to conceive everything you can do at an early stage of
development than later.
> Could you assign senses to actions, that is, make the objects that are "in
> scope" for a particular action depend on whether the object in question is
> accessible to a particular sense (or combination of senses)?
>
> That might involve new "I can't see that here" messages since an object
> that cannot be taken might well be visible. Hum. Anyway, I feel these
> things are important; if not from the start, then at least special-case-
> able without requiring authors to devise major workarounds.
I think that I am in the same line of thought.
> I think it's probably easiest to go with "size" (bulk), that is, the sum
> of a container's content's sizes is tested against the container's
> "maximum bulk" (I don't think players would notice if a container's
> maximum bulk defaulted to its own bulk, but there might well be
> exceptions, so I'd keep the two separate.)
Yes, I think it is the easiest way, unless someone else has an idea
> Weight doesn't usually play an important part there. However, some authors
> may want to code paper shopping bags, stockings, fish tanks or the like,
> that is, containers that are likely to tear or break once their contents'
> *weights* exceed a particular value.
It is important I you want weight to be a limit of your inventory capacity.
> Of course the size of bags (if we're talking about pouches, rucksacks,
> etc.) will increase or decrease with the total size of their contents.
I'll add a boolean variable to the bag, whether it is of fixed size or
variable.
Thanks a lot for your reply, you ahve contributed a lot to my engine with
this message and saved me a lot of boring coding time.
Uli Kusterer
wrote:
> I am designing an engine, not a game. That's why I need to know what
> author's feel is needed. Of course we need what I defined as bags and
> containers, but do we need takeable boxes and transparant containers at
> this point?
> And of course, you can see what is in a transparant container and cannot
> take it? What I am asking, is should all actions to affect the items be
> blocked besides the descriptions that is in the box.
Hi,
I think you will not get around giving your users containers (I'm
talking about the general concept) that can be opened or closed, and you
won't get around having containers that can be carried. They are used in
many games, be it as treasure chests, cupboards or similar. Transparent
containers are less common, but you should see them as an opportunity to
make your library able to block only certain actions on an item.
However, this shouldn't be restricted to the special case of a box of
glass. There may be cases where you won't be able to look at items
because it's dark, but do everything else... All this stuff would, in a
well-designed library, work using the same basic mechanism.
You could even use this to implement sense-passing, where people can
look into another room, but they're not able to manipulate it themselves
(imagine making a phone call to an NPC in a different room, where you
can tell the NPC to pick up the ball and throw it at the window, so it
ends up in your room -- you'll have to be able to refer to the ball, but
all actions would be prohibited on it for the player. However, you'll be
able to talk to the player, while you're not able to touch him, examine
him etc.)
> I have containers, bags and boxes, all three are different. I should have
> called it something else, I will call it "chest" from now one.
What's the difference between a bag and a chest in your game logic? The
way I understand it, both should work the same. A chest just might be
openable, while a bag may not, but I don't see why that should cause
such a distinction. A matchbox may be an example of a chest in such a
library: you can carry it, open/close it, and it is a container. Or does
a bag grow to contain more items and a chest doesn't? In that case I'd
probably just go with having a chest with its maxweight set to SHORT_MAX
or whatever...
> One question nobody answered, is one unit size a good way to measure size
> limitations or is there a better system.
"one unit size"?? I didn't see the original posting, but if you mean
the maximum contents of a chest is specified in "number of objects" I
definitely wouldn't do that. Use some arbitrary integral unit and let
the game author specify individual objects' weight. It might also be
interesting to have the concept "bulk" as well. After all, carrying
around a human probably works if you go by weight, but carrying him
around in a steel cigar box that can hold the same weight in gold still
won't seem logical.
Cheers,
M. Uli Kusterer
"The Witnesses of TeachText are everywhere..."
kodrik
> talking about the general concept) that can be opened or closed, and you
> won't get around having containers that can be carried. They are used in
> many games, be it as treasure chests, cupboards or similar. Transparent
> containers are less common, but you should see them as an opportunity to
> make your library able to block only certain actions on an item.
I have containers and I want to cover as many kind of useful containers as
I want.
> However, this shouldn't be restricted to the special case of a box of
> glass. There may be cases where you won't be able to look at items
> because it's dark, but do everything else... All this stuff would, in a
> well-designed library, work using the same basic mechanism.
Yes, exactly, something mentionned it and it can be implemented with a
filering mechanism on the container and assigning "powers" to keys to check
against the filters.
> You could even use this to implement sense-passing, where people can
> look into another room, but they're not able to manipulate it themselves
> (imagine making a phone call to an NPC in a different room, where you
> can tell the NPC to pick up the ball and throw it at the window, so it
> ends up in your room -- you'll have to be able to refer to the ball, but
> all actions would be prohibited on it for the player. However, you'll be
> able to talk to the player, while you're not able to touch him, examine
> him etc.)
Keys can already have requirements based on anything in the game, anywhere,
and can modify anything in the game, anywhere.
So using the container filtering system to disguise another room as a
closed container is definitelly feasible, but a lot of thinking will be
required to do it right. I guess it will be a "window" object that of
course cannot be opened since the filters must always be on.
> What's the difference between a bag and a chest in your game logic? The
> way I understand it, both should work the same. A chest just might be
> openable, while a bag may not, but I don't see why that should cause
> such a distinction. A matchbox may be an example of a chest in such a
> library: you can carry it, open/close it, and it is a container. Or does
> a bag grow to contain more items and a chest doesn't? In that case I'd
> probably just go with having a chest with its maxweight set to SHORT_MAX
> or whatever...
Actually, I'm back down to two containers now, the regular container and
the bag (three: the window now).
The regular container cannot be taken and it's item keys can be directly
accessed, as may level down as possible.
The bag can be taken and it's items can only be accessed one level down.
Which means, if you have bagA and inside it you have BagB, you can only
view the content of BagB if you remove BagB from bagA first.
I was wondering if a bag with multiple level reach was needed. I realize
now it is not; if you have a cigarette in a pack in your pocket, you will
first remove the pack from your pocket and then take the cigarette from
your pack. You do not walk around with multiple levels of open boxes inside
each other.
Of course, regular containers shouldbe able to go deep. In the bathroom of
the ritual, the curtain of the bathtub is a container as well as the ice in
the bathtub. When you take the object in cellophane, you are reaching down
two levels in two opened containers.
> "one unit size"?? I didn't see the original posting, but if you mean
> the maximum contents of a chest is specified in "number of objects" I
> definitely wouldn't do that. Use some arbitrary integral unit and let
> the game author specify individual objects' weight. It might also be
> interesting to have the concept "bulk" as well. After all, carrying
> around a human probably works if you go by weight, but carrying him
> around in a steel cigar box that can hold the same weight in gold still
> won't seem logical.
Bulk was what I was talking about, I already have weight and unit count as
options, I wanted to add bulk. The only practical way I see to do it is to
speficy a single number for the size, it won't represent shape and actual
space used but it will server its purpose to set a size limit on containers
and inventory items.
You could also set a filter on container based on size: "You can only pass
item of size 3 or less through the bars of the cage";
Uli Kusterer
wrote:
> Keys can already have requirements based on anything in the game, anywhere,
> and can modify anything in the game, anywhere.
> So using the container filtering system to disguise another room as a
> closed container is definitelly feasible, but a lot of thinking will be
> required to do it right. I guess it will be a "window" object that of
> course cannot be opened since the filters must always be on.
Well, I was thinking of how, in TADS, every room is actually a
container. This is especially useful for nested rooms, because you can
use all the filtering stuff that you use for accessing nested containers
for nested rooms as well. E.g. for a car.
> Actually, I'm back down to two containers now, the regular container and
> the bag (three: the window now).
Well, I wouldn't make the window a container, if you ask me. I'd just
allow establishing connections between two rooms that allow certain
actions ("senses" or "powers") to pass. The actual window should just be
a fixeditem (in TADS parlance) whose state (open/closed) controls
whether the connection to the other room is established. You shouldn't
have to duplicate a room's objects inside a window because that'd mean
you'd have to keep them in sync.
> The regular container cannot be taken and it's item keys can be directly
> accessed, as may level down as possible.
> The bag can be taken and it's items can only be accessed one level down.
If the fact that the regular container can't be taken is a limit of the
engine, I'd remove that limit. It's much easier to turn off certain
behaviour by printing a message like "you can't do that", than it is to
actually add behavior to an object. Most objects (match boxes etc.) that
are containers will actually be takeable in a game (the cellophane you
mention is one of these). Just my $0.02
> Which means, if you have bagA and inside it you have BagB, you can only
> view the content of BagB if you remove BagB from bagA first.
Again, if that's an engine limitation, remove it. I can think of few
cases where this is needed, which means I'd rather add special code to
prevent reching into an item in another one than to support that feature
by writing my own code that does it.
> I was wondering if a bag with multiple level reach was needed. I realize
> now it is not; if you have a cigarette in a pack in your pocket, you will
> first remove the pack from your pocket and then take the cigarette from
> your pack. You do not walk around with multiple levels of open boxes inside
> each other.
>
> Of course, regular containers shouldbe able to go deep. In the bathroom of
> the ritual, the curtain of the bathtub is a container as well as the ice in
> the bathtub. When you take the object in cellophane, you are reaching down
> two levels in two opened containers.
I wouldn't call it a "bag" if it's just a "nonnestableContainer" or
whatever. Bag to me really implies something more flexible, but it
doesn't imply to me that I can't have opened boxes in there. Well, not
unless I think of open milk bottles that are upside down...
> Bulk was what I was talking about, I already have weight and unit count as
> options, I wanted to add bulk. The only practical way I see to do it is to
> speficy a single number for the size, it won't represent shape and actual
> space used but it will server its purpose to set a size limit on containers
> and inventory items.
> You could also set a filter on container based on size: "You can only pass
> item of size 3 or less through the bars of the cage";
I've not yet seen a case where you'd need more than bulk (size) and
weight. I think for most games this will be enough. No need to bloat the
library by adding more.
kodrik
> container. This is especially useful for nested rooms, because you can
> use all the filtering stuff that you use for accessing nested containers
> for nested rooms as well. E.g. for a car.
It makes perfect sense, but with my engine, although they share many
properties, your position in the game is centered around the room so the
rooms needs some extra information like its coordinates.
All elements works on similar bases, some just have a little more
information than others (passages transport you, containers can contain
stuff, items can be taken and are replaced by another element, equipment
that has its own properties).
>> Actually, I'm back down to two containers now, the regular container and
>> the bag (three: the window now).
>
> Well, I wouldn't make the window a container, if you ask me. I'd just
> allow establishing connections between two rooms that allow certain
> actions ("senses" or "powers") to pass. The actual window should just be
> a fixeditem (in TADS parlance) whose state (open/closed) controls
> whether the connection to the other room is established. You shouldn't
> have to duplicate a room's objects inside a window because that'd mean
> you'd have to keep them in sync.
Exactly, its some kind of "link container" or "alias container". I should
make the window object be an alias to any other element, whether a room, an
object or a container, with its own filtering rules.
> If the fact that the regular container can't be taken is a limit of the
> engine, I'd remove that limit.
> Again, if that's an engine limitation, remove it. I can think of few
> cases where this is needed, which means I'd rather add special code to
> prevent reching into an item in another one than to support that feature
> by writing my own code that does it.
> I wouldn't call it a "bag" if it's just a "nonnestableContainer" or
> whatever. Bag to me really implies something more flexible, but it
> doesn't imply to me that I can't have opened boxes in there. Well, not
> unless I think of open milk bottles that are upside down...
You are so right, I have to create a new logic for inheritance in which
filters and status are past down from the top level (room) down to
containers and their contents.
Keys will decide what can be done with an element and what keys can be
activated will be decided by the current filters and other prerequisits.
Authors should be able to design their own filters and Key Power
requirements (not sure how to call it) and these should also have their own
inheritance system.
One drawback about these discussions is that they are very inspiring and I
have problem to focus on only one aspect and nothing gets done. I think it
was Kevin Forchione that warned me about this.
I HAVE TO STAY FOCUSED ON THE CONTAINERS AND FILTERS.
What about the parser, the ritual, the flash interface... There is so much
to do.
THAT SHALL WAIT
No fun :(
> I've not yet seen a case where you'd need more than bulk (size) and
> weight. I think for most games this will be enough. No need to bloat the
> library by adding more.
These, with simple unit count, will be the only ones pre-built. But nothing
will prvent the author to add a "temperature" or "state" requirement if
they want to for their adventure.
Thanks a lot for the input, even if I don't look forward to code the new
container system, it is necessary and I do look forward to it being done.
My satisfaction with the tools I develop dissipates fast into realizing
their inadequacies, but I do marvel at the power the new tools will provide.
IF is really a great field to develop for.
Uli Kusterer
> information than others (passages transport you, containers can contain
> stuff, items can be taken and are replaced by another element, equipment
> that has its own properties).
Just a quick note what I think works best: Keep the actual stuff in
your interpreter very simple, and try to have it provide all the stuff
that is needed to make it work, but put the rest in the library. I.e.
your basic engine would best only contain ways to define objects, their
actions, and their properties.
All the rest (what verbs are supported, what senses/actions, how an
NPC, the PC and rooms are implemented) should be part of the library,
since those are things that the game author will want to change. You may
have to make some compromises when you notice that speed issues arise,
and add specific support for speed-dependent stuff into your engine, but
by doing as much as you can in e.g. the scripting language that is used
to do the game logic, your engine will become much more flexible. It
will also make it easier to port, as only the basic foundations have to
be ported, if you get it right.
This, of course, applies only to languages like TADS or Inform. If
you're writing a C/C++ library or something like that, you wouldn't
typically do that.
Now I'll close, so your engine won't be kept from completion any longer
:-)
kodrik
> your interpreter very simple, and try to have it provide all the stuff
> that is needed to make it work, but put the rest in the library. I.e.
> your basic engine would best only contain ways to define objects, their
> actions, and their properties.
>
> All the rest (what verbs are supported, what senses/actions, how an
> NPC, the PC and rooms are implemented) should be part of the library,
Actually, the library as it is used in Inform will just be bunch of
functions in my engine. Things like types, vocabulary and game variables
will be author defined.
These will be at first defined from scratch by some authors and then saved
to what I call a "library" so that other authors can import, modify them if
necessary and export the new objects and actions to the library for other
authors to use. The library could contain million of entries without
affecting game speed.
> since those are things that the game author will want to change. You may
> have to make some compromises when you notice that speed issues arise,
> and add specific support for speed-dependent stuff into your engine, but
> by doing as much as you can in e.g. the scripting language that is used
> to do the game logic, your engine will become much more flexible.
Since all environment information of the game is stored and acces though an
SQL db, they are stored and accessed through an SQL database, quantity will
not affect speed. And as for the language, I am not using my own but an
existing one, php, and that will handle the load of the different author
scripts pretty eaily.
> It
> will also make it easier to port, as only the basic foundations have to
> be ported, if you get it right.
>
> This, of course, applies only to languages like TADS or Inform. If
> you're writing a C/C++ library or something like that, you wouldn't
> typically do that.
Actually, authors will be coding some aspects of it in pure php (a C like
language). The engine is server based so portability is not an issue. But
if I ever want to make a local version, php is available on most OS.
The library will just be php funtions that the author can call to make
changes to the data in the database. The authors will not have direct query
access to the database.
> Now I'll close, so your engine won't be kept from completion any longer
> :-)
Too late, you inspired me to redo my engine from other posts. :)
Uli Kusterer
> functions in my engine. Things like types, vocabulary and game variables
> will be author defined.
> These will be at first defined from scratch by some authors and then saved
> to what I call a "library" so that other authors can import, modify them if
> necessary and export the new objects and actions to the library for other
> authors to use. The library could contain million of entries without
> affecting game speed.
Well, that sounds pretty similar to what I said, if I understood you
right.
> Since all environment information of the game is stored and acces though an
> SQL db, they are stored and accessed through an SQL database, quantity will
> not affect speed. And as for the language, I am not using my own but an
> existing one, php, and that will handle the load of the different author
> scripts pretty eaily.
Yeah, well, I thought you were writing it entirely yourself. PHP pretty
much does what I suggested (i.e. it is already pretty
platform-independent). Though I would advise you to read the other
discussion here about the importance of the language vs. its libraries.
Although you can theoretically write IF in almost every programming
language, the dedicated ones have some optimizations that make it much
easier. You might want to have a look at those, since you'll most likely
need them unless you're writing a GUI editor as well.
> Too late, you inspired me to redo my engine from other posts. :)
Bwahhahhaaaaaaa! And now that I've done that, I'll go and...
... TAKE OVER THE WORLD!!!!! Bruhahahahahahahaaaaaaaa!!!!!!
kodrik
> discussion here about the importance of the language vs. its libraries.
> Although you can theoretically write IF in almost every programming
> language, the dedicated ones have some optimizations that make it much
> easier. You might want to have a look at those, since you'll most likely
> need them unless you're writing a GUI editor as well.
Read my post [IFonline] a new beginning.
All the game elements are created though a GUI interface and stored in a
SQL database.
Coding is just meant to specify things like requirements and activation of
actions. Functions will be available to modify the game environment and
I'll ty to closely match such functions of existing IF engines.
// Example of requirement:
if(!elem_in_inventory("elemname")) $requirement=fail;
// Example of activation:
moveplayer("roomname");
So the gam wil basically be created with a gui interface and a collection
of php scripts.