I have a situation where it’s impossible to know how many instances of a particular kind I’m going to need. Is there a way I can just create new ones as required? Or do I have to declare a bunch of superfluous crap that I will then have to needlessly loop over?
Have you had a look at the Dynamic Objects extension by Jesse McGrew?
Looks like it was last updated to make sure it was running in Inform 6L02.
It also requires Dynamic Tables by the same author, which is in the same directory, and was last updated for 6L38.
I have not tried these myself.
-Wade
It will be easier to define a fixed number of objects and come up with some reason why that is really the limit. Then you loop over them.
It’s not needless looping if you decide it’s the right solution. :)
I took a look at those extensions, but I haven’t checked to see if they still function yet. Definitely not something I would be able to update without a lot of help. I don’t know a lot about how all of this works, but a thing in Inform is just an object, right? Doing this in a regular coding language would be really simple, so why is it so complicated here?
I think this would be the best solution in a regular project where I’m creating a bunch of self-contained, identical universes that I have full control over. Instead, I decided to build an unpredictable multiverse, connected by a central wormhole, where I’m not the only god. Because go go Vorple.
Mostly, I’m just testing some coding tricks for a larger project. But since I’m not going to be terribly bothered if people break a code test, I figured I’d have some fun and test human behavior as well. I’m curious how much real freedom I can give people before they start destroying everything. I’m guessing it’s not much, but I’m trying to avoid as many limits as possible.
The example game that’s included in the Dynamic Objects extension compiles without a problem in the current Inform 7 6M62.
I guess the reason is that Inform was originally designed to compile Z-code for the Z-machine, which is a relatively tightly constrained virtual machine.
(That’s also why those extensions are for Glulx, which is the default compilation target currently.)
More specifically, the Z-Machine has no way to request more memory from the operating system. The amount of memory used is specified in the header. (The main object table needs to stay contiguous in memory, which is another complication, but one that could be overcome if more memory could be requested from the system.)
1 Like
Except…
Dynamically creating new objects is straightforward in I6 compiled for Z-machine, but unimplemented in I7…
However, the maximum number of possible objects of a kind must be specified in source, presumably so that memory can be pre-allocated. This is probably why dynamic object creation is unimplemented in I7, since much the same effect can be replicated by keeping a store of pre-created objects either off-stage or in a dedicated inaccessible store-room then moving them in-and-out of play as required, rather than creating and destroying them.
This is not dynamically creating new objects. This is pre-defining a bunch of objects and bringing them on-stage when desired. The original poster considered that option.
1 Like
What is the thing and the context in which it is used? Sometimes there are better solutions that look the same on the front end but on the back end aren’t actually “create an object.”
1 Like
From the DM4, describing object creation/destruction and comparing to moving on-stage/off-stage in I6:
Inform does allow object creation during play, but it insists that the
programmer must specify in advance the maximum resources which will ever
be needed. (For example, the maximum number of beach stones which can
ever be in play.) This is a nuisance, but means that the resulting story file will
always work, or always fail, identically on every machine running it. It won’t
do one thing on the designer’s 256-megabyte Sun workstation in Venice and
then quite another on a player’s personal organiser in a commuter train in New
Jersey.
If you want to create objects, you need to define a class for them and to specify
N, the maximum number ever needed at once. Objects can be deleted once
created, so if all N are in play then deleting one will allow another to be
created.
Suppose the beach is to contain up to fifty pebbles. Then:
Class Pebble(50)
with name ‘smooth’ ‘pebble’,
short_name “smooth pebble from the beach”;
Pebble is an ordinary class in every respect, except that it has the ability to
create up to N = 50 instances of itself.
Creating and destroying objects is done by sending messages to the class
Pebble itself, so for instance sending the message Pebble.create() will bring
another pebble into existence. Classes can receive five different messages, as
follows:
remaining()
How many more instances of this class can be created?
create(hparametersi)
Replies with a newly created object of this class, or else with nothing if no
more can be created. If given, the parameters are passed on to the object so
that it can use them to configure itself (see below).
destroy(I)
Destroys the instance I, which must previously have been created. You can’t
destroy an object which you defined by hand in the source code. (This is quite
unlike remove, which only takes an object out of the tree for a while but keeps
it in existence, ready to be moved back again later.)
This is one of those outright misleading parts of DM4. See I6: Objects from a class already created at start of execution? but the short version is that, in I6, when you specify a class with N possible instances, N+1 instances are compiled and placed as children of the associated class object in the object tree.
… except for the resetting properties and attributes part upon “destruction,” which upholds the illusion that a completely new object has been produced by “creation”.
3 Likes
So it would seem. Destruction is not ‘quite unlike’ removing an object from the tree, but in many ways rather similar!
Yes. I guess you’d have to simulate this in I7 by having a ‘to destroy…’ phrase that reset an object to defaults at the same time as moving it to limbo.
1 Like