itch.io

Glad you liked the idea!

Yeah I'm not working on this game anymore. The new game I'm working on, 'The Big Forest' builds upon some of the same ideas of exploration, even though it's a very different game. https://runevision.com/multimedia/thebigforest/

Unfortunately I can't find the research paper I referred to (I read it many years ago) but if you search on Google Scholar for 'sokoban "state space"' there are a lot of papers covering the topic in various ways.

Glad you find it interesting!

I'm familiar with PuzzleScript, though I haven't tried to make something with it myself. If someone were to make a state space visualizer for PuzzleScript, I'd certainly find it interesting too!

But I'm not sure it's viable. Consider a very simple 5 x 5 room with a character and two pushable crates. There's 25 walkable tiles that the character and each crate can be on, so that's 25 * 25 * 25 = 15625 states. Divide by two (the factorial of 2) if the crates are interchangeable, but that's still over 7000 states for a really simple puzzle. Most PuzzleScript levels have more walkable tiles and more interactive elements. A 6 x 6 tiles room with a character and 3 crates would be 36 * 36 * 36 * 36 / 6 = 279936 states. It grows exponentially and most PuzzleScript levels probably have millions or billions of states, if not even more.

It's intractable to calculate such a large state space. There's a reason PuzzleGraph represent rooms as abstract nodes instead of supporting tile based levels.

Now, there was some researcher who found a way to reduce the state space for classic Sokoban, but the method was quite complex and also quite tailored to the specific rules of Sokoban. I'm not sure it generalizes to the extreme flexibility of PuzzleScript. In any case it would be a highly complex research problem to solve, if it's possible. If someone attempts it, good luck to them!

Hi, thanks for trying the game!

First of all, I'm sorry to hear you're not finding the exploration rewarding. I get where you're coming from, and an aim for my next game is certainly to have more varied things to find.

Then, a small provocation: If you can see in advance that a given path is just an offshoot leading to more psi, there's nothing forcing you to go there. You can just pursue other paths that you don't yet know where leads. :)

Finally, some thoughts: Many games have a clearly marked "main path" that leads to the current main goal. In such games exploration is optional and leads to optional rewards, or they don't reward exploration and you just find empty dead ends if you try to deviate from the marked path. That's the usual context when talking about whether a game rewards exploration or not.

But in The Cluster, there's no clearly marked paths leading to the main goals (the artefacts). There's various hints, but you still have to explore to find the artefacts. So finding those is the main "reward" of exploration, and simultaneously the main goals of the game. Of course, there have to be other paths that don't lead to the artefacts, or else there wouldn't be any exploration needed. Rather than leaving those empty, there's psi or enemy bases there so that they still serve a purpose. If you will, you can think of those as "consolidation prizes" for having followed a path that did not lead on to an artefact, instead of there just being nothing there.

Still, after creating the algorithm used in this game, I've since learned the importance of using loops rather than dead ends in level design. The Cluster does try to create loops here and there, but there's still a lot dead ends. I'd focus (even) more on loops in future games.

The “manual bump” was more than just an increment of the “date” of your project. I also tagged your game in a way that makes it eligible to appear on the homepage outside of direct recommendations/followers (The “fresh games” section).

I see, thanks for that clarification and for applying that tag.

I also appreciate that you are listening this far and trying to clarify things. With your latest reply I feel we are finally at least talking about the same things.

There are a lot of edge cases that could influence when a page was actually “published”. (For example, in response to your own suggestion: a developer could easily accidentally “publish” their page, then take it down, leave it up for some time as unindexed, then publish it again later and wonder why it’s not showing up in most recent)

Sure, with my suggestion such edge cases would still require a human review, so no worse than today.

