DLL-Node Faster than regular?

[Goblin Witch Girl]

Okay I did some testing and it sems that the Custom Nodes are consistently faster than just putting nodes per hand. Is that intentional? Because I feel like a cheater now ...

[Mitch Rocks]

It is intentional, it works that way with nodes based on prior tasks too. The idea is that it runs trhough the condensed node faster than through the uncondensed node.

Also, in programming, there is no cheating, only doing it better.

[Delth]

That behaviour is... bizarre...

What happens is, the time shortens whenever you pack existing scheme (say, custom node) inside a scheme (say, DLL, or another custom node). Every time you do that, regardless whether your new scheme does something else or exactly the same, the time to finish the operation decreases. That's what happens with "Only Red" custom node, which packs "R/Else divide" and is therefore faster. Depending on how many DLL slots you have you can make that operation even faster (by nesting them). What the hell.

I mean, fine, but it is bizarre and not at all explained in the game.

[nulldivisor]

I agree. What's more, the only way to reach gold on some tasks seems to consist of using these nested custom nodes with their undocumented magic properties.

I spent quite some time in vain trying to come up with clever solutions based on the concepts taught in-game, optimizing parallelization and so on. The solutions based on the weird properties of custom nodes feel rather unsatisfying and more like abusing a bug.

The fact that the timing information on these nodes seems to be off and isn't really explained anywhere, doesn't help either. I'm really not comfortable with using these nodes in the current state.

[GospodinNoob]

Originally posted by nulldivisor:

I agree. What's more, the only way to reach gold on some tasks seems to consist of using these nested custom nodes with their undocumented magic properties.

I spent quite some time in vain trying to come up with clever solutions based on the concepts taught in-game, optimizing parallelization and so on. The solutions based on the weird properties of custom nodes feel rather unsatisfying and more like abusing a bug.

The fact that the timing information on these nodes seems to be off and isn't really explained anywhere, doesn't help either. I'm really not comfortable with using these nodes in the current state.

Originally posted by Delth:

That behaviour is... bizarre...

What happens is, the time shortens whenever you pack existing scheme (say, custom node) inside a scheme (say, DLL, or another custom node). Every time you do that, regardless whether your new scheme does something else or exactly the same, the time to finish the operation decreases. That's what happens with "Only Red" custom node, which packs "R/Else divide" and is therefore faster. Depending on how many DLL slots you have you can make that operation even faster (by nesting them). What the hell.

I mean, fine, but it is bizarre and not at all explained in the game.

Hi.

As said in tutorial, DLL nodes and custom nodes don't spend time to send elements from one node to another, so the works faster. Thats true.

[joanq]

Just discovered this behaviour trying to solve the Dictatorship level with gold medal.

It doesn't feel right: you can make a custom DLL for each level exactly the same way you'd solve it directly, but the solution will be faster (a lot faster).

I don't think it's just the time spent sending elements. My DLL takes 12.3 seconds, and the same solution by hand takes 38.7 seconds.

[Delth]

Originally posted by GamineBrownies:

Hi.

As said in tutorial, DLL nodes and custom nodes don't spend time to send elements from one node to another, so the works faster. Thats true.

