Differences

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

--- javascript_terminal_v2 [2023/11/27 04:41] – appledog
+++ javascript_terminal_v2 [2023/11/27 04:51] (current) – appledog
@@ Line 55: / Line 55: @@
 <Code:JavaScript>
     SET_NAME
-    VAR NAME = INPUT SET_CLASS "What is your class (Fighter, Mage)?
+    VAR NAME VALUE
-    INPUT SET_RACE "What is your race (Human, Elf, Hobbit)?
 </Code>
-FIXME
+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
-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.
+<Code:JavaScript>
+    INPUT using A
+    VAR NAME is A
+</Code>
-This requires a different game update and display loop and a different handler.
+The interpreter can read and write, even to a map (dictionary) if string indexing is not available.
-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.
+=== The VM idea
+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).
-Then, when the user presses up, down, a different inventory item can be highlighted in the drawn-over menu.
+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.
-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 v3 Rant]].
-=== 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.
-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