next »

[Kyzrati]

Wow, the highlighting is awesome and so useful; it turns a potential mess into a thing of beauty. I also like the idea of reinforcing what you can do rather than the other way around.

[0x0961h]

Wow, the highlighting is awesome and so useful; it turns a potential mess into a thing of beauty.

Exactly my thoughts!

I also like the idea of reinforcing what you can do rather than the other way around.

And it also looks much better this way:

[0x0961h]

Update #5. dUIlemma (really?)

Oukay... I can play with wires forever, but I have to start thinking about UI, because it's a vital part of game too. And it's also the part I re-e-eally hate working on. That's why I need your opinions and thoughts.

The idea is: you click on something and context menu appears. Let's say you clicked on the empty space, you click and you see the first context menu. You choose the "Add new element" (or anything else, like, maybe "Run debug") option, menu changes its context and your next step is element's class selection (e.g. adder, multiplier, comparator, etc.), you choose it and then you select concrete element type (e.g. 2 inputs, 3 inputs, etc.) you'd like to install on the board. So think of it like series of context menus. But it's one of the concept, though.

I made 4 UI mockups:

   

   

Click on any mockup to see the larger image.

• A is radial menu. You click and it appears in the center of the screen.
• B is bottom menu. You click and it appears from the bottom. Left part is
• C is naive context menu. You've seen it, like, billions of millions times. Nothing new here.
• D is grid-based context menu. It's just like C, but more compact.

That's it, guys. It'd be very awesome to hear your opinions on these mockups, because I'm really stuck atm.

[Kyzrati]

Radial. It's a great option because it both looks good and, more importantly, because it's not square like everything else immediately tells me that this is not a part of the rest of the UI--it's something different. It stands out well.

Is it not possible to make A as compact as D if necessary? Compact is nice, but... more squares (D)?

B is also an okay option, though hopefully with a background that makes it appear much more separate from the rest of the board.

C is horrible, because

You've seen it, like, billions of millions times. Nothing new here.

plus it's entirely text

BTW, nice title.

[0x0961h]

Is it not possible to make A as compact as D if necessary? Compact is nice, but... more squares (D)?

Fun fact: when I was making this post this idea suddenly struck me. Like, to shrink A's circle radius.

Though, I don't think that it should also appear at cursor's position like in D, because it'll be pretty messy if you click not on the center of the screen, but on its the corner. With D you can adjust menu's position, because it's a square and squares are pretty okay with it, but with A you have to either forget about "radial menu's center is at the cursor's position" thing or do some camera adjustments, but I tried this once and it was awful and annoying.

Situation I'm talking about: I clicked on the bottom right corner,
but menu appeared not at the cursor's position.

Btw, what do you think about background? Which one looks better than others? Blurry one (A)? Or desaturated one? Or blurry desatured (D)?

[Kyzrati]

If you're going to force it to the center of the screen, may as well be larger.

The blurred background makes for better screenshots, but the blurry + desaturated makes for better usability (and still looks good).

[0x0961h]

Well, I can also go with it for corner cases:

Though I think it'll be overkill. Welp, I think I'll try A with a smaller size of circle and normalization of menu on corner cases.

[Kyzrati]

Hm... changing your menu layout based on where it is is probably not a good idea. Then you suddenly have an extra whole set of positions for muscle memory to store (assuming your basic radial menu has set positions for everything, which it should if at all possible).

[0x0961h]

Update #5.1. dUIlemma, part 2

Okay, after few hours of brainstorming (and after all the feedback I got from you, guys, thanks everyone!) I decided to try so called "A' approach", which is A (radial menu) + D (smaller size, not tied to screen center).

Note: this footage was captured in 1280x720 screen mode.
Wheel is much smaller than it was in A.

Purple circle was added after I saw that menu is hardly distinguishable from desaturated and blurred background, so it helps menu stand out from grid.

Circle cases are solved now by shifting menu wheel back to the screen. So, if you click not on the corners, menu will appear "around" your cursor, otherwise, it'll be shifted:

Note: I haven't yet fixed wires and elements logic, so they
are highlighting when mouse moves over them.

[Kyzrati]

Looks great. And of course it's purple

[0x0961h]

Looks great. And of course it's purple

Ha, sure, I'm addicted to it, remember? 

But I have plans to make the colour customizable, so-o-o if you're ever gonna play NeuroIDE, you can make it more Cogmind-like.

Or is it more Moonman-like? [:D]

