next »

[zugz]

That's really weird, and I can't seem to replicate it.

If you wouldn't mind helping me track down the bug, could you redownload and try again? All I've changed is to make it write a file called 'debug' if it can't load the font file, saying where it was looking for it.

[Quicksand-S]

"Warning: font file not found at E:\_TIG TESTING EXTRA\intricacy-0.3.3\VeraMono.ttf."

The font is actually at "E:\_TIG TESTING EXTRA\Intricacy\VeraMono.ttf". Since I thought I might be getting multiple versions, I just made a folder called "Intricacy", without a version number, in which to put the files. I'm guessing you partially hard-coded the paths rather than letting it check the folder that the program is actually in?

Wow, I just got crazy deja vu and had to double-check that I hadn't already commented on all this in the past. This whole message so far seems so familiar. Weird.


Anyway, I just extracted with the folder name intact and it works fine. The main screen is still really sparse and unclear. I thought I was still missing half the text at first. The whole interface in the game is very strange, actually. I love the graphics of the puzzles, but It would be nice to be able to tell what button does what at a glance, rather than having to check all the tooltips first. The initial level of the tutorial doesn't really teach much either.

I moved the hook, pulled back the bolt as far as it would go (no idea why it stopped. I guess the two forces equalized or something?) and then had no idea what to do with the wrench. The "open lock" button is very small and out-of-the-way, so I didn't even notice it for quite a while.

Why do the controls change if I select both tools at once? I was under the impression that the hook was controlled by the numpad and the wrench by letters, but then it changed things up when I had only the hook selected. Also, the letters felt really strange because they're not arranged anything like the on-screen ones. I kept hitting "M" by accident.

Are there any other tools later in the game? If it's just the two, then why not have a "switch tool" key, rather than a specific button for each?

Note that it's not fully playable with the mouse yet. Clicking the "?" button opens up a window that has to be closed with the keyboard.

You know, this game could be interesting to try setting up gamepad support for. With two thumbsticks, one for moving each tool, and maybe the shoulder buttons for hook rotations, it might work well.

The "mark state" option is nice but a quick restart would be good (maybe just pressing "R"), and actually showing a list of which numbers have been used would probably be a good idea. Showing a thumbnail for each would be even better.

This is a small thing, but I find the wrench irritating to use because there's always what feels like an "extra" turn at the end of its path, where it's still trying to move forward but it's blocked. Why doesn't it just go into its "stopped" state as soon as it reaches a wall?

This is another smallish thing: The icon shown in the taskbar is an "unknown file type" icon for some reason.

I got halfway through the second tutorial before getting sick of the controls and the lack of teaching. I reached the end of the lock but neither tool could get into a position to push the thing, so I have no idea where to go from there.

In any case, the concept is sound and the graphics are nice. I really think the interface and controls could use an overhaul, and the tutorial could be improved with more teaching. Either show players what sorts of things they could come up against and how to get deal with them, or maybe give players a slightly more open area at first which they can use to learn things for themselves.

[linley]

I don't usually like puzzle games, but something about the art style appealed to me and I downloaded this game. No problems getting it to work on Windows, except that the text files (README etc) lack .txt extensions, which makes them slightly difficult to open, and they don't have the kind of line breaks that Windows expects (opening in Notepad gives no line breaks at all; opening in Wordpad gives too many line breaks, in the wrong places).

I got up to tutorial 4 before I got stuck; the tutorials explain what the tools do but don't really explain how the spring physics work, and I think I needed to know more about that to get through tutorial 4 (I guessed I needed to press down both yellow springs at once so that the green spring would retract, but I spent a while trying to do this, and anything else I could think of, and nothing worked).

I like the way the art style looks in a screenshot, but the graphics are kind of dry in action. It really needs little things like transitional animations when a tool or a spring moves from one position or state to another, and more feedback when you try to do something that doesn't work. Basic sound effects would go a long way, too.

Also, the blocking force arrows are useful and should probably be on by default.

[zugz]

Quicksand-S, linley: thanks for the feedback! Very helpful.

The directory hardcoding is part of the Haskell "cabal" packaging system, and would be painful to change. Hopefully the error file will be enough for that.

I've had an idea for dealing with the initially mysterious buttons: how about an initially enabled option to have the function of a button written over each button in place of the keyboard command (up to two words of 4 characters each should fit)? That would save you mousing over them.

