I found this recipe pretty intuitive, since the symmetry made it obvious. I was a bit surprised that the "odd item out" in the Annihilator recipe itself went on top instead of the base, but for the advanced one, there were only 2 reasonable options to test.
The storage box recipe was much less intuitive, using a much more odd line of symmetry and it took me a couple minutes of shuffling things around.
It sounds like you're confused. Are you sure you posted this for the correct mod?
It's definitely for cooperative building, not for PvP. In fact, the game doesn't even really have much PvP potential to begin with.
I don't know what this talk of "chests" or "locked chests" is; those are things from another game that this mod isn't compatible with.
The idea of players voluntarily putting away their items before disconnecting is already fully supported by the mod, and if players do this, then there will be no items to float in the air, so the entire point is irrelevant. However, that process doesn't cover cases where a player's internet connection goes out beyond their control.
Also, I'm not sure why you would bother to review a deprecated mod. The review is wasted as deprecated mods are already pushed way down in the listings, if not hidden altogether.
If chaining green tiles were all that you needed to make wires, it would trivialize what you actually need to do to make wires and transistors and the like.
Okay, I mostly wanted to make sure it wasn't something I did wrong or something obvious I missed.
I tried getting the upgrades and it made little difference. I even tried cheating and it barely made a difference, and by the time I had enough cheats enabled to actually let me get through the first level and past the first significant obstacle on the second one, I realized I was just going to spoil the whole game without actually "playing" it, so I'd rather wait for the post-jam version.
Even if it's technically winnable, the balance issue is still completely game-breaking for me; it's basically a frantic "bullet hell" game now, which means I can't enjoy the maps (which I noticed you put a lot of care into) and I can't even focus on trying to solve puzzles or anything, so it would only be winnable if I already knew where I was going and what I was doing.
It looks like the two commits that fix this bug were already in your main branch, mixed in with other contributed post-jam changes, and just need to be cherry-picked into a separate branch to be released. This seems to be the minimum set of changes necessary to fix the crash without altering the gameplay as designed.
I noticed that you don't have an Issue Tracker link in the links at the top of the CDB listing, nor are there any other kind of "contact me" instructions in the description. But you do have a GitHub repo linked, and that repo has an issue tracker open (but so far unused).
What's your preferred method of hearing about issues, suggestions, receiving code contributions, etc? Is it best to use that issue tracker? Or do you prefer CDB threads? Or something else?
There is so much to these maps to explore, but in areas where enemies spawn, they end up spawning at such an insane rate that it's impossible for me to keep them down to a survivable level. With the flying dudes it quickly becomes bullet hell. Is this some kind of bug, like the enemies are too aggressive or spawn too fast, or are you just supposed to need to be really hardcore to play this?
What if, instead of a mad scientist as the villain of a game, you had one as the developer?
Looking at the scope and design goals of this project, it feels like it really should have the "Joke / April Fools" tag. Looking at the actual execution, it becomes obvious that it really should not.
The Boom game, in particular, seems to be a complete software-rendered 3D game implemented in typescript, transpiled into Lua, and rendering to [png: texture modifiers; the fact that it actually runs at all on my laptop from 2012 is amazing. Bit's Battle demonstrates that it's not just pure tech demos that run in this environment, but games with actual gameplay and progression, albeit only a rudimentary amount as implemented so far.
To enjoy this "game" to the fullest, it helps for a player to understand the spectrum of games that have been created in Minetest, and understand how much this is abusing the game engine to make it possible. It feels like something in the same spirit as arbitrary code execution in NES games. Rather than being "immersed" in the experience, it sort of demands that you remember that this is all running inside Minetest. There's not a ton of depth and it won't keep you occupied for hours (especially if it crashes MT in a few minutes; I don't know where the "B" in "BOOM" comes from, but I know where the "OOM" does) but it's a spectacle worth witnessing.
This is a very balanced and well-executed game. It has a well-written story, variety of gameplay elements and areas, fits the theme, and seems to suffer from no major bugs or breakages.
The main annoyance I ran into, that made it hard to complete the game without resorting to cheating, is how unforgiving the parkour sections are, especially considering the level of movement jank in Minetest. It was hard to get my momentum correct client-side but lock in server-side, even with the short network path for singleplayer. Something like allowing you to set restart checkpoints by standing perfectly still for a few seconds would have been more fair, without sacrificing the challenge for people who want to speed through.
The projectile combat also felt a little sluggish, though this may just have been my bias coming from other games with faster-moving projectiles; given the movement speed of the enemies, it didn't feel unfair or anything. I didn't have enough health supplies for the boss fight, but apparently the only consequence for dying is injury to my pride, so you can still make it through even if you didn't plan well enough.
I didn't find the plot twist all that surprising, but the evolving gameplay supplied enough intrigue to keep me interested through it, and the story was at least not a distraction, and gave the gameplay a sense of structure and meaning.
Players should expect to need some patience for the parkour elements (especially with MT's imprecision) but the momentum-locking mechanic makes those still worth experiencing, and the game overall is enjoyable in a single sitting, and for replay value you can speed-run it.
I've been toying with the idea of a "video game without the video" for a while now, and it's great to see somebody actually attempt it. I love the ambition of the concept. It might just be a bit much to try to make it work as a sandbox game during a game jam timeframe.
Unfortunately, while a human has potentially dozens of senses (sight, sound, touch, smell, taste, balance, body position, temperature, passage of time, etc) on a computer you mostly just get sight and sound, and losing sight is harder to compensate. Without a sense of balance or body position, it's hard to tell when I'm looking at the horizon, or when I just fell down a hole, or about how far. Without touch, I can't tell if the crunchy-sounding stuff I'm touching is sand, gravel, or dirt. The use of "synesthesia particles" is a pretty good way to translate at least some of the missing senses into the unused visual medium, but it really needs to expand to cover more senses. In particular, when I'm working without a sense of sight (reaching deep into a machine to find a broken part) I rely on touch, not just to sense obstacles, but feeling textures, shapes, temperatures. More missing senses need to be recreated in some way to know what it means when I poke something and it sounds like a drum.
I'm not sure I can recommend this to a player yet. It was a bit intriguing wandering around and getting lost in a cave but now I think I'm stuck. It definitely feels like a project whose development I want to get involved in, suggesting, experimenting with, or contributing some ways to recreate the missing senses ... but for those not developerly inclined, it's one I'd watch for future updates rather than expecting much right now. I'm definitely looking forward to when it reaches the tipping point where I can change my neutral review to a positive one.
Also, the "no sense of sight" game being one of the few to actually feature a gameplay video was entertaining.
A mix of maze exploration, gentle parkour, and puzzle solving gameplay in a world with free travel across more dimensions than you thought you were getting when you opened the box. On top of the 3 spatial dimensions, not only do you need to travel across time to navigate the citadel, but you need to change the past and create alternate timelines.
The gameplay is well executed, given how ambitious the idea was and the tight timeline. It's rough around the edges and there are minor bugs galore, but the core seems to be intact, and the gameplay is well thought out and reasonably balanced. The setting, storytelling, and atmosphere all work together well, and the plot twist fits the jam's "unexpected" theme, as does the surprising depth of mechanics.
To navigate the extra depth and complexity of the game, players will need to bring a measure of patience and keen perception. The deceptively small size of the game world in 3 dimensions hides a surprisingly intricate maze of paths across time and possibility. Expect to spend a lot of time looking for subtly hidden treasures, and trying to fit an image of the citadel superimposed across a handful of different eras in your mind.
Things that aren't obvious bugs but I'd still like to see include reducing immersion breaks (diagetic guidance, and the entire inventory screen is unnecessary), a bit richer in-world sound (footsteps! maybe voice acting...?) and some accessibility improvements (fixes for HUD/GUI and font scaling settings, translations).
I'm excited to hopefully see more developer attention on this game in the future, to clear away annoyances and distractions and add the shine and polish it deserves, and hopefully the community will rise to the occasion with play testing, bug reports, and pull requests.
Don't worry about it, no amount of understanding of English would help anyone make sense of the comment.
The "etymology lesson" paragraph is, at least, interesting, even though it's completely wrong (false friends).
As for the technological aspects of mese, it's not really relevant to golden bread since the bread is gold, not mese. Also not sure where the Scheme interpreter comment is coming from, since Greenspun's Tenth Law clearly specifies Common Lisp, not Scheme.
I went down a similar rabbit hole shortly after playing the original, and discovered both the artist and the book. I found the book at my local library, quite enjoyed it, and I think it may have been a factor in helping me decide to do the remake. You can see influence from both book and the orginal artist in the game (and the book itself also alludes to the original artist).
the "Unlicense" option does not mean the content is unlicensed, it means that it's licensed under the terms of the license named the Unlicense. Please direct complaints about the confusingly named license to its creators.
Content for which you do not have the right to grant permission to use cannot be distributed via CDB at all. You will either need to track down the sources and get proper permission from them (in the form of a license, not just a personal promise) or you will have to replace the items for which license is not available.
For the record, you apparently found Issue #45: Disappearing Items, which is now fixed in the latest release. If you think you may have lost potentially important items due to this bug, you should start a new world.
I experimented with 3 different forms of movement control (minetest-style pitch-move, not-minetest-style pitch-move, and non-pitch-move) and settled on the one I used because (1) it seems like players found all 3 about equally unintuitive, and (2) MT doesn't (at least at the time) provide a way to find out what the state of the client-side toggle is. If I could detect it, then I could support the toggle automatically and transparently.
Sometimes I felt like I was teleported around a few nodes
I've seen some movement jank when a lag spike hits. I thought it could be related to the Klots movement code, but I've seen some of the same jank when using standard MT movement, and even in other games. I think mostly it's just easier to observe in Klots becauase the movement is novel so you're noticing it more.
dedicated_server_step
Unfortunately, this ALSO affects the animation timing for object:move_to(pos), which affects how smoothly Klots appear to move when you push them; shortening it tends to shorten the animation to the point where you lose the sense of motion. Would be nice to have these things decoupled so we could get the best of all worlds.
I want more levels
Me too! I've got a few ideas for level designs, but if you have some yourself, there's actually a fairly robust level editor built into the game, and a level editing guide that explains how to set it up, use it, and ways to submit levels if you want them included upstream.
My original idea was that the first few steps you'd take would be a bit louder, and then it would fade with monotony to let other sounds take over.
This mod has amazing performance.
Basically all mapgen stuff is done via schematics, and there is almost no need to manipulate node metadata at any point, making it easy to do fast. IIRC the original Piranesi was also mostly schematic-based. The fact that the map is basically empty until you step over a threshold, and only the room you're stepping into is actually generated, helps a lot.
thrown away all of the base lua and started from scratch
That's what I did. No criticism to the original author (that they got such an ambitious project working at all in a game jam timeframe, on top of the amazing concept, design, and artwork is quite impressive) but I just found it easier to work with the code by restructuring everything, and getting rid of a lot of external dependencies.
I am still as confused as ever
Some of these puzzles are pretty hard. The star puzzle you mentioned took me until almost the end of the rewrite to figure out (the code for the solution in the original is stubbed out so I actually couldn't even cheat by reading the source).
assistance of some friends
Playing with friends can help a LOT, especially when you're stuck on one stubborn thing. I think being able to collaborate, or at least share your progress, makes it more fun even when you're not making much progress.
once I've completed this version
You can also play this one through again and aim for a higher completion %, or a faster time! 🙂
Yeah, after checking it again, I concur about the footsteps. It would be nice if they could be changed dynamically, but the best I can do is reduce them by about 12dB for the next release.
On certain drawtypes, especially mesh, paramtype="light" is de facto "required". Otherwise, the node will be fully in darkness, which smooth lighting partially hides, but only in trivial circumstances. Try turning off smooth lighting or making a huge heap of the plushie models and see that the fully-enclosed ones are completely black. It's a good idea to do some testing with smooth lighting disabled to unmask these problems before release.
It already made my issue list early on. It's just a bit hard figuring out some unique patterns that can be used to tell them apart that would be distinguishable, but not suggest that each type of klot has a particular "personality" or something.
Klot textures having a different resolution than the rest of the stuff...
Besides the fact that I more or less can't do pixel art, I also sort of wanted Klots to have an uncanny feel, like they aren't really a proper part of the environment.
Glassy sounds bumping into metal...
Sci-Fi Nodes' decision, not mine, and I didn't really want to get too into the weeds to second guess that mod's decisions all individually.
A lot of this game is also an experiment in working with mods originally intended for survival/creative gameplay, and "freezing" them into inert scenery for puzzle gameplay environments. Definition Ripper was a consequence of work I did for this Jam.
I would allow host/server mode as long as it's just one player, but hide the checkbox in the UI via game.conf options. I tend to just launch MT in LAN host mode by default, since it helps with testing, and it's needlessly annoying getting kicked out of the game when there's only one player anyway.
I tried following the clock puzzle instructions, and I also looked in the code for the "special room" patterns, but they aren't in the Jam release. This must be something that's in the upcoming version to be released later, right?
I definitely saw the potion order in the bathroom, and it was different from the order I saw in the code ... but I may have been looking at the wrong version of the code at the time.
Okay, the candle room flower puzzle eluded me, even looking at the code, because it was tucked away in a different mod ... that's gotta make the project pretty hard to keep organized! Also, I missed most of it when I placed the flowers ... do I have to leave and try again with fresh flowers? Maybe it should repeat or something?
So the clues are mostly there, some of them are just really well-hidden. Leaving a few extra written notes or something for players might help (maybe some that only show up after the player has been playing a certain amount of time, or been to a certain number of rooms, to avoid nerfing it prematurely).
Instead of cluttering up this thread (getting a little off-topic from the original issue report), you can also reach me on Minetest's IRC, Matrix, or Discord.
I got very hooked on the story and setting, so I doggedly forced my way through the whole game, hacking it to splinters where necessary. Are you interested in some help fixing it up post-jam? It would be really great to see this game polished and working.
When I first saw this mod, I was uncertain about its value, since generally NodeCore encourages players to be methodical about lighting, and the light sources in this mod fill a very narrow niche once the player has unlocked Optics.
However, playing on Kimapr's "darkest NodeCore" server running Nodeternal Darkness, this mod is an extremely valuable addition to that world, and balances excellently with the darkness. Players tend to build their settlements at some distance apart, and avoid building networks of lighted areas to connect to each other, to defend against griefers and thieves. Portable light sources, relatively unimportant in Vanilla NodeCore, are the principal way for players to travel between settlements and avoid getting lost or falling in pits. Torches are a suitable emergency light source for getting started at the very beginning of the game, but the longer-lasting light sources make pre-optic living more tolerable, and the powerful Luxlamp is a reliable workhorse for long-distance travel and exploration.
On Vanilla, as well, while these tools don't play as vital of a role or take center stage in gameplay, they also do not really significantly unbalance the game, and can make things like finding lost tools dropped into a dark cave a little less painful, for players not looking for such unforgiving consequences for carelessness.
After having run the JIT profiler on my production server, even after stopping it, I noticed server freezes or slowdowns that would eventualy cause my server watchdog to trip and restart the server.
Even given that, it's still worth having the mod available, in case I need to debug performance issues that are hard to reproduce locally again. Yes, of course, generic protests against "debugging in production," but I already have a test environment, and sometimes you just can't reproduce a bug locally, and sometimes the most efficient way to get forensics on a problem is to capture it in production. Even if the server needs to restart, I still get the valuable forensic data to track down issues that affect everyone, not even just my server.
This basically just means that I won't be sampling randomly on my server, but only when there's an actual suspected problem.
Sometimes a lot of C code execution is reported in suspicious places. I think this represents time taken by the Minetest engine, but I don't know why the profiler thinks the code is executed inside a Lua function. -- (from the documentation)
I noticed this, and it was probably the biggest obstacle to interpreting my results. I used a simple perl script/regex to pre-filter the raw profiler data, and produced a "filtered" and a "raw" version of each flame graph.
The "filtered" one helped point towards places where I was doing things in lua that were too expensive. It was best for identifying problems that I could directly and immedately fix.
The "raw" version seemed to indicate the overall performance impact of major components, e.g. globalsteps vs ABMs vs node timers. Seeing a lot of poorly-affiliated C code execution time in any branch of the graph suggested that I may be making API calls or other decisions that were impacting the amount of time the engine was spending on things. Things like adding a neighbor check to an ABM can make it roughly 7x as expensive on the C++ side, so things like this need to be weighed carefully, and the "raw" graph helped me get an idea of how much attention practices like these warranted.
Doesn't this only apply to LuaJIT though?
Technically, yes, results you get profiling the JIT are not necessarily comparable to PUC, and they may have different performance characteristics under certain kind of workload. However, almost all of the problems I discovered were algorithmic problems, or using engine APIs incorrectly (e.g. making unnecessary calls to the engine that I could avoid), so I expect the result to improve performance on PUC-only platforms significantly also.
Even if you are mainly targeting PUC (i.e. the way IKEA is/was), it still makes sense to get a JIT build of MT and run this mod against it to find non-runtime-specific performance issues.
I maintain NodeCore, a very complex game spanning over 20k lines of code. For some time (apparently years), a serious performance issue had been slowly building up on my NodeCore server, causing bad lag spikes, and my players and I were having no luck figuring out the cause. Minetest's built-in profiler was no help, and I had tapped out its extremely limited abilities a long time ago.
I highly recommend all modders who care about quality use this tool and test performance of all their packages. It is a little complex to run but very much worth it.
It sounds like what you're finding is dungeons with loot, which are a part of the mapgen. Those were meant to add some spice to the game, and possibly tease players with some more advanced content to get them interested in trying to make those things themselves. The closest thing that the game has to official "lore" for them is that they're the remnants of a past civilization that once developed on this world, but apparently had to flee suddenly, leaving a lot of their stuff behind in disarray. Much is still left to the player's imagination.
While the loot itself is randomly generated, the actual rarity tables for loot were based on a sampling of items stored by players on the NodeCore Community server ... so in a way, that "past civilization" could be an alternate history for the server.
On NodeCore releases since about 2021-11-27, glowing prills cooling inside any storage box deletes the storage box, leaving only a bare stack of prills. This affects lode as well as adamant, since this mod replaces the heating/cooling recipes for all metals.
A proposed fix is available. Server operators can consider using it until the issue is fixed officially.
I run this mod on a family private server (where the gameplay is less "hardcore" than vanilla) and it's a nice and very natural-feeling extension of gameplay. It changes the gameplay balance, especially making ongoing lode supplies much cheaper, but compensates nicely by adding an engaging snake feeding and caretaking system.
Criticisms:
UPDATE: I'm revising my criticism, because, at least since the addition of Forms to the game, it is highly feasible to catch a snake and trap it in an enclosure that ensures it stays safe and healthy indefinitely, as long as the player remembers to keep it fed, which is not an error-prone process. Leaving design of such an enclosure as the player's responsibility is consistent with the challenge level of NodeCore.
Suggestions:
In addition to less self-trapping behavior, richer pathfinding interactions might be nice, like certain kinds of nodes it avoids (igniters, radioactives, metals?)
Reproduction/renewal mechanics, such as laying eggs if fed certain high-value resources. It would be nice to be able to keep dormant eggs in storage until needed, and then incubate them somehow to hatch them, esp. as mitigation for snake fragility. (There's a "skyblock recipe" that allows making one from nothing, but a more natural way to expand a stock of them once you have one would be nice)
Latest release includes a number of improvements that are relevant to the feedback in this review:
Hints have been renamed to Challenges, to make it clearer that they're (at least for now) not there to assist but merely to motivate.
Package description has added warnings about the unforgivingness of the game.
Package description and in-game guide now make it clear that asking for help is okay. Getting through the game entirely on your own may be ideal but for a game of this scope and scale it's probably unrealistic.
There is now a "stone anvil" system that makes useful metalworking accessible earlier (requiring less ore), including Hint/Challenge coverage.
Shelf recipe reform is in progress. "Form" nodes exist (not covered yet by Hints/Challenges) that will be new recipe ingredients, but they already introduce some new gameplay features.
These were actually already buried in my "ideas" list, but there are some technical obstacles, and I'm actually more inclined to redesign problem recipes rather than expand hinting.
Avoiding Guesswork
There are currently some known-bad recipes in the game (especially the "3x3" ones like shelves/cases/crates, totes). I hope to fix those someday but finding good replacements is hard, e.g. they need to be more intuitive, they may require intermediate stage items (and then what do those items themselves do) and the risk of "accidental" recipe completion needs to be low.
there are bricks, but mettallurgy is a prerequisite...
You can steal them from dungeons until you reach the point where you can make them. Both materials and storage in NodeCore tend to be tighter than in other games, so once you get used to the economics, you find that a few dungeons can provide quite a good supply of bricks.
The game sped up massively after metallurgy...
I'm considering some alternative routes that can be added to allow earlier access to usable metallurgy, i.e. with a lower initial investment of material. Experienced players tend to be able to reach metal within an hour or two, with optimal mining strategies and careful use of geological hints, though there are still luck factors. Metal remains valuable through at least the mid-game, though, so I'm wary of making it too easy to find.
converted review into a thread
I found this recipe pretty intuitive, since the symmetry made it obvious. I was a bit surprised that the "odd item out" in the Annihilator recipe itself went on top instead of the base, but for the advanced one, there were only 2 reasonable options to test.
The storage box recipe was much less intuitive, using a much more odd line of symmetry and it took me a couple minutes of shuffling things around.
I had a hard time telling if it was supposed to be an ass mech which is bad, a bad mech which is ass, or just a mech which is both ass and bad.
converted review into a thread
It sounds like you're confused. Are you sure you posted this for the correct mod?
The idea of players voluntarily putting away their items before disconnecting is already fully supported by the mod, and if players do this, then there will be no items to float in the air, so the entire point is irrelevant. However, that process doesn't cover cases where a player's internet connection goes out beyond their control.
Also, I'm not sure why you would bother to review a deprecated mod. The review is wasted as deprecated mods are already pushed way down in the listings, if not hidden altogether.
If chaining green tiles were all that you needed to make wires, it would trivialize what you actually need to do to make wires and transistors and the like.
How far have you gotten? 😅
Nice any% run ... have you considered running the 101% category too? 😄
I cant tell if the pun was intended but it was definitely appreciated 😄
Okay, I mostly wanted to make sure it wasn't something I did wrong or something obvious I missed.
I tried getting the upgrades and it made little difference. I even tried cheating and it barely made a difference, and by the time I had enough cheats enabled to actually let me get through the first level and past the first significant obstacle on the second one, I realized I was just going to spoil the whole game without actually "playing" it, so I'd rather wait for the post-jam version.
Even if it's technically winnable, the balance issue is still completely game-breaking for me; it's basically a frantic "bullet hell" game now, which means I can't enjoy the maps (which I noticed you put a lot of care into) and I can't even focus on trying to solve puzzles or anything, so it would only be winnable if I already knew where I was going and what I was doing.
It looks like the two commits that fix this bug were already in your main branch, mixed in with other contributed post-jam changes, and just need to be cherry-picked into a separate branch to be released. This seems to be the minimum set of changes necessary to fix the crash without altering the gameplay as designed.
I made the branch for you already, and you'd just need to pull it into your repo as a new branch, and then make a release from that instead of main. https://github.com/Warr1024/minetest-citadel/commits/jamhotfix/
Do you need help with any of the git or CDB parts of this?
I noticed that you don't have an
Issue Trackerlink in the links at the top of the CDB listing, nor are there any other kind of "contact me" instructions in the description. But you do have a GitHub repo linked, and that repo has an issue tracker open (but so far unused).What's your preferred method of hearing about issues, suggestions, receiving code contributions, etc? Is it best to use that issue tracker? Or do you prefer CDB threads? Or something else?
There is so much to these maps to explore, but in areas where enemies spawn, they end up spawning at such an insane rate that it's impossible for me to keep them down to a survivable level. With the flying dudes it quickly becomes bullet hell. Is this some kind of bug, like the enemies are too aggressive or spawn too fast, or are you just supposed to need to be really hardcore to play this?
What if, instead of a mad scientist as the villain of a game, you had one as the developer?
Looking at the scope and design goals of this project, it feels like it really should have the "Joke / April Fools" tag. Looking at the actual execution, it becomes obvious that it really should not.
The Boom game, in particular, seems to be a complete software-rendered 3D game implemented in typescript, transpiled into Lua, and rendering to
[png:texture modifiers; the fact that it actually runs at all on my laptop from 2012 is amazing. Bit's Battle demonstrates that it's not just pure tech demos that run in this environment, but games with actual gameplay and progression, albeit only a rudimentary amount as implemented so far.To enjoy this "game" to the fullest, it helps for a player to understand the spectrum of games that have been created in Minetest, and understand how much this is abusing the game engine to make it possible. It feels like something in the same spirit as arbitrary code execution in NES games. Rather than being "immersed" in the experience, it sort of demands that you remember that this is all running inside Minetest. There's not a ton of depth and it won't keep you occupied for hours (especially if it crashes MT in a few minutes; I don't know where the "B" in "BOOM" comes from, but I know where the "OOM" does) but it's a spectacle worth witnessing.
This is a very balanced and well-executed game. It has a well-written story, variety of gameplay elements and areas, fits the theme, and seems to suffer from no major bugs or breakages.
The main annoyance I ran into, that made it hard to complete the game without resorting to cheating, is how unforgiving the parkour sections are, especially considering the level of movement jank in Minetest. It was hard to get my momentum correct client-side but lock in server-side, even with the short network path for singleplayer. Something like allowing you to set restart checkpoints by standing perfectly still for a few seconds would have been more fair, without sacrificing the challenge for people who want to speed through.
The projectile combat also felt a little sluggish, though this may just have been my bias coming from other games with faster-moving projectiles; given the movement speed of the enemies, it didn't feel unfair or anything. I didn't have enough health supplies for the boss fight, but apparently the only consequence for dying is injury to my pride, so you can still make it through even if you didn't plan well enough.
I didn't find the plot twist all that surprising, but the evolving gameplay supplied enough intrigue to keep me interested through it, and the story was at least not a distraction, and gave the gameplay a sense of structure and meaning.
Players should expect to need some patience for the parkour elements (especially with MT's imprecision) but the momentum-locking mechanic makes those still worth experiencing, and the game overall is enjoyable in a single sitting, and for replay value you can speed-run it.
I've been toying with the idea of a "video game without the video" for a while now, and it's great to see somebody actually attempt it. I love the ambition of the concept. It might just be a bit much to try to make it work as a sandbox game during a game jam timeframe.
Unfortunately, while a human has potentially dozens of senses (sight, sound, touch, smell, taste, balance, body position, temperature, passage of time, etc) on a computer you mostly just get sight and sound, and losing sight is harder to compensate. Without a sense of balance or body position, it's hard to tell when I'm looking at the horizon, or when I just fell down a hole, or about how far. Without touch, I can't tell if the crunchy-sounding stuff I'm touching is sand, gravel, or dirt. The use of "synesthesia particles" is a pretty good way to translate at least some of the missing senses into the unused visual medium, but it really needs to expand to cover more senses. In particular, when I'm working without a sense of sight (reaching deep into a machine to find a broken part) I rely on touch, not just to sense obstacles, but feeling textures, shapes, temperatures. More missing senses need to be recreated in some way to know what it means when I poke something and it sounds like a drum.
I'm not sure I can recommend this to a player yet. It was a bit intriguing wandering around and getting lost in a cave but now I think I'm stuck. It definitely feels like a project whose development I want to get involved in, suggesting, experimenting with, or contributing some ways to recreate the missing senses ... but for those not developerly inclined, it's one I'd watch for future updates rather than expecting much right now. I'm definitely looking forward to when it reaches the tipping point where I can change my neutral review to a positive one.
Also, the "no sense of sight" game being one of the few to actually feature a gameplay video was entertaining.
A mix of maze exploration, gentle parkour, and puzzle solving gameplay in a world with free travel across more dimensions than you thought you were getting when you opened the box. On top of the 3 spatial dimensions, not only do you need to travel across time to navigate the citadel, but you need to change the past and create alternate timelines.
The gameplay is well executed, given how ambitious the idea was and the tight timeline. It's rough around the edges and there are minor bugs galore, but the core seems to be intact, and the gameplay is well thought out and reasonably balanced. The setting, storytelling, and atmosphere all work together well, and the plot twist fits the jam's "unexpected" theme, as does the surprising depth of mechanics.
To navigate the extra depth and complexity of the game, players will need to bring a measure of patience and keen perception. The deceptively small size of the game world in 3 dimensions hides a surprisingly intricate maze of paths across time and possibility. Expect to spend a lot of time looking for subtly hidden treasures, and trying to fit an image of the citadel superimposed across a handful of different eras in your mind.
Things that aren't obvious bugs but I'd still like to see include reducing immersion breaks (diagetic guidance, and the entire inventory screen is unnecessary), a bit richer in-world sound (footsteps! maybe voice acting...?) and some accessibility improvements (fixes for HUD/GUI and font scaling settings, translations).
I'm excited to hopefully see more developer attention on this game in the future, to clear away annoyances and distractions and add the shine and polish it deserves, and hopefully the community will rise to the occasion with play testing, bug reports, and pull requests.
Don't worry about it, no amount of understanding of English would help anyone make sense of the comment.
The "etymology lesson" paragraph is, at least, interesting, even though it's completely wrong (false friends).
As for the technological aspects of mese, it's not really relevant to golden bread since the bread is gold, not mese. Also not sure where the Scheme interpreter comment is coming from, since Greenspun's Tenth Law clearly specifies Common Lisp, not Scheme.
I went down a similar rabbit hole shortly after playing the original, and discovered both the artist and the book. I found the book at my local library, quite enjoyed it, and I think it may have been a factor in helping me decide to do the remake. You can see influence from both book and the orginal artist in the game (and the book itself also alludes to the original artist).
the "Unlicense" option does not mean the content is unlicensed, it means that it's licensed under the terms of the license named the Unlicense. Please direct complaints about the confusingly named license to its creators.
Content for which you do not have the right to grant permission to use cannot be distributed via CDB at all. You will either need to track down the sources and get proper permission from them (in the form of a license, not just a personal promise) or you will have to replace the items for which license is not available.
Relevant section of the copyright guide
For the record, you apparently found Issue #45: Disappearing Items, which is now fixed in the latest release. If you think you may have lost potentially important items due to this bug, you should start a new world.
I experimented with 3 different forms of movement control (minetest-style pitch-move, not-minetest-style pitch-move, and non-pitch-move) and settled on the one I used because (1) it seems like players found all 3 about equally unintuitive, and (2) MT doesn't (at least at the time) provide a way to find out what the state of the client-side toggle is. If I could detect it, then I could support the toggle automatically and transparently.
I've seen some movement jank when a lag spike hits. I thought it could be related to the Klots movement code, but I've seen some of the same jank when using standard MT movement, and even in other games. I think mostly it's just easier to observe in Klots becauase the movement is novel so you're noticing it more.
Unfortunately, this ALSO affects the animation timing for object:move_to(pos), which affects how smoothly Klots appear to move when you push them; shortening it tends to shorten the animation to the point where you lose the sense of motion. Would be nice to have these things decoupled so we could get the best of all worlds.
Me too! I've got a few ideas for level designs, but if you have some yourself, there's actually a fairly robust level editor built into the game, and a level editing guide that explains how to set it up, use it, and ways to submit levels if you want them included upstream.
My original idea was that the first few steps you'd take would be a bit louder, and then it would fade with monotony to let other sounds take over.
Basically all mapgen stuff is done via schematics, and there is almost no need to manipulate node metadata at any point, making it easy to do fast. IIRC the original Piranesi was also mostly schematic-based. The fact that the map is basically empty until you step over a threshold, and only the room you're stepping into is actually generated, helps a lot.
That's what I did. No criticism to the original author (that they got such an ambitious project working at all in a game jam timeframe, on top of the amazing concept, design, and artwork is quite impressive) but I just found it easier to work with the code by restructuring everything, and getting rid of a lot of external dependencies.
Some of these puzzles are pretty hard. The star puzzle you mentioned took me until almost the end of the rewrite to figure out (the code for the solution in the original is stubbed out so I actually couldn't even cheat by reading the source).
Playing with friends can help a LOT, especially when you're stuck on one stubborn thing. I think being able to collaborate, or at least share your progress, makes it more fun even when you're not making much progress.
You can also play this one through again and aim for a higher completion %, or a faster time! 🙂
Yeah, after checking it again, I concur about the footsteps. It would be nice if they could be changed dynamically, but the best I can do is reduce them by about 12dB for the next release.
On certain drawtypes, especially mesh, paramtype="light" is de facto "required". Otherwise, the node will be fully in darkness, which smooth lighting partially hides, but only in trivial circumstances. Try turning off smooth lighting or making a huge heap of the plushie models and see that the fully-enclosed ones are completely black. It's a good idea to do some testing with smooth lighting disabled to unmask these problems before release.
It already made my issue list early on. It's just a bit hard figuring out some unique patterns that can be used to tell them apart that would be distinguishable, but not suggest that each type of klot has a particular "personality" or something.
Besides the fact that I more or less can't do pixel art, I also sort of wanted Klots to have an uncanny feel, like they aren't really a proper part of the environment.
Sci-Fi Nodes' decision, not mine, and I didn't really want to get too into the weeds to second guess that mod's decisions all individually.
A lot of this game is also an experiment in working with mods originally intended for survival/creative gameplay, and "freezing" them into inert scenery for puzzle gameplay environments. Definition Ripper was a consequence of work I did for this Jam.
So the clues are mostly there, some of them are just really well-hidden. Leaving a few extra written notes or something for players might help (maybe some that only show up after the player has been playing a certain amount of time, or been to a certain number of rooms, to avoid nerfing it prematurely).
Instead of cluttering up this thread (getting a little off-topic from the original issue report), you can also reach me on Minetest's IRC, Matrix, or Discord.
Oddly, I did not run into the rumored door crash ... but I managed to run into just about every other one.
https://gist.github.com/Warr1024/be057037259b51f5133efa0ae5a10d70
I got very hooked on the story and setting, so I doggedly forced my way through the whole game, hacking it to splinters where necessary. Are you interested in some help fixing it up post-jam? It would be really great to see this game polished and working.
Sorry, but ContentDB Review comments are not meant to be "general support" threads.
Check out the "Join the Community" links in the package description for places you can ask/look for more info.
When I first saw this mod, I was uncertain about its value, since generally NodeCore encourages players to be methodical about lighting, and the light sources in this mod fill a very narrow niche once the player has unlocked Optics.
However, playing on Kimapr's "darkest NodeCore" server running Nodeternal Darkness, this mod is an extremely valuable addition to that world, and balances excellently with the darkness. Players tend to build their settlements at some distance apart, and avoid building networks of lighted areas to connect to each other, to defend against griefers and thieves. Portable light sources, relatively unimportant in Vanilla NodeCore, are the principal way for players to travel between settlements and avoid getting lost or falling in pits. Torches are a suitable emergency light source for getting started at the very beginning of the game, but the longer-lasting light sources make pre-optic living more tolerable, and the powerful Luxlamp is a reliable workhorse for long-distance travel and exploration.
On Vanilla, as well, while these tools don't play as vital of a role or take center stage in gameplay, they also do not really significantly unbalance the game, and can make things like finding lost tools dropped into a dark cave a little less painful, for players not looking for such unforgiving consequences for carelessness.
One small caveat I observed:
After having run the JIT profiler on my production server, even after stopping it, I noticed server freezes or slowdowns that would eventualy cause my server watchdog to trip and restart the server.
Even given that, it's still worth having the mod available, in case I need to debug performance issues that are hard to reproduce locally again. Yes, of course, generic protests against "debugging in production," but I already have a test environment, and sometimes you just can't reproduce a bug locally, and sometimes the most efficient way to get forensics on a problem is to capture it in production. Even if the server needs to restart, I still get the valuable forensic data to track down issues that affect everyone, not even just my server.
This basically just means that I won't be sampling randomly on my server, but only when there's an actual suspected problem.
A few more technical notes:
I noticed this, and it was probably the biggest obstacle to interpreting my results. I used a simple perl script/regex to pre-filter the raw profiler data, and produced a "filtered" and a "raw" version of each flame graph.
Doesn't this only apply to LuaJIT though?
Technically, yes, results you get profiling the JIT are not necessarily comparable to PUC, and they may have different performance characteristics under certain kind of workload. However, almost all of the problems I discovered were algorithmic problems, or using engine APIs incorrectly (e.g. making unnecessary calls to the engine that I could avoid), so I expect the result to improve performance on PUC-only platforms significantly also.
Even if you are mainly targeting PUC (i.e. the way IKEA is/was), it still makes sense to get a JIT build of MT and run this mod against it to find non-runtime-specific performance issues.
I maintain NodeCore, a very complex game spanning over 20k lines of code. For some time (apparently years), a serious performance issue had been slowly building up on my NodeCore server, causing bad lag spikes, and my players and I were having no luck figuring out the cause. Minetest's built-in profiler was no help, and I had tapped out its extremely limited abilities a long time ago.
After being pointed to the JIT Profiler, and figuring out how to use it and interpret the results (read the description carefully), it helped solve the performance problem very quickly (a raycast happening too early in a sequence of checks), and also identified other performance issues that I hadn't even detected yet (uncached privilege checks, dynamic lighting checks, and more).
I highly recommend all modders who care about quality use this tool and test performance of all their packages. It is a little complex to run but very much worth it.
(more in comments)
It sounds like what you're finding is dungeons with loot, which are a part of the mapgen. Those were meant to add some spice to the game, and possibly tease players with some more advanced content to get them interested in trying to make those things themselves. The closest thing that the game has to official "lore" for them is that they're the remnants of a past civilization that once developed on this world, but apparently had to flee suddenly, leaving a lot of their stuff behind in disarray. Much is still left to the player's imagination.
While the loot itself is randomly generated, the actual rarity tables for loot were based on a sampling of items stored by players on the NodeCore Community server ... so in a way, that "past civilization" could be an alternate history for the server.
converted review into a thread
converted review into a thread
On NodeCore releases since about 2021-11-27, glowing prills cooling inside any storage box deletes the storage box, leaving only a bare stack of prills. This affects lode as well as adamant, since this mod replaces the heating/cooling recipes for all metals.
A proposed fix is available. Server operators can consider using it until the issue is fixed officially.
I run this mod on a family private server (where the gameplay is less "hardcore" than vanilla) and it's a nice and very natural-feeling extension of gameplay. It changes the gameplay balance, especially making ongoing lode supplies much cheaper, but compensates nicely by adding an engaging snake feeding and caretaking system.
Criticisms:
UPDATE: I'm revising my criticism, because, at least since the addition of Forms to the game, it is highly feasible to catch a snake and trap it in an enclosure that ensures it stays safe and healthy indefinitely, as long as the player remembers to keep it fed, which is not an error-prone process. Leaving design of such an enclosure as the player's responsibility is consistent with the challenge level of NodeCore.
Suggestions:
In addition to less self-trapping behavior,richer pathfinding interactions might be nice, like certain kinds of nodes it avoids (igniters, radioactives, metals?)Latest release includes a number of improvements that are relevant to the feedback in this review:
These were actually already buried in my "ideas" list, but there are some technical obstacles, and I'm actually more inclined to redesign problem recipes rather than expand hinting.
There are currently some known-bad recipes in the game (especially the "3x3" ones like shelves/cases/crates, totes). I hope to fix those someday but finding good replacements is hard, e.g. they need to be more intuitive, they may require intermediate stage items (and then what do those items themselves do) and the risk of "accidental" recipe completion needs to be low.
You can steal them from dungeons until you reach the point where you can make them. Both materials and storage in NodeCore tend to be tighter than in other games, so once you get used to the economics, you find that a few dungeons can provide quite a good supply of bricks.
I'm considering some alternative routes that can be added to allow earlier access to usable metallurgy, i.e. with a lower initial investment of material. Experienced players tend to be able to reach metal within an hour or two, with optimal mining strategies and careful use of geological hints, though there are still luck factors. Metal remains valuable through at least the mid-game, though, so I'm wary of making it too easy to find.