Btw, I also played with visual effects, and you can see that radial menu now has this fancy blurred Aero-like background and "corruption"-like desaturating shadow effect around the circle.

[lapinozz]

in what language/engine is this?

[0x0961h]

in what language/engine is this?

It's Java + LibGDX.

[0x0961h]

Update #6. Emulator and lambdas, NeuroVM and jumps

So, this week I was pretty busy IRL and pretty tired also, so it wasn't a very productive week, but there's some progress, anyway.

So, after somewhat dealing with my most "favorite" part, UI, I decided to relax and dig into emulator and virtual machine parts. I'm now in a process of revamping circuit emulator, I want to untangle it from rendering (now it spawns all that fancy stuff and deals with animation and everything) and make it absolutely independent. In other words: I want to make it clean. Now it iterates all the circuit elements and wires and wraps 'em into special structs without any heavy logic and rendering stuff.

I'm also taking advantage of Java 8's lambdas. To be honest, they are pretty cool. I don't think I'm overusing them, but, you know, it's always better to be aware about it rather than using it here and here and then having to deal with weird freezes and glithces.

For example: wires are wrapped in "connection" structs with two lambdas: the first one gets input port value, the seconds one sets it to output port.

I have no new screenshots and all last updates are deeply internal,
so here, take this fancy code snippet.

After all elements are wrapped, I just iterate through all the connections' classes and run a transition routine on each of them. Of course it can be replaced by a single lambda and it certainly will be replaced, but now I need two lambdas simply for debugging purposes.