But the more sensible case of first having a game not available (and thus not indexed) though it has a public page, and later make it available (so it's indexed) would work much better out of the box without any human review needed.

My point is that using the first time a game is indexed as its "initial time" is just the sensible baseline and has only advantages and no disadvantages compared to using an "initial time" that precedes the game being indexed at all. There is just no argument for using an "initial time" that is earlier than the first time of being indexed.

We want to encourage people to write a devlog when they change their page substantially (or even on project launch). (...) Just keep in mind that some stages may require a human review, so there may be a delay before the system processes your page.

Yes, the human reviews are slow and/or unreliable. Again, I did make a "major update" tagged devlog shortly after my game was available for download and indexed, but there was no effect from that in the three days between I posted it and you applied your bump, so either it was not picked up in human review, or it was still in queue after three days.

This is not a complaint over the human reviews not being more efficient - I know there are limited resources and a huge amount of games and so on. Rather, it just supports my argument that it's sensible to not rely on human reviews for things where the system could be improved in a way that would make some of those human reviews less critical. Anything that can work better in an automated way would both benefit developers and ease the load on human reviews.

There are many circumstances where can’t have “fully automatic” freshness bumps due to abuse.

Giving a game a "bump" at the time it's indexed for the first time is not a "freshness bump" because it's never been on the index at all prior to this point. It's not like it will result in a game being at the top of the Most Recent list once, and then again when it's indexed, because prior to indexing it's not on that list at all. So my suggestion would only result in the game starting at the top of Most Recent once instead of never.

Your page previously wasn’t in any queue to be reviewed since it was marked by you as unavailable up until when you changed its status

Yes and it was also not indexed before for the same reason. Naturally the first time it's available and thus indexed, it should start at the top of Most Recent, not because of manual review or "freshness bump", but simply because it's the most recent entry to be on the Most Recent page (and in the index in general).

If a game is available from the beginning when it's published (and the dev is in good standing due to prior games) then the game automatically starts at the top of the Most Recent page without any review needed, from my understanding. This is because the time of indexing and the time of page creation happens to be the same. Time of page creation works as the "initial time" used for sorting, without any "freshness bumps" having been applied. All I'm saying is that this "initial time" should not be the time of page creation (where the game may not be indexed at all anyway), but rather the time of being included in the index for the first time.

Generally speaking, I do not advise developers to depend on the “Most recent” page for discoverability, as there are many games coming through those pages daily.

Completely off topic argument. I did do external promotion. But the Most Recent and similar lists on Itch exist, and they do have an effect, so there's reason to want them to work in a sensible way rather than in a way that penalizes games that had a page available long before the game itself was indexed. For reference, here's a comparison between my external promotion vs the effect of getting on those Itch lists when you applied the manual bump.

Many developers simply don't have anything at their own disposal that's as powerful as the eyeballs that those lists on Itch  provides. So whether you're comfortable with it or not, the exact logic of how those lists work does have a big effect on which games gets seen or not.

Again, I'm not arguing for any "additional exposure", I'm simply arguing for a different time to be the "initial one" that's used without considering any "freshness bumps". And I'm saying that this initial time should obviously be the time a game is included in the Itch index, rather than a point in time that may be long before that.

Hope that helps explain a few things

Unfortunately not, as it seemed to misunderstand my point and did not present any argument for why using time of indexing as the initial time is not superior to using time of page creation as the initial time.

This developer seems to have hidden the download button via custom css so that the page is still indexed on Itch even though you can't get it. This seems like an exploit - developers are supposed to disable downloads if they do not want people to download the game.

However, note that you can still install the game via the Itch app.

You try to equate "most recent" on Itch with "sort by release date" on Steam. But there is no such thing as an official release date on Itch you could sort by.

You keep saying that, and I keep saying that it would make perfect sense to sort by time of indexing. This time is when a game is "released" for the public for the purposes of discoverability on Itch, since it's not discoverable before this time, and is discoverable after this time. If it's sorted by time of indexing, each game would start its time on the Most Recent page at the top (for however short a time), just as one would expect.

The default list has every release status in it.

But I'm not talking about release status. I'm talking about indexed vs not indexed, and the Most Recent list only has indexed games in it, while it does not have non-indexed games in it.

Discussing about the expectation from a list called "Most Recent" is interesting, but the term is ambigous. Whom is it most recent to? From developer's perspective, or Itch's, or the user's?

From the perspective of the Most Recent list itself, with Most Recent meaning the most recent game to be included on the list. There is nothing ambiguous about that.

Creating a major update devlog and publishing it can make your page eligible for a freshness bump that can place it on the top of the most recent page.

Right, I did that 3 days ago shortly after creating this thread, based on suggestions by others, but it had no effect. It's something worth trying I'm sure, but not something that necessarily works.

Just to make sure you’re getting some visibility I’ve given your page the bump since it looks like an interesting project.

Thanks a lot, I appreciate it.

Still, I'd hope the underlying issue would get fixed for everyone's sake instead of relying on unreliable measures like major release devlogs which may not work, or complaining on this forum to get attention.

The fact is, a game is by all intents and purposes only public (discoverable) once it's indexed. Prior to that it's not searchable and not in the various "Recent" lists. It stands to reason that those lists should use the time of indexing for sorting, rather than the time of page creation. Or to put it in terms of existing functionality, the moment a page is indexed it should get a recency "bump" fully automatic, so that once it gets on the "Most Recent" list for the first time, it should start at the top of that list, rather than way down the page (if the game's page was published long ago, but the game was not indexed back then).

Do you not see the logic in this? That the criteria for inclusion on the Most Recent page and the criteria for sorting on the Most Recent page should match up rather than the sorting being based on a date (page creation) that could be months prior to the game entering the Most Recent page at all (due to being indexed)?

If you believe the current logic makes more sense, I'd really love to see an argument for why that is. It's completely contrary to how most "most recent" lists work, and does not match common sense at all. Plus, most importantly, it lets devs shoot themselves in the foot completely unnecessarily just because they publish a game page before the game is actually available. This is standard practice outside of Itch (generally recommended promotion tactic, and required on Steam). But on Itch doing this same thing will mean your game will not ever be at the top of the Most Recent lists, except if you're lucky that publishing a major update actually works (and know about that trick in the first place).

Glad you liked it, and got a feeling the design was built with purpose! The new game I'm working on - working title The Big Forest - is a different genre (not platformer) but will build upon the same kind of procedural algorithms while having more varied environments and gameplay, or at least that's the plan. :)

Those tips are helpful, but also kind of off-topic for the subject discussed here. They don't change the fact that:

It makes no sense for a "Most Recent" list where entries can jump from not yet being on the list at all to being way down the list, without ever having been at the top. For a "most recent" list, the top entry should be the one that most recently appeared in the list. Anything else doesn't make sense and only points to a mis-match in the metrics used for inclusion and for sorting.

Why do you publish a page "in development" but disable it?

For multiple reasons. One of them is to do closed playtesting, and still have a page where people potentially interested in playtesting can read about the page. See Itch's own documentation on using the restriction options to do closed playtesting. The option to disable downloads is there for a reason:
https://itch.io/docs/creators/limited-releases#the-toolset/closed-playtesting

Another is to just have a page where people can learn about the upcoming game. In an ideal world, people could add the game to their wishlists from here, but Itch doesn't have wishlists, only confusing multi-purpose "collections". but I digress, it's still nice to have a page where the game can be properly described in detail, that I can point people to who want to learn about it.

So, Itch has built-in options to have a public page before the game itself is publicly available. The logic for how the Most Recent list works should naturally make sense also for this scenario.

And saying that the "most recent" (and other lists that use recency as a partial metric) don't matter anyway is unhelpful. The pages are there, so clearly they have a function, and that function should work in a sensible way.

You will be "on top" of most recent for like 5 minutes. If that is the only marketing and promotion you do and is the only source of any views, your project has bigger problems.

Who said anything about that? There can be plenty of other promotion outside of Itch, but that's not what this thread is about. It's about how the Recent page works and how visibility boosts in Itch do or don't work, so that's what we're discussing here.

Do a major update development blog when you "release" after development. This can get you on most recent again. No guarantee. It is said to be staff approved if a devlog gets you on recent again.

Good to know.

It's much worse. If the page is created long before the game is indexed (for example if downloads are disabled prior to release, which prevents indexing), the game will never get any boost at all.

The reason is that the game will only appear on the Most Recent page once it's indexed (i.e. available for download etc.) but the Most Recent page is not sorted by index time, it's sorted by page creation time. So if e.g. you release the game one month after creating the page for it, then once the game is released, the game will appear on the Most Recent page for the first time, but way down on the page together with games released (or having their page created) one month ago.

See my post here for more info:
https://itch.io/t/4011432/games-released-well-after-page-creation-never-get-on-m...

I just released my game The Cluster yesterday, meaning:

• I removed the "Disable new downloads & purchases" checkmark.
• I changed the release status from "In development" to "Released".

For a while the game did not show up when I searched for its name, but today it just got indexed and does show up when searching.

However, on the "Most Recent" page it doesn't show up at the top, nor together with games released one day ago. Instead it's way down with games released 39 days ago. That was the day I made the game's page public, but people couldn't download it back then and the game's status was "in development".

So, do I understand right, that if a game has its page made public way before the game is actually released, the game will never be at the top of the "Most Recent" page (and forgo its chance with the "New & Popular" page too). Instead, once it's indexed, the game will pop into existence way down on the "Most Recent" page and never at any point be anywhere near the top?

This logic seems completely broken. Especially since Steam has conditioned developers to ensure their page is public and visible well before the release of their game (in fact this is a requirement). If you do the same on Itch, it will torpedo your chances of getting on the front page listings.

What is the reasoning behind this logic? It must be a bug?

The only reasonable way for things to work is that "Most Recent" (and any other listings using recency as input) would use the time of indexing for determining how "recent" something is. That's the only way all games would get their moment at the top of the lists. Basing "Most Recent" on a time at which the game was not indexed at all just makes no sense.

I got this game 7 years ago and just got around to playing it now. I enjoyed the spatial thinking puzzles a lot and getting to be inside the M. C. Escher like spaces I was fascinated with as a kid! Also nice to see there keeps coming new comments in from people playing the game this many years after release.

No, it just goes on forever.

Ok, I assume by 10p you mean 1080p. The application is supposed to run as a window that you can resize and can make fill your entire screen if you want, at native resolution. Is this not the case for you?

Sorry, I don't understand the comment.

Glad you like it!

Hi, merry Xmas!

I'm really happy you find PuzzleGraph useful to use for your teaching.

PuzzleGraph is open source, and you're welcome to make a clone of the repository and add features there. I'd follow that with interest! If I end up liking them, I can roll them into the original distribution, and either way you can distribute your version yourself. The source code repository is here (in Mercurial format):
https://hg.sr.ht/~runevision/puzzlegraph

Cheers!

Certainly! You can select a node or an edge by clicking on it, and then pressing Delete or Backspace on the keyboard to delete it.

Hi, PuzzleGraph is made with Unity.

Oh good, glad to hear it!

You still can't run it? Did you follow the steps in the link I posted? What issue are you hitting now?

I know this reply comes a bit late, but there's now a new version which is 64 bit and supports Catalina and Big Sur.

I uploaded a new build which should support Catalina and Big Sur and which also implements retina support.

Yes, macOS does that for all software that doesn't have certificates. Read here how to open it anyway:
https://support.apple.com/guide/mac-help/open-a-mac-app-from-an-unidentified-dev...  

By the way, I just uploaded a new version which has retina support and this should look better, so try to redownload before you try to open again.

Right, thanks for the reminder. Since Bitbucket stopped Mercurial support, the source is now available here:

https://hg.sr.ht/~runevision/puzzlegraph

Hi and welcome back! Yeah, it's most certainly still being made.
You can keep up to date in the Discord server for the game here:

https://discord.gg/yGN7bDQ

Hi. Glad you like the tool!

Thanks for the suggestion, but I'm not actively developing the tool further (though it's open source if anyone want to give it a go themselves).

