next »

[Pfotegeist]

I got the start menu on the laptop interface to display early this week, it's not the fact it displays but it's a prototype for how buttons will work at the moment. So, I can see the atomic scale of work in action. It's a little lackluster still.

I've begun to put the variable capacity of the system to practice. Ok, that's all you really need to know but I like to write a lot. Here are more details.

...

I've had to relearn what I'm working on. Here is what I learned.

The basis of the game is augmented dialogue. I wrote a calculator so dialogue and physical filters intertwine. The game industry calls the approach I use systemic design.

GUI generated from text is an amazing idea for this circumstance where I already wrote a dialogue calculator. Specifically, the text can be copied, altered, and display generated graphics with randomized flaws later, and because it's a GUI that can turn a useful prompt into something confusing or broken.


I am programming widgets now. Things like radio buttons...

The system I modeled emulates a real-life context: 1 interface, n apps. There's a slight differentiation between the two in code. In practice, interfaces determine how apps are displayed and accessed, ie a laptop shows us software, and software has icons and it's stored in a hard drive, etc.

I wrote this at the beginning of the day. Now, what I wrote at the end of the day.
...

The way that I interpret GUI has changed quite a lot as I iterated. I just finished understanding how it works all over again.

The concept of shared resources often calls on HUBs, subscriptions, and limited scopes. Ok, I don't know where the heck things were going to be while I wrote the system, so I wrote search methods instead.

And then there are variables with global scopes, literally, they will affect everything. Is the laptop plugged into a powered wire? Or How's its battery? Both amounting to, is the laptop powered? And if so Is the laptop off? (yes it's off) Then I shouldn't see the screen. The OS emulation needs to go through a boot sequence if it's turned on again later. The apps should all be off. All progress should be lost, but a player character will remember everything. My attention to detail here might be a bit much, I haven't implemented this yet. Vice-versa, turn off the app normally and it auto-saves. Nothing changes but the player character, an emulation of semipermanent changes in behavior, and soon to discover that the app does in fact auto-save, to a particular player character's relief.

[Pfotegeist]

[Pfotegeist]

So this week I moved the interpretation of inner-scoped variables to take place in an object's unique interpreter, if that's desired. A set of rules are also easily defined by mixing classes. I already knew how to do this already because I wrote a lambda interpreter. So the only thing left to experiment and implement is a default ruleset. I added the potential to call on custom functions, and any string being interpreted can also be altered on the fly allowing for, anything, but more importantly, I can write a "variable" like a fake OS registry, inside of code... that emulates an OS. A folder like C/users/%user%, for Jerri, would add a folder named "Jerri" to C/users, close enough it resembles a real OS.

...
Everything after this point is pretty complicated, so, if a GUI can be generated to a satisfactory level before I get to really implementing control logic, I might say the foundation for the code is pretty much done.

I modeled the Bunny Datesim as a mockup which involves control logic and potentially loading assets, issues I considered but haven't begun programming yet. I'm sure they will work, but will it be optimal?

keywords
There are a few keywords that declare lists.

rulesets
If it turns out that I'm better off reusing rules by scripting them, I can add another keyword.

Control flow
A C# script is probably good enough.

But this new scripting language is high level. Virtual methods can have their body interpreted at real-time allowing for sequences to be modified at real-time. Sentinel variables implement selection. Loops? No loops. It should be safe for program illiterate end-users. In the same sense that dropping your W...... OS folder into a trashcan doesn't sound possible, but you can probably do it. I had a M........ for a couple weeks, and I put the M. C...... icon in the trash to see, and it never turned on again.

End-user Safety
This is a very high-level interpreter, it should be difficult to cause it to slow down or crash the game. I won't claim to know what it can do, even if I program it entirely, but I'm pretty sure.

I have added coroutines to my parsers in the past. So, when I write the parser that interprets virtual methods, you can bet I'm adding a coroutine that handles real-time scripting separately.

Programmer level control
Regardless, GUI always follows whatever the prefab's script tells it. So, if someone writes C# and then calls it from a script, that's not what I consider end-user programming. I'd have to write an initial class that understands more intricately defined rules and force it to be inherited, I'm not going that far.


Initial concept
My initial idea was... optional:
Some variables declared in components are global nevermind this isn't going to make sense without a longer explanation.

Hypothetically, the GUI has a built-in event system, already set up. It will require a bit more work to add control logi. In practice, an event system is already working as I have described, all the components can easily subscribe and listen, so I just want to build off that to produce an automatic connection to common methods.

[Pfotegeist]