I'll set the 'open lock' button to change colour when the lock is solved - that should make it more discoverable.

The movement keys are traditional roguelike keys. Any suggestions for something which feels more natural to the modern gamer?

Capital letters move the wrench, lower case the hook. I'm not sure how better to teach that.

I don't know how the tutorials could be improved. I wanted to keep them short and simple, basically just to teach the keys, so people got quickly into the real game. Maybe I should just get rid of the 4th one - having to figure out the details of the game mechanics in the context of solving someone else's puzzle is probably more satisfying that having it be in the context of a tutorial (where there's the implication that it's meant to be easy, and you must be dumb if you can't work it out - that's never nice).

I'll write again once I've implemented all this. Thanks again for the feedback.

[Scottimus]

Played a little bit while trying to think of ways to have the game start out more intuitively.  I have a couple of humble suggestions:

• Have the game launch right into the tutorial mode if it's your first game.
• Have the first tutorial not be a complete level. Just have the player move the hook to some place and twirl it to complete the level.  Repeat with the wrench.  Then you're on to the current first tutorial.  The hope is that this will introduce the mechanics of the game by degree and make it feel a bit less daunting at first.

A really neat idea.  Good luck!

[Quicksand-S]

The directory hardcoding is part of the Haskell "cabal" packaging system, and would be painful to change.

Ah. Too bad.

I've had an idea for dealing with the initially mysterious buttons: how about an initially enabled option to have the function of a button written over each button in place of the keyboard command (up to two words of 4 characters each should fit)? That would save you mousing over them.

That sounds like it might just switch one problem for another, since having the keyboard commands visible is helpful.

I'll set the 'open lock' button to change colour when the lock is solved - that should make it more discoverable.

My issue was just that I wasn't looking up there at all. My focus was primarily on the puzzle and the bottom left of the window, so even if something changed color up there it probably wouldn't stand out that much. I think you may need to have some larger hexagons for important buttons like that, or maybe move that button down with the movement controls (since it doesn't really fit with the "options" hexagons).

The movement keys are traditional roguelike keys. Any suggestions for something which feels more natural to the modern gamer?

They are? I don't remember ever using those letter keys in any game. I think the ones I played usually just used the numpad for movement. In any case, I feel like finding a set of letters that is actually arranged the same way as the ones on-screen would help a lot. It looks like it should be using G and K instead of H and L. Then maybe H and J could be used for rotation, so I don't have to move my hand over to the numpad. It may also make sense to swap which one requires capitals. The hook always has the numpad as an option (at the moment, anyway), so maybe the wrench should always have its letters ready to be pressed as well. (It also makes sense with the hook being larger and capital letters being larger.)

Capital letters move the wrench, lower case the hook. I'm not sure how better to teach that.

That part was clear (although not ideal since doing it with one hand feels a little awkward). What I found confusing was that you also had numpad controls for things. Why not just stick to one set of keys?

I don't know how the tutorials could be improved. I wanted to keep them short and simple, basically just to teach the keys, so people got quickly into the real game.

Having only been taught the keys, I felt like I was missing important information when Tutorial 2 came around.

My thought process, in case it helps: The first tutorial seems to teach that the final part of the lock needs to be pushed open physically, which seems impossible to do in Tutorial 2 with either of the tools. I can get through it just fine, but can't compress the final spring in any way because there's nowhere to push it from. I thought maybe I had to hold all the springs down and it would automatically open, but that didn't do anything either.

Of course, while writing that, I figured it out, and I realized what my problem was. Visually it goes against everything I've learned in the game. Being able to rotate into the side of an object without running into a blocking force doesn't feel right. Maybe that final piece could be drawn with a little more of a slant on the bottom to show that it's not just a side that you'd be hitting.

(On a semi-related note, having Y and N show up under the "Quit" button when you're being asked if you want to go to the next level is very strange.)

Balance-wise, Tutorial 3 practically leads you by the nose, while Tutorial 2 actually requires some slightly tricky maneuvering. After being stumped for ages on Tutorial 2, numbers 3 and 4 took no time at all. Neither requires any tricky maneuvering, while number 2 does to some degree.


Moving on to the other puzzles, the puzzles I encountered were really simple, but this threw me off when I tried to declare my solutions: "You first need to place a lock to secure your solution behind." The statement itself is clear enough, but actually figuring out where to do that was a problem because of the interface again. After playing through six puzzles, the controls and interface are still my biggest issue.

When I found the lock editor, the controls were a bit frustrating. Pieces regularly split into two when I tried to add to an existing piece. I'm really not sure why. I'd place one hexagon beside another and it would grow, then I'd place one above and it would cause the original piece to split. I also had a lot of times where I was trying to enlarge one piece and a nearby one would be enlarged instead. I ended up having to build pieces separately and then move them together (I was very happy to see the "right-button to move" functionality).

There are little things that are strange about the editor too. "Test Lock"? What is that for? I thought "Play Lock" would be enough. When I go to exit the editor, I don't get y/N confirmation like other places in the game.

So...I made a lock, played through it to make sure it worked as intended, saved it...and I still get the message about placing a lock. No idea what to do now.

[zugz]

Thanks for all the feedback, I very much appreciate it.

I've just uploaded a new version (0.3.4) which tries to do something about most of these problems.

I've redone the tutorial, shrinking it to three levels, getting rid of the confirmation between levels, and putting in an entirely different level for the hook which really forces you to discover the 'peeling aside' mechanic.

I've added mention of keys to various bits of text in the game. This should deal with many of the "WTF do I do now" problems.

I've made sure that the 'j' and 'k' keys to rotate the hook are shown with the rest of the hook keys, which they confusingly weren't.

Quicksand-S: does that make you any happier with the roguelike keys? I swear I didn't make them up, by the way; e.g. they're the default keys in rogue and nethack and so on, based on the keys from the 'vi' text editor. Placing a lock is a separate command ('P') - I've added a message to hopefully make that clearer.

Scottimus: I hate games that push you into playing a tutorial, so I don't like dumping new players straight into it. I've added explicit description of the movement controls to the first tutorial, and added the open key to the "unlocked" message, which should hopefully make the first tutorial as straightforward as it was intended to be.

I overlaying the buttons with descriptive text, but it looks awful. I don't know... I think the buttons are a really neat way to allow mouse-only play while teaching the keyboard controls, I'd really rather not get rid of them. I'm hoping that pointing out the important keys/buttons in the text will be enough - so rather than having to mouse over everything to work out how to do the first basic things, you're just left with some unexplained buttons you can explore at leisure.

[zugz]

So I realised that I was missing something obvious. Overlaying the buttons with help text looks awful and obscures the keybinding, but... why not draw the help text *next* to the button? Genius, eh?

New version does this, as an initially enabled option. Here's a link to a screenshot of what it looks like at its most busy, on the metagame screen with every possible button being shown:

http://mbays.freeshell.org/intricacy/screenshots/buttonText.png

Any thoughts on how far this goes toward making the interface newbie-friendly?

[zugz]

And as if that wasn't enough to prove that I listen: I've added some sound effects, as linley suggested. Not exactly Overgod standard, though ;)

[dormir]

I played your game (0.3.5). I liked it but I'd also agree with the other testers that it's quite hard to get into. The complicated and interesting puzzle mechanics are one of the positive features of the game, so that's a legitimate source of difficulty, but I think there's room to eliminate other causes of difficulty. Mainly by intuitive controls and gradual introduction of the complexity.

So, for a "newbie-friendly" interface, I'd keep the keyboard controls tucked well away. The hex-grid and the rotating hook make intuitive keys very problematic. The mouse controls work reasonably well and the undo functionality means that precision isn't that important anyway. I'm certain I'd have gotten the hang of the mechanics faster if I hadn't known keyboard controls existed. "hjkluybnHLUYBN" isn't what you want in the first tutorial sentence!

I'd also have all the buttons at the bottom left invisible by default. Players will turn to those "unexplained buttons you can explore at leisure" when they are trying to figure out how to play the game and if those buttons only provide redundancy with the mouse controls then they'll just be a hindrance.

Perhaps the tutorial text could then read more like:
Tutorial 1
Use tools to pull bolt, then open the lock
Click and drag tools with the mouse. Use the mouse wheel to rotate the hook.

It might be helpful indicating what the tools actually are too. A whizzing dot and a circle with a line coming out of it aren't intuitively a wrench and a hook. Keeping the first tutorial level really simple should help new players to more easily find the objects that they can directly move though.

I still don't really understand what is going on on the main screen where the locks on the server are displayed. "Read:"? "Holds notes:"? Different coloured hexagons with three characters on them in groups? +1? -3? This stuff could really use some kind of explanation.
My experience was that I solved a few locks and found I couldn't "declare" them without placing a lock of my own. I eventually went into the editor, but although it seems decent enough, I didn't feel ready to create an interesting level. I think players need to get a good handle on the puzzle mechanics before being asked to create a new puzzle. I understand that a single player mode isn't really what you were going for with this game but an "extended tutorial" or whatever you would choose to call it could provide a way of easing players in through a controlled progression of levels.

I hope this doesn't sound too negative. I do actually like the game and think there's some nice ideas here.


A few other specific points:

• Make the hex-grid background bolder. Aesthetically it looks cool as it is but it doesn't provide enough of a visual cue that the movement follows that grid. Also, it fades to black a lot in the centre which it shouldn't because within the lock is where it actually serves a function.
• Clicking on the wrench when it is already selected should do "nothing" (eg. advance time like the spacebar). At the moment, clicking anywhere adjacent to a moving wrench will continue its movement, but not actually clicking on it.
• Clicking on the buttons (the letters) at the top right in the editor has very strange behaviour. It places an object wherever your cursor is, which will always be the top right because that's where the mouse cursor is.
• When I tried to play the advanced tutorials by copying them into the tutorial directory as suggested in the readme, I got this (Win7):
  C:\Games\intricacy-0.3.5-win32\intricacy-0.3.5\tutorial\4-plug.text:
  openBinaryFile: does not exist (No such file or directory)

[zugz]

dormir: Thanks, all very helpful. I've implemented most of your suggestions in 0.3.7.

Making the keyboard movement buttons invisible at first, and emphasising the mouse control in the tutorials, seems like it might be a sensible idea. I have a personal aversion to mice, but I suppose I shouldn't inflict my tastes on my players. I've implemented it.

I've also added a load of mouse-hover help text on the metagame screen to explain how the scoring and so on works. It's toggled with the same button which toggles the button help text. The aim was to convey enough with use of colour and so on that the rest could be worked out with experimentation, but I suppose optional explanatory text can't hurt.

I'm torn on the subject of tutorials. I could put in a long series of easy tutorial levels gradually introducing all the tricks you can pull with the game mechanics, but I feel this would spoil the fun. I want people to discover the tricks by working them out themselves, or by playing the locks of others who have, and seeing how they can adapt the techniques for their own puzzles. So I've compromised by just reintroducing a reworked version of the 4th "plunger" tutorial level, to make sure that all the core mechanics (as opposed to all their interactions and subtleties) are on show in the tutorials.

I think it's good to force players to get into lock design early on. It shows them what the game is really about, and gets them contributing back to the puzzle pool. Of course their first locks will be easy, but it's useful to have some easy locks around for other new players to cut their teeth on. The metagame is set up such that easy locks will be removed from the pool over time.

Visible background in centre: good idea. Done.

Clicking on wrench to wait: the problem is that it then runs away from you if you try to drag it. I could have it move only on button-up, but that's getting confusing. Instead, you can now wait a turn by clicking the right mouse button.

Edit buttons: those aren't really intended to be clicked on, but not having them function when you do click on them would be more confusing.

tutorial-extra bug: thanks, fixed.

[dormir]

The metagame is set up such that easy locks will be removed from the pool over time.

Hmm, yeah. There's some tricky ones around. I just tried version 0.3.7 and attempted ZED A and ZED B and failed to solve either.

I think I get most of the metagame screen now with the exception of quite what notes are. ...And maybe some other stuff. The mouse-hover text on the metagame screen is useful but I'd go further with it to explain as much as possible. For example It'd be nice if the colours used in the colour-coded relative score was explicitly stated rather than something you have to work out. Also, I wasn't clear with the relative score about whether positive or negative was better. I guess relative score isn't a great guide anyway for new players to how hard a lock will be since they'll have zero with everyone.

The person whose locks you are viewing should probably be more emphasised. Perhaps an oversized hexagon? There's currently not even a mouseover text and I reckon that's basically a pre-requisite to understanding most of the rest of the screen.

Why does the selection of random players only show on the home screen?

What's the select lock button for (L)? I tried pressing it and then selecting lock C and the top right lock area went blank. I was then unable to access any of my locks (and what a fine array of locks I have) since the next and previous buttons also dissappeared. Order was finally restored by clicking edit and then saving a new lock as this brought the "next" and "previous" buttons back.

Any reason the button hexagons are rotated differently than the rest? I'd have to see a comparison to be sure but it feels like it'd look better if they were consistent.

Edit buttons: those aren't really intended to be clicked on, but not having them function when you do click on them would be more confusing.

Yeah but surely then they should just have the same functionality as clicking on the object part of the button. The current behaviour is never going to be desired.

Clicking on wrench to wait: the problem is that it then runs away from you if you try to drag it. I could have it move only on button-up, but that's getting confusing. Instead, you can now wait a turn by clicking the right mouse button.

Oh really? I thought SDL separated polling for events from checking the current state of an input (like for dragging with the mouse). Anyway, that's not a big issue.

Tutorial level 4 is decent and definitely better to have than not. I think with tutorials, they don't need to go as difficult as the locks might be on the metagame and explore every subtlety, but also don't necessarily expect players to totally "get" the mechanics that they have supposedly utilised to solve a tutorial. Tutorial 4 wasn't especially hard to solve, yet I didn't totally know how it worked, even when I solved it (I didn't realise the main spring was under tension already).

I like the sound effects. I didn't expect them to be much use but they really do help.

[zugz]

Thanks.

ZED is me, of course... but e.g. I found JWG:B pretty tricky (even though it's basically just ice-sokoban). Maybe DOR:A could be the next stumper? ;)

I've added some extra hover text. Interesting how some things I assumed would be obvious clearly really aren't... hopefully this will help.

The random list now persists away from home, but gets shuffled only when you go home. Hopefully that isn't too confusing; I don't really want to add yet another command.

The L command is for choosing a lock by (file)name. I've stopped the N and O disappearing when there's no lock by the given name.

The buttons look like they do because I think it's neat. So there ;)

Clicking a button always has the same effect as pressing the key, and that's how it should be.

Notes are... whatever they have to be to make the game mechanics make sense. I decided against spinning any explicit story over the structure, so that's left to your imagination... but I had in mind something along the lines of this: when you solve a lock, you make obfuscated notes on your solution sufficient to make it clear to those who might challenge your honour as a lockpicker that you did indeed solve the lock yourself. If you manage to read three such notes, that's enough to piece the fragmentary accounts together into a full solution.

(I considered having reading one or two notes give the player some sort of explicit hint towards a solution to the lock, but I couldn't find a way to do that which was both useful and non-abusable)

[dormir]

The L command is for choosing a lock by (file)name. I've stopped the N and O disappearing when there's no lock by the given name.

Ah OK. But I'd never have guessed to type a (file)name in there. Perhaps change the "Select lock:" prompt to something more like "Type lock name:".

Clicking a button always has the same effect as pressing the key, and that's how it should be.

The principle sounds fine but the reality is just insane. Also, the principle is already violated since pressing the key places an object at the cursor AND that object becomes the selected one, whereas clicking the button only does the former. Also also, the useful hover text is on the letter buttons so they are more likely to get clicked to attempt to select that tool.</rant> Well I guess it's your game.

Notes are...

That sounds great actually. I think you just need to think carefully about wording to try to get that idea across as succinctly as possible. "Accessed by:", "Read:" and "Holds notes:" can probably be improved on. Also, the "Read" section should go next to "Accessed by" and if possible it should be emphasised that it's a subset. Perhaps even do away with the "Read" section and instead highlight the notes from "Accessed by" that have been read. The relative score colour-coding is more of a user-user thing so it would be OK/preferable to not use it for these sections. However you choose to address it, I think expressing the note idea clearly is really important.

I just realised that the spring graphics are pretty weird. It's hard to be sure whether they are stretched, compressed or at rest. It would be great if their state was more obvious. They often appear inconsistently tensioned across hexagons too.

I had a bit of a hang when the program couldn't access the thesmegz.net or whatever it is server. After I said y to declaring a solution, it was unresponsive for about 8 seconds, then when it came back and I chose a lock to stash my solution in it hung again for about 40 seconds. I don't know how much of a pain it would be to do, but it'd be nice if it handled that situation a bit better.

I WILL create a decent lock soon. I've solved everything except the ZED locks so I should be readyish now.

[zugz]

Thanks. I've tried to clarify some of these things in 0.3.7.1.

I'm keeping the 3 slots for notes, in the same line "solved" goes; it's a key hint towards discovering the notes mechanic. You're right that the icons should indicate if you've accessed the lock they're pointing to, though; the new build does that with colour.

The springs look "weird" because it's a tile-based game, so any compression or extension is drawn only on individual tiles. This does actually make it much easier to work out how compressed/extended the spring is, you just have to really look tile-by-tile. Any ideas on making it clearer?

The hang was because I tripped on the server's power cable (this game is bedroom-hosted as well as bedroom-coded), and lost my 50-odd days uptime! It's hard to have the client be very responsive while it's waiting for TCP timeouts, but if you can get it to switch to the "cache-only" mode during an outage, you can carry on playing without talking to the server.

Looking forward to the lock!

[dormir]

Phew. Making decent locks is really a nightmare. It took ages and so many times I couldn't get parts to interact in the way that I wanted. I realised during editing that I really don't get the orange and pink blocking arrows and if anything they misled me about what wasn't working. I must've spent at least 95% of the (very long) time making the lock just on getting the bits that the player can't directly interact with to interact with each other as I wanted. I went back to your lock A just to check that creation is the hardest part and I solved it much quicker than it took to make my lock despite yours being tougher.

Kind of too exhausted now to give any more feedback. I did take some screenshots though of mechanics/visual feedback that I found confusing so I'll post them later.

[zugz]

Nice lock! I figured it out, but it took a couple of sessions, and wasn't straightforward at all.

Designing locks is hard work, I know! This game is aimed at those perverse or masochistic enough to find it fun. A niche audience, for sure...

The interface is meant to make it as painless as possible, though, so any ideas for improvements on that would be great.

Accurately conveying the details of the physics is really tricky. I think it's going to have to mostly be discovered through experimentation. The arrows hopefully indicate where you should be looking to see what's getting blocked, at least. The purple arrows mean there's a conflict, two pieces trying to move into the same hex. Not very discoverable, but I'm not sure how to explain it in-game (it is explained in the README, for whatever that may be worth).

Setting a lock is necessarily much harder and more time-consuming than solving one. But each lock gets played many times, and this is a factor in the overall balance between solving and setting.

But there is a worry - if it turns out that the best players can easily solve the hardest locks of the best setters, that means the game is broken. I think it's fine though for there to be a disparity between the two skills at lower levels - for players at a certain level of skill and familiarity with the game to be able to relatively easily solve locks of similarly skilled and experienced players, as long as they still find those of higher-level players sufficiently difficult.

There are a couple of things that could be done to tweak the extent of the disparity. The simplest is to increase the size of the locks. It's much easier to fit a complicated lock in a bigger frame, and obviously this increases the upper limit of complexity. With the current UI design, the size can go as far as a radius of 11. The current radius is 8. That nearly doubles the available area (351 hexes versus 169). So if players end up exhausting the possibilities at the current size, they could graduate to playing at a larger size. Conversely, it might be worth having new players start on a server using smaller locks until they feel ready to handle size 8. But since there have so far never been more than 2 really active players on the server at a time, I don't think splintering is a good idea now!

The other possibility is to add new game elements. I have a couple of ideas for these which wouldn't complicate the UI much, but I'd prefer not to make the game mechanics any more complicated if it isn't necessary. The current ones do seem to support significant complexity.

[dormir]

The readme was pretty interesting. I forgot all about it after I first tried the game. Hard to assimilate it completely but it sheds some light on some of the behaviour I found confusing.

Have blocking (pink) arrows only by default with options also for all or none. Make those pink arrows bolder and extend into the tile where the conflict occurs. Or highlight the tile with a big pink cross or something. This was a very common source of misunderstanding for me so an important one to express visually I think.

Two of the screenshots I took turned out to be this mechanic on closer inspection:
http://nesthole.com/dump/Intricacy%20Mechanics%201.png
http://nesthole.com/dump/Intricacy%20Mechanics%203.png
In the second screen (03), all the pieces were static (nothing moved by pressing space). Also, there are two conflicts there. The one toward the lower right perhaps shouldn't actually be a conflict given that the larger piece is also conflicting toward the left and so wouldn't be able to move anyway.

Also reduce the number of arrows. Surely some (such as ones acting on a sprung block against the direction of its allowed movement) of them needn't be displayed.

Make pivot arms and the hook arm bigger and bolder. Maybe just a thicker line which is especially thick toward the extremity. This would make collisions between pivot arms more intuitive and hopefully the rotational force aspect too.

Do something to springs. I'm not sure what, and anyway I understand them now but it took long enough. In fact the one/two/three coils thing isn't explicitly stated anywhere is it?

Ok, these two screens are good:

http://nesthole.com/dump/Intricacy%20Mechanics%202.png
Here you can see that the ball above the hook won't move to its "preferred" location (SouthWest) because it considers the hook arm to be in the way. This is strange and I guess a consequence of the tools being considered first. I would have expected it to be a valid move since the hook arm is going to move out of the way simultaneously.

http://nesthole.com/dump/Intricacy%20Mechanics%204.png
In this one, the hook can make a clockwise rotation and the ball appears to move directly to the right. I believe what actually happens though is that the ball actually moves NorthEast (spinning the left pivot) and THEN gets moved SouthEast by the right pivot. This graphically appears as though it has just moved directly right.

So, this is maybe an untenable solution, but how about providing the ability to breakdown a turn and step through the phases of the algorhythm? I don't know if you could break it down further than the two main phases, but even that would be very helpful. Obviously not the default way to handle every turn but maybe available as an alternate redo? It might sound overkill to expose all that detail, but I found that being ignorant to it and trying to work it out as I went was much more painful. It would have helped me massively I think.

Re: The lock-creation lock-solving difficulty disparity:
I see the potential problem there but I wouldn't even think about that until you've made puzzle-creation as easy as possible (through visual feedback, etc) and then reassess that disparity. I found that I just couldn't predict object interaction or understand the mechanics well enough at all. This was a major problem in itself for me and is much more frustrating than being taxed by complexity.

Having said that, there's a lot I really like about this game. I also think there's potentially a pretty decent audience for it too.

[zugz]

Defaulting to blocking arrows only and collision markers will be in the next version. I did have collision markers in an old version, but found them ugly... but I suppose they are important.

I like the current look of pivot arms; I worry a triangle would look cartoonish. Is it the clawing mechanic you're worried isn't clear, or something more?

For springs: I'll try making the compressed/extended tiles brighter than the relaxed tiles. That works well in the ascii mode, and I think it should in the graphical mode.

You're right about what's going on in all the screenshots. Of course, it would be better if players don't have to read the README to figure it out! Regarding the second screenshot, and the conflict which looks like it shouldn't exist because one of the conflicting parties is blocked by another conflict - this is a necessary part of the physics design. There are rambling details in the design notes, but basically: if blockages can block other blockages from happening, then you either end up with circular paradoxes or you have to introduce something like a finite-speed flow of forces across the board, which can result in seriously complicated mechanics of the kind which lead to some witty player implementing a turing machine in the game. I've specifically avoided that kind of complexity (after seeing what happened in The Castle Doctrine), in favour of having the players' tools be the ultimate driving force behind any movement (up to finite).

I've thought about animating through the physics calculations. It might be doable, but if it's going to be fully accurate then I worry it'll be severely confusing for new players if they turn it on, even in simple cases where it's easy to understand intuitively what's going on, and give them the impression that the game mechanics are incomprehensibly baroque.

Just showing the intermediate state after the player moves and before springs take their turn is an interesting idea, though. It's true that this is a confusing aspect of the game (especially when it results in entities moving two squares in a single turn). Given the ability to undo and repeat the move, I guess it would be enough to show the intermediate state quite briefly, 100ms maybe; so then this could be the default behaviour.

Anything in the editor itself which could be improved?

As for an audience - we can dream! It did get a tince of media attention on first release, namely a mini-review in Linux Format, but this didn't translate into players at all. I guess even the linux geeks couldn't handle the keyboard-only interface...

[zugz]

New release 0.3.8.1 includes this two-frame "animation" each turn. Turned out to be remarkably easy to implement, even though I hadn't designed the architecture with it in mind at all. I do love Haskell!

I settled on just a 50ms between the tools moving and the springs getting their turn. I hope that, given undo, it's enough. Anything higher I found annoying. That 50 is configurable, but currently only by editing a textfile.

Hey, this technically means I've implemented both of linley's suggestions, sound and animation! Amazing.

Edit: I also decided to make the language a little less abstract and colourless. I think you, dormir, were right to imply that the dull neutral nondescriptness made it difficult to conceptualise the metagame.

"accessing a lock" becomes "being privy to a lock's secrets"; "players" become "fellow guild members"; "relative score" becomes "relative esteem"; notes are described as "obfuscated sketches of method, proving success but revealing little".