Since you're sharing your puzzle: You can choose Menu > Open Puzzle Folder and see the text files for your puzzles. If you post the text content somewhere, other people will be able to save it as text files and open it locally in their own PuzzleGraph application. :)

Good find! To be honest I haven't tested a lot with multiple player characters so am not too surprised. You say you discovered this by looking through the code. What specifically tipped you off?

New build available April 21. (Read here how to sign up to get access.) Same download link you already got works for new build.

The new builds features pots at various places throughout the temple. Tap them lightly to tease out a few gems at a time, or break them to release them all at once. Not all pots are within reach, so you'll need to use the whip either way.

Instructions:

• Play area of 2 by 2 meters needed.
• Two controllers are needed (for torch and a whip).

Feedback

Reply to share your thoughts. All feedback welcome!

Hi. I'm not looking for more testers right now, but leave a message in the thread https://itch.io/t/59040/early-testers-welcome-thread-introduce-yourself then you'll be next in line when I'm looking for more.

Eye of the Temple recently got a Steam page. It also now has a Discord server (text chat channels).

I'm transitioning the pre-release testers/community communications from itch (with itch keys) to Discord (with Steam keys).

The reasons are:

• Only few people have stayed active in the forum here.
• Adding new people to the pool of testers is annoyingly difficult on itch.
• Discord has a very positive reputation among other game developers and is highly customizable in how it can be setup.
• Discord has something as basic as private messages (lacking here on itch).
• Steam automatically fetches new builds, which means it's easier for people to try out new builds. Itch only does that if people use the itch client, which few do.

