Differences

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

--- javascript_terminal_v2 [2023/11/24 02:15] – 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 was left out of v2, because to do string input you can just puts() and then enter terminal mode and allow the user to press ENTER. Then you will have a response ("ENTER ...") which you can interpret using your own code. Actually this is a little clunky. Ideally you would want to write a function to state what command code it would use, such as SET_NAME or PLAY_NOTES, so that your game engine could process it and get on with the game. For now you need to set a separate variable to know what event the ENTER is for when it hits the engine. You will notice that this information is filed under the 'bugs' section. Please see the code commetary for v3 for the exciting conclusion to this mystery.
 == 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]].