A passing mention in tutorial text (which I really don't remember, and I encountered that behaviour on the same day I started a new file with tutorials) is really not enough for behaviour that important and unexpected.

Also, that does feel like a bug. The way DLLs are set up they feel like they should only serve the purpose of creating your own custom nodes the way you want them. A decluttering measure. If they're supposed to be a strictly better option... Than gameplay wise, they suck, since they provide an obligatory busywork for those wanting the best scores. No thought needed, not a design challange, just "implement your solution in another screen and it's magically better". Not to mention "and pack it in another DLL as many times as you have slots for even better result".

[Mitch Rocks]

I agree the recursive stacking's an issue. Having something actually math out the travel times between nodes and subtract that would help to fix that, since one node schemes wouldn't have travel time.

[125_m_125]

I initially thought, that dlls where only intended to store partial solutions... Looks like I was wrong. While I could understand a little bit of speedup, the dictatorship solution makes zero sense to me... Connect both outputs of a load balancer to a single only red block, and suddenly you have a block that filters only reds with a speed of 0.084? Shouldn't the resulting speed still be close to 1? This dll is now 12 times as fast as the same construction without dll...

[GospodinNoob]

Originally posted by 125_m_125:

I initially thought, that dlls where only intended to store partial solutions... Looks like I was wrong. While I could understand a little bit of speedup, the dictatorship solution makes zero sense to me... Connect both outputs of a load balancer to a single only red block, and suddenly you have a block that filters only reds with a speed of 0.084? Shouldn't the resulting speed still be close to 1? This dll is now 12 times as fast as the same construction without dll...

Hi
time on a custom node isn't the same as on normal node. It is time "how often node start processing the element"

[The Flaming Red]

I too completely missed where it said this in the tutorial, and gameplay wise this was compeletely unituitive that a script we manually programed on a previous level now runs magnitudes quicker when used on a later level.

I mean, this passes with gold:
https://i.imgur.com/JIJkRYv.png

Meanwhile, recrerating the same thing in the nodes ( https://i.imgur.com/ACPIHJO.png ) or even to its purest form ( https://i.imgur.com/6ynufOB.png ) get so jammed up that you don't get the same result. (however, both these latter solutions take close to (if not exactly) identical times to complete. Note that all of these solutions use the same node limit (4)

When it comes to having a fun, puzzle, logic game - I feel that identical solutions (which all of these three solutions are) should have identical outcomes, otherwise the logic just is not consistant. Instead we have some strange caveat rule that "if you use a custom node within a custom node in your solution then the outcome will be faster for no apparent reason" - and while I missed the tutorial message regarding this, I don't feel that this concept should be a part of a puzzle game in the first place. It becomes a 'what is logically the best way to do this' to 'am I doing exactly what the game designer wanted me to do for this puzzle'

I am all up for a game that wants me to do thing with an optimal solution in various ways. I love Human Resource Machine and Cargo Bot (ios) and both have levels in them I cannot get a gold star for (HRM has some levels where I just cannot figure out a way to remove a step I don't need & CB has this awesome thing where you can do a wind-up mechanic so that a solution can return itself to its intial position with use of running scripts - and half the time I cannot wrap my head around that process), however this strange 'ah, just put the solution in a custom node to make things quicker' just..... its not the right way to promote optimisation.

[Majora]

Originally posted by TheFlamingRed:

I too completely missed where it said this in the tutorial, and gameplay wise this was compeletely unituitive that a script we manually programed on a previous level now runs magnitudes quicker when used on a later level.

I'm in the same boat, it seems like I missed the part where custom nodes were explained. Up until the dictatorship level I thought the game was good, if different from other puzzle games such as Zachtronics ones, especially because of the way solutions are timed, which makes it impossible to get a gold medal without upgrades. It adds another layer, but suddenly you're not just judged on your cleverness, but also on how many upgrades you bought to get that little 0.05s boost that will change your rating from silver to gold.

Now, the way custom nodes work in regards to timing makes little sense, even in the conext of a game. To add to your examples, those two perform differently when they are basically the same if you decompose the custom node:

https://steamcommunity.com/sharedfiles/filedetails/?id=1630720518

https://steamcommunity.com/sharedfiles/filedetails/?id=1630720440

At this point it feels like the game will just become "what custom node of a custom node of a custom node to build so that the time gets even closer to 0?", unfortunately.

[Archi]

This is the biggest ♥♥♥♥♥♥♥♥ that ruins the whole game for me. I'm a programmer myself and this logic is the most irrational thing out of whole game, let alone something that doesn't exist in real world. Creating a function and packing logic there, if anything, increases computing requiremenets or at best gets inlined in a way that computing requirements stay the same. I have no clue who thought that it'd be a great idea to make custom modules and DLLs magically cut the processing time inside them to just a single node, but finding out about this has just ruined the whole experience for me and turned a masterpiece game into a piece of garbage. Judging from the release state of the game, I doubt that you're going to completely rework the mechanism introduced here (as it'd require recalculation of objectives basically in the whole game), so the game changes from a beautiful optimization experience into "now copy-paste what you've created into a DLL and just put that DLL there so it magically gets 4x faster".

On top of that there are other irrational things, such as how decision tree created from Red and Any, with outputs of A and B actually do not produce the reversed output when you change them to Any and Red. This means that one setup will be faster while other one will be slower, it's especially visible on medx level where switching Any/Red to Red/Any and appropriately reversing the outputs will magically make the solution slower than the other way. If you switch both Any/Red and Any/Green to the reverse and update outputs, then magically you'll fail your gold because the solution somehow got slow enough to bring you down to bronze, except logically it's exactly the same, because there is no branch prediction implemented in the game, so A ? B -> 1 : C -> 2 should have the same performance and output as !A ? C -> 2 : B -> 1.

I could classify second thing as a bug, but the fact that you've classified first thing as intended mechanism in a game that strictly follows expected logic makes it immediate thumbs down for me. I really wish that you'd rework this mechanism into something that is actually appropriate (custom modules and DLLs working as inlined functions), but I know the reality and the fact that it's highly unlikely to happen. But if by any chance you wake up and realize how flawed it is, please prove me wrong and correct this game-breaking "intended features" that ruin the whole experience for not only programmers, but gamers first and foremost.

[The Flaming Red]

Originally posted by Archi:

I could classify second thing as a bug, but the fact that you've classified first thing as intended mechanism in a game that strictly follows expected logic makes it immediate thumbs down for me.

I must admit, that I'm only a modder for a couple of games, and this element of the game went me from saying "hey, check out this cool little programming game" to "but it seems to have a strange concept in the middle" to removing the recommendation completely within an hour before anyone really saw it. And this is a shame because the presentation and variety up to this point had me invested. The start ups were very interesting because of the impact the upgrade system had and promoted experimenting with complexity and seeing how earnings change.

However, after finding this illogical concept in a logic game, I probably would have refunded it then and there, but after doing all the investigations and grabbing all the screenshots and checking online to make sure this was intended behaviour, I had surpassed steams magic 2h mark.

[2rok]

This DLL cheat is totally ruins the game. I've found the game challanging until that point when I found the DLL option. Now it ridiculously easy. I just have to construct a far from optimal solution and put it in a DLL. Also the "self driving car" and the startups are a totally random events. If they fix it it can be a good game. Now the first part is good the midgame/endgame is horrible.

[Archi]

Originally posted by TheFlamingRed:

Originally posted by Archi:

I could classify second thing as a bug, but the fact that you've classified first thing as intended mechanism in a game that strictly follows expected logic makes it immediate thumbs down for me.

I must admit, that I'm only a modder for a couple of games, and this element of the game went me from saying "hey, check out this cool little programming game" to "but it seems to have a strange concept in the middle" to removing the recommendation completely within an hour before anyone really saw it. And this is a shame because the presentation and variety up to this point had me invested. The start ups were very interesting because of the impact the upgrade system had and promoted experimenting with complexity and seeing how earnings change.

However, after finding this illogical concept in a logic game, I probably would have refunded it then and there, but after doing all the investigations and grabbing all the screenshots and checking online to make sure this was intended behaviour, I had surpassed steams magic 2h mark.

Sadly the same for me. The best I can do is write a review to warn others and hopefully convince the devs that it's a flawed concept that needs fixing. It's sad to see such great masterpiece game ruined by such irrational and stupid detail, the whole gameplay is awesome, but the level design which expects from you to get upgrades and abuse DLLs to get gold medals is utterly stupid.

However, to not leave the devs alone without a constructive feedback, here is my list of things that should be corrected:
- Custom modules and DLLs should have the processing time (and all other details) equal to writing all inner nodes by hand.
- The decision tree logic mentioned by me above should be investigated and fixed, this is very likely a bug, as the node does not work as it's documented to work.
- Levels which are impossible to gold should be properly annotated with "you might not have hardware/skills good enough to finish this level yet". Either something is a solvable (but possibly super hard) puzzle, or something is impossible to beat in the first place, and the game should not expect from the player to guess on his own.
- All levels will likely need to be reworked in terms of target time after first (and likely second) cases are resolved.

I'll keep an eye on this thread and potential future patches to see if the situation improves.