Thoughts On Storage

The project has come to the point where some thought needs to go into how things are going to be stored.

Currently we use an array to store objects in play - that is objects on the work area, which includes;

• An Object ID - which identifies what the object is
• A Sprite reference - used to display the object on the work area

This is fine as it is, there is enough information to manipulate the objects, any further information will be retrieved from whatever system we use to store the objects themselves..

We don't yet have a way to combine objects, but this is not needed to simply move the objects around.

This post is concerned with that other information.  What we store about the objects themselves and how they interact with each other.

1) Objects

Currently we use the object ID as a frame number for it's image. It allows us 250 different images from an icon sheet so should provide enough variety for a while.

If at a later time, we need to extend the number of images, we could add a sheet number and frame number, but the object ID will still be the same.

The object will need a name, and possibly a description.  These will require a text string, so could be stored  in the same string with a delimiter.  For example  "Name,Description"

We will also need to know if the object is "known about", that is, has the player discovered it yet, in which case it will be available for use.  This only need be a 1 or 0 value indicating known or unknown.

Finally, it has already been mentioned that objects will be arranged in groups or classes, in which case we will need some way to identify which group an object belongs to.

2) Groups

Each will have a group ID, in the same way as the objects do.

Each group should have an Icon - to enable selecting that group from the panel.

Each group will also have a name and possibly a description.

We will need a way to identify which objects belong to which groups.

3) Recipes

These are the combinations that tell us what is produced when one object is combined with another.

So will need an input list (which objects are combined) and an output list (what results are produced)

We will need a way to identify all the recipes for a particular object.

We will need a way to list "known" recipes, while keeping unknown ones hidden.

There needs to be a way to go through the recipes in an efficient manner to see if one exists for a particular combination of objects.

These are our main storage requirements.  Now we need to look at our options.

Options

Looking at Objects and groups, we see that these share a lot of common features;

• Object or Group ID
• Icon Image
• Name, possibly a description

So possibly they would be stored the same way.  Perhaps we can have it so that the first so many object ID's identify groups, or that each object has a flag to indicate it IS a group.

The idea could be taken further to have groups of groups.  Perhaps a hierarchy system

Whichever way seems right, either the object contains a value indicating which group it belongs to or the group has a list of member objects.  We probably wouldn't want to do both as this would duplicate information.

So whatever system we end up with - and it could change as we go - the most likely way to store objects and groups is in one or two single dimension arrays - in the same way do it for work objects, but with a little more information for each entry.

We have to be a bit more careful with recipes.

It might seem a good idea to use a two dimensional array, which one dimension for the first object and the other for the second, but this would be very costly in terms of storage as the total number of cells would be the number of objects squared. So a hundred objects would require 10,000 cells and most of them would be unused.

Again, the best option will probably be a single dimension array that contains only two items. One for the objects combined and the other for the results produced.  That way, only used recipes would require space.

In both cases, the objects would be stored as strings - which have the advantage of being variable in length.

Number arrays, and arrays that use numbers as part of a User Defined type, require a fixed size which can accommodate the largest possible value.

AGK stores numbers in 32 bit format irrespective of the largest number needed and since a 32 bit number allows over 4 billion combinations, we are unlikely to ever use them to their potential.

Strings can vary in length, to accommodate their contents, the smallest being an empty string.

It is possible to convert a number to a string code which makes storage much more efficient.