GLYMMER: console based simulation instead of commands

Originally, I was expecting to use F(X) Launcher to implement the business logic via command line and then implementing the user interface that would build up the command and call the business logic. The user interface would be defined in a JSON, XML another format file or in the code. It would list the series of steps taken by the user interface to obtain the necessary information to call the business logic.

The advantages with this method:

  • You can easily test with a script the business logic.
  • Designing commands necessary for the game to work is easy, it's a single name with parameters.

The disadvantages:

  • You need to use commands to show information what you will use to build your command. For example, check for character ID, and reuse that ID in another command.
  • It's not wysiwig, you could be playing the game perfectly as command line, but the user interface could behave differently. Therefore the process is different.
  • You need to accumulate variables/answers somewhere to be able to build your command once finished. Since the number of steps is undefined, that could lead to dynamic allocation.
  • The business logic will need to read those parameters and build SQL commands with it to do the necessary game logic operations which could lead to a lot of boiler plate code.

SOLUTION

The idea would be to maximize the amount of work we keep in the world of SQL and avoid unnecessary conversions between data in C and SQL. Still, some operations like combat would require much more complex operation. IN that case it would require importing information from SQL, making computation and updating the database. Still, I think this could be kept to a minimum, and many operations could simply be done with a series of step especially for simple CRUD operations.

Each step would have the following information:

  • SQL command used to display information to the user, ran before the dialog.
  • determine the type of dialog desired ( single select, string input, Question, multi select, distributor, option, etc)
  • SQL command used with the answer
  • Additional pre/post dialog SQL commands to run. (Or, make a very log SQL command separated with semi-colons)

So when opening a windows, the first SQL command is launched, the display is built with it. Then we wait for the user to make a choice, then we execute the final SQL command. In that case no information would be transferred between steps. So how does the communication works?

Each table would have the following mandatory requirements:

  • PK: a field name pk that acts like a primary key as integer. This is to make sure that choices/answers can be easily identified with the key. It might be required that each preSQL requires the first field in the select to be pk so that they can be marked.
  • MARK: a field name mark as boolean that would be used to mark records that were selected in the dialog. It would allow single and multi select. The dialog will auto mark selected item by using PK to track down the selected field and mark it. Once marked, the post SQL command will be able to use those markings to do operation with it. Tables would have to be unmarked at the end.

So the communication is being operated by marking records. The only real communications is the answer of the dialog being used as a parameter in the post SQL command for marking records for example.

EXAMPLE

Here is a possible example of "character curing" operation with pseudo SQL:

Step1: Display list of character with illness.

  • pre SQL: select all character with at least 1 illness
  • dialog: single select list
  • post SQL: mark selected character

Step2: Display list of illness

  • pre SQL: Select list of illness attached to marked character with cure cost
  • dialog: single select list (mark illness to be cured)
  • post SQL: mark selected illness

Step3: Confirmation dialog

  • pre SQL: Select cure price
  • dialog: question dialog

Step4: launch business logic

  • C: verify that the right amount of gold is available, if not, return error and display message
  • SQL: remove marked illness from the database

In some situation, it could be possible to implement a system where no C programming is required if the resulting action is a simple SQL command.

NOTE: Marking could be non boolean. Maybe, some records could be displayed grayed out, so that in the example above, illness that the player cannot afford would marked "grayed", which means that they would be displayed but could not be selected. That would prevent the need to validate the player have enough money.

There is many advantages to this solution:

  • A text only interface could be made to test the menu system by typing numbers for selecting records. This would recreate an accurate simulation of the real thing.
  • Keeps most of the logic inside the SQL database to avoid C coding.
  • Queries would be constants in code or loaded from a file meaning that there will be little need to build SQL queries and plan a large buffer to hold the query and make sure there is no overflow. Building SQL commands from C can be complicated. It's easier to use a parametrized query instead and insert the variables.
  • There will be no need to have commands that display information, it would be part of the engine.
  • No need to store variables between steps.

The disadvantages:

  • Automated testing would not be possible, or would be more complicated to implement.
  • Some situation like distributor could have inconsistant logic with the rest of the system and require exceptions.
  • The steps must be linear, there cannot be any branching according to some character choices.
  • It forces certain field and format requirements to the SQL schema. If those fields are missing, it could potentially crash or make the program misbehave.

IMPLEMENTATION

So I think this could be an interesting system that could be tested on text console before integrating any graphic system. I think the console mode should be independent of the allegro graphic display to be able to use the console mode without allegro. So they would probably be 2 separated modules to allow other visual implementations.

AFTER THOUGHT

Here are a few points to consider in general after more thinking about it.

  • In order to maximise what can be done in SQL, it could require exploding the amount of tables and relationship. For example, it would be more convenient to keep character attributes into a separate table to be able to create update and select queries more easily.

  • In order to avoid having conditional logic and loops to implements in steps. Each step would be stored separately in an internal structure that would allow pre and post query. Those will be invoked in the C code in the order they should appear, and validation could be made before progressing. Here is an example for character creation where each step encapsulate the querying, dialog display, record marking, etc.:

  • step 1: input character name

  • Step 2: Select race

  • Step 3: Assign attribute + display class requirements

  • Check in C if at least a pair of attribute has 13 points. If not, move back to step 3.

  • Step 4: Select class

  • I have to consider that certain side dialogs will have to update after each cursor movement. Which could use record marking to display information correctly. That could imply that a single step could use more than 1 dialog, so an array of dialogs would be required. Still, since the array size is fixed at compile time as constants, it should not be a problem. I might just need to make sure the array is null terminated. the engine would read the structure.

  • Doing a text based version might not be that complicated. The sequence of action could be launched with F(X)Launcher to simulate making a choice in the high level menu, then the sequence of steps is executed on the console in text.

  • The idea would be to use russian doll system to encapsulate what has already been encapsulated. Still, the step idea works well when the database is involved. But there are situation where no database querying is involved. In those case, dialogs should be able to be invoked manually.

Sample of step structure

Here is a potential structure that could be used. I might not want to use a database or an external file XML, JSON to contain the information. Variadic arrays can be used for variable size steps. Each step will be store into a separate variable since C code can interfere between steps, it is not self contained.

Before stepSQL
After stepSQL
Variable list of dialogs
| dialog 0
|   | presql?
|   | display sql: Query displayed in the window
|   | format to display the query
|   | type of dialog
|   | postsql? 
| ...
| dialog N (the last dialog always get the focus)

For the format of the file, YAML or XML seems more appropriate because there is no need to encapsulate data between "" characters. This is important since SQL commands are very likely to have "" in it which would require escaping them.

Edited by Eric Pietrocupo