Thanks for the clarification. In light of it, please let me apologize for insinuating that you were being mean towards the mod author. (I believe I owe you an explanation: I simply had not seen a direct connection between your review and this mod initially. It seemed to me as if you were not reviewing their mod specifically, but rather voicing generic criticism not specific to this mod.)
Given this clarification, ContentDB staff might want to reconsider whether this would qualify as a review.
There is no mechanism in this repository to limit proliferation of such mods
How ContentDB deals with library mods is a ContentDB problem, not a problem of this mod; and ContentDB has a tag for library mods ("API / Library").
It's bad enough that users get creatura, mobs_redo, etc. installed when they choose a mob related package
Is it though? If everything goes smoothly, I don't see any issues here. And I don't see a solid suggestion for how to handle library mods instead coming from you either.
How should a user know why they need logging, super_logging, logging_47, and logging_fork packages.
Easy: Because a mod they use depends on them. Note also that our users aren't just players, but also e.g. admins or other developers.
This gives bad user experience. Please don't do this.
Please don't do what you did here: Write a review which is not at all about the actual "content" of this library mod - the actual APIs implemented - but rather about the meta-topic of "how do we want to deal with library mods".
I frankly think you're being mean and unfair towards the author of this mod.
You have no substantial criticism relevant to what this package is about, yet gave this package a negative review.
PS: if someone thinks this is a great mod, write a positive review. Please do!
I will not write a positive review of a library mod I haven't used and potentially will not use just to balance out your unfair negative review.
unlike e.g. the unicode_text mod this package doesn't provide any value directly to the user of minetest, but only to the development of other mods.
This statement is false. Any library mod, including unicode text, only provides value to modders, who then use that value to create value for players. Some contributions may be more direct, but better logging may certainly benefit end users, especially as they get more technical (which does not just mean developers; there are also admins and moderators).
Such content does not belong as a separate entity (aka binary dependency) into this user facing repository.
(I still don't get why you're calling this "binary" when it's plaintext source code. That's a very confusing, fearmongering way to use the word "binary" for sure - as if this was some intransparent binary blob rather than a small piece of Lua any interested tinkerer can easily poke.)
This is where you go plain wrong. ContentDB is explicitly also a place for such dependencies, whether you like that or not. Quoting the package inclusion policy:
Adding non-player facing mods, such as libraries and server tools, is perfectly fine and encouraged. ContentDB isn't just for player-facing things, and adding libraries allows them to be installed when a mod depends on it.
In other words, you're negatively reviewing a package for doing something encouraged by the package inclusion policy.
I can only agree with the other reviewer(s): This is by far the best chess implementation in Minetest to date. It's nicely usable; you get a 3d view of the board. The engine works and actually picks decent moves.
Now, that's where the unexpected part comes in: Random "events" can completely change the course of the game. Strategies that work against the engine in "normal" chess don't work anymore. Beating the engine at "normal" chess is doable, but the "unexpected" version will give you a much harder time. It can be pretty frustrating if you worked hard on getting your pawns into good positions and suddenly they all just evaporate :P
Suggestions: Highlight the last move / action somehow (maybe using particle effects?). Otherwise it is at times hard to see what just happened.
Also, please give the player a moment to review a checkmate.
Huh, that's odd. Could you maybe detail your experience?
I found the game to be pretty straightforward: When you spawn, there's basically only one way you can go. As you walk this way, the story is presented to you through the dialogue between you and the light orb: You have to collect light crystals while fighting off "shadowspawns". For that you have to go through the portals.
The ending (the boss you have to fight) fits "unexpected" quite well, I'd say.
I like this demonstration of just how much Minetest can be abused, but there isn't really anything to do; all the "games" become pretty boring pretty fast.
Took me ~20 minutes to play this through, I like the mechanics. The "health powder" feels like a bit of a cheat - I had plenty of it when I went into the boss fight.
Good to know! but wait... you just said only 6.0 may break compatibility...
Yes, just like 5.0 broke compatibility in 2019. These breaking releases are rare though.
so does this mean I am in danger? in some eventual point in time?
I wouldn't say you are "in danger". Minetest likely won't have a breaking release for a while; the next scheduled release is 5.9. But there will eventually be a breaking release, and it is possible that some mods that aren't updated will not work with the newer Minetest engine then.
is there ANYTHING I can do to stop my engine from updating?
Yes: Don't update. Minetest doesn't update itself. If your package manager installs breaking updates automatically, configure your package manager properly.
it has instilled in me that mods sometimes usually break when you move up to the latest version(if the modder never updated their mod)
In an ideal world, they should not. However neither Minetest Engine nor modders are perfect. There are three reasons that mods do break:
Modders often rely on undocumented engine implementation details that aren't guaranteed to not change, which eventually change, accidentally or deliberately.
Core devs may accidentally break backwards compatibility.
Core devs may deliberately break backwards compatibility in "minor" ways if they are reasonably certain that (1) (most) mods don't rely on a certain (possibly documented) behavior (2) it provides significant benefit to do so.
But nevertheless, for the most part, the Minetest Engine has a good track record of keeping backwards compatibility. I don't know whether caverealms or Minetest is to blame in this specific instance. I would recommend reporting the issue.
if I were to get myself a fresh copy of the minetest game from 5.1.1 and put it into the game folder of the current engine... would it run?
It should. Since version 5.0, the Minetest Engine tries to follow semantic versioning. This means that "minor" releases like 5.8 are backwards compatible with other "minor" releases like 5.1. So if a game or mod works on 5.1, it should also work on 5.2, 5.3, ..., 5.8, 5.9 etc. Only 6.0 may break compatibility.
Hence Minetest Game 5.1.1 should work in Minetest Engine 5.8 just fine. Of course, you'll miss out on the bugfixes later Minetest Game versions bring.
Minetest Game strives to follow semantic versioning and be backwards compatible just as well, so if mods work with MTG 5.1, they should continue to work with MTG 5.2, 5.3, etc.
First off: On ContentDB, please open threads (rather than making neutral reviews) for questions.
I've been having a good time so far with this, except for the latest update that happened and just got forced down my throat. see, I just recently rolled in from my old version of minetest that was a version 5.1.1 that was on my old windows 7 pc. I have since, migrated to the latest version on Android(playing on a tablet). took me a while to get my bearings straight, but have adjusted relatively well.
All of this seems to concern the Minetest Engine rather than Minetest Game?
I MUST know if this means some out of date mods will stop working
They should not: Minetest 5.8 is a minor release. It should not be breaking compatibility.
will things start to break, if I DON'T update the main minetest game?
No.
NOT all content and mods are kept to date... so I must know if I'm in any danger.
You should not be. (There is always a small risk of modders relying on engine internals however.)
I noticed doors open with one tap now instead of two
This is an engine change. It is unrelated to Minetest Game.
It's not me who wants to waste your time reviewing my mod.
The time spent on mod reviews is not "wasted"; it is necessary to nip some issues in the bud before they arise, and it worked well here: Without the review, you would have released the mod under a name that was already in use.
There have also been plenty of other mods with issues that got caught in review. It is especially useful to try to catch copyright (and other legal) issues before there is a formal complaint.
Either way, I don't think the review system is up for debate.
You're still not finished after 17 hours now and referring to the review queue.
You're being very impatient. Waiting a few days for your mod to be reviewed is normal.
Thanks for the review! What exactly is nerdpoling (is it what I know as "pillaring"?), and what would you suggest to "stop it"? I wrote this as a means of (among other things) slowing down pillaring, since fast pillaring typically requires you to place blocks colliding with you. A block placement quota might additionally be useful to slow down pillaring. An alternative option to consider is something like structural integrity checking, where pillars past a certain height would degrade to piles (blocks would fall left and right).
This is likely to be out of scope. character_anim tries to be as game-agnostic as possible by only expecting a few standard bones the Minetest Game default player model (character.b3d) typically provides: Body, head and right arm. I don't plan to add custom models. I could add support for more advanced model conventions, but that would complicate the code and probably only serve a single game (Mineclone) which provides such a model (and already has its own provisions for animations).
You can use visible_wielditem.item_tweaks.names["default:torch"] to change that. I could add better default settings for MTG items, but I feel that would bloat the scope of this project - there probably are plenty of items in plenty of games that could use special tweaks...
Thanks for the report. This was a character_anim bug I never noticed because as soon as player_api changes the animation - as soon as you move, punch, rightclick, lay, use a boat, whatever - an animation would have been set; this bug was only noticeable if you actually immediately changed into third-person view before doing anything. The fix was trivial; I just had to preserve the initial animation.
Minetest Game being bundled by default is an engine issue rather than a game issue. This renders your review irrelevant for the Minetest Game ContentDB package.
I have recently bumped the modlib dependency to version rolling-100 since it fixes a bug with subfolder media collection. The error message should be telling you:
update modlib to version rolling-100 or newer
which is exactly what you have to do: simply update your modlib. rolling-100 is available on CDB.
Please read error messages. Note that this is tagged as a "developer tool", so I don't think it's entirely unreasonable to expect the users to read the error messages.
For the future: Please attach stack traces to bug reports.
This does not implement *nix Glob Patterns, but rather simply uses Lua patterns. Nobody in their right mind would do rm -rf .* in their terminal - that will not remove all files, but rather only hidden files (files starting with a dot in their name)!
The only function provided is not exactly useful; how often do you need to kick multiple players based on a pattern? I could imagine this being useful only in very rare cases where an attacker is dumb enough to make his names follow a pattern. What makes this even more useless is that the Minetest chat features tab completion for playernames.
What I could see being useful: Actual globs, e.g. for file traversal purposes, but as an API rather than user-facing chatcommands.
No, not at all. Devtest is a tool, not a base for modding. You should not base games on devtest (like e.g. runs did with the Samz); games won't want the quickly thrown-together test content devtest provides.
The only thing I would like to be changed is add a setting for 'default' mods, to allow for modders to test things for performance simultaneously with gameplay.
This would completely defeat the purpose of devtest which is to be a minimal testbed. If you want mods, add and enable them. Wrap them up in a modpack if you want to use your usual mod soup.
Usually the best testbed for engine development or if you want to quickly play around with an engine feature.
Also very useful in mod development due to its minimalism,
which allows for a very fast loading time and also helps ensure that
your mod works even in a minimalist environment without bloaty mods such as default.
Devtest also provides a few introspective facilities (e.g. node editing tools etc.) and example content (nodes, entities etc.) that aid in engine and mod testing.
That said, when you're developing a new game for players, you should under no circumstances base it on devtest (except if your game is intended to serve as a replacement testbed or perhaps a more specific mod testbed).
The awesome art is mostly thanks to TEMHOTAOKEAHA and Dragoni, our awesome pixel artists :)
The mech model looks nice, I only wish it had animations.
This was planned but the model had to be added last minute and there was no time left to add animations unfortunately. In fact there even is an animated model that just couldn't be added yet.
I believe that the music in the ice layer could be more varied, as you're bound to spend more time in there to stockpile supplies for the danger ahead.
Agreed. IIRC I had to sort out some tracks due to nonfree (non-commercial) licenses.
I couldn't complete the game because the enemies simply frightened me too much: when I poked my head in a cave close to their spawn depth, a swarm of 10~ of them attacked me and caused me to flee. When I tried to fight them, they always overwhelmed me with numbers because of their fast spawn rate.
Hostile spawning has been limited post-submission.
The pixel art in the opening and menus is very clean too.
That's mostly thanks to TEMHOTAOKEAHA and Dragoni, our awesome pixel artists :)
especially for drilling
There is a sound effect for drilling, but it requires MT 5.7-dev... Should be fine as soon as 5.7 releases though. More sound FX are definitely planned long term.
There were some plants that were kind of floating a few blocks off the ground that looked like they should be hanging from the ceiling.
Hmm indeed, I'll look into this.
Hostile spawning has been limited post-submission.
What was confusing is the game tells you to go to a spot on your radar but I did that and found ... nothing. Strange. Probably this wasn't coded yet?
This definitely is implemented ("beacons"). How many of these (and of which kinds) you manage to obtain determines your ending. Note that the dot on your radar gets larger the closer you get to the beacon on the vertical axis. Perhaps you were at the wrong depth? (It is possible that there are issues with beacon spawning code though; in my tests I have always been able to dig at least one beacon though).
This game should actually be called "Speedrunning Down" because that's the winning strategy. :D
Heh, not quite. You should have gotten the "bad" ending if you just went down immediately; that is, "you find the same fate as the astronauts before you". Speedrunning Down is an "ending" strategy, but not a "winning" one :D
Minetest actually allows you to let a texture span over multiple nodes
We considered world-aligned textures but preferred mapgen randomization of textures.
Also, using the spray gun triggers an error message (not a crash).
Yep, added that last minute and the Minetest player name vs. player ref inconsistency got me :)
Fixed post-submission.
[Performance Problems]
I have fixed mob overpopulation post-submission. Optimizing the mapgen further is hard. I think it is already asymptotically optimal (or close to it), and I haven't been able to go much further on the constant factors using the LuaJIT profiler. In hindsight implementing the custom mapgen probably wasn't the best idea as it took an immense development effort and largely wrecks performance, even after optimization.
The acid sprayer is functional (it requires acid though); it's only the sound playing that's not working (I added that last minute). Fixed on Git (post-submission).
The lag is definitely a major problem - we didn't have enough time to optimize it properly (optimizing the mapgen in particular is very hard). We learned that implementing a fully custom, sophisticated Lua-only mapgen for a game jam game probably isn't the best idea.
I have fixed the mob overpopulation already, it's just post-submission as well. I'll also look into further optimizing stuff.
TL;DR: Not enough time in the game jam timeframe to polish everything (esp. as mapgen dev was very time consuming), but we will get there :)
You mean renaming worlds? That's an engine feature request: https://github.com/minetest/minetest/issues/10147.
Thanks for the clarification. In light of it, please let me apologize for insinuating that you were being mean towards the mod author. (I believe I owe you an explanation: I simply had not seen a direct connection between your review and this mod initially. It seemed to me as if you were not reviewing their mod specifically, but rather voicing generic criticism not specific to this mod.)
Given this clarification, ContentDB staff might want to reconsider whether this would qualify as a review.
How ContentDB deals with library mods is a ContentDB problem, not a problem of this mod; and ContentDB has a tag for library mods ("API / Library").
Is it though? If everything goes smoothly, I don't see any issues here. And I don't see a solid suggestion for how to handle library mods instead coming from you either.
Easy: Because a mod they use depends on them. Note also that our users aren't just players, but also e.g. admins or other developers.
Please don't do what you did here: Write a review which is not at all about the actual "content" of this library mod - the actual APIs implemented - but rather about the meta-topic of "how do we want to deal with library mods".
I frankly think you're being mean and unfair towards the author of this mod.
You have no substantial criticism relevant to what this package is about, yet gave this package a negative review.
I will not write a positive review of a library mod I haven't used and potentially will not use just to balance out your unfair negative review.
This statement is false. Any library mod, including unicode text, only provides value to modders, who then use that value to create value for players. Some contributions may be more direct, but better logging may certainly benefit end users, especially as they get more technical (which does not just mean developers; there are also admins and moderators).
(I still don't get why you're calling this "binary" when it's plaintext source code. That's a very confusing, fearmongering way to use the word "binary" for sure - as if this was some intransparent binary blob rather than a small piece of Lua any interested tinkerer can easily poke.)
This is where you go plain wrong. ContentDB is explicitly also a place for such dependencies, whether you like that or not. Quoting the package inclusion policy:
In other words, you're negatively reviewing a package for doing something encouraged by the package inclusion policy.
I'm not sure where you see any "binary dependencies" here.
This is quite a critical, potentially game-breaking bug though. Users should be made aware of this one way or another.
I can only agree with the other reviewer(s): This is by far the best chess implementation in Minetest to date. It's nicely usable; you get a 3d view of the board. The engine works and actually picks decent moves.
Now, that's where the unexpected part comes in: Random "events" can completely change the course of the game. Strategies that work against the engine in "normal" chess don't work anymore. Beating the engine at "normal" chess is doable, but the "unexpected" version will give you a much harder time. It can be pretty frustrating if you worked hard on getting your pawns into good positions and suddenly they all just evaporate :P
Suggestions: Highlight the last move / action somehow (maybe using particle effects?). Otherwise it is at times hard to see what just happened. Also, please give the player a moment to review a checkmate.
Overall, a very good game!
Huh, that's odd. Could you maybe detail your experience?
I found the game to be pretty straightforward: When you spawn, there's basically only one way you can go. As you walk this way, the story is presented to you through the dialogue between you and the light orb: You have to collect light crystals while fighting off "shadowspawns". For that you have to go through the portals.
The ending (the boss you have to fight) fits "unexpected" quite well, I'd say.
I like this demonstration of just how much Minetest can be abused, but there isn't really anything to do; all the "games" become pretty boring pretty fast.
I like the graphics as well as the gameplay. The trick is to not fight too much, but to make a run for it ;P
Took me ~20 minutes to play this through, I like the mechanics. The "health powder" feels like a bit of a cheat - I had plenty of it when I went into the boss fight.
"Your a teenager who does the devious licks challenge"
Yes, just like 5.0 broke compatibility in 2019. These breaking releases are rare though.
I wouldn't say you are "in danger". Minetest likely won't have a breaking release for a while; the next scheduled release is 5.9. But there will eventually be a breaking release, and it is possible that some mods that aren't updated will not work with the newer Minetest engine then.
Yes: Don't update. Minetest doesn't update itself. If your package manager installs breaking updates automatically, configure your package manager properly.
In an ideal world, they should not. However neither Minetest Engine nor modders are perfect. There are three reasons that mods do break:
But nevertheless, for the most part, the Minetest Engine has a good track record of keeping backwards compatibility. I don't know whether caverealms or Minetest is to blame in this specific instance. I would recommend reporting the issue.
It should. Since version 5.0, the Minetest Engine tries to follow semantic versioning. This means that "minor" releases like 5.8 are backwards compatible with other "minor" releases like 5.1. So if a game or mod works on 5.1, it should also work on 5.2, 5.3, ..., 5.8, 5.9 etc. Only 6.0 may break compatibility.
Hence Minetest Game 5.1.1 should work in Minetest Engine 5.8 just fine. Of course, you'll miss out on the bugfixes later Minetest Game versions bring. Minetest Game strives to follow semantic versioning and be backwards compatible just as well, so if mods work with MTG 5.1, they should continue to work with MTG 5.2, 5.3, etc.
First off: On ContentDB, please open threads (rather than making neutral reviews) for questions.
All of this seems to concern the Minetest Engine rather than Minetest Game?
They should not: Minetest 5.8 is a minor release. It should not be breaking compatibility.
No.
You should not be. (There is always a small risk of modders relying on engine internals however.)
This is an engine change. It is unrelated to Minetest Game.
Let me add my opinion as a modder.
The time spent on mod reviews is not "wasted"; it is necessary to nip some issues in the bud before they arise, and it worked well here: Without the review, you would have released the mod under a name that was already in use.
There have also been plenty of other mods with issues that got caught in review. It is especially useful to try to catch copyright (and other legal) issues before there is a formal complaint.
Either way, I don't think the review system is up for debate.
You're being very impatient. Waiting a few days for your mod to be reviewed is normal.
Well, this is for player interaction, not for mods doing things.
Swap node detection? What do you mean by that? Like replacing, say, a plant with another node? What do you expect this mod to do in such a case?
Thanks for the review! What exactly is nerdpoling (is it what I know as "pillaring"?), and what would you suggest to "stop it"? I wrote this as a means of (among other things) slowing down pillaring, since fast pillaring typically requires you to place blocks colliding with you. A block placement quota might additionally be useful to slow down pillaring. An alternative option to consider is something like structural integrity checking, where pillars past a certain height would degrade to piles (blocks would fall left and right).
This is likely to be out of scope.
character_animtries to be as game-agnostic as possible by only expecting a few standard bones the Minetest Game default player model (character.b3d) typically provides: Body, head and right arm. I don't plan to add custom models. I could add support for more advanced model conventions, but that would complicate the code and probably only serve a single game (Mineclone) which provides such a model (and already has its own provisions for animations).You can use
visible_wielditem.item_tweaks.names["default:torch"]to change that. I could add better default settings for MTG items, but I feel that would bloat the scope of this project - there probably are plenty of items in plenty of games that could use special tweaks...Thanks for the report. This was a character_anim bug I never noticed because as soon as
player_apichanges the animation - as soon as you move, punch, rightclick, lay, use a boat, whatever - an animation would have been set; this bug was only noticeable if you actually immediately changed into third-person view before doing anything. The fix was trivial; I just had to preserve the initial animation.Sounds like a Minetest issue with chunkgen and (graphics card / Irrlicht) geometry limits (max vertices / indices / ...)
Minetest Game being bundled by default is an engine issue rather than a game issue. This renders your review irrelevant for the Minetest Game ContentDB package.
Devtest is to be used as a tool, not as a base for modding...
I have recently bumped the modlib dependency to version rolling-100 since it fixes a bug with subfolder media collection. The error message should be telling you:
which is exactly what you have to do: simply update your modlib. rolling-100 is available on CDB.
Please read error messages. Note that this is tagged as a "developer tool", so I don't think it's entirely unreasonable to expect the users to read the error messages.
For the future: Please attach stack traces to bug reports.
This does not implement *nix Glob Patterns, but rather simply uses Lua patterns. Nobody in their right mind would do
rm -rf .*in their terminal - that will not remove all files, but rather only hidden files (files starting with a dot in their name)!The only function provided is not exactly useful; how often do you need to kick multiple players based on a pattern? I could imagine this being useful only in very rare cases where an attacker is dumb enough to make his names follow a pattern. What makes this even more useless is that the Minetest chat features tab completion for playernames.
What I could see being useful: Actual globs, e.g. for file traversal purposes, but as an API rather than user-facing chatcommands.
No, not at all. Devtest is a tool, not a base for modding. You should not base games on devtest (like e.g. runs did with the Samz); games won't want the quickly thrown-together test content devtest provides.
This would completely defeat the purpose of devtest which is to be a minimal testbed. If you want mods, add and enable them. Wrap them up in a modpack if you want to use your usual mod soup.
Usually the best testbed for engine development or if you want to quickly play around with an engine feature.
Also very useful in mod development due to its minimalism, which allows for a very fast loading time and also helps ensure that your mod works even in a minimalist environment without bloaty mods such as
default.Devtest also provides a few introspective facilities (e.g. node editing tools etc.) and example content (nodes, entities etc.) that aid in engine and mod testing.
That said, when you're developing a new game for players, you should under no circumstances base it on
devtest(except if your game is intended to serve as a replacement testbed or perhaps a more specific mod testbed).Ah, so if you just wanted to translate it, why did you review it?
Your mod? You're not supposed to leave reviews on your own mods using alternate accounts…
You could (and should) have just left your personal feelings out of it to keep it professional. Professional reviews also don't "get hate".
How is this relevant for your review?
Would you consider yourself unbiased?
Thanks for your review.
The awesome art is mostly thanks to TEMHOTAOKEAHA and Dragoni, our awesome pixel artists :)
This was planned but the model had to be added last minute and there was no time left to add animations unfortunately. In fact there even is an animated model that just couldn't be added yet.
Agreed. IIRC I had to sort out some tracks due to nonfree (non-commercial) licenses.
Hostile spawning has been limited post-submission.
Bugs
Thanks for your review.
That's mostly thanks to TEMHOTAOKEAHA and Dragoni, our awesome pixel artists :)
There is a sound effect for drilling, but it requires MT 5.7-dev... Should be fine as soon as 5.7 releases though. More sound FX are definitely planned long term.
Hmm indeed, I'll look into this.
Hostile spawning has been limited post-submission.
This definitely is implemented ("beacons"). How many of these (and of which kinds) you manage to obtain determines your ending. Note that the dot on your radar gets larger the closer you get to the beacon on the vertical axis. Perhaps you were at the wrong depth? (It is possible that there are issues with beacon spawning code though; in my tests I have always been able to dig at least one beacon though).
Heh, not quite. You should have gotten the "bad" ending if you just went down immediately; that is, "you find the same fate as the astronauts before you". Speedrunning Down is an "ending" strategy, but not a "winning" one :D
We considered world-aligned textures but preferred mapgen randomization of textures.
Yep, added that last minute and the Minetest player name vs. player ref inconsistency got me :)
Fixed post-submission.
I have fixed mob overpopulation post-submission. Optimizing the mapgen further is hard. I think it is already asymptotically optimal (or close to it), and I haven't been able to go much further on the constant factors using the LuaJIT profiler. In hindsight implementing the custom mapgen probably wasn't the best idea as it took an immense development effort and largely wrecks performance, even after optimization.
The acid sprayer is functional (it requires acid though); it's only the sound playing that's not working (I added that last minute). Fixed on Git (post-submission).
The lag is definitely a major problem - we didn't have enough time to optimize it properly (optimizing the mapgen in particular is very hard). We learned that implementing a fully custom, sophisticated Lua-only mapgen for a game jam game probably isn't the best idea.
I have fixed the mob overpopulation already, it's just post-submission as well. I'll also look into further optimizing stuff.
TL;DR: Not enough time in the game jam timeframe to polish everything (esp. as mapgen dev was very time consuming), but we will get there :)
(accidentally posted under a shared account which obviously may not reflect the views of only a single member)
Nothing more to this game. About 30 lines of Lua:
and
which mostly are taken verbatim from the Void Game (and which are just boring definitions anyways). No game logic behind it.