Yes, animating is difficult and when you finally understand it it is only very slow. That representation took me about 10 minutes but because I already had the initial drawing.
(I feel that I explain myself better in drawings.)
It's the idea I told you about, I just didn't have time to draw it digitally. Basically, every time you level up a statistic by 10, there would be an image as a reward that tells a little erotic story during the mushroom harvesting journey. The idea is more extensive, which is why I was asking if you had thought of an ending for the game.
I really like the idea a lot, although I鈥檓 not sure how to approach it. Maybe the image below the purchase button could represent the multiplier, or it could work more like an unlockable achievement, where every x5 or x10 increase unlocks a new image.
The problem with the first option is that I have limited space for drawing, but it would be more dynamic and visually appealing, and not as plain as it is now. On the other hand, the side section would stay the same, and you鈥檇 unlock full-screen illustrations…
I need to think it through, but I really liked the idea, I definitely have to implement it somehow.
At the beginning of the game, everything will be normal, with the same cutscenes in the character box, until you buy the first upgrade at level 10. At that moment, the first image related to the improved statistic will appear.
(Optional - if you click on it, the game pauses and shows the image in full size until you click again, and the game will resume.)
The game will continue as always until reaching level 50, where the last erotic scene reward will appear, and an achievement related to the statistic will be awarded. This last image, being the final one, may be something more special and detailed. If you go to achievements, a (new) tag will appear next to the logo. When clicked, it shows a gallery of images for the achiev
creo que es una idea que pude ayudarlo a avanzar con el juego, agrgando mas intriga a los jugadores nuevos por ver que tipo de imajen seguira, y supongo que sera mas facil que programar todo el dia, por eso intento dejarlo claro con dibujos aun que los realizo rapido por falta de tiempo. una de las cosas mas importantes de este tipo de juegos es el porno y a este juego aun le falta porno prinsipal mente . aun falta ajustes en lo tecnico pero no puede salir una 1.0 sin mas porno .
claro hablo desde pocicion de jugador de videojuegos y no desde desarroyo por que no e programado nada en mi vida que no sea el temporisador del microndas :v
I'm really loving all the drawings and ideas to represent the different levels, and I think something very interesting can come out of this. But I want to shape it a bit first, give it some structure so that it feels well integrated, and that鈥檚 what I鈥檝e been thinking about since yesterday. But I assure you, I鈥檓 definitely going to implement it in some way.
Me est谩n encantando todos los dibujos e ideas para representar los distintos niveles, y creo que puede salir algo muy interesante de aqu铆 pero quiero darle un poco de forma, estructurarlo un poco primero para que se sienta bien integrado y eso es lo que llevo pensando desde ayer pero te aseguro que de alguna forma lo voy a implementar
So I extracted the Windows build with gdsdecomp and used it to make a Linux executable, being sure to untick "Export with Debug". You can extract this to the same folder as the base game and play as long as the name matches the .pck file.
This alone did not fix the lag, but now I can open the project in Godot and view the colliders via the debug settings.

This revealed that instead of the player having one magnet collider, every collectable has its own magnet colliders.

Every collider is an object, and every object inherits all the features (and overhead) of its parent classes. Much more all those colliders are also tracking everything they collide with (like other magnets colliders) even if they don't do anything with the data. No wonder why there's so much lag. If you move the magnet code to the player, you can get rid of the extra area 2D nodes and reduce the number of collisions. You don't need CharacterBody2d since they carry tons of functions intended for platformer games. move_and_slide() for example checks for friction and sliding between colliding objects. Complete overkill. The simpler move_toward() which comes with the Area2D node is plenty for this case.
Sorry if I'm mean here. Insomnia makes me cranky.
On a related note, I've fiddled with a few things, like making mimics rewards scale with your multiplier.

Above uses 1000 * ((Multi + 5)/5) where Multi = 30. At higher multipliers the text spills out and overlaps in ugly ways. This could potentially be an upgrade, though I'm not sure if to have this higher or lower than normal chests.
I also have an idea for a slime girl enemy that still grants semen if you fail, but success gives a higher amount plus reduces you multiplier decay for a few seconds (because her slime lubricates you.)
Wow, you've been working on a lot of things lately. The first thing I realize is that I need to add some security to my code so it's not so easy to manipulate. Don鈥檛 get me wrong—I鈥檓 not upset that you did it, especially since it was meant to help, but it鈥檚 definitely something I need to keep in mind for the future.
The translation isn't very accurate, especially when it comes to more technical stuff, but if I understood correctly, you're suggesting that I stop using a CharacterBody2D and instead use an Area2D as the parent node to optimize things?
As for Mimi giving more points based on luck, that鈥檚 actually an idea I鈥檝e had for a while but haven鈥檛 implemented yet. Regarding the slime girl, the original idea was that she'd move from one side of the map to the other, absorbing objects, and if you caught her, you鈥檇 earn what she had collected multiplied, and if you missed, you鈥檇 lose some coins. That said, I really like the idea that whether you win or lose, since she's a slime, she could "lubricate" you and make it easier to raise the multiplier for a few seconds.