Please stop submitting your game to unrelated jams. Also, please learn how to make the resolution actually fit the context. Asking the player to use fullscreen is a cop-out.
Colin EUMP
Creator of
Recent community posts
I just got around to trying this. Let me just go over my experience so you can understand why I'm probably not going to play this again. The opening narration was fine, but once out in the mine, the only indication I saw of an objective was the chest. I decided to follow the railroad after seeing that the nearby sign had no point to it, and that got me into battle with the first slime.
There were 4 of them. I didn't get the tutorial message about weaknesses until after I'd split one, at which point I found out that they deal less damage that way. That meant that the information I had available was that I might be able to kill them faster if I tested for their weakness, but my best hope of minimizing damage in this 1v4 fight was to split all of them. Put another way, the best strat that I knew was definitely available for the very first fight in the game was to make the fight take a really long time. I also still lost 2/3 of the maximum hp in the process for only a small portion of exp.
After that I continued down the railroad and tried to avoid the next slime, only for Shiori's inner monologue to hit and prevent any movement. At that point I then found the slime's ice weakness, but I was still annoyed at having to fight it at all.
From there I thought maybe I should check a side route for chests, and then got caught by a rat that I literally couldn't see due to the lack of color contrast. I decided to use lightning because rats and slimes are very different, but the rat turned into a basty, then cast sleep with no message indicating how sleep works nor any indication of which monster's weakness would have applied during that attack.
From there, I tried the two spells on it and found that neither were its weakness, before the other 3 rats got enough crits for a game over. Since it hadn't occurred to me that saving would be needed that early, I started a new game. I then found out that the opening dialogue has very frequent hard pauses that prevent skipping it. That's the point where I stop playing.
This is pretty enjoyable over all. However, I ran into two problem: 1. on the first run I reach Shiori with 1 sanity, and got the game over message without any indication of what took the last point of sanity. 2. The "test of mind" riddle seems to have completely mysterious expectations on how the answer is supposed to be formed, and the two tips only made it more unclear. Also, I don't get why the answer wouldn't just be "nothing", or perhaps leaving the prompt blank.
So, for the question 4x = (16 ÷ (30 + 2)), the correct answer as written based on the normal usage of those symbols in the US is 1/8 (AKA 0.125). I've heard of the "÷" being used for a different meaning in other countries, but I'm not sure what usage would result in the answer that the game just told me is correct. For example, if it meant the left number on the bottom, that would give the answer 1/2. I was able to answer correctly, but only by trying to think of how someone might screw up that problem.
By any chance, did you mean to put x/4 = (16 ÷ (30 + 2)?
Oh, huh. I wouldn't have expected the engine version to matter. Those errors are from the files not being the right version. Well, depending on what features Zephyr's actually uses, you might be able to instead replace the folders rather than merge. (as in getting rid of the renpy and lib folders that it came with the download and just using the ones from a different game)
Sorry if I caused you to waste effort, by the way. The reason I was confident in this solution is because I've done it with 3 separate games with no problems.
Right, I forgot that Windows defaults hide that kind of thing. You won't see the ".exe" unless you have file extensions visible. In file explorer, you should be able to see info on each file. If not, there's an icon in the bottom right of file explorer that lets you switch to information display. One of the columns shows "Type". Files with the extensions ".exe" will show "Application". What you need to do to have an executable is copy the "Application" type file from one of the other games, paste it into the folder for the linux version, then rename it to match the file that's already there of type "SH file".
Also, in case I wasn't clear enough before, I'll be more precise about the folders to copy. The linux version should already have "lib" and "renpy" folders. To get the windows engine, you copy "lib" and "renpy" folders from another game into the same spot. When Windows then asks, you want to merge the folders and overwrite all.
I just got an error when trying to load a chapter 3 save (more relevantly, one from last september). I'm guessing it's the one you mentioned in the development log. Out of curiosity, since I occasionally like messing with renpy stuff, I thought I'd look at the traceback and see if I could figure out the error. To summarize, it looks like you reverted to Ren'Py version 7, but the chapter 3 saves expect version 8.
Now, I just tried copying version 8 into the game folder (taken from another game since the engine is just copy-pasted when building) to see if that works. It does. However, without knowing why the version was reverted, I'm hesitant about this solution. Is there something about version 8 that wasn't working?
If not, then the solution that players can do requires only 2 steps: 1. copy and replace the "lib" and "renpy" folders from a game using version 8, then 2. copy the other game's executable and rename it to match this game.
"The size of a square should equal the size of the wall segments it is connected to. Think of a grid square as a cube with ground, four walls and a ceiling." So, I get that the movement needs to be along the grid and walls should match. However, the last time I made a first person maze in a game, I included walls that only existed between grid spaces. This wouldn't violate the rules as stated, but it also would mean having to have walls with thickness lying on the grid lines themselves to make them not look weird, which seems like a grey area. Also, the actual method I used was having a different internal representation of the grid in memory than shown on screen, with the internal version not having the same meaning for movement (non-existent grid spaces that would be skipped over).
Are either thin walls between grid spaces or the use of non-existent rows and columns in the internal representation of maps against the rules?
So, in case anyone else wants a windows version of this game for any future versions of the game or whatever, I thought I'd just point out that this thread is entirely overthinking this. Ren'py is an interpreter engine. The entirety of the actual game is in the "game" folder. There's no "compiling" or "building" actually being done when it creates the distributions. All it does is copy the needed files for whichever platforms are requested then copy the game contents.
As such, if you ever see a creator using Ren'py who doesn't like one of the common PC platforms, all you need to do is copy the platform stuff from another game made in Ren'py. For windows, that would be the "lib" folder, the "renpy" folder, and the ".exe" file (which you can rename if you want). I suspect mac would need a bit of editing to the file for telling the OS about the game, but otherwise be the same.
Oops...I went back and checked again. It turns out the smudges on my monitor were the problem. Sorry for the false alarm.
To explain, my method of solving this category of puzzle is to copy it into notepad, invert the squares that are red on the solution, then solve for the puzzle with equivalent inputs that would instead turn the translated puzzle all green. If translating to the all-green version doesn't make the solution obvious, then I check for minimum required inputs (as in, pick a corner that isn't green and look at the 4 inputs that can make it green, then recurse). In this case, that reduces the number of variations to look at down to 16, which I can easily fit on my monitor. However, all of the above is foiled if the 0's and 1's I'm using in notepad look wrong.
Your minigame gives prompts that seem obviously impossible and, on further analysis, can be easily proven to be impossible. I can't tell if that was intentional, especially given that it's still possible to beat the high score in only a couple tries. If it wasn't, I would recommend designing puzzle mini-games in a way so that the prompts are generated by working backwards from the solution, rather than hardcoded them.
I did. I'm not sure how I would've run it otherwise. Out of curiosity I tried it again. This time it got through the unity logo and then showed a block of text, an x in the top left corner and a "play game" button, but then locked up and became unresponsive when I tried to click the button. I tried yet again, and the same thing happened.
Having a sniper without any indication of such feels unfair, as does the enemies not taking damage when getting hit by a spike box. It would also be better if the die hitting the green box had an indication that it worked.
Other than that, the die being a die seems unimportant. The player can just push it instead.
The tasks were hard to read both because the text is small and because they ended up formatted wrong. In case it matters, my screen resolution is 1920x1080.
It's generally a good idea to put in an in-game way to quit at all times, since not all players know about alt-f4 and it doesn't always work anyway.
I think you need to plan out your visuals better. I couldn't tell at all what was going on, mostly because I couldn't tell when enemies were dead, KO'd or whatever. The results of each die roll was a total mystery to me as well.
The menu looked like it had automatically contracted to fit my screen, but in a way that made everything unreadable. My screen is 1920x1080. I think it'd be a good idea to test your game at different window sizes, if Godot makes that easy enough (I haven't used it myself).
Oh, and I've never seen d4's that actually match the values with the faces, since that makes the value that was actually rolled unreadable. As such, I wouldn't recommend d4's for this concept.
It seems to run really slowly in a browser, especially given how simple the graphics are.
I feel like the only strategy is realizing that 2 of the options are pointless. I guess it is at least a functional game with decent presentation though. My main complaint would be how long it takes to finish given how little the player actually has to do.
The auto-turns item doesn't seem worth it, given that it doesn't buy more in preparation for running out. Other than that, the only things that stand out to me are minor visual things. The button text for "buyTurns" isn't formatted the same way as everything else, which looks like a mistake. A lot of the text on buttons goes right up to the borders of the text, which makes them look cramped. Most pressingly, the timer not formatting the time correctly is a very common issue I see in a lot of small games that makes it harder to read.
In case it comes up again, I just did a quick check of the String class for Godot, and the pad_zeros() function seems like your best option for timer formatting.
I'm not fond of clickers myself, but overall this does at least seem like it's one of the more finished entries. I also like that it has and ending.
The game seems to run very slowly for me, even offline. I'm using a windows 10 laptop with "AMD Ryzen 3 3250U with Radeon Graphics 2.60 GHz" according to the settings and 5.95 "usable" RAM, in case that's helpful at all.
The music sounds like a much more chill version of "Fortunate Son", which I'm guessing is on purpose, so good job making it recognizable. The visuals also do a great job at being exactly what would make sense. I couldn't tell what type of monster figures were attacking though. Still, this is probably the most visually clear game I've played so far in this jam.
For gameplay, it is a functional top-down shooter, and I was able to guess correctly what I could shoot over. I was a bit surprised that I could move off the gridded area though. Mainly, I don't get when the enemies are actually attacking. I had to sit still for quite a while to even find out that the game has damage implemented. At the same time, I doubt this game would be any fun even if the enemy attacks were more threatening, due to how they spawn in. Having them spawn right next to the player while the camera isn't centered on the player just makes everything feel awkward. Overall, the enemy behaviors and spawn mechanics feel both unjustified in context and kinda pointless. It really needs some hint as to why Army Man is being attacked by monsters and why the monsters spawn in any particular spot.
You've got a good base, but it seems like it would've needed either a lot more time or a lot more focus to actually make this work.
The collision box for the spikes is too big. As a result the cats get hit long before it looks like they should. Having the bottom cat be able to move while the die is rolling makes it feel like guesswork where the bottom cat should start. Also, having one of the cats barely be able to make even a small jump is just annoying to deal with.
I got through a handful of the sections, then stopped because it felt like they were just repeating with no difficulty curve at all.
There's several places where I couldn't tell if there was ground or a gap due to the colors. Also, I couldn't tell well the die is on the ground during normal movement, which made jumping really awkward. I'm not sure how the player is supposed handle the case where the die is stuck on the even side given the lack of control over how the die rolls.