StoryDev's codebase is growing, and so too will its features and the ways in which components interact. So far, we spent many a time manually creating different user interfaces allowing for the management of data in many specific-use forms. We have Items, Places of Interest, Characters, Achievements, etc.

What if all of these features were to be consolidated into a different format and packaged separately from StoryDev itself?

Form Designer

The Form Designer started work two weeks ago when the Scripting Interface was implemented. Although the idea behind the Scripting Interface was really just a method to put all your scripts in one place, the first thing we demonstrated was that each Data Module could be displayed under a specific menu, called "Modules".

Now, we have a sizeable demo to show regarding the design of the Forms that go with these Data Modules.

We have what is effectively a grid-based design approach. We have rows, and in each row many columns. We can create new rows and columns by right-clicking the area of a cell and clicking one of the options available.

You can also see in the animated GIF above that we can resize the columns, using percentage values or fixed-pixel values. When choosing fixed-pixel values, any percentage-based widths in the same row are calculated based on the remaining width and not the full width of the row, meaning you can be sure all the widths and sizes are accurate.

It may not look accurate when we use the "Even Distribution" option for the top row. This is because there are three columns which calculate to be 33% of the total width of the row. Naturally, it looks like there is a bit missing, which is the 1% not filled in. This could be more accurate.

You will also find that the "Even Distribution" also takes into account any fixed-sized columns by safely ignoring them and only calculating the percentage-based columns.

By clicking on Form Properties, we get the following options:

  • Global Padding - This is the padding applied all around elements as you add them in any one cell of the form designer.
  • Field Label Position - This specifies where each field's respective label descriptor is displayed, such as above the input (Top) or to the Left.
  • Auto-Width Field Components - We will discuss each component size next, but this option specifies that ALL components should automatically fill the total width of the cell regardless of its fixed-width value.
  • Margin - This, of course, indicates the margin. That is the margin around the form itself, not what's in the form. This is not visible in the form designer, but will eventually be in the Preview tab seen in the main form.

Next, we have each Component that exists:

Except for Button's and Label's, where it's size behaviour is calculated based on its text content regardless of any options you specify (except in the form designer itself; more on this later), each component can be separately customised to your liking. Perhaps Drop Down Combo Boxes should have a default width of 125, or the label position on multiline input fields should be above while all other label positions should be to the left.

This is really just convenience, but it means less time customising certain trivial options. It may be expanded later if needed.

We also have the option to apply these changes globally. This will make sure ALL newly created forms will inherit the same customisation options we apply here. This would not affect existing forms. There may be an option for that.

Inserting Elements

Now for something more interesting.

Forgive some of the crude graphics, some of them don't look relevant (I'm looking at you, Icon Selector). I did draw them, though, so I have only myself to blame.

Nevertheless, here is where we can select the element we wish to add to any given cell in the form we are designing. The Button element gives us only one option: the Field Name. Technically, this is a misnomer, and the same would be true for Labels. It is in fact it's display value, and we will also be able to change this later.

Let's look at something that gives us more options.

Here, we have a Check Box, and like most elements on this screen, we are given the option to choose a Reference. At the moment, this is a dummy and has no options available, but the Reference is the Field this Check Box would apply to. Certain elements will only accept certain field types. Check Box will only accept a Field that is a Boolean type, Date Picker will only accept Date types, etc.

Icon Selector is a special case. It accepts only an Integer, but we will be able to map the Icon Set the selector should display later.

Here, we have a Check List, and now we have even more options available.

We have the ability to Set a custom data source for the display options available. This is handy for something like a "Set Use Contexts" in the Artefact section of our database.

We have two options, "Manually Define" or "Script Defined". In almost all cases, you will most likely choose "Script Defined", to select a previously defined variable of string values compounded into a list or array. "Manually Define" may only be chosen if, for example, it was merely a display option to determine if another field should appear or not.

Okay. Now it's time to get serious about data.

It is obvious at some point you will need to link data together, like relationships in a database. This is pretty much exactly like that.

A Single Link will likely have a Reference to a field with the type Integer. This Reference is the "Foreign Key" of our current table, let's say, talking in database terms.

Our Module Reference is effectively the Table, Display Field the Field we want to display to the user, and Relationship is the Primary Key our Reference should link to.

We have an Edit option, which would allow for us to edit the Module Reference we have selected. The "..." button would also open up a list of Modules we can browse as well as create new ones.

Linked Detailed View is similar to above, except here, we are expecting a LIST of results rather than a single link. This is where our Reference field becomes the Primary Key rather than the Foreign Key, and the Relationship is the Foreign Key in the selected Module Reference.

Ultimately, the idea is to retrieve a list of results.

We can also eventually be able to Edit Display Columns. In other words, select the columns we wish to display to the user, how they should be displayed, etc.

From Specific Data to Custom Modules

Eventually, there will be two different types of Modules:

  1. Packed - This type of Module is a scripted "pack" which is compressed into a single file with all the actual source files inside.
  2. Compiled - This type of Module is compiled into a DLL, which is then executed when StoryDev is launched.

Why the difference? The purpose is ultimately for copyright freedom. The actual practicality behind the choices remains the same, StoryDev simply executes what's inside either and you get the results. But perhaps you wish to license your Data Modules under a proprietary license, in which case a compiled DLL file would be more suitable.

The idea behind this is to allow people to create their own custom Data Modules and share it with the StoryDev community. With that comes the need for an ACTUAL community, which StoryDev virtually does not have.

A website specifically catered for StoryDev will come, but time is what is needed and that is rather limited. Perhaps a website builder will be used at first, and when StoryDev expands, so too will its website.

For now, thank you for reading, and I will see you in the next ranting. Au revoir!

Developer at home, customer services at work. In my free-time, I enjoy writing and coding.