Variables are now read in ways that I find acceptable. Although it's not exactly what I want.
edit: It works like I want now, although I will be removing redundant keywords so if A is variable, and B is in A without another declaration, B is obviously a variable unless it was added by another script, soon as I get back to it.

Any variable between brackets reference a dictionary. Components reference a prefab. And most importantly, bracket variables reference components defined in the script. All other variables are inert for now.




edit2: I am trying to get to the good part sooner, but I have to prioritize tweaking the parser to enable code like:

Code:

# within a bracket delimited object, each of these will declare a 
#component within it ( a component is actually some kind of Unity 
#GameObject at the moment, it'll be like that for the foreseeable future)
object{
	AComponent, Name
			
	DComponent:	
	BComponent:{} 	
			
	EComponent,	
	CComponent,{}
	BComponent,:{} #why? idk


# I even acknowledged that it might look better to list things in one line without a 
#fuss and added semicolon as a soft line-break
	GComponent:;KComponent:

}

# but generally a component with a lot of functionality looks like...
D, Name:[activator],[operation] 
{ #body#
 #keyword, variable, method, component, or window, 
#A window looks kind of like ASCII art, but that is only one possible use.
+---+
|   |
|   |
+---+

}

# one big component definition like this can be assigned 
#to a variable and spread around the document making it 
#incredibly fast at populating hierarchy lists
#very fast string-searchable
#codable, parametric, and easily marked up, that's all so far. Functionality, coming soon.

I went out of my way a long time ago to get the window portion of the code working. I'm glad I'm able to address even these mundane bits while I'm returning to programming adequacy.

[Pfotegeist]

I've been working to interpret the methods:
As a function called by the interpreter, works fine. I can also use this to call a validating method and check if the variables are in scope.

As lambda.

Code:

OnClick(){
...Do this...
[if this][ANDthis]...Do this...
... Keep going...
[not this]...Do this....
[this][this]...Do this...
... Keep going...

[this] exit

}

I should add an else. I should add an or. I need to test this next week.

Finally, a method is easily a more interesting variable if I can change its definition on the fly. A bit-wise comparison is fast, and it can be very complicated, but it's not Shakespear.

Different topic the calculator
This is one of my more abstract filters for a series based on detection, which either does or doesn't allow a portion of text to be read.

Code:

public DChemicalFilterIn(){type = "Chemical.in";}
public override void Filter(Redacted t)  {
	int hits = Intersection ();
	string binHits = Convert.ToString(hits, 2);
	int spills = Spills     ();
	string binSpills = Convert.ToString(spills, 2);
	
	int total = Convert.ToString(chem, 2).Count('1');
	
	hits = binHits.Count('1');
	spills = binSpills.Count('1');
	
	captureRate = (float)hits / total;
	spillRate = (float)spills / total;
	if (captureRate >= UnityEngine.Random.value) 
		Redacted.captured = true;
	else
		Redacted.captured = false;


}

Basically, "captured" is the most important point, when the variable is set the stream of text will be transferred through the calculator into the scanner, and if that's connected to long-term memory it's copied there.

[Pfotegeist]

This much works. The only thing I'm still mildly uncertain of is the parameter. I suppose anything in the parameter is actually handled by the calling script. Everything in the body references numbers, string, or variables.

Code:

Debug ( ){
#comments work like usual
	[0<5000][2>1]|[1 < 1]
		tv = 1 ;vv = 2
		bb = 3
		bb = 4
	:else:
		tv = 2
		exit
		
	[3=1]|[4<2][0=1]
		tv = 9 
		vv = 99
		bb = 999
	:else:
		tv = 9999
		
	[a=a]
		tv = 0
}

It doesn't branch much; if, and, or, else, exit; variable reference, assignment, and dictionary instancing. List access is going to come up in a few places.

The code is entirely oriented towards building lists full of lists, references and copies. So, I will reinterpret the header like:
Namespace, Class : [onoff] {
}

I am going to try and port my behavior tree to a system of modular variables before the weekend. Adding code to take modules from other classes might be the only really big addition.

edit: I didn't make it. In need of R&R.

I will make a behavior tree class. In this context it easily resembles another scripted language but that shouldn't be a problem.

Code:

BehaviorTree, NPCBehavior{

  main {
        sleep
        select {
          A 
          B 
          C
        }
  }

  # local modules
  A{}
  B{}
  C{}
}

The way I wrote my classes, they have some versatility. A select is just a sequence that exits after one success. Something like this:

Code:

 sequence {
  exit after 1 success
          A 
          B 
          C
 }

[Pfotegeist]

After I have my energy back, then finish the stuff I already decided on, I'm going to take a class I already wrote based on some game logic and have it take these

