Codavore

Okay, so all the key tests are done, and now I can move on to phase 3, the real program. Phase 1 was brain storming. Once it had an outcome of interest defined, the next phase was to figure out key missing knowledge to prepare for actual development (PoC's). That was the phase that just ended. I needed Proof of Concepts. Such as the 2D Physics based rocket system, the fuel line interactions, the dynamic MonoBehaviour attachment, and some initial draft of how the coding system will run/be generated.   source  https://pixabay.com/photos/concept-man-papers-person-plan-1868728/ But now, I've moved onto actually building the real product. For this part, I need to settle down on architectural needs. I tend to strongly oppose putting a heavy architecture in place, but ignoring it is a sure fire way to over complicate everything. So I'm looking at things that absolutely need it, and how I will approach it.   To begin with, I'm planning to build a C# IDE in game.  Tha

This game needs the player to write code that will compile and then affect the game. In order to accomplish this, I need to compile code in the game. I had already tested the ability to compile C# at run time in Unity, but today I went a step farther.  I had it produce a MonoBehaviour, and attach it to a game object.  The test passed.  :)  On an odd note, I did test to try pulling in the text from a TextMeshProGui object, but it would not run.  I think there may be an invisible formatting character getting pulled in when I try to get text. It would complain about compiling that it had a '?' in it, but it did not, (I carefully checked, and logged it). source  https://pixabay.com/photos/rubber-duck-2821371/

source pixabay So, the parser is not necessary for pretesting, but a proof of the in-game compiler is. For the time being, I'm putting the parser on the back burner. I've posed a few questions online on where I can get more help, and suggestions for how to approach the challenges I've faced so far. I'm hoping to get some valuable results on reducing Roslyn to just its C# parser. But even if I cannot, for instance, if it also requires having Visual Studio installed to operate, I've already thought through how I will write my own parser. I really liked the structure of Roslyn's Syntax Tree, and basically plan to duplicate that functionality (with limitations). The Compiler So the compiler, is not just the compiler. I've already proved live compiling and execution in the Unity engine.  What I need to prove now, is the programming view. I.e. I need to create a test UI that lets me see the C# code, enter (or paste) code in, and then run it, to have an

Recap for anyone who didn't read the posts on the last article .  I found Roslyn, an open source project on github by Microsoft, that includes a C# parser.  Unfortunately, it did a lot, like also cover VB, compiler abilities, Visual Studio extensions, tools and more; >240K unit tests.  I didn't expect all these features to work once pulled into Unity, especially the VS plugins, so I took an approach to start hacking pieces off I didn't think were needed. Unfortunately, this started me down a long path that in the end I don't trust.  I think Roslyn has a good chance of working for me, but not in this way. When I was done axe-wielding a keyboard, I had stripped off dozens of projects, hundreds of files and thousands of lines of code. It had all the precision of a bull in a tea shop, and the end result (8 hours of effort later) resulted in eleven hundred failed test cases.  :( Don't get me wrong, I ended up with only 25% of the test cases left, nearly all focuse

I don't have any Proof of Concept in place yet on this, but I've finally started designing how the code editor UI will work, then designed some of the basic architecture needed to support how the UI would work, and finally, this lead to how I need to protect the user from dangerous code (you can write C# to format your machine, or try to steal memory from other apps like passwords), while also improving the debugging and teaching abilities. Alright, so I'm planning on having Classes exposed, as an item, then under the class view, is a list of items, like fields, properties, methods, etc. When selecting one of the members, you get details like notes, title, version history; for beginner coders I felt giving them a really easy ability to step back a version or two to something that last worked. Then show the code.  To be able to provide physical system responses, we need to detect all sort of things, like an infinite loop. In the case of an infinite loop, we don't

For this update, I'm introducing the art for engine parts.  I was looking at this pack that I had intended to use as building art, and realized many of these things look like engine parts. Since its a constructor pack (and a nice one, see it here: Building Constructor ) it means each of these buildings are generated from smaller pieces.  Minimal modifications of one of the buildings ... ... allowed me to generate a rather nice looking engine. Then I saved it as a prefab, and added it to my ship layout scene in replacement of the other engine. I took a snap shot of it, and mocked it with a concept for selection details. I don't fully know if this is how things will display, as it lead me to the line of thought, that since code directly relates to physical devices in the game, that Intellisense should probably have a visible element to it.  In this case we see the reverse, that a visual element is expressing its code variables, like what it's thruster id s