Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1370252 Posts in 64449 Topics- by 56501 Members - Latest Member: liquidpigstudios

December 09, 2019, 01:54:44 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogs5N²+6N-4 . . . . . . (codename)
Pages: 1 ... 3 4 [5]
Print
Author Topic: 5N²+6N-4 . . . . . . (codename)  (Read 8327 times)
a-k-
Level 1
*


View Profile
« Reply #80 on: November 30, 2019, 07:46:02 AM »

.
Logged

a-k-
Level 1
*


View Profile
« Reply #81 on: November 30, 2019, 07:47:53 AM »

I think having a shortcut for swapping workers would be pretty convenient, because my most common mistake was "oh whoops i got the order wrong" and then having to re-input both workers, or having A join B require drag join then two more shortcuts instead of just drag and swap. It is just another shortcut, but given how many times I found myself just wanting to swap the order instead of change the actual workers, I'd probably get more use out of an exchange shortcut than the dedicated worker and SHIFT+worker shortcuts as the majority of my use of them was swapping the order already on the command.
Shortcut added (that was 3 lines of code).

And yeah I guess my natural assumption was that program counter would continue along the last direction without interruption, especially if I'm just dragging commands into a straight row. I definitely think laying commands could be made faster with the ability to maybe turn on/off an autoconnect that links the last placed command to the newest command if they're adjacent or something like that, something optional.

But either way, great work with the project!

Thanks, this is really helping! I've implemented auto-connect and it's now in the prototype. It's not optional, it's unlocked after a few levels and then effective forever (that practice may be controversial, I know...) It can be enabled already from the first level by opening the browser console and typing
window.frames[0].postMessage('enableAutoConnect', '*');

Just managed to sit down and give this is a spin. Very neat!
Thank you!   (looking up the various meanings of neat in the dictionary...)
Logged

JobLeonard
Level 10
*****



View Profile
« Reply #82 on: December 01, 2019, 01:25:01 AM »

(Oh shit, don't tell me there's a negative or sarcastic one among them? Who, Me?)
Logged
a-k-
Level 1
*


View Profile
« Reply #83 on: December 02, 2019, 09:57:03 AM »

I figured I would provide more details about the auto-connect algorithm mentioned in the last post. It's quite involved, so I'm just going to provide a specific example here while simplifying things for the sake of presentation.

We're talking about the player inserting commands using the mouse or the keyboard, including the ability to copy or move commands around, and the editor attempting to spare the trouble of manually setting the direction of each command toward the next one.

The algorithm is activated whenever the player inserts a new command in an empty cell on the grid, and that cell is not pointed to by any of the existing commands (i.e. it is "disconnected"). For example:


(player inserting a command into a grid with 4 sequences of commands)

Here, there are four neighboring commands, (1) to (4). Which one, if at all, should we connect to the newly-inserted one?

In order to reduce guessing, the editor remembers which command was placed last. This is tricky since the player may move the command, edit older commands, and in general perform arbitrary drag & drop operations that are sometimes ambiguous. And when they're finished, continue inserting more commands. So the editor has a "best-effort" concept of that previously-placed command - sometimes it's known, and at other times it's not.

When this information is available, how is it used? If the previously-placed command was (1), (2) or (3), then we simply connect it to the newer one. If it was (4), we don't auto-connect anything since it already has a direction (pointing downwards).

Now, suppose that we don't have a previously-placed command, or perhaps we do have, but it is neither of (1) to (4). In that case, we examine each one of the neighbors.

First, just like before, (4) is eliminated since it already has a direction. Secondly, we give priority to (1) over both (2) and (3) since it is part of the current program (that starts with the yellow symbol at the left) - there's greater chance that the player is currently editing it. Since we're left with only one candidate, we can now auto-connect (1) to the newly-inserted command.

Actually, (1) is not always selected. If (1) is part of a solution to the level that the player has already tested, then why would they want to extend it further with another command? In that case, (2) and (3) remain the only relevant candidates. In general, if there are two options and we can't determine which one to select, we do nothing. But suppose that (2) is also part of a (probably different) solution, and (3) is not - in that case, we'll auto-connect (3) to the new command.

There are additional safety measures, like not auto-connecting commands that are far away and therefore invisible (cannot happen in the prototype), and more design decisions like having the auto-connect be part of the same undo/redo event of the command insertion, so that undo cancels both.

As you can see, the algorithm takes many variables into account. While this may introduce some form of unpredictability for the player, in practice all this information is used in order to be as conservative as possible, and most importantly, in any case never override previous decisions of the player. This last point implies a simple way for players to avoid the algorithm altogether - set the direction of the last command before placing the next one. So even though there's no setting for disabling auto-connect, in a sense it may be regarded as optional.


(Oh shit, don't tell me there's a negative or sarcastic one among them? Who, Me?)
Not in the slightest! Now also verified numerologically in radix 10 and 16.
Logged

destinysWalrus
Level 0
*


View Profile
« Reply #84 on: December 03, 2019, 04:23:35 AM »

I tried out the demo! So far it provided enough puzzle (for a demo) without driving me bonkers trying to figure things out. It took me a few tries to get how the unlink worked - I kept putting the workers in the wrong order - but once I got that down I didn't have too much trouble.