Code:

^DU++
   a2
   ==
   1b
   ++

Eventually, this will work the same way, but I need to play with the language a bit

Code:

^F+:DU+
   a2
   ==
   1b
  +---+
# the same as

^F+>a=1+
  +2=b<+

As this, read from the left to right in the usual way:

Code:

a = 1
b = 2

Explanation: The windows are cool and I wanted to be able to add readable code to them. The space around the window is an atlas. The script will terminate an atlas automatically without the use of the atlas modifier. So, a window that escapes that functionality made sense. I can also enforce an atlas by beginning it with the modifier, and manually setting the position in the document to terminate, this future-proofs it when I reach more elaborate ways windows will interact, when I get to that point.

[Pfotegeist]

I got the ball rolling for adding a behavior tree class. But I only got a little done one day of the week.

14 generic nodes. I'll be adding one more that calls a lambda. If it's not obvious, behavior trees are pretty good, for programmers. Simply excluding game-breaking components from a list of available components in real-time, or adding some that don't loop, or with power limits will curb any accidental misuse.

[Pfotegeist]

The program will pretty much continue development as I predicted. Everything from now is another iteration of the program done so far.

A few common conventions like accessors, indexers, and namespace references are winning their way in. I'll also use a String search method and conditional like var[X < 5] returns every variable X with at least one value less than five, including string length. That could be confusing, I think it sounds great. Alright. I might be quiet until I start getting graphics moving around. Everything is a little unfinished.

[Pfotegeist]

Weekly update/humble-brag

The code's becoming more capable than I thought. I'll be able to add automatic debugging. There was going to be some naming convention to allow windows to communicate. If I allow windows to call functions that reference variables then the scope of changes that can be performed by an end-user in a single click has no limit. I might have to look through the list of modifiers and decide which ones are excess now.

[ActiveUnique]

Hi I'm the dev, still working. For game development, 3D or 2D. The hierarchy lists are now functionally a massive file system sandbox.

I'll call it: "Yes" man

[a-k-]

Okay, I think I understand how to write a comment...

[ActiveUnique]

I have started back on the GUI-specific program.

Next. It will read variables written in multiple directions by tomorrow.

I can break down the 2D game into modules, import assets, define a few generic behaviors expected from GUI as experimentation is my forte.

When it produces a laptop emulation I can switch on that's the extent of my initial investment. I'll stop pretending this is easy. At the very least I'll post the notes I took while writing it along with the parser implementation somewhere like Git hub edit: Actually, I'll try to make a free Unity asset. I can still put the notes on GitHub. And I'll make a Twitter account for tips, but that's it.

I'll make the Graphic/Gui generator. It won't take long but I have to add in some new tricks to make it worth it.

I've run out of observable bugs in lambda while running experiments. This was the result.


Technically this is only reading left-to-right in the code. The next minor goal is to get it to read the lines eight different ways. It already knows how to, but I have to program the first behavior-modifying element. It works like this:

Code:

 |name:modifier| 

the modifiers will look like this:

Code:

 |name:UL| 

Modifiers are one of the most important features because it's an attempt to meet visually programmed languages halfway.


The picture displays current progress, the carat is modifying the boxed-in section to parse variables rather than output a graphic. It's possible someone would prefer to write code in-between GUI while designing a large atlas so this remains as a convenience much like in-line comments are an easy way to hide code and turn it off.

[ActiveUnique]

For future compatibility, the blocks are being read with something like a cursor that detects when it reaches the end of a line or a wall. Later I'll add steering (spirals, ping-pong) and a flow modifier, which will be reused for special effects.

Atlas affecting reading direction. I'm manually hiding each one here to illustrate the effect.



Successfully applied to sub-window by touch. The following displays only one downside, inline-text will displace the physical window. Future: There will be layers that allow intersection (negating this) and potentially bridge into 3D.

Next step. Reproducing the app, not at the atomic level though, as modules that accept parameters, mostly text.

[ActiveUnique]

This will be complicated.

The read direction for an atlas is following default instructions. I'll add a keyword to change that.

Maybe that wasn't complicated.

I spent last week moving code around to allow custom read-direction rules per component. I can't tell if I'll use it, but it's good to know it is there.

[ActiveUnique]

No update. Here's a brief history of "Yes" man.

When I began to write "Yes" man I was designing something that really makes more sense as a video game than a program language. I leaned towards how effortlessly GUI becomes too complicated, like wading through piles of documentation, and a few years of understanding I got from programming custom GUI, just to handle one click.

I've been seeing code examples of a lot of different languages, it looks different.