I don't want any existing testers here feeling left behind, so if you are part of the testing program, just do this to get a testing-access Steam key:

• Find your itch download key link for Eye of the Temple.
  • You can get it by logging into itch, and go to the game's page and click the Download button near the top. The URL of the page you land on is your download key link.
• Join the Discord.
• Send me a private message on Discord with your itch download key link, so I know you were one of the testers.
• I'll send you a testing-access Steam key in return.

I hope to see you on the other side!

I can see how that could be useful sometimes. I'll see what I can do!

Thanks for the suggestion! I agree it feels a bit tame when it just clips through. I'm not sure I have the resources to do much about it but I'll keep it in mind!

Thanks for trying it out!

I think the whip could be improved slightly, with maybe using the trigger to do a ‘whip back’ which could be used to grab levers better, and also a whip back at the right time to hit enemies harder.

Hmm. It's kind of a design decision to keep the whip "pure" in that it doesn't move "on its own" based on buttons/controls but 100% based on hand movement only. It's part of the dedication to immersion in the game. As a result, it's probably the element in the game with most skill involved too, for better or worse. You can usually grab levers in the first try with the right technique, but it can require some practice to get to that point. I appreciate the input but I think I'll keep this one as it is. :)

I find myself looking at my feet a lot, so maybe use things up higher to force your eyesight upward.