The main exception to the above was level B7, though this was mostly because I misunderstood the instructions! For whatever reason, I thought that I had to - out of the cycle and chain - construct a cycle combining the two, not a chain. I spent ages trying to figure out how I'd do that without conditionals or access to worker H, tentatively concluded it was impossible, then kept trying on the assumption that you wouldn't give us an impossible level. Basically I meant to make a single chain as Step 1, then figure out how to connect the ends as Step 2, but was mildly surprised when Step 1 was the actual goal. Facepalm Grin This probably tells me that 3:30 a.m. is not an optimal time for programming or puzzle games.

I did very much appreciate the single step forward/back buttons once I unlocked them. It meshes with my programming style - basically work on a bit of a problem, slightly tinker with it until I get that step right, then continue to the next bit and repeat.
(Python was my first programming language, and it made that kind of thing really easy)
Logged
a-k-
Level 1
*


View Profile
« Reply #85 on: December 05, 2019, 09:50:28 AM »

I tried out the demo! So far it provided enough puzzle (for a demo) without driving me bonkers trying to figure things out.
Thank you for playing the demo! That's exactly what I've been aiming for.

It took me a few tries to get how the unlink worked - I kept putting the workers in the wrong order - but once I got that down I didn't have too much trouble.
You seem to be in good company with respect to "unlink"! There are good reasons for keeping the order of the workers as is, as well as not reversing the animation (which might have helped?) Instead, I've changed the error for "unlink" so that it will be slightly different when a link exists in the opposite direction. It's subtle but perhaps it can help a little.

The main exception to the above was level B7, though this was mostly because I misunderstood the instructions! For whatever reason, I thought that I had to - out of the cycle and chain - construct a cycle combining the two, not a chain. I spent ages trying to figure out how I'd do that without conditionals or access to worker H, tentatively concluded it was impossible, then kept trying on the assumption that you wouldn't give us an impossible level. Basically I meant to make a single chain as Step 1, then figure out how to connect the ends as Step 2, but was mildly surprised when Step 1 was the actual goal. Facepalm Grin This probably tells me that 3:30 a.m. is not an optimal time for programming or puzzle games.

Any time is perfect for having fun! I think I can see where the confusion came from, the layout of the goal was too similar to a cycle, at least for the default input. I've changed it to be S-shaped:



I did very much appreciate the single step forward/back buttons once I unlocked them. It meshes with my programming style - basically work on a bit of a problem, slightly tinker with it until I get that step right, then continue to the next bit and repeat.
(Python was my first programming language, and it made that kind of thing really easy)

I'm glad you find backward-stepping in particular useful - it's even more powerful when combined with breakpoints and more challenging levels. When you control all state changes, supporting running backward is actually no different than having undo/redo.
And Python is a great language! It's even included in the full game (though I had to butcher it a little for achieving that... may BDFL forgive me.)
Logged

a-k-
Level 1
*


View Profile
« Reply #86 on: December 07, 2019, 10:15:58 AM »

I've discovered (a bit late) that most players could not communicate with my server, so their solutions were not received and the global histograms were not shown to them. Nobody here complained about this, I guess you all thought they weren't implemented.

I'm still not 100% sure what the root cause is. Before I made the game available here, the itch.io version had already been tested on 4 browser families, on multiple computers (and 1 smart TV), and everyone had seen the histograms. After rejecting a few possibilities (locked-down environments, DNS/DoH issues, CSP etc.), I came to suspect browser extensions such as ad-blockers that do not only use blacklists but also employ heuristics to block tracking - perhaps they classify my XmlHttpRequests as such?

I'm not familiar with ad-blocker extensions (I use different measures), but come to think of it, if I were to develop one, I would certainly block the communication with my server. Here's why:


(itch.io setup)

1. The webpage is hosted on one domain (....itch.io)
2. The game runs inside an <iframe> from another, unrelated domain (....hwcdn.net)
3. The code from that 3rd party domain, running in that <iframe>, tries to communicate with yet another 3rd party domain (my server)

Now, even if I wanted to, I can't test with all the various ad-blockers, and I imagine their heuristics constantly change anyway as part of the online tracking arms race. So with some educated guessing, I changed the setup on itch.io as follows:


(new itch.io setup)

1. The game now runs from my server instead of the CDN that itch.io uses.
2. The communication between the game and the server is in the same domain.
3. Additionally, the domain name was renamed from a combination of cryptic letters to the game name, and the server endpoint URL - from "gamestats" to "gamehistograms"...

This also involved hastily making my website available, where players can finally view the leaderboards, including new screenshots that show futuristic content.

I'm hoping that this fixes the issue. It would be great if someone that had previously played the game and was seeing "waiting for server.." indefinitely could confirm that they're seeing all histograms now (it's enough to test on 1 level). link to itch.io

---
Following marcgfx's feedback from the playtesting section:
[...] I also found the help text rather confusing. Telling the player to press the next button (that while looking like a button is not one, but you have to click top right).

I've added support for "control references", where a GUI element that is hovered can reference another control, by name. Specifically, when the player hovers a "rich text" label that mentions other parts of the UI, a blue arrow is automatically drawn from it to the target:


(usually the actual control is further than is shown here)
« Last Edit: December 07, 2019, 10:29:30 AM by a-k- » Logged

JobLeonard
Level 10
*****



View Profile
« Reply #87 on: December 08, 2019, 03:30:18 AM »

>  Nobody here complained about this, I guess you all thought they weren't implemented.

Yep
Logged
Pages: 1 ... 3 4 [5]
Print
Jump to:  

Theme orange-lt created by panic