Slowdown fixed! Cheers. And thanks in general for supporting older computers.

Okay, just updated the repository with the latest version.

zugz - this should fix those issues.

Sadly it hasn't fixed the slowdown. It did fix the map scrolling while
skipping.

Re queuing: I see your point, but it still seems unintuitive and annoying that
you have to drag things around manually just to get a builder to build
immediately. How about an easy way to put an order at the front of the queue?
I think that would be a more useful meaning of ctrl-click than the current
one.

Great. One little problem though - when an editor tab is open, moving the
mouse to the very top-right corner leads to the main map scrolling.

I've added a check for this which will hopefully fix the problem.

It did!

But the big commit on Wednesday (2348adf1), though it included some nice
things, seems to have broken things a bit for me. The game now runs really
slowly. The game rate seems to be scaling with fps, which it seemed not to be
before. I get about 12-15fps when not much is going on, which translates to a
painfully slow gamerate. If I turn off the background (thanks for that
option!) I get 30 fps and a decent gamerate.

Couple of other things I forgot to mention before (not affected by this
update):

When any of the 'skip' options are in effect, the game runs faster as you'd
expect, but scrolling the map is paradoxically much slower then normal.

I wonder if it would make sense to make the build queue a bit cleverer.
Currently it waits for the builder of the job at the front of the queue to
finish recycling, even if it would be possible to start a job further down in
the queue immediately. It took me a while even to realise that recycling was
per-builder rather than global, and realising it made my operations much more
efficient - but more fiddly.

- closing all panels (or closing the last open panel) now blocks mouse
  scrolling until the mouse moves away, as zugz suggested.

Great. One little problem though - when an editor tab is open, moving the
mouse to the very top-right corner leads to the main map scrolling.

- there's a new "reload" function in the "File" editor menu. It reloads the current file from disk.

Good stuff. How about a keyboard shortcut for it (^R?)?

Thanks, the update helped. The editor now processes my keystrokes fine.
I like the new position of the buttons on the main map screen, but there's
still a slight problem in the other direction: hitting the 'X' to get *back*
to the main screen leaves the mouse in position to scroll. This is quite
annoying and disorienting. I'm not sure what should be done about it - perhaps
just a special case for this situation that the pointer is in the scroll
border when the map is shown, making the map scroll only once the pointer
leaves the border then re-enters it.

The component box placement is fine, and thanks to the alpha blending doesn't
seriously get in the way. I think it would be worth allowing it to be closed
without closing the process box too, though.

As a datapoint: I had no problem differentiating foreground from background.

Another little thing to add to the wishlist: a way to quit a game which doesn't exit the whole program.

Cool, I look forward to the next update.

I can definitely imagine the autonomous mode getting some interest... maybe
(eventually) you could set up an automatic weekly tournament, where players
mail in the latest version of their template, they play each other, and the
results are announced. Could be fun!

A few more niggles and suggestions:

The in-game text editor regularly drops characters when I type, I guess
because I type faster than 1 key per frame. I don't know if allegro has an
event buffer like SDL does, but if so that would be more appropriate than just
checking for what key is being held down.

I guess this is again because I'm using a lower resolution than you test with,
but for me the minimap hides most of the component information dialogue. Maybe
the minimap could float over leftwards when it needs to?

I wonder whether it would make sense to support some C preprocessor statements
- maybe just #include, #define, and #ifdef. Of course players can run cpp
themselves to generate source files to be read by the game, but it'd be easier
if it was directly supported. This would make it much easier to develop and
maintain interdependent processes - which if you want autonomous mode to be a
big part of the game, seems important.

It could even makes sense to have a single editable master autocode file, with
the autocode function on the design screen just setting some #defines
according to the objects on the process and the chosen AI behaviour, made use
of by #ifdefs in the autocode file. That way autocode would stay useful even
when you find you want to customise the details.

One last thing: I experimented with messages, and found that check_messages()
seems to always returns a positive number even when no message had been
received, contrary to the docs.

Thanks for the update. The changes all helped, including eliminating the
slowdown.

I think there needs to be a way of manually hiding the buttons when all panels
are closed, so that they don't interfere with scrolling. I'm thinking of
adding a new button which does this.

Actually what I think might be nicest is to have a simple toggle between
having just the main game screen visible and having other tabs open too. Then
you can place the toggle somewhere away from the scroll border, and it means
that the choice of which tabs to have open can be saved - so with one
click/keypress you can bring back whatever tabs you had open when you were
last working on something.

The function key idea is a good one, too. I haven't generally put as much
thought into keyboard shortcuts as I should have.

More would be better! I'd also like keyboard commands in the editor for
compiling and for loading and saving.

The move methods should deal with most configurations. But if there are only
two thrusters, pointing in opposite directions, it may be that there's no
simple way to use them to travel as they both probably produce too much spin.