Yes, indeed, I agree! There's a few things already, but I'm always considering more ways to create variation in where to look. The obstacles that come down from the ceiling is one thing to look out for. Gems that are sometimes above your head is another, but currently it's easy to just miss those, so I need to figure out a way to draw attention to them.

but you could almost do with a system that lets you manipulate the centre of your play area and downsize your overall area etc. Or rotate it maybe, something to cater for the variations in play space.  Big ask and probably not possible I know.

Haha, nice! :) Did you get an impression of which tracks fits particularly well with which areas of the game? I can't use the Indiana Jones soundtrack itself, but it would be interesting to know in terms of developing the soundtrack for the parts of the game that doesn't have it yet.

Thanks for the update!

> I did finish it and got throught that new puzzle area pretty easily. It was a cool addition but didnt make me scratch my head at all.

That's fair! It isn't meant to be hard, but as designer it's always hard to predict in advance how it appears to other people. :)

> I really think you need to add more music to your game.

Yes, agreed! There is more music planned, but I'm waiting a bit with this until the level design overhaul is further along, so the musician and I have a better idea of what environments to create music for. Glad you like the existing music. :)

> I started on the speed run but didnt get very far. I think there sould be a timer or something to incicate your speed while playing that.

Thanks a lot for trying the speedrun! I can see I have some work making it clearer how it works. There should be a timer on the handle of the torch, but it may be a bit hard to see. I can work on making it clearer.

> Is the speed run any different than the regular game? I think the blocks were moving faster but Im not sure.

Ah. The speed increases if you are timing your steps well. This means that you step down on a new platform in the same moment as it lines up, which requires that you started taking the step a bit in advance. I wrote more details in the post about the speedrun mode here.

If you keep timing your steps well you can build up insanely crazy speed, but it's definitely not clear how to use the speedrun mode without that explanation. That's something I'll work on for sure.