Also, this weekend I was working on NeuroVM (read Update #1 for more information), because emulator's processing cycle is relying hard on it. So I decided to improve it a little more.

• I wrote an "in-house" documentation for myself, so I won't forget all the commands and important stuff about bytecode.
• I added two more registers: one for internal memory (it's, like, a set of public variables, that can be accessed from the emulator) and one for external data (now it's only for datasets, but can be used for, like, parameters set by the player).
• I added a flow control commands (a.k.a. JMP, JZ, JNZ, etc.).
• I made an "injection" thing (for example, "compare" command is replaced by set of commands during pre-compilation phase, so I don't have to add one more "if command is CMP then do some comparing stuff" thing, I just re-use already implemented stuff).

Basically, you can say that this NeuroVM thing is very meta, because, you know, I'm making a tool that will compile and run bytecode, so I can program elements via configuration files, so I can make a game with them, so people will arrange elements to make this bytecode working, which is a some sort of programming.

You know, I even think about making this NeuroVM a part of the game, but, you know, like, a set of additional levels that won't be necessary to complete the game. Like, some sort of a hardcore challenge: solve all the puzzles by using only NeuroVM and nothing else. But, you know, it's only a crazy thought for now...

So, that's all for this week, I hope next one will be a little more productive and presentable. For now I have plans to dig deeper into the new emulator and replace existing one with it. After that I can start making elements' library, so I'll be able to fill that fancy UI menu I've made a week ago. Sounds like a plan to me.

[0x0961h]

Update #7. Scary Emulators and Nice Datasets

It's been a week without any visible progress, huh? Anyone is still here? Okay, let's begin.

So, as you remember last week I was working hard on a brand new circuit emulator. I'm glad to say that I've successfully finished it, it works perfectly now, synchronizing, processing all stuff with NeuroVM, without hardcoding, so it's actually a great achievement and improvement. That hardly can be seen by anyone, but me, though...

This week I was integrating new emulator into the game and slowly returning to UI development. I added chromatic aberration for the background (for now at least, I'm not too AAA atm to inject it everywhere), made menu closing on pressing Escape key or by simple clicking outside of the menu circle, returned fullscreen blur and desaturation for menu background, also fixed some bugs and improved my ECS overlay a little.

But what's most important, I've added datasets indicator:

Click to see larger picture.

I'm talking about this little thing:

It'll be used to switch between datasets to see inputs/output circuit data, to pick dataset to test scheme with. Though I have some problems with actual representation of the datasets data: I simply don't know how to do it.

My first thought was to add a little LCD display to each input and output element, but it's not so great, mostly because I plan to have different data types (and it'll be pretty hard to display type with actual data on a little screen) and, what's more important, it's too skeuomorphic. I mean, it's not a real scheme and I think inner wires is already enough for "realism". LCD displays aren't that necessary and useful. So-o-o...

One of my current thoughts is to make tooltip-like thing, so when player will pick dataset, they'll see little popups over inputs and outputs that will close after some time, or when player clicks on one of them, or maybe once player decides to install new element, call menu, select something or do smth else. But, well, I still don't know if it's a good idea. I'm stuck right now, but I think I'll figure out something. Well, at least I hope I will...

Current tooltip prototype looks like this:

[0x0961h]

Welp, LCD-ish displays on I/O elements don't look that bad after all:

Still thinking though, but I like it very much. I mean, it's very representative, constantly visible (no sudden disappearings), can be seen on small zooms, can be modified for different datatypes (e.g. LCDs can be used for decimals, LEDs for booleans, etc.).

[0x0961h]

A-a-and it's totally functional now.

Phew.

[TomaLexi]

I cant tell you how much I love what you are going for here. I played your Cyberjam version, which is of course much too simple as a concept for a full game but shows a lot of promise. After reading your devlog I'll make sure to keep a close eye on this project, since you seem to have a good handle on menu/element design and mechanics. I wish I could subscribe to a mailing list for your updates somewhere (if I sub to this thread, I get messages for everyone posting, not just you).

I am an avid fan of SpaceChem/Infinifactory (among my favourite games ever) and other similar games. If you ever need some Alpha/Beta feedback, I'd love to be looped in and would gladly provide you with feedback on bugs, balancing and mechanics.

[0x0961h]

TomaLexi, why, thank you! It's always heartwarming to hear things like this. I don't have mailing list yet, I'll think about starting site with a proper mailing list, blog and stuff later. I'm knee deep in core gameplay stuff right now.

Speaking of a core stuff...

Update #8. Liquid Crystals and Fast Squares

Looks like weekly reports is definitely my style of devlogging. Well, it's actually, pretty good if you think about it.

This week I finally began to work on visual improvements. I mean, internal stuff is very important, but it's very difficult to share a progress about it, because it's, well, internal. This week I got rid of few TODOs I left for myself before about optimizations and future refactoring.

As you remember last week I added LCD displays to inputs and outputs and made them change their values after choosing active dataset. This week I've added some color to them:

Improved datasets indicators in their natural habitat. Left to right:

> processed dataset, incorrect;
> processed dataset, correct;
> unprocessed dataset

I also improved LCD displays by doing the same thing to them:

The top element received the wrong result,
the bottom one received the correct result.

Of course, I didn't forget about colorblind people and I18N, so I'll add checkmarks and cross to both datasets indicators and LCD displays very soon. I also think that LCD displays should show received data after execution, not the expected result. Or I should somehow toggle shown data, so I can see what data I want and what data I got within few clicks. I'll think about it.

But what's more important and exciting is that I've added circuit emulation animations! They were removed after I decided to revamp emulator and now I finally returned them:

Click to see larger picture.

And now I can finally replace outdated gif from the first post with a new one, identical to the old one (only in terms of the same scheme), but very different. Compare yourself:

The old one

Click to see larger picture.

And the new one:

Click to see larger picture.

wow                                      
                                       such better

         so improvements

[0x0961h]

Update #9. Labels and Users

Hey, everyone! 0x0961h's here, reporting about NeuroIDE status. It's alive. Thank you, good bye!

Nah, just kidding about the "good bye", I, actually, have something interesting to show you and to ask about.

First of all, I've added fancy data labels! Now you can see what data are traveling between elements:

You can also see, right after the beginning, that animation can be paused. I made it to give player ability to freeze the whole circuit to see what data can cause errors and everything. Player can also "highlight" the label to be able to distinguish one data piece from another:

A-a-and now to the prototyping phase. Yes, I'm back to UI. Sort of.
I want NeuroIDE's UI to be simple and powerful without obvious overkills and whistles. That's why, I'm afraid, I'll have to cut off circular menu, because it just doesn't feel right here.

Right now I made this prototype of game screen:

Click to see larger picture.

Left to right:

• Mode selector to change a game mode: Edit (to place and manipulate elements), Launch (to execute circuit on high speed to test all the datasets) and Debug (to execute circuit only on currently selected dataset step by step)
• Context buttons to use tools of current game mode
• Dataset selector to see datasets statuses (passed/failed) and select active dataset

Context buttons will change once player press Edit or Debug button:

Click to see larger picture.

A-a-and one more thing. 'cause I'm thinking about abandoning circular menu, I need to show context operations somehow. Right now I have an idea of a small circular context menu like this:

Pretty Watch Dog-ish, huh? Well, looks like a plan for me. But, you know, I'm open for your opinions if you have anything to say about it.

Cheers!