Haha, I get what you mean. The more I played with it, the more I kept thinking "This feels rewarding to me because I know how it works but would probably frustrate anyone looking for a game".
Thanks for trying it out anyway :-)
That comment about the default number of iterations being too large for a large number of systems should probably be unrolled by default ;-)
Aside from that I enjoyed playing around with the various examples. I never found an excuse to dive deeper into L-systems than the superficial rewriting-grammar analogy but seeing how much parameters and control you can encode into those rules is really inspiring!
I played around for a bit trying to recreate the cool looking effects you show off in your screenshots and it took me a few minutes to notice that you can use the arrow keys to control where the camera is looking at; combined with the "peintre" command this instantly made the experience better, I liked it a lot!
I liked having the parameters on both sides of the screen, it makes it easy to experiment and play with the generator! As I remember from when I tried a similar project, it seems like the more rocks you have the easiest it is for our eyes and brain to see the path to the exit...
I would love to have more details about how you generate those levels :-)
I like how you can see the whole city building itself and rising in front of you, and of course the end result is stunning :-o
1400+ sprites is a lot (even when accounting for 1-bit depth and multiple frames per building block), but the variety it offers really shows, the buildings still look organic and quite different from each others. How long did it took you to draw all of them?
Despite the numerous options to adjust I think my favourite results were the more abstract ones I got by reducing all shapes to 1 and the number of colours to 2. It got me something that looks like a lion's head (on the right) and a minotaur that could come from a Rayman game. Pretty fun to play with!
This was a lot of fun to play with, having controls over so many parameters is always a joy :-)
I thin I understand most of the sliders pretty good, except for the ones that define the proportions of each type of terrain tiles. Is it only based on the height of the tile (e.g. a lower tile will be assigned the sand type before a higher one) ?
Je comprends bien ce que tu me décris, c’était la première approche que j'ai tentée :-) J'avais deux problèmes majeurs avec les résultats qu'elle me donnait :
Le deuxième point était le plus important pour moi, et sans faire de raisonnements et preuves mathématiques sur mon processus de construction je ne me voyais pas pouvoir créer cette garantie de manière constructive. Je suis donc passé par la solution de secours du bidouillage algorithmique qui consiste à faire un parcours en largeur de la carte à chaque modification pour s'assurer de ne pas avoir réduit la longueur de la solution sans le vouloir.
Vu que ça me donnait facilement accès à tous les chemins existant depuis un point de la carte, j'ai aussi pu me débarrasser de la marche aléatoire et me contenter de placer des rochers au hasard de manière uniforme, ce qui a fortement augmenter la probabilité d'utiliser toute la map ou presque. Une bonne façon de s'en assurer pourrait être de considérer un chemin en plusieurs étapes plutôt qu'une solution en un seul segment, mais le coût en calcul et complexité de code dépasse surement le temps que j'avais à consacrer à ce problème pendant la Procjam...
(et pas de raycasting non plus dans ma première approche parce que si c'est un outil utile quand on vit dans un monde continu, moi je travaillais sur une grille discrète qui est facile à explorer de manière exhaustive)
Content que ça ait plu :-) Je ne suis pas assez bon en pixel art pour sortir des designs de ma tête, donc j'ai effectivement gardé la map de la route de glace de Crystal ouverte pour me servir d'inspiration.
Oui, tous les niveaux sont générés durant le fondu au noir qui les précède. Je viens de rajouter une explication du fonctionnement dans la description ; mais en quelques mots l'algorithme place des rochers au hasard, calcule le chemin le plus long et essaye d'ajouter ou de retirer des obstacles tant que ça rallonge la solution la plus courte.
(donc pas de raycasting, mais beaucoup de pathfinding pour essayer de s'assurer un niveau jouable et intéressant)
The first time I got stuck just before the top because no green block generated on the top two layer, leaving me at the bottom of two-units-deep holes I could not jump out of. Other than that, it worked very well for a 3D maze, the size was just enough to get lost a little without it becoming too frustrating. Great job!
First, thanks for playing and commenting! Separating buttons was mandatory to execute some of the puzzle I had in mind when designing them, however I did not manage to fit them into a single screen yet...
On another note, I am interested in getting some more feedback about this rendering error, since a friend of mine reported the same issue but I was not able to reproduce it on my computer. Can you read the text on the very first level ? For time constraint reasons text and background are displayed with the same code, so an answer or even a screenshot could go a long way to help me fix the issue.
First generation Surface Pro (https://en.wikipedia.org/wiki/Surface_Pro). Good luck with your engine !
The game was a fun to play and very polished experienced, displaying the trajectory was a good idea to make the game less frustrating and more about reflexion than execution. My favourite puzzle was the symmetric one not long after the box return, that was great. Transporting those cubes and solving puzzle with them made me think of Portal...
The game is simple but really fun to play once you find a good strategy and try to stick to it! I got to the high 47000 with two bodies, as this is the setting where I felt I could best control the other bodies' trajectory. Is it possible to avoid the collision right after the beginning though ? I could never manage to do it ...