Yeah, it seems auto_move prioritising turning to face the target over
accelerating towards it. That makes sense for many configurations, but not for
all. But maybe it's fine to let the player do the coding if they want
unconventional movement.

It would be good to have a way to open files in an external editor, but I
think I would need someone else to code that as I don't have any way of
testing those kinds of *nix things on Windows.

Actually, more important than opening an external editor is getting easy
access to what it saves. A "reload" command which doesn't make you locate the
source file every time would be great. So would be the ability to load files
for locked templates when the header hasn't changed.

You can resize the panels! (except the template panel)

So you can. That does help! It's still a little painful to have to resize
every time I bring up a new tab - would be nice to have it remember the width
you've set for the nth panel.

The manual has details of all of the functions

Aha, I entirely missed the existence of the manual! It does the job well.

The current zoom levels are my attempt at a compromise.

I experimented with allowing view.zoom_level=1, but at least on my machine it
isn't actually usable - I get 2-4fps. So probably it's best to keep it as it
is.

I played around a bit more, and have a few more comments.

I tried to remap the control groups (I use a dvorak keyboard, for which the
defaults are horrible), but couldn't get it to work.

I'm finding it quite annoying that the map scrolls when I try to select the
buttons in the top-right for the tabs. I'm not sure what to do about it
though... maybe move the buttons to just above the minimap when the main view
is in focus, and hope it isn't too confusing that they pop up to the top-right
once selected? Assigning keys to them (e.g. F6-F10) could also help.

I believe %d is rather more common that %i as a printf escape for an integer.

I found that auto_move() doesn't handle unusual configurations of thrusters -
I tried having two pointing in opposite directions, and auto_move() just fired
them both at once, leading to plenty of spin but no travel...

I found the in-game text editor pretty painful to use, without features like
autoindent and keyboard-only navigation beyond arrow keys. But I don't suggest
you reimplement a proper programmer's editor, and I can see it does make sense
to have some kind of editor in there, if only to teach the player that there
is code for them to play with. So the only thing I'd suggest is a quick way to
fire up an external editor on a process source file (using $EDITOR on *nix).

Anyway, I'm generally pretty impressed with the project. It's a really unique
game, solidly implemented. Good luck with the final polishing!

Very nice!

To get it to compile on gentoo linux, I had to manually link with -lm and
-lallegro_foo for various values of foo.

On a 1024x768 sreen, the help text in the design tab flows off the screen, and
in-game text editor shows too few columns to be usable. I'd suggest having the
rightmost tab take up more of the width of the screen than it does.

If I select 'custom game' from the main menu, everything slows to a 0.2fps
crawl until I quit the game.

It would be very nice to be able to rebind keys by name rather than keycode,
at least for alphanumerics.

As for the game itself: I've played only the first three levels and fiddled
about a bit with the designer. It all seems pretty smooth. The design
interface was slightly confusing at first, particularly with the role of
uplinks and downlinks, but became clear after a little experimentation.

I haven't really experimented with the coding aspect. It looks feasible and
plausibly fun, but pretty daunting! I don't see any documentation of the 'auto
classes' or the basic functions like scan_for_threat() - is the idea that you
figure these out from the few samples provided, or are you meant to sourcedive
into the actual game source?

In principle, designing and on-the-fly adapting an RTS AI does sound like a
lot of fun (though probably a pretty niche kind of fun!).

One thing - since you already seem to have set up the graphics structure to
allow arbitrary zoom, it would be very nice to be able to zoom out arbitrarily
far in the main game screen. I think it would make for a more intuitively
fluid way of navigating the map than using the minimap.

Intricacy is a game of competitive puzzle design, partially riffing off Rohrer's The Castle Doctrine but quite distinct.

The game has you picking locks by co-ordinating a pair of tools to manipulate its mechanism, in a turn-based hex-grid puzzle game with full undo, which looks a bit like this:
.

The twist is that the locks you pick are designed by other players, and you have to design your own - once you have solved another player's lock, for the solution to count towards your score against that player, you must secure your solution behind a lock of your own, and the other player must not solve your lock.

So the game is about trying to design maximally difficult puzzles within tight size constraints, and solving the puzzles others have set.

It's free software. Source and binaries for Linux, Windows, and OS X are available from the game's website:
    http://sdf.org/~mbays/intricacy/ .

I posted about the game on the Playtesting forum a while ago, and got some very useful feedback; now the game is in a state I'm tempted to call Finished, so I thought I'd see if I could attract the odd player. Hence this post.

Well solved. I do have another even harder one prepared, but I don't want to retire any of my current locks yet.

It would indeed be good to get some feedback from new players. I don't know if there are any potential testers left on this forum, but if any are reading it would be great to hear their thoughts. (But note that the server will be down from now until Sunday (hopefully the last outage for a while).)

I briefly lost control of the domain name a month ago, but the server should have been working near-continuously for the last few weeks.

Passwords are stored (securely hashed) in metagame.conf in the config directory (~/.intricacy on unix, or something like ...\Application Data\intricacy\ on windows). I don't know why it would have got lost.

There's no way I can find out your passwords, but I can reset them. I'll pm you both about it.

In other news, thanks to the work of one Kevin Eaves, the game now runs on OS X. There's a binary on the website (http://mbays.freeshell.org/intricacy)

New version 0.5.1 up at
 

http://mbays.freeshell.org/intricacy/
; main change is that I've implemented the new scoring system.

The new scoring system should make it clearer why you'd be tempted to replace
a lock once it's been solved by people - you won't get points for their locks
if you put the notes behind your compromised lock.

It's important to have a tight limit on the number of lock slots, so locks do
get retired eventually. It could be increased from three, but I hope it won't
have to be. If you itch to create more locks (which is great to hear!), you
can always start working on eventual replacements for your current ones, or
you could play on the big-lock server (see the forum).

We can't have anything which involves rewarding the player just for having
lots of notes, by the way, because they could just create an alt and get the
reward for solving their alt's locks. This game is meant to be cheat-proof.

I'll be very impressed if anyone solves ZED:C! It should be very hard indeed.
I think ZGZ:A is pretty trick too, btw. But then, I don't see how either of
NOI:C or DOR:C can be possible, which apparently they are...

Edit: ok DOR, you met my challenge and solved both ZED:C and ZGZ:A, and I am
duly very impressed!

I think it's important to have multiple locks all on the same footing. If you have only one largest lock slot, say, then you're going to be tempted to replace it as soon as even a few people have solved it. If instead you can just ignore it and start storing new notes behind a different lock, then the old lock is going to last in the game, providing challenge and reward to other players, for longer.

I know what you mean about having to remember which of your locks is which. You can always cancel though when it asks which lock to use, then go home and declare the note manually.

I think it's inevitable that new players will be happier solving than creating locks, and so they're going to put their notes behind useless dummy locks. I think that's fine though - it just means that you have to make sure your locks can't be solved by new players! And forcing them to at least make that dummy lock means they see how they're meant to play, even if they ignore it at first.

Meanwhile, I'm currently stuck on NOI:B, NOI:C, and DOR:B/C! So maybe these locks are big enough, yes...

RSS feed here btw: http://intricacy.thegonz.net/mainServerFeed/rss

Oops! Thanks, I should have fixed the forum now.

I've replied to your attempted reply there.

Re multiple lock sizes: I think players would end up basically ignoring all slots except the largest, at least when considering where to store their notes, since it's going to be the hardest. I think having one max lock size per server is best.

Hi DOR, NOI; great to have you both playing! I've been enjoying (the various versions of) NOI:B and NOI:C, which I indeed found much harder than my undo-pruned solutions indicate!

The crashes are worrying. I don't know what could be causing it. Please tell me, DOR, if you find a consistent way to crash the game.

The config file is called "SDLUI.conf", and it should be whereever windows stores user config files, which I think is somewhere like "...\Application Data\intricacy\".

Meanwhile, any thoughts on this proposal:
http://intricacy.thegonz.net/forum/viewtopic.php?pid=3
?

I was also wondering if I should try allowing slightly bigger locks on the server, to make it easier to construct more difficult locks. I feel the balance may be too far towards the solvers currently. But really more data is needed!

Hmm... having in-game notification of changes could be interesting, yes.
Perhaps you could "set your spies" on players of your choosing, and then get
reports on activity involving those players since your last visit. So e.g. if
there's a player whose lock you really can't solve, you can spy on that player
to see when new notes appear on the lock for you to collect. All this would be
controlled from a single new screen, rather than further cluttering the main
interface.

I'll think about it. But I'm more worried for now about getting players for us
to spy on!

I think failure stays silent for now, sorry, if only to keep things simple. You can always post on the oh-so-active forum (http://intricacy.thegonz.net/forum) about the locks which are frustrating you.

Announcing real activity makes sense, though. How about an RSS feed?

Hi NOI. You're right that it would be nice to know when people are trying your locks, and even nicer to see their failed attempts. That was one of the coolest things about The Castle Doctrine. But the problem is that the people trying your lock have no reason to give you that information, and indeed would rationally prefer not to lest it cause you to stop securing valuable notes behind that lock. So since the client is meant to be on the side of the player, the client doesn't even tell the server about failed attempts on locks (nor even undeclared successful attempts).

So I'm afraid the only solution to the lack of interesting things happening is to get more players! Somehow.