Our ARPG Dungeon Boy: a game of gold and llamaboys, is finished and up for Mac, Linux, and Windows! It was a fun journey, and although there are some silly run animations and odd sword-swings, I'm proud of what we've made. For a small team of three, it's a great game, it feels finished (if not polished), and it's fun. Try it here: https://ldjam.com/events/ludum-dare/40/$56107
I came into this jam with high hopes, I felt accomplished enough to do something good. Then, the theme hit. What kind of a theme was that!? Two hours were wasted trying to think of something, then I just decided "Farming". What doesn't go with farming but still kind of does? Action! And Cornivore was born, kind of. I still had no idea what I was making, just that it had homicidal fruits, and you planted them.
I made models, I made them work, and I made an inventory system. It's now the end of day 1.5 and I have a bad farming sim and no player model. Also no idea what the gameplay is actually going to be like. Day 2(ish), I NEED A PLAYER MODEL. Take care of that quick (but not because the face is terrible) and make some animations that are slightly better than last time. Wire him up, it start to feel like a game. Model some more stuff to flesh it out... and it's the end of day two. No music, the plants don't attack, and nothing really happens.
THE FINAL DAY. Start out, get plants and worms attacking because I don't have a game unless that happens. Check. Music time! Nothing fancy, but I get it done in an hour. It sounds kind of cool. That is a win for me. Now I make machines. They work. Good. Two hours from submission, main menu time! Finally, one thing that kind of went smoothly (except unity UI sucking, but that's to be expected). One hour remains, but the game still feels empty. HATS. I model a hat. I make a machine to give you the hat. Hats are done. Time to submit. Oops, no death screen. You can get back to the main menu and restart, so no big deal.
All in all, a good shot at it. If I hadn't tried to make a robust inventory system and all, I probably could've made it better. I only say that because I didn't enjoy making the system and far more enjoyed modeling evil plants.
Here's a link if you'd like to play: https://ldjam.com/events/ludum-dare/41/cornivore
This theme is actually really good for me because I'm stuck in the loop of doing one ludum dare then missing the next two so I think I'll be in
I have finally made something I'm comfortable calling a game in one of these alone! Not for lack of trying either, Cornivore and Dungeon boy were something, a lot of work went into them. They just... missed the "game" part, they were a lot of parts that could have been something fun.
This time I started with something game-like on the first day and refined it. Slowly added to it, reached my "feature complete" stage and even got some bonus content in! Keeping it simple and understanding my limits on building content and creating assets finally let me make a game! More post-mortem later, but as a simple post-jam post this will do.
Over Unity - A Puzzle Game is a 3D puzzle game built around creating perpetual motion machines powering "wheels", using portals, velocity addition arrows, gravity changer arrows, and little wooden deflectors! I'm going to be talking through my Ludum dare, initial ideas on what I wanted to do, the scope I grew into over the first day, troubles through day 2, and the mad dash that day 3 always is! Here's the game's page: https://ldjam.com/events/ludum-dare/47/over-unity-a-puzzle-game
Again, here's the link to the game: https://ldjam.com/events/ludum-dare/47/over-unity-a-puzzle-game
As soon as I saw the theme I thought death loop, as I figured everyone else would, so I discarded that. I wanted something different that would fit the theme. Pretty soon, getting an object stuck in a loop came to mind. From that it wasn't much a jump to perpetual motion machines - though I guess it could have gone the other way. I wanted to use a grid to make the puzzles stable/safe, with custom "physics". I hadn't made a puzzle game before so I was concerned about things being ever-so-slightly misaligned if it weren't nicely grid based. I'm kind of questioning this decision now, but at the time it made sense. The original ideas about what "Tiles" there would be were a bit more vague/nebulous and larger in scale. I initially envisioned them as having any size (multiple tiles wide), and specific input/output directions and tiles.
Initially I went into full "systems mode", putting together the grid system and all of the little things that made it tick. I did this before I'd really fully conceptualized what tiles would be, so if you look in the code now, you'll find some unused things that just fell out of scope as I worked. Once I wanted to get in and test the system in-game, I decided to hop over and create some models.
I used blender to model all of the objects in game. I'm not much of a 3D artist, so I kept everything very wieldy and low-poly. I still had the game mis-scoped at this point, so I made a few assets that never got used (including a 2x1x3 conveyor belt!). I got the environmental assets and the portal and wheel tiles done, so I moved back to the game
There were obvious bugs, as most people who've made games would expect. They were easy to fix. I noticed I messed up the normals on the conveyor belt, so it didn't get put in. This was the first step toward my eventual scope-thinning. The simple portal and wheel formed the basis of it. Simple 1-tile things that changed one thing about the ball. Following this I decided I wanted to add velocity and gravity effectors, as well as deflectors. I wanted at least 10 puzzle rooms, and a split path in rooms you could do. I ended the first day at this point, but overall I'd say it went well.
On day two, I created the rest of the tiles and threw them in. Bugs galore! I didn't really think about all of the edge cases with my weird grid-based system, so a lot of this day was spent fixing them. The morning was the new tiles. The afternoon was a cycle of create room -> notice bugs -> fix bugs -> fix room puzzle -> create next room. I noticed a fairly big bug with the code to move the ball between two locations, to check every tile in between for interactions, so that was quite the thing to fix. I was using a 3D breshenham line-drawing algorithm found online, but I realized it was only correct for one octant of 3D space. I remembered I'd written a line-drawing algorithm for minecraft world generation years prior, so I dug that up and ported it from java to C#. It worked fantastically, but it was a really silly waste of valuable time. Additionally, I added the tile indicator showing which tile you were interacting with at the moment. It was a really simple implementation of it, but it improved playability massively.
Finally, after a bunch of this, at 3 AM on Sunday I made unity crash with the SECOND occurrence of a stack overflow bug. The first didn't scare me enough I guess. I had around 7 rooms done at this point. I hadn't saved the scene in over 24 hours (silly me), and I lost 5 puzzles. Luckily, most of what I did in that time was fix bugs, not create puzzles. Additionally, I remembered most of what those puzzles were, so it only took me an hour to get those recreated, and by 6AM, I had 10 puzzles ready, my goal. The next day would hold mostly aesthetic stuff.
Goals on day three included creation of a UI, SFX, music, and a real model for the player (before I'd been using the unity capsule). My girlfriend graciously made the UI assets, and picked the font. The UI went together pretty quickly. Hint text went on most levels (though I regret the color of the text for it). After all of that, I turned toward music. I'd been having a music-writing block for a while, but I breezed through the creation of the background song for the game. It only took a little more than an hour, and mood-wise and musically I'm pretty happy with it. It seems like the rest of the people who've played the game have enjoyed it as well, so I'm pretty happy with myself for that. The SFX was kind of sketchy for me - I've never really made SFX myself before. I did what I could, and it came out usable, but not great. Anyway, it was all implemented. After that, I was done... which was weird. I had nothing else I needed to add, so I could just use it to add more content. In 2 hours I'd added 5 more rooms to the end. These puzzles tended to be pretty hard, and I'm sure very few Ludum Dare'ers will get to them, but I'm happy I added them. It was a good exercise in puzzle creation. At the very end I realized a few mistakes in collider placement on some rooms on my test playthrough, so the last 30 minutes before time ended was frantically fixing those. I fixed it with 10 minutes to spare, built, and uploaded!
I really feel like I hit the scope I'd had in my game since early day two, was satisfied with the music, and the art. Even though it wasn't great, at least it was a particular, consistent style that I liked. The regrets are mostly in the execution. I realized early on that it was difficult to tell the placement of things in 3D space with a static camera. I kept feeling like I should do something about that, but I'd never gotten around to it, or even figuring out what it'd look like. As well, I probably should have been a lot more explicit with hints, it seems people have trouble interpreting what the player should be doing for certain puzzles, what the goal is and how to get to it.
With my progression system (opening doors), I tried to make it such that you had to continuously power the machine to open the door enough to progress. My implementation left a lot to be desired. If you squeezed through a door in a small time-frame, you could lock yourself our of the room before, a puzzle that you needed to complete to progress. I could probably consider this a bug and fix it, but at some point it kind of feels like fundamentally changing how the game works, so I won't do it for the judged version.
I probably should have also made better tutorial rooms in general. Some of the objects used to affect the ball are non-obvious until they're seen in use, even with the little text blurb I make about them. The behaviour of the ball when in free motion is non-trivial, with it being able to move at any angle. This is kind of at odds with the grid mechanic, and my graphical presentation didn't help.
The graphical presentation of the ball left a lot to be desired. Originally I just had the ball popping between locations, but that wasn't clear enough, so I lerped it between them. This was "good enough", and I thought eventually I might do something better. I got caught up in a lot of other things, and that never happened. Given the time now I'd like to properly integrate the ball's velocity and acceleration to give a smoother, more predictable appearance. You might not notice now, but the entire ball-system runs on a twice-per second tick. Living in this sort of half-space between that and smooth motion doesn't exactly work. Additionally, the ball just goes to the center of every tile. That's not great, and certain tiles would benefit from having a more particular animation. Given time I would have liked to add this.
Over this long-winded post-mortem, I might sound a bit disappointed in the game. I guess that's the nature of the format. This is actually my most successful Ludum Dare not in a large team. I made a game that's actually a... game. It has goals and satisfying gameplay, and things to do. My previous entries had one, or even none of those. I'm very happy with what I produced and I feel satisfied with it being done, unable to change it for the purposes of this jam.
I finished the game! Near the original feature set too. The biggest things I didn't get to were mostly aesthetic - I didn't make additional tilemaps nor pretty up the main one, and I didn't procedurally generate enemy sprites. That said, this is absolutely my proudest LD yet. I made a procedurally generated ARPG with a super expressive effect system that allows the player and enemies alike to powerup and have a dynamic experience. A post-mortem to come later, when I have more sleep. Should not have pushed for features right until the end - but hey - the lighting's nice!
Cave Girl - SUPER AQUA GOTH is a procedurally generated ARPG where the player and the enemies use the same powerups! It went... okay. I think it's certainly my most interesting and most feature-complete entry yet, though that doesn't mean it's at all perfect. In fact, the first few reviews I got showed me some of the fairly obvious issues the game has. We're going to go through the development, and then get to a few regrets I have, and where Cave Girl will go from here.
I started the jam with the theme, Deeper and Deeper, reminding me of an entry I made a few years ago, Dungeon Boy, about delving deeper and deeper in a dungeon. It was pretty bad, so I thought I'd use this opportunity to make something better in the same sort of ARPG vein. I started with some silly messy notes on what I wanted to make, which I'll show here, in the form they were left in.
Yeah... not much. I had more an idea in my head, though I think writing more down at this point would have been beneficial. The basic idea in my head was - Procedurally Generated world - Maybe procedurally generated enemies, at least procedurally generated behaviours - Powerups that can affect both the player and the enemy, that interact with eachother - Projectile-based effects that propagate down with the projectile - Pixel art tiles - A sword and bow player (initially the bow was going to be a powerup) - Floor hazards (this is kinda not coherent with the rest of the design I think)
And I think you can see most of this in the final game, though the way it got there was kind of bumpy. I started with the proc gen world actually, having a lot of experience with proc gen. It's a fairly simple system, I start with three different "terrain" types, defined by each - Regular Perlin, 4 octaves - Ridged Perlin, 4 octaves - An average of a ridged and billowed generator
(For a bit of background. Perlin is a coherent noise generation algorithm, it makes pretty uniform high and low values. Ridged noise is perlin squared, and looks like wavey ridges, and billowed noise the absolute value of perlin, and looks - well - poofy)
I blended these together and it looked pretty good. I added a kind of circular filter to make the caves not go to the edge, which, again, is something I've got a good bit of experience with. I want to stress in this section that the kind of proc gen I did was really simple, look in my code! You just need to know your tools. That, and getting the player moving was most of the first night.
Starting saturday, I wanted to get the player totally set up and enemies basically in. At this point the game still had no art, but that was fine. Getting the bow and sword working were fairly simple, and I added a circle to treat as an enemy. The enemy design was much like the eventual powerup design, where the enemy was really a dumb holder, and it had a bunch of behaviours that could be asked how they wanted to move, and were states in themselves, with transitions between behaviours defined in them. It was simple, but effective. There's only a few basic behaviours in the game which work fairly well, but don't quite work design-wise. The behaviours basically are: random walk, chase, circle, attack, and shoot projectiles. At the beginning, the projectile behaviour wasn't implemented.
While this produces kind of fun looking behaviour, it doesn't quite produce fun gameplay. Enemies never stay still, and the basic 4-way attack I implemented means it's really hard to hit circling enemies. I should've changed the attack style (which I'll get into later), and I really should've considered more the interaction between the player's abilities and the enemies behaviours. Anyway - the enemy worked, so I went on to the next step, art!
I'm pretty happy with how the art turned out on a basic level, but it hides a few issues. As I've said in comments on my game, I made the palette first. This was a mistake. I didn't sufficiently consider the range of colors I'd need to make a game that's clearly readable. The things that hurt you, and places you could walk, and the collision, wasn't sufficiently distinguished. When I get to a post-jam version I'm going to make the hurty things a very different color. Stylistically though, I'm happy.
The player art was really impromptu. I went in with no idea what the player nor the theming would be, but I started sketch a blue creature, that turned into a girl, and super aqua girl was born! An hour later, and super aqua girl was animated and ready to use, along with the bow and sword.
I implemented the tile art with unity's rule tiles, which I actually hadn't used before despite making a tile-based game at the moment, they're really pretty great, full marks. I had some problems with just not having created some edge case tiles, so there's a sneaky thing I did in generation to get rid of the artifacts - tiles only generate in 2x2 chunks! If it works and it's silly, it's not silly! I also got the player art in and she looked really good, though the sword felt kind of short. That was about all I got done on day two, and I was feeling good.
At the start of day three I was realizing I'd made something game-adjacent, but not quite a game. At this point I frantically wired up the progression down. That was more of a game, so I went on to the powerups. As I said before, the powerup system was thought of early and a bit of groundwork was already laid, so putting it together really wasn't too bad. In making the enemy I made "touch damage" a powerup - shown in game now as thorns. I followed that with fire, that made me iron out some issues with the system, then moved onto reflect, and split, and various projectile spawners, explosion spawners, range up, etc. Development of these was kind of push and pull, though once I got into a rhythm it worked well. The biggest regret here is actually how ad-hoc I applied fixes. For example, I noticed some issues early on where certain powerups would propagate too far down a projectile chain, so I added band-aids to fix that... which had to get applied to other projectile spawners... and so on. I wish I centralized that system so it was easier to fix. As an example of what kind of trouble this got me into, late in development I realized I was a bit too harsh with having your own projectiles hit you, so I tried to fix it. Certain things got by, like fire, because it was so ad-hoc. Probably the biggest issue with the powerup system overall.
At this point though, I still only had one enemy, so I hurriedly made five more! These were rather simple graphically, only a few had animations, but I liked the art. With the behaviour system I made before, putting them in game was quite simple. I just added a couple of projectile-based behaviours and assigned them to the enemies and it worked great - so win for that system.
I also added health and bomb pickups at this point, which I think were a good decision. Anyway, one more day and I just had UI and Music I HAD to do, not too bad.
I started the day with the music, which again, went pretty well. I find for me it's a lot easier to write music when I'm under pressure, so the song took about an hour and a half. It's terribly mixed, but I think it's interesting and fun so for a jam game, good enough. I decided to use sfxr for the sounds, which I'd come to regret a bit with a few comments on my game. I didn't really give the sounds much care, and I didn't give a way to turn them off, so the sound design gets a bit grating sometimes. I wish I gave them a bit more time. Anyway, I got those all in and still had quite a bit of time.
For the UI, I made a start screen and a "falling" screen, which turned out kind of okay. The falling screen was fun. I also chose a font that looked a bit more fitting and threw those in. Really simple, missing sound sliders, but it worked. I then added a bit of variation in world-generation and you went deeper, which was pretty simple with my generation system. Just animation curves tied to certain perlin parameters. I also made weighted randoms for the enemy and powerup and enemy powerup spawning, which was also pretty quick. Finally, I added the moisture system. Probably the least well-tuned system, the water jugs being super rare, though I thought it added a nice urgency to the game that didn't exist before.
With about 2 hours left, I added the lighting system. It's pretty fun, everything with a light draws to a separate render texture before the screen is rendered, with a colored light circle. There's a post processor that then uses that texture to shade the screen. Less than an hour! At this point I started the bugfixing and the final builds. It did not go well.
There were a few simple bugs that were no big deal, but there was also a unity web player bug. I pushed a development build to Itch.IO to get the game submitted, but getting to the bottom of this went beyond the end of the jam. Unity fails to set a flag in its web asm compiler that makes sure weird float rounding doesn't cause divide by zero issues, but it doesn't tell you it does this. About half an hour after the submission hour, I finally got the bug fixed and uploaded an absolutely final version, phew!
The biggest biggest biggest thing is the player's aiming mechanics. I went with 4-directional aiming to make it simple to use controller or keyboard or mouse originally, but I didn't realize how much better the gameplay would be with mouse aim. Every commenter has pointed this out and they're absolutely right. It's really important to get multiple sets of eyes on your game pre-release.
Another thing I'd want to add are tooltips for the powerups. Me and my girlfriend, the sole tester, both knew all about the powerups, but the player didn't. I think tooltips would have helped a lot.
The palette was kinda weird.
I started with the idea that a bit of a grungy game where things were kind of obscure would be fun, but I think making the things that hurt you stand our a bit more would also have been good.
Next, I think a bit better handling of projectiles would have been good. More consistent mechanics on what damages you, and probably some distinguishing factor between your own and the enemy's projectiles.
Finally, I think intentionally setting up the first level or two as "tutorial" levels would have massively helped in getting people into the game. I see a lot of people who only got down three or four levels in my game and I think with a bit of help at the beginning it'd be better.
While many of these are rather small and could have been implemented given the planning, without having another person or two telling me these are issues they were hard to see.
I'm going to fix the "regret" issues and polish a few of the mechanics in the game, and add a few more enemies. Beyond there, I don't know. I'm interested in turning it into a more full game, but I don't know what the additional content would be. I want to make more world generators definitely, and perhaps go into the more proc-gen enemies like I wanted, but beyond that, maybe shop levels? Give me your thoughts! Again, play the game here at Cave Girl - SUPER AQUA GOTH
Play it here: https://ldjam.com/events/ludum-dare/49/sky-burns-red
Sky Burns Red is a rhythm-balancing game. It's developed in Unity3D, and I made it for this jam, with Dirk Kluesing. I did the programming and art, and Dirk did the music and audio, aside from the song Wither.
I wasn't immediately inspired by this theme. On Friday, I took a walk, played a game, and just kinda spitballed things for a whole. I came in wanting to do some kind of rhythm game, but I didn't know how to get them together. In the end, I feel like I kinda decided on a ham-fisted approach. Unstable platform + rhythm. The mechanics kind of naturally fell out of that. You could hit the notes with either the left or right arrow. It'd be nice to have held notes (though these didn't make it in). There's an unstable platform that's basically simulated as a pendulum. It gets more unstable as the crowd gets angry. Yeah - that sounded easy enough.
I started by making the pendulum simulator on Friday. It was pretty simple, I'm a fairly mathy person, and I've studied dynamical systems, so the single pendulum came easily. I also implemented a double pendulum that didn't get added in. I decided to manually do this instead of using physics so I could "fake" the physics to make the feel better. There's not a lot of faking in the final product, it's mostly around the way your inputs push the platform around. But night on friday came quickly, and all I had was this pendulum. Surely the beatmap can't be hard to implement!
The next day I went to work on making the beatmap. I decided to make an editor in-game. I chose to do this to make editing simpler for me, and I think broadly it's a pretty good idea. I could've made the beatmaps in a spreadsheet editor, but I think this was just a little easier, and loaded into engine very easily with JSONUtility. I made a separate renderer and manager for the editor and the gameplay, which kind of doubled the work, but allowed me to make a really nice, performant game renderer without worrying about the way the editor works. I don't know it was the best choice, but it did work. I made the basic UI elements in Aseprite, and wired it all up. It took me a while to get the bugs worked out, but by the end of saturday, both beatmap systems were starting to get solid. Now I just had to do the rest of the work...
Sunday brought in most of the rest of the systems. I got to wiring up a main menu, so I could manage multiple beatmaps. I separated out each of the game states. I made the crowd controlled, and a lot of the little "feel" things of the game. A lot of them were made on a whim. The PERF and BAD things that fly off when you hit a note, the not animation, the crowd's animations and heart/boo things that fly off. All just little things I felt like making throughout the day. I also made the first Trees beatmap once Dirk got the song completed! It was rather uneventful, everything worked. I did spend a lot of time balancing the balancing system, but that was mostly just playing over and over and tweaking. The other big thing this day was art. The game still looked like mostly nothing, so I got to making most of the art you see. I took my time on the background and platform, probably spending 3 or 4 hours just on those. I spent another hour or two on the little people, then brought everything into unity. As I'd set things up fairly well, wiring things up didn't take long. I also threw up the end screens, but that was about all. Technically the game way playable, but there was a lot more to do to make it great.
On Monday, I only had about 8 hours from the time I got up, and I made the most of it. I started with touching up the UI. Everything was there, it just needed actual assets instead of the unity default buttons. I also made the title screen. I then worked a bit on some different difficulties of Trees. I also animated the braces of the platform to communicate how unstable it was. All of that didn't take long, so I also added powerups. These weren't the best use of time. Their effect was rather slight, and not communicated well. No matter. Once they were in, I had about an hour and a half left - just enough time to throw together another song! I did that. It was a wild flurry of picking synths and putting down notes without too much though. Well - the primary thought was making the song interesting to play. I think it turned out okay in that respect - horribly balanced though. That made it in with one beatmap, and it was published.
Immediately after publishing, I was tired, and I didn't feel great about the game. It worked, but would people like it? It turned out yes, and for a lot of reasons I'd thought about, but didn't really trust. I think this heled reinforce the way trusting instincts on game-feel are really important, especially when compared to just adding more content. This is actually one of the most content-bare jam games I've made recently, but in that, it's the most concise, and the most polished. The game very quickly gets through what it wants to, and that's a good thing. I think if I put a bit more thought in at the beginning, maybe I'd have made better decisions over doing separate play and editor beatmap managers, and things like powerups, but I don't know. In the end, I think the way I didn't overthink things was a big help to this. I never felt stuck, I always had a place to move. In the end, I'm really happy with it. I think in a way, the time limitation kept me from bloating it, from overthinking it, and in that, it felt really good.
Thanks for reading, and I hope you all have a great Ludum Dare!
I will be accepting submissions, with preference given to games that haven't hit 20 ratings! Come watch at https://www.twitch.tv/nardandas20
My ludum dare project didn't go so well, but I made it! A little overscoping... so I think I'll play some of your games!
https://www.twitch.tv/nardandas20
Hi! This LD I kinda went in wanting to make an eco-farming game, where it was more important to make sure the environment was good for a plant than it was to sit there watering it. I kinda failed at that, but I did make a game where you place plants and water and grow things to stop bulldozers, which is cool. You also get to save animal friends.
You can play it here: https://ldjam.com/events/ludum-dare/50/anyas-valley
I always feel kind of disappointed in myself when I finish a jam, so many I'm not the best judge of my own product, but this one kinda felt particularly bad. I started off kind of aimless, "eco farming" doesn't map nicely onto "inevitable" in my mind. I went through a few little ideas but I settled on this "dozers are coming to kill your valley and you have to delay/evacuate people". Nice enough, but I didn't ask enough questions about what I wanted to do really. What was "eco-farming" mechanically? I had a lot of random ideas, but eventually it became plant grow based on water + sunlight + the plants around them. I wanted to add stuff like pests and keeping pests away bit it fell out of scope. What was "evacuating people". I kind of cobbled it in as making little environments for a couple NPCs in a nearby valley, but I wanted it to kind of feel better? Just a lot of things I didn't really think through. So it started with a muddy, unclear scope.
I'm happy with how a lot of the little bits of the game went. I like my work on the character art, they all look very nice. Watching plants grow feels good. The idea came through. The music is nice (though I didn't get to SFX). But I think for now that's kind of what I have to take from this.
Next jam I really need to go back to the way I used to think about these. Start with a small, clear scope, and find ways I can expand on that. This time I didn't have a playable prototype until 4 hours before the deadline! And "playable" was marginal, at best. I'm a lot happier when I have something playable the first day, and I can spend the rest of the time improving it and making content.
Hi, join me here! https://www.twitch.tv/nardandas20. I'm kinda down on my own games so I wanna find some cool games to play!
For the past few months I've had an idea that I kind of built out in my game here https://ldjam.com/events/ludum-dare/50/anyas-valley stick in my head. Farming, where instead of watering and fertilizing, you just try and meet the plant's needs with the environment. It didn't work out so well for this theme, and I think I might have done better to not focus so much on what I wanted to build. Does anyone else get this kind of thing? While it wasn't quite how I wanted it, you can built a heart scene in the game, which is really fun :)
Hi, I'm playing games over at https://www.twitch.tv/nardandas20. If you're having trouble getting a download game played please stop on by, I play them all!
Hi everyone! I know board games often don't get the feedback they deserve on here so I wanted to try and collect some of them to try out!
Drop by if you need an extra play to make it! https://www.twitch.tv/nardandas20
I made a little game about growing plants.
It's a pretty technically complicated little guy. It generates its own mesh for the plants, applies rules to make the plant grow arbitrarily. For some reason I decided the way the plant grows should be defined in a custom language, so I made a lexer and parser for it??? I think this one was mostly just me liking lexers and parsers. I didn't quite get to everything I wanted to but I think the game evolved along the way. I like it a lot!
My goals at the beginning were to make something with a weird control scheme - I felt like I normally defaulted to a character moving around in a 2D space, and something chill to spite the "10 second" theme. I met those. I also kind of wanted it to be speedrunable, but I didn't really go that way. That's fine, other games of mine from these jams are.
While I don't at all regret spending a lot of time creating these technical little parts of the game, I don't know if I'll make another one like this soon.
https://ldjam.com/events/ludum-dare/51/silvi
Wanna grow a plant? https://ldjam.com/events/ludum-dare/51/silvi
Unity's web player always says "web builds are not supported in mobile", but mine seems to work absolutely fine! Does anyone else's work? Mine's entirely controllable by touch, if anyone wants to try. Let me know if yours works on mobile, I wanna try some!
https://ldjam.com/events/ludum-dare/51/silvi
I've seen a few folks wondering how I did my game, so I'm going to show a little bit of it here. As you see the plants aren't at all 3D, just really simple 2D geometry. I regenerate the mesh each frame as the wind and all affects it, on the CPU. I think it'd best be done on the GPU, but this way kept all the data easily accessible to me to use in other systems. Yes my game is horribly coupled, it's just a fact of some of these jam games.
The way I generate the geometry is rather simple. First, all of the pieces of the plant - all the stems and leaves and flowers - are stored as lengths and angles, so we have to transform those into positions. During this step we consider the current wind - a two octave perlin noise generator, and apply that to the angle based on a weird cross-product like thing. The wind at this point is converted into an angle, which is a rather weird conversion, but works cohesively with the rest of the system. The mesh is then generated by taking these positions and generating vertices along the length between each position, based on a list defined for each type of piece. We linearly interpolate between the start perpendicular vector and the end perpendicular vector to make the ends all match up. That's really it!
The plants are defined in a little language I wrote myself for this jam for no real reason, a bit of it looks like this
leaf: ((.1, .3, 1, .8, .2, 0), #69cc45, 0, 0.3, .3, .01, .1)
stem: ((1, 1), #376339, 5, .8, .2, .4, 0)
tiny_stem: ((1, 1), #69cc45, 5, .4, .2, .2, .05)
flower: ((.1, .1, .9, 1.3, 0), #d14232, 0, 0.4, .4, .05, .12)
s=stem, maxinhib=14, height = .3, diststem = 8:
```(
(
[leaf, angle=30, a_size=.7, len=2.5 {.7}
) {.2}
[
stem, angle=-12, size = 0.95, len=.6 {1}
] {.3}
+[
stem, angle=10, size=.9, len = .6 {.4}
] {.2}
) {.1}```
You'll notice a lot of unnamed numbers, this was a mistake. I'd rather have done this in json I think. The basic idea of how the data is stored is sound. It's basically that we have a list of piece types at the top, then a list of conditions, and under each condition, a list of things that can generate if it's met. It's a variation on an L system. The things in () are "roll each", the things in [] are "pick one", and the things in +[] are "pick at least one". This makes the growing system pretty expressive. The things in the {} are the chances for each thing.
Currently it doesn't consider the amount of sun or anything else. I want it to eventually.
This wasn't very in depth but I hope it's interesting and answers some questions!
https://ldjam.com/events/ludum-dare/51/silvi