Differences

This shows you the differences between two versions of the page.

--- javascript_terminal_v2 [2023/11/24 04:17] – appledog
+++ javascript_terminal_v2 [2023/11/27 04:51] (current) – appledog
@@ Line 22: / Line 22: @@
 This separation of terminal mode and command move is central to the goal of escaping the limitations of JavaScript. We do this by creating the nucleus of a state machine and atomizing the execution of instructions inside the context of that machine. This is the 'VM idea'.
+=== the input() connundrum
+After I published technical demo 2 (this) I added an input() function, which led to a realization that there was no need to use state to operate the game in two modes; what was really required were a series of flags such as 'echo' (echo on, echo off), and hooks where a game could read those keystrokes. In fact, this contributes towards the 'VM idea' (see below).
+I did retroactively add input() to technical demo 2 (see commands HELP and INPUT). String input in the form of an input() function works by giving the system the KEY which will identify the event-command, and a prompt string. The prompt string can be empty and no prompt string will be shown; Calling this loses program context so processing will effectively end after the input command is given. This works as follows; the user enters a 'change name' command. The program then calls
+<Code:JavaScript>
+    input("SET_NAME", "What is your name? ");
+    return;
+</Code>
+Then, when the user presses ENTER, an event will be added to the queue which looks like this:
+<Code:JavaScript>
+    SET_NAME Richard
+</Code>
+Then, the game engine will handle this event by changing the user's name. In theory, the game engine will set the name before the next user event is called, either by having a priority queue for state changes, or by assumption (i.e. fiat) that there is no command in the queue which relies on SET_NAME. If so, the system could be programmed to HALT until SET_NAME executes (SET_NAME would be added and the system would wait until it changed to SET NAME <value>).
+What if multiple contexts are required; such as, asking three questions in a row? Then, multiple events could be added to the queue:
+<Code:JavaScript>
+    INPUT SET_NAME What is your name?
+    INPUT SET_CLASS "What is your class (Fighter, Mage)?
+    INPUT SET_RACE "What is your race (Human, Elf, Hobbit)?
+</Code>
+The engine can then throw an INPUT command, and since event processing stops during INPUT, the next question will be asked once the previous one is answered.
+What if you need to control state? then you can add queue commands such as:
+<Code:JavaScript>
+    SET_NAME
+    VAR NAME VALUE
+</Code>
+or if you want to be fancy you can index the value by string name; ex. variables[s] where s is the string value of something like
+<Code:JavaScript>
+    INPUT using A
+    VAR NAME is A
+</Code>
+The interpreter can read and write, even to a map (dictionary) if string indexing is not available.
 === The VM idea
-The idea is that we get around the limitations of JavaScript (or any modern game engine, or, single threaded environment) by creating a virtual machine that accepts commands, like a computer or cpu that pulls instructions and executes them in the context of some environment. This environment has defined inputs and outputs to the screen, the DOM, or for whatever use it requires. As long as one event can be processed in one 'cycle' then context doesn't matter and we can ignore context in terms of sharing a thread with the UI. We can subvert the UI thread to create events, and then process them within the context of our program, updating the up whenever we need to.
+The idea was that we would get around the limitations of JavaScript (or any modern game engine, or, single threaded environment) by creating a virtual machine that accepts commands, like a computer or cpu that pulls instructions and executes them in the context of some environment. This is what the original idea was, we would create an event after we processed the input in 'input mode' (such as SET_NAME). But then, it became obvious that the same system, taken a little further could also do variables, and even simulate BASIC (line numbers could be array indexes, for easy sorting and renumbering).
+This led to the realization that having two modes wasn't really necessary. There should only be one mode, and when input is needed an input flag could occur which would put characters into a string buffer OR which would trigger a line read from a cursor position, or, on the current line, or context, as contextually implied by the environment. For example a command line has different parameters than a 'What is your name?' prompt in Nethack, or a simulated getkey.
-Carried to an obsessive conclusion, we are essentially writing a CPU simulator which handles opcodes, and then writing assembly language programs using that, and projecting the input and output into the faux memory of this virtual CPU.
+Eventually it became obvious that the system was falling towards a CPU/System simulator. My mind jumped to 'emulator', even though that would be overkill, as a way to try and define an upper bound to what I would need to do.
-In practical terms, what this means is we can simulate string input by having command mode switch to a terminal and then back again to process one line of input.
+This topic became too large to fit inside the JavaScript Terminal or JavaScript Netwhack idea, so I will write about it somewhere else, maybe [[JavaScript Virtual Machine]].
 == Code Commentary
@@ Line 862: / Line 908: @@
 In that sense there aren't really any other serious bugs, it basicaly works as intended (I checked). If it's something I didn't check then you will be able to work around it in the game code.
-=== String Input
-String input in the form of an input() function works by giving the system the KEY which will identify the event-command, and a prompt string. The prompt string can be empty and no prompt string will be shown. Calling this loses program context so processing will effectively end after the input command is given. This works as follows; the user enters a 'change name' command. The program then calls
-<Code:JavaScript>
-    input("SET_NAME", "What is your name? ");
-    return;
-</Code>
-Then, when the user presses ENTER, an event will be added to the queue which looks like this:
-    SET_NAME Richard
-Then, the game engine will handle this event by changing the user's name.
-What if multiple contexts are required; such as, asking three questions in a row? You can write a console command called INPUT which works like this:
-INPUT SET_NAME What is your name?
-INPUT SET_CLASS "What is your class (Fighter, Mage)?
-INPUT SET_RACE "What is your race (Human, Elf, Hobbit)?
-The engine can then throw an INPUT command, and since event processing stops during INPUT, the next question will be asked once the previous one is answered.
-This idea can be further developed by creating scenes, or contexts, for your game. For example, let's say you have an item or inventory display and allow the user to select an item by letter (one keypress) or by cursoring over it and then one keypress (enter) -- or both.
-This requires a different game update and display loop and a different handler.
-During the handling of the original game loop, the game must detect a state. The state will read for example INVENTORY_SELECT. This can be simply a keyword on the event queue. When the game engine sees this, it doesn't remove it; it knows there is no item so it jumps to a function which has it's own miniature game loop and display function. It could call the regular display function then draw on top of that a window for inventory. When a keypress occurrs if there is a STATE it could send the keypress to a buffer called input_buffer['STATE']. This state would then be read by that function.
-Then, when the user presses up, down, a different inventory item can be highlighted in the drawn-over menu.
-Alternately, an "overlay" array could be created with screen data that will be drawn on top of the main screen. This implies screen data and terminal data must be separated -- as it was in Java Netwhack.
-Of course, all of that requires programming in the game engine, so it is not included here.
-The ultimate question would be how to get the direct context of the program to continue after the INPUT statement. This is why this is filed under the BUGS section. The fact is, while this is a solution in a sense, that allows us to do vastly interesting things, what we have really done is just taken a step towards what we really need to do, which is create more and more state and remove our reliance on the program context of javascript at all. For a discussion on this I am working it out here; [[JavaScript Terminal State Machine]].
 == Closing Thoughts
 This is an exciting platform to work with, once it is understood. To understand how to use this platform and how to extend it towards your game, I will discuss my plans for extending this code-base into JavaScript NetWhack. I will put this in a page [[JavaScript NetWhack]].