next »

[Zireael]

Wires are cool <3 robots are cooler <3 it looks like you have a GUI that's gonna be hot! 

[0x0961h]

Anyway, looking forward to seeing where you go with it. This project already had potential before, but now it's like quadruple potential

Hope so. :D

I like your auto-wiring system, will you smooth everything in the end or keep orthogonal?

I plan to keep 'em this way. Mostly because I once made a prototype with smoothed wires and it was a real mess. Imo, it's easy to see and "understand" wire when you have a mental model "okay, so wire can go 45 or 90 degrees from here, cool, got it". Though I think the system still need some tweaks in terms of pathfinding, but not now. After wires/elements highlighting will be implemented it probably won't be super important at all.

it looks like you have a GUI that's gonna be hot! 

Ha, yeah. I actually plan to take a lot of previous prototype's UI because it was good and I liked it, like, a lot.

[0x0961h]

Update #15. Virtual machines and revelations

As you might remember (if you don't, you can read about it here) last time I began with developing a virtual machine with its own ASM-like language called NeuroVM. This time is no different, but this time it's way more powerful. Please welcome, NeuroVM 2.0.

But first, let me slightly introduce you to the game situation I'm using as a example of what I'm going to solve with all the stuff I'm creating right now.

Imaging having a bot with a material scanner that scans the space in front of it. Your task is to move the bot to the wall if the wall is made of some kind of material (let's say, plastic) or simply ignore everything and stay in place if it isn't. Simple enough.

The scheme player needs to design to solve this puzzle must be something like this:

Fuchsia wires (like the one that connects START w/ SCAN) connect so called "flow" ports. Flow is the concept that is pretty familiar to those who ever touched Unreal Engine 4's Blueprints. Basically, Flow is the way program will execute during one cycle (execution from START element to END element). Flows can be split (welcome to parallel programming hell!), synchronized, merged and branched by BRANCH blocks. Green wires connect integer ports. Red wires connect boolean ports.

Following the flow on the diagram the algorithm for the scheme is:

     1. START the cycle for bot #1
     2. Asking bot #1 to SCAN the space in front of it
     3. Compare MAT output from SCAN element (bottom right port) with CONST 005 (code for plastic) with EQ element
     4. If true, move bot #1 forward for DST steps (middle right port of SCAN) with FWDN element, then END the cycle for bot #1
     5. If false, END the cycle for bot #1

As you can see not all the elements have Flow ports. EQ and CONST elements process data in the background once all their input ports receive data.

Now, when you understand (I hope) Flow and scheme basics I can go back to explaining NeuroVM 2.0.

Key features of NeuroVM 2.0 are data types, variables, const and dynamic/duck typing. In NVM 1.0 there was only one data type, integer numbers, so there was no need in duck typing. This time I there are three types of data: integer, boolean and bot handle. The last one acts as Flow exclusive data type and contains a direct pointer to Flow owner, the bot.

Because I have data types I can't just allow the same behaviour as before, so variables have types too now. You can define a variable without type, but it will be set after first assignment and can't be change after that. It was made to add integrity control over types and to protect NeuroVM from JS dynamic typing hell.

Another feature is direct bot memory access. By using bot handle variables I can get access to bot inner memory directly from element code so I can write and read data from bot. Bot operates as a standalone entity with its own memory and processor.

That's all I wanted to say about NeuroVM without drowning in boring tech stuff (yes, there are even more details). So you can say this time I'm pretty serious about NeuroIDE.

The next step is scheme emulator. Here I go!

P.S. The title is slightly related to Muse's "Black Holes and Revelations".

[0x0961h]

Update #16. Emulations and animations

All of a sudden it's been a week since the last update. Okay.

Last time I was playing with virtual machine for element behaviour emulation. This week I spent on implementing a scheme emulator. I decided not to reinvent a wheel and use the same concept of two phases (transporting and processing), but changed the element activation rules. Let me break it down a little.

So. Imagine you have a basic scheme like this:

You just take two consts (let's say A and B), add them together in the first bot's flow, ignore the result of calculation and end the cycle for this bot. Simple.

Emulator will work like this:

• Calculation Phase 1. No elements with inputs have values on 'em, so we ignore SUM and FLOW_END. Yet we have two INT_CONST and one BOT1_FLOW_START that don't have any inputs. We'll process them (.
• Transporting Phase 1. Transporting data from INT_CONSTs and BOT1_FLOW_START to SUM element.
• Calculation Phase 2. SUM now has data on every input, so we can calculate the sum of two integers and pass it to the bottom output. We also pass bot handle to the top output.
• TransportingPhase 2. The only new data this phase is bot handle on the SUM's top output.
• Calculation Phase 3. FLOW_END consumes bot handle. The cycle ends here.

Animated it looks like this:

Blinking elements are Calculation Phases, blinking wires are Transporting Phases. Looks pretty informative, doesn't it? But there's something that was left undecided for now. Data visualization.

As you might remember the last time I made pieces of data look like this:

This time blinking wires and elements feel more fitting, in my opinion. But I still need to show data somehow so players can see what caused scheme failure and debug it. I now have few design ideas for it and I'd really appreciate your help with it:

Maybe I can combine few of them and make the whole emulation feel more interactive and visually pleasing while making it absolute clear and informative.

[0x0961h]

few hours later

Okay, I solved this mystery by combining and extending my ideas. The result looks like this:

Click to enlarge image (recommended)

I'm extremely happy, because suddenly it looks EXACTLY how I wanted.

[Zireael]

The data flow looks fairly neat!

[0x0961h]

The data flow looks fairly neat!

Hey, thanks! I like it a lot too. I can even say I'm really proud of it.


Update #17. Movement and targets

Hi, everyone! I'm still on the track, still working on the game. A lot of things were changed since the last update. I'll try to cover them all in this post.

First of all, I've made first steps towards customizable UI: now it's possible to set different sizes for scheme and level zones. It's not actually resizable atm, but I have this feature in plans. Ideally, players will have an ability to resize viewports however they want.

Before (left) and after (right)

Another new feature is ability to connect one output with multiple inputs. I had this in the very first prototype, but later I decided to stick with one-to-one connection scheme. It was good, but not really, because it means that you have to deal with SPLIT element just to transport one value to multiple inputs. It's bad and it breaks the scheme understanding flow.

Two wires connecting one output with two inputs

Next. I got rid of checkers background. Welcome good old dotted rectangles. I also fixed some uncool wires behaviours, like incorrect highlighting and unnecessary dots on completely straight wires.

But the best things I've done are bot interaction and cycle execution.

Click to enlarge image (recommended)

You're looking at complete scheme that works. It makes bot scans the space in front of it, then decides if bot should move forward (if there is free space in front of it) or rotate CCW (if there's not). You can see that this scheme solves the problem in three cycles. Cycle is the when all flows from flow starters make their way to flow end elements. After cycle ends, new cycle starts. Execution ends when all bots reach their targets.

Fun fact: I tried to make emulator and game work in different threads, but this idea failed right after concurrent array modification exceptions. Multithreading in games is hard.

That's it for this update. Must say, I'm getting pretty close to completing the core of the game. I now have properly working element and scheme emulators, I have bots framework, after few tests I can seal them up and focus on new bots, levels, UI, graphics, SFX, different customizations and accessibility features.

I have a good feeling about this.