next »

[0x0961h]

NeuroIDE is a math and logic-based puzzle
in a cyberpunk world of technologies, evil
corporations and neural implants.

G R I M   C Y B E R   D A R K N E S S

The first version of NeuroIDE (aka "prototype") was made for April's Cyberpunk Jam and still available to play at my itch.io page.

So, in a prototype you played as a doctor in a classic CyberPunk future world filled with neural implants, corporations, glowing hi-tech stuff and civil wars between human formations. Your mission was to fix neural circuits in people's brain implants. These circuits were processing data from neural inputs using 4 math elements (add, multiply, even/odd checker and zero signal generator) and sending results to neural outputs. You must connect elements to each other in a way that produces correct outputs for multiple input data sets.

The prototype contains 2 interactive tutorial levels and 10 puzzles.

N E U R A L   M O D U L E   B L U E P R I N T

I'm working on an extended version of NeuroIDE right now. I'm remaking it from zero, making it more polished and interesting. My main goals are:

• Adding more elements (maths elements, logic gates and some fun things)
• Adding more gameplay features (more complex wiring, more freedom for placing elements)
• Complete, non-"please read it in description" story
• Adding more hardcore math and logic puzzles
• Accessibility design (e.g. colour schemes for colour blind people, ability to use only one input device and rebind it buttons)

So if you was always fond of flip-flops, maths, algorithms, circuits and programmers' games, I'm pretty sure you'll find NeuroIDE as good as I see it.

I M P L A N T   S T A T U S

Game is in active development phase since October 26, 2014.

Done stuff:

• Basic elements placement logic
• Basic wiring and wires management
• Step-by-step execution
• Automated execution
• Multiple input datasets
• Notifications system
• Circuit elements synchronization
• Basic I18N stuff
• Restrictions for elements placement
• Wires removal logic

Stuff to be done:

• Neuroelements library UI
• Elements removal logic
• A lot of other awesome stuff

I M A G E - T O - B R A I N   M O D U L E

Click to see larger picture.

E X O N E T   R E S O U R C E S

0x0961h’s NeuroIDE was made for last month’s Cyberpunk Jam; in it, you are a doctor tasked with fixing the neural circuits in people’s brain implants. To do so, you must exercise your powers of logic to solve some pretty difficult math problems.

In some ways, NeuroIDE is reminiscent of SpaceChem. You have data inputs on the left and must use pre-defined operations to change the data inputs so that they match the required outputs on the right-hand side. NeuroIDE is less complex than SpaceChem, though, with no ability to have branching if [something], then do [whatever] clauses and only four possible operations. You can multiply numbers, add them, check to see whether or not a number is even, or pass in a zero.

NeuroIDE’s puzzles feature something that SpaceChem doesn’t have, however, which is multiple data sets. That is, most of the levels have multiple sets of input/output numbers. Your solution must work for all of the data sets in the level. That’s what makes the game so difficult: you must find one formula that works for all of the data. It’s serious math problem-solving in game form, and even with a “debug” option that shows you all of the values that result from your current configuration, the puzzles still take some work to solve.

0x0961h designed the game with colorblindness in mind. It also has an option to turn off the glitching background effects for those with epilepsy.

NeuroIDE demands (demands!) that you connect A sockets to C sockets, using the appropriate B. That involves combining numbers in different ways to achieve the correct results, using different mathematical signs. Once you’ve got that down, it’ll show you how you’re wrong, because your solution needs to apply to multiple dimensions, not just the one.

It’s good for a small session, and won’t tax your brain a crazy amount. Just the right level for the end of the day.

A D D I T I O N A L   D A T A S E T

You can follow me on Twitter (@0x0961h) to receive updates about NeuroIDE.
I'm also available on Tumblr (0x0961h.tumblr.com), but it's pretty silent in here.

[Slader16]

I need this game in my life.

[pmprog]

Looks pretty cool.

[0x0961h]

I need this game in my life.

Looks pretty cool.

Thanks, guys. I hope it'll be cool when I finally release it. Someday.


Update #1. NeuroVM.

Warning! Tech stuff.

So. A little update for you. I'm working now at... how should I call it... ah! "Flexibilization"! (really?) Until now all the elements were loaded to some sort of library this way:

Onсe again: all the elements. I have 4 elements right now, but I have plans for much, much more. This approach was good at the early phase, but for now... it's not so flexible, too limiting. I didn't have problems to throw information about inputs and outputs into JSON and just parse it during library initialization though. What was bothering me most: element action code. Like, okay, I extract everything from code to JSON, but still have actions being describe inside the game code. That's how I decided to try a virtual machine approach.

Long story short: I want to have some sort of tool that will process bytecode and do some stuff I want it to do. So when data reach element circuit emulator won't poke NeuroAction's doProcess method, it will push bytecode to the VM and it'll do all the job.

That's how I ended up with this kind of system:

The steps are:

1. Extracting Base64 encoded bytecode from JSON file
2. Decoding it to byte array ("true" bytecode)
3. Sending this array to NeuroVM
4. Sending data from emulator to NeuroVM
5. Executing bytecode

The simple program that performs arithmetic operation of addition on two numbers in a NeuroVM Assembly Language looks like this:

Code:

push rg_in[0]
push rg_in[1]
add
pop rg_out[0]

The modulus operation program looks like this:

Code:

push rg_in[0]
push rg_in[1]
sub
abs
pop rg_out[0]

More complex example: (4 + i1) * (7 + i2) + 13

Code:

def tmp

push 4
push rg_in[0]
add
pop tmp

push 7
push rg_in[1]
add

push tmp
mul

push 13
add
pop rg_out[0]

As you can see, it's not very difficult to understand especially if you ever poked any Assembly Language before. Each element has few registers (e.g. inputs, outputs, top/bottom service port registers) data can be extracted from, there's a stack to push and pop elements, there are variables to hold data between operations.

This code is not what will be stored in element description block, though, and definitely not will be executed by VM during gameplay. This code will be compiled to the sequence of bytes. Last one, for example, compiles to this:

Code:

76 31 30 30 7E 7E 01 01 00 04 03 00 00 06 04 00 01 00 07 03 00 01 06 02 00 09 01 00 0D 06 05 01 00 

Unreadable for humans, perfect for VM. To be able to store this bytecode in JSON I encode array with Base64 to "djEwMH5+AQEABAMAAAYEAAEABwMAAQYCAAkBAA0GBQEA", which can be easily saved to file and can be easily read from it during initialization.

So, this is how I made a basic virtual machine (I call it NeuroVM or NVM) to be able to work with basic arithmetic (and logic, atm) operations. It's enough to cover logic for most elements. Though, I don't quite understand how I should convert syncrhonization element code to bytecode. Well, maaaybe I should review synchronization process first, make it more generic and maybe then I'll be able to convert its logic to NVM format.

But! I will think about it later. Thank you for your time, Happy Holidays to everyone.

[wccrawford]

Love these kinds of games.  Looking forward to this!

[0x0961h]

Love these kinds of games.  Looking forward to this!

Will try not to disappoint you.


Update #2. Elements' Design.

So, Happy New Year to everyone! Let's get down to business, there's a lot of thing to do... and to think about.

First of all, after I've successfully implemented and integrated described above NeuroVM thing into the game core, I decided to move to elements' design. Since I have separated (not fully yet, but it's only a matter of time) elements' data from library code, I thing it's a good time to work on this issue.

Old design was pretty good (imo), but it was hand-crafted, which means I'll have to make every single element all by myself. Which sounds like an overkill. So first of all I captioned all the ports, so player can understand what this port is for:

(I also added x4 zoom so players won't have to strain the eyes to see these captions)

Looks pretty sweet. But not enough. That's why I played a little with new element design so I'll be able to "bake" it during library initialization part:

And if someone's reading this right now, I'd really appreciate some feedback on this iteration of elements' design. Thanks.

[Kyzrati]

And you were hesitating to do any kind of devlog before? This is complete awesomeness!

Love the designs, both actually, though it's difficult to compare directly from what you've provided here--for comparison shots you should make as many variables consistent as possible, and in this case is the second supposed to be the same size (in use) as the first? Shrink the second and give it the same surroundings as the first. It could be that I just like the colors of the first better, but it's difficult to be sure.

[0x0961h]

And you were hesitating to do any kind of devlog before? This is complete awesomeness!

Eeyup, because I'm a very bad storyteller. :D

...though it's difficult to compare directly from what you've provided here...

Oh, oh, sure, sure... Haven't thought about that...

• A is a "published" design as seen on animation in the first post. Was revamped for the sake of new element structure.
• B is a design from the Update #2.
• C and D are here for the sake of design diversity.

[Kyzrati]

I say B.

A has little color variation and fuzzy background lines purely there for the look.
C has a less consistent-feeling style.
D is difficult to read with such a bright background.

B, though, looks good with the subtle yet thicker inner connection lines and higher contrast. It also just "looks coolest" to me

It could be that C looks better when zoomed out, though, since the central symbol stands out a lot more with that contrast. If differentiating between symbols of different elements is the main focus of gameplay, make sure that's easy.

[0x0961h]

I say B.

Thanks for the feedback. I like it too. I think I'll stick with this design for now. Maybe I'll come up with something even more good later, who knows.

[pmprog]

I'd also say "B"

[0x0961h]

Update #3. Elements' Design.

Good news, everyone! I've finished (for now, at least) designing elements. Thanks for all your feedback!

And, of course, I couldn't leave elements static, and I added a little "juice" to it -- glowing inner wires. Heavily inspired by old-school colour cycling I decided that having this kind of thing in NeuroIDE would be pretty good for the static circuit elements.

I've also integrated this animation into the emulation flow.

Click to see the full size & pixel-perfect GIF.

All the element become "alive" when they receive a data to process. Synchronization and input elements begin to "glow" right after player launches circuit emulator.

[0x0961h]

Update #4. Wiring System v2.0

Well, it all began with this:

I decided to change the way player selects element port for wiring. The previous way of doing this was pretty good, but it turns out it was good only for test environment. When it comes to wiring two elements that placed near each other... Well, it looks like the most awkward and unconvinient way of doing this. So I decided to remade the whole port selection process. This new approach worked pretty well with the old wiring system:

And then I suddenly remembered that I wanted to revamp the wiring system, and give more freedom by adding manual wiring. That's where things went down the Rabbit Hole. After short programming session the first iteration was ready. It was all curly and "45-degrees-ish" (oh my, really?), but there was a lot of problems...

I planned the mechanism this way: you click on the port, fix wire in some points, then click on the other port and wire automatically connects to it. Sounds good, but it required to completely remake pathfind method. Previously, pathfinding was based on a "big grid" (as seen on screenshots as semitransparent dotted squares). It searched path from center of the first element to the center of the target element and then "normalize" it to make lines connect with elements' ports and to make 'em more linear.

New method just naively connected last fixed point with the port and then lines were feeded to the old optimization method. But the problem was that this method was too naive and all that it did -- it was straighting lines. And in some cases wires were "optimized" in a way they crossed the elements. Not what I really wanted.

The second iteration of the new wiring system eliminated diagonal lines, changed the pathfind algorithm and changed the behavior of the "last mile" connection strategy. If player's wire almost reach the port, it's just extended until they connect. Otherwise new pathfind algorithm takes the wheel.

Basically I had to abandon "big grid" approach and think more "molecular". Algorithm makes jumps for 1/8 of grid square size from side to side, just like in good old A*. After few iterations, I've ended up with very slow implementation of A*, so I had to add some visual feedback to trace the problem.

Click for the full pixel-perfect version.
This is from more optimized implementation, the old one
"hanged" the game completely.

So-o-o, the algorithm was looking at already visited points, even though I told him not to do it. But, you know... children... always so rebellious... ahem... where was I? After I fixed this weird behaviour, A* suddenly became Dijkstra-like and very slow, which was eliminated by applying some tricks from amazing Red Blob Games' A* article series. After multiplying heuristic function result by 1.001 all the problems with pathfinding were solved and I got this:

Tada-a-a!

As you can see, I still need to fix the "last mile" segment, there are some problems with redundant wire segments, wires are still laying over each other (but I think I'll fix it with giving the ability to "move" wires up and down), but it's not so important right now. What's more important is that the new wiring system...

...works. C:

[0x0961h]

Update #4.1. Bells & Whistles

This week was pretty quiet for NeuroIDE. Fixed few wiring system bugs and added framebuffers to my ECS-based game framework, so now I can make a lot of fancy things, like this background animation straight from jam's version:

Click to see larger picture.

Also found a "let's play" video on YouTube and realized that the original puzzles were a mess. Things that were meant to be solved in weird ways could be solved by simple double multiplication. But after few levels here comes this piece of art:

Click to see larger picture.
Image was posted in comments, because author failed to solve the puzzle and requested help from his viewers.
Difficulty curve? Never heard of it...

We-e-eird.

Oh, and, I've made a IndieDB page for NeuroIDE. I don't think you'll gonna be interested in it, mostly because it'll be a mirror of this devlog, but still. Yay.

[~Tidal]

Keep going. I really like this, it will be great!

[0x0961h]

Keep going. I really like this, it will be great!

Oh, thank you. I hope it will be great.  

[0x0961h]

Update #4.2. Wires

Wireman. That's how they call me. Wireman. Because I spend, like, 90% of development time modifying wiring system and wires' behaviour. And you know what this post will be about? Aha, you're right.

Bad news first: I decided to get rid of free wiring. It's cool and everything, but it's filled with bugs, so (at least for now) I cut this feature from the game.

After that I suddenly faced strange bug with "mouse over" action. I have a Polygon object binded to GUIComponent and I'm checking if mouse position is in this polygon. Not long ago I replaced naive creation of Polygon with pool-based obtaining, and -- tadaaa! -- here was the bug. I still don't know why it has happened, I think it's because Polygon wasn't cleared correctly after "freeing". I still have a "dirty" code with lots of expensive memory allocations, so I decided to leave this issue for the optimization phase.

Let's talk about my favorite wires, though. I've changed two things. First of all, I fixed weird straight lines behaviour:

Before (top) and after (bottom). Corneration ftw!

No more filthy "non-right" angles. Good.

After that I played a little bit more with pathfinding algorithm and make it take in account other wires to minimize crossings. That's what I've got after this little modification:

Before (top) and after (bottom).

The first one is pretty organized, but wires are combined into some sort of buses. It's clearer, but can be confusing. The second one looks wa-a-ay more weird and chaotic at first sight, but new pathfinding method in combination with wires colors and different patterns increases quality of visualization.

Fun fact: NeuroIDE has got some fancy wire patterns.

[0x0961h]

Update #4.3. Distinguishability

This week I was playing with another way of increasing "distinguishability" of wires and elements by highlighting them. Turns out it's pretty good. You hover your mouse over the wire, wait one second and see only this wire and two elements connected with it:

When you hover your mouse over elements you'll see a familiar thing, but this time all the wires and elements connected to this element will be highlighted:

This little trick solves one of the problems with "can become very messy" wires -- losing of "distinguishability". Not very appealing and leads to frustration. Though I don't think that puzzles will be that difficult to have such weird connections all over the circuit board.

One more little detail that was added this week: in element placement mode cells, that player unable to install new element to, are red now:

[William Chyr]

One more little detail that was added this week: in element placement mode cells, that player unable to install new element to, are red now:

Instead of using red to show where the player can't place something, have you tried using green to show where they *can* place?

[0x0961h]

Instead of using red to show where the player can't place something, have you tried using green to show where they *can* place?

T-that's actually a very intersting idea and a pretty great psychological aspect. Yeah, maybe you're right, I'll try this approach, thanks!