Critter Conflict: https://ldjam.com/events/ludum-dare/56/critter-conflict

Don't be shy :)

Before I go into detail about what went wrong with our game, rest assured: we did actually submit our game and we're proud of the result. We'd love for you to give it a try and leave us a rating, a comment, or both! No web build available unfortunately (more on that in just a second), but you can download the Windows and macOS builds right here.

The game is absolute hopping (if you catch our drift)!

Beware all Godot users, we want to hear your experiences! This is the third time we're participating in Ludum Dare as a team, and the third time we're using Godot. We always run into one problem or another, but usually we manage to sort things out. This time though, the end of the jam put is in a bit of a... jam I suppose. No matter what we tried, the web build just wasn't working. We're both C# engineers from experience, so we're using Godot 3.5 Mono so we can get the web exports (Godot 4.x only supports the web platform when using GDScript). While the Windows and macOS builds worked as expected, the web export runs into an absolutely mind baffling bug: a static class field gets reset to its default value (null) and well, given that this is our central singleton object, everything breaks! Maybe our code name for this project - Bug Chess - had become a bad omen.

We spent several hours debugging and searching online to no avail. Unfortunately, this ate into our time for getting the extra bit of polish out in the end. Even post-submission we spent a few more hours, but we've head dead ends everywhere. Combine this with the editor becoming unstable and crashing regularly, and we didn't end the jam weekend on the high note we were hoping.

For next time, we're considering how to address this. If web builds become a "maybe, maybe not" affair, we might as well switch to the latest Godot and get all of the great new features. We're also considering finally making the plunge and switch to GDScript, which may be more reliable to begin with.

This is why we'd like to hear from you! Have you ever had trouble with web exports in Godot? Maybe even had this exact same issue? Have any of you switched from C# to GDScript in Godot and if so, what were your experiences? Does anybody use the mono version of Godot in the first place?

Once you're done answering, don't forget to still play and rate the game.

P.S. The web build is published right here in case you're a bit weird and love to see a dev console full with errors :smile:

Hiya! TinyTaunters team here. We’d like to share our experience with LD56 and some news.

Building everything from scratch including audio and hand drawn artwork was super exciting and we loved all the feedback we got. Most of us are really inexperienced in game dev and have only joined a couple of jams and figuring stuff as you go bears its consequences.

We were thinking of doing a post-mortem for Tiny Taunters but… the game is simply not dead. It’s just getting patched… rather slowly due to all of us having to go back to our banal non-jam day-to-day.

Good news is we’ve got our first major UPDATES. So let’s talk about the major issues we encountered with the game and how we solved them.

Enemy Pathfinding

Our original pathfinding algorithm for the enemy AI was naive to say the least. We just calculated a vector towards the player, raycast and if there were obstacles in the way you stayed put, if not you went towards the position where you last saw the player.

This resulted in some very fun exploits where you could just stack enemies in corners and spam them with taunts

In order to fix it we moved to an A* solution. It was fairly easy to implement and with some fine tuning … the enemies were too smart. You could literally not get away from them even if they were slow as a turtle.

Also we had to abandon moving their transforms and try to use the physics engine through rigidbody which took some time to work into the scripts.

After some more tuning we found a decent balance of stupid vs fun. Now you can still sort of trick them but it is harder and kind of fun to try out.

Box collider hell

We also tried to do tile maps and sprite colliders for the first time. Our first plan was to put everything in tilemaps and then draw colliders on top of it. It turned out… fine. But when we started messing with the scales or positions of objects we had to manually move all colliders around and wall colliders were a mess.

A bigger problem surfaced when we added animations to the enemies. Since our art was all hand drawn, their sprites were all over the place leading to really messy interactions.

First approach towards a fix was a polygon collider. This fixed the problem with the animations but the generated colliders had a lot of edges and the enemies got stuck all over the place. This also applied to a lot of the objects.

Our second approach was adding simpler colliders on enemies and composing them into shapes with good round edges. Then we discovered that we could add tilemap colliders while making custom physics shapes for our tiles. Splash a composite collider on top and you have a minimal polygon that looks exactly as you designed it. We separated the tiles that had collisions with the tiles that were just the ground and we were good to go.

Tiny Taunters version 2! What’s next? We published a new version of our game yesterday. This includes major fixes such as: - A* pathfinding for enemies - Better colliders - New artwork - New animations - Various quality of life fixes - 🥳A public Leaderboard!🥳

We really liked the idea of having a leaderboard in order to interact with other players worldwide so we used https://danqzq.itch.io/leaderboard-creator to set it up.

We are thinking of doing some major reworks and adding some exciting new features. Namely, we are considering collectibles and alternative scoring system, different character powers and more beautiful artwork by metaksonio

Play the game and leave some feedback here!

Test

So, I had a blast taking part in this Ludum Dare and haven't written a postmortem yet, so here we go!

Let me introduce you to Snail away, the platformer where you can't jump!

Day 1

A chaotic start: who needs a CI/CD pipeline :sob:

The jam started very chaotically for me. I recently learned about CI/CD pipelines, which, for those who don't know, allow you to automate the process of exporting and publishing a project. So, like, 2 hours before the jam, I thought, let's give it a go! (Spoiler: that was a mistake...)

I had no experience in making such pipelines, and it was way harder to get them to work than I thought, with many examples being either outdated or needing tweaking. So I was hard at work on that when the theme dropped. My two least favorite themes of the round were Strange Machines and Tiny Creatures, so when I saw Tiny Creatures on Twitter while working on my half-broken CI/CD pipeline... man. :sob:

On Saturday morning, I woke up obviously very uninspired by the theme and thought I'd try to fix my CI/CD pipeline. It took me a lot of trial and error, but after a few hours, I got it working! Man, the feeling of just doing a git commit and having your game actually playable online felt incredibly good. The only thing was... there was still no game to play, not even a concept, and I had already burned the entire morning of the first day.

Brainstorming time! :gun: or :boxing_glove: or :snail:

Earlier I said I didn't like the theme, but taking a step back, it wasn’t so bad after all. After some brainstorming, I had three game ideas:

:gun: A first-person shooter where you play as a mosquito trying to take down a (giant) human. I liked the idea and thought it would make for interesting gameplay, but at the same time, I felt the success of the game heavily relied on the AI and animations of the giant human, which seemed too difficult to get convincing results within the time frame. Plus, I'm more of a 2D artist than a 3D one, and I thought it would be too challenging to make the game look good.

:boxing_glove: A 2D, first-person fighting game set inside an anthill. Making a 2D first-person fighting game was something I already had in the back of my mind. In the end, I didn’t really like the idea of using an old game concept and just slapping a Tiny Creatures theme on top of it.

:snail: And lastly, a 2D platformer where you play as a snail. The idea quickly stuck with me (pun intended) because I thought there was something really cool to do with how a snail moves—sticking to surfaces or rolling inside its shell. So I eventually picked that idea. And I think I made the right choice!

Making good platformer physics!

Since the game was a platformer, my main priority on the first day was movement and physics. For anyone making a platformer out there, please, good controls and physics should be an absolute priority—this is the core of the game.

From a technical point of view, my snail is a CharacterBody2D in Godot that always tries to stick to the ground. When rolling inside its shell, the CharacterBody2D despawns, and a RigidBody2D spawns instead. Since the sprites stay in place, it’s impossible to tell that the collision object actually changed under the hood. But it works great.

Procedural animation?

Once I had that working, the snail's graphics were another priority. I knew it just HAD to be procedurally animated because that’s how a snail’s tail should look like. So, I used a Line2D in Godot and animated the points with code.

I used raycasts to anchor the tail's points to the ground. For the head, I made some basic damping physics. For anyone interested, the math is very straightforward: it's basically just, every frame: position += (target - position) * speed * delta, where delta is the time between two frames, and speed is a parameter to control how fast the object should follow. Very simple, but it looks nice and satisfying.

Once I got the physics and procedural animation somewhat working, it was Saturday night, and I started playing with it a bit. And I realized: wow, this is actually pretty cool! I didn’t know how good it was going to be, but by the end of the first day, I was surprised at how good it felt to play with the snail. At that point, I just had a simple snail controller... but still no real gameplay, or levels, or graphics, or any sort of complete game.

Day 2

Throughout day 2, a lot of things got done! I started by fixing some bugs on the player physics and animations. I made a few mechanics, like plants that bend as the player walks. I also worked on graphics—the snail’s shell, some leaves, and a few decorations.

Level design time!

Then it was time for level design. And I realized that being a snail means... you can walk anywhere! Like, literally anywhere. For example, if I put a wall to stop the player... well, the snail can just walk on top of it. There’s no stopping a snail. So I added a new mechanic: spiderwebs, which you can’t stick to, and block the player. This mechanic turned out a little buggy, but it worked well enough for most playthroughs.

I was finally ready to design some levels. The trick I used was to make the levels within the engine itself with basic polygon shapes. This way I could prototype very quickly, and the game still looked okay without needing to create more art. Very handy. I also used Godot's feature to automatically generate collision polygons from sprite—again, super handy!

Extra stuff! :heavyplussign:

I still had to cut the scope down and make the game much shorter than expected, though. I spent a bunch of time at the end polishing the game: adding a parallax background, sound effects, music, and collectible ladybugs. And that was it! Before the end of the jam, a friend tested my game... and really liked it! At the end of the jam, I played it a few more times and realized I was super happy with what I had made!

That's a wrap! :clapper:

Now it’s been about 10 days since the game was released. So many people have played it, and most really liked it! The response has been overwhelmingly positive—the best response I’ve ever had for a game I’ve made! I’ve made quite a few games in the past (this is my 12th Ludum Dare!), and it’s so cool to see I’m still making progress and creating better and better games. There are still some things that could use more work, like certain aspects of the level design, and the game is very short. It’s obviously not perfect, but that’s not what it’s all about. For me, it’s about trying to make a better game than last time, even if it’s just a little bit better. And I think I achieved that.

Anyway, thanks for reading my postmortem, and thanks to everyone who gave feedback. You can still play the game if you're interested!

What makes a game difficult?

When creating our game Gnomin' we took inspiration from games like Getting Over It and Get Out Joey. These games are usually quite difficult, but should still be fair. We hope to be both, and would like your opinion! Is our game difficult enough? Is it too difficult? Are there any aspects you find unfair?

The leaderboard

Similar to our other games, Gnomin' has a leaderboard to motivate players to compete with each other. At this moment, I am still first place, I'd like this to be changed! Help Ink the gnome get to the end of the cave as fast as you can and beat me, Korcalius and Meep out of the top 3!

You can play Gnomin here: https://ldjam.com/events/ludum-dare/56/gnomin

It wouldn't be game development if we didn't ship with some bugs. We did - like Mites creating a small moshpit. But do not despair, now you can play a 1.1 version, that forbids moshpit joy!

All the changes:

-Fixed Mites doing a moshpit in the play space

-Fixed issue with missing font

-Fixed issue with text appearing over the hand

-Fixed the wrong portal color

-Improved optimization

-Added controls reminder to playspace

Of course, the old version is still available, if you would like to put some Gojira on and party with the Mites!

FINALLY, our hands have reached the bug fixes. We spent so much effort (no) and time (no) to fix these problems (in fact, we just rested and appreciated the wonderful games).

Here is a list of all the changes:

1. Fixed a bug with the board, now it is possible to chop all kinds of vegetables that are still available.
2. Fixed a bug with orders, now after the delivery of the order, the old plate / bowl is successfully deleted.
3. Fixed a bug with the appearance of a mouse, now the player on the stage will be disturbed by the mouse (so far only visually).
4. Added decor to the order scene (the designer can finally celebrate).
5. Added a trash can that removes unnecessary vegetables.
6. The chance of getting cut was slightly reduced.
7. POTATOES WERE ADDED.

This was our first experience in developing such a project and I hope everyone enjoyed it.

You can also try the new version of the game and write comments about new bugs :) Thank you all for your attention.

Critter Conflict: https://ldjam.com/events/ludum-dare/56/critter-conflict

Currently live at https://twitch.tv/ategondev playing games from the jam! Feel free to stop by and watch me play your game

Hi, Misa here, one of the developers on Miku's Minion Madness (https://ldjam.com/events/ludum-dare/56/mikus-minion-madness), and I wanted to talk about the making of the game! This one will be a bit long, so we'll split it into multiple posts. This one is the Before the Jam edition.

2 Days Before the Jam

@poco0317 and my fiancée @miku had decided months before this point that we would participate, but with the looming weekend, no ideas, and all of us facing general exhaustion, we were just going to see where it would go. Maybe we’d get a shell of a project out, or maybe we would just be one of the unfinished entries. We were ready to face any possibility. We had also recruited our friend @jason-woerner, who like myself and @miku, has extensive experience in the gaming industry. After thinking about it, Miku decided we simply couldn’t waste the talents of this team!

It only took a moment for our team lead to go from "Should we do this?" to "We should do this!" Miku took point and in 30 minutes, wrote up a card rogue-like adventure. We decided to head into the weekend with this general plan, but otherwise we had no specific ideas until the theme would be revealed.

1 Day Before the Jam

We were all feeling a bit of anxiety the day before - we had a solid base idea, although it was a pretty large scope, if we included everything we'd like to achieve. We decided to downscale it further after the theme came out. We knew we wanted some elements of playing cards, inspired by Slay the Spire and games of that genre. We were constantly chatting - the jam was soon, but we had no idea how the project would go.

Miku reached out to @emiri, our producer friend (check him out here: https://www.youtube.com/channel/UC1f-lKIatUwQBLzHuf98s0g) and asked:

Miku sent him the proposal and showed him the rules of Ludum Dare. He was in, and even though we didn’t know anything else at the time, we knew that the music would be a banger. Miku spent some extra time researching previous game jam entries that were card games, to make sure we were all on the same page as to what made people want to play these games to completion.

When the countdown timer hit 0, our team excitedly hit refresh, only to be met with a syntaxerror. Oops! Refreshing again, we finally found that it was the Tiny Creatures theme. With so many thoughts racing through our minds, we started our meeting about 15 minutes past the theme reveal. We were ready to discuss how we would interpret this theme. The game has only just begun.

The Meeting

After exchanging the usual pleasantries, we headed right into it with a Discord Whiteboard. Although the controls weren’t perfect, we found a way to make it work. We simply needed a place to quickly write down ideas and iterate. We began discussing how our game proposal would work into this, how to interpret the tiny creatures, further ideas, and most importantly: how do we down scope our game so it would be completable in a weekend?

An important reminder to designers everywhere: It’s fun to design in a vacuum, but the most important part of this process was to design with the capabilities of our team. None of our designs, even if it was the most elegant, would mean anything if it wasn’t going to get implemented. After an hour of discussion, refining and cutting ideas, we ended up with four buckets to organize our ideas: - Confirmed Ideas – These ideas are priority #1 on implementation - Stretch – We will get to these ideas if we have enough time after the jam - Idea Pool – Extra ideas that we could add or not add. - Rejected – We simply did not pursue these ideas further.

Discord’s Whiteboard feature was helpful in allowing us to move ideas around, as well as providing some sketching tools so that we could have a bare bones idea of what the game would eventually look like. Using the feature to move ideas around, we were able to tighten the list of what we must do. We got an estimation from our engineer as to when each feature would be complete, and we started to march towards our goal.

We knew we wanted to make an accessible game, playable on mobile and browser, so with that in mind, we got ready for the first 24 hours!

I just realised there was only just over a week left and i haven't gotten close to enough ratings

It's funny when we look back at the first sketches and early ideas for this game, and then see how the final result turned out! 😄

PLAY NOW: https://ldjam.com/events/ludum-dare/56/tinygotchi-creatures

Give it a try and let us know what you think!

If you missed our previous "Blob, To the Top!" post, you can read it here: https://ldjam.com/events/ludum-dare/56/blob-to-the-top/blob-to-the-top-is-now-even-blobbier-than-before

Highlights of this patch!

• New max power indicator, which subtly shows to what extent the blob launcher can be charged. The charging mechanic should be less confusing now. You won't overshoot this time, right? Right?

• Blobs are now properly synchronized with the camera regardless of the frame rate. Developers were crying when it finally started working...

• Blobs will no longer get stuck in one-way platforms and will fly through them correctly from below. No blobs are left behind!

• Blobs now bounce off bouncy walls properly and in a more predictable manner. Check the wind, adjust the angle, and finally make stylish and mathematically correct blob shots!

• ...and even more bugfixes, difficulty adjustments and performance boosts.

The full changelog can be found on the game's page here:

https://ldjam.com/events/ludum-dare/56/blob-to-the-top

Once again, thank you sooo much for all the feedback you left under our little blobby game :heart: Your words gave us the confidence we needed. We are now fully committed to continue working on "Blob, To the Top!", with the goal of releasing it as a full-fledged game in the future! And because you are the first to read this post... tell us what you would like to see in the full game, we will see what we can do :wink:

This is the last patch for "Blob, To the Top!". Now we would like to fully focus on playing your games! We have a very long list of games that we want to try before the voting period ends. We probably won't be able to play everything before time runs out (working on this patch and real life stuff took all of our free time).

First, we want to play all the games from people that commented on our game (just to thank for all the fantastic feedback - we appreciate every little bit of it). But for those of you who made it to the end of this post... link your game below so we will play it first right after that :grin:

And finally, a small bonus for fellow Godot developers. Our work on the blob shader synchronization (so that their position is always correct relative to the camera regardless of the frame rate) has taken our sleep away last weekend. We want to share a small tip for you so you don't have to go through the same thing we did. In short... if you want to get the camera position in the canvas_item shader, don't send it by uniform. Instead, read it directly like so:

varying vec2 v_camera_coords; void vertex() { vec2 camera_pos = vec2(CANVAS_MATRIX[3][0], CANVAS_MATRIX[3][1]); vec2 camera_zoom = vec2(CANVAS_MATRIX[0][0], CANVAS_MATRIX[1][1]); v_camera_coords = -camera_pos / camera_zoom; }

Critter Conflict: https://ldjam.com/events/ludum-dare/56/critter-conflict

One of the interesting problems we faced when programming Bunny Wrangler was adding the ability to determine what the player had outlined. We had decided to only recognize circles as it simplifies the problem a lot, and because we wanted to make it western themed, so it made a lot of sense for a lasso.

Figure 1: Bunny Wrangler gameplay

I have already somewhat answered this as a comment on the game, but I figured I would post it here too with some more information as people seemed to like it!

Detecting a circle

Perfect circles always have the distance from the center to the outside edge the same length. I figured I could use that fact as a simple test for our case. But what's the best way to figure out the center of our list of segments? The segments in our rope are just some points in space.

I started of taking the average point of all given segments. This worked pretty well in most cases as seen in Figure 2.

Figure 2: Average point represented by the big red dot

One big flaw I ran into, is that because of limited frame rate, the average point would shift dramatically based on the player mouse speed. Notice the segment sizes on the left vs right in Figure 3.

Figure 3: Average point (red dot) shifted all the way left

So instead I wanted to find a way to find the center that doesn't rely on the segment sizes. Eventually I ended up calculating the bounding box of all the segments. This gives a way better center point for our use case. It's the big green dot in Figure 3.

Now we have a good center point, the next step is to figure out if the segments are roughly the same distance away from the center. I'm keeping track of the minimum and maximum distance. In the case of a perfect circle, these values should equal. minimum / maximum = 1

Figure 4: Calculating the minimum and maximum distance from the center

In practice, these minimum and maximum values never equal. But we can see how close we are by dividing these values. The result of this can be compared against some threshold that we experimented with. In case of Figure 4, it would be roughly:

minimum = 175 maximum = 210 circleness = 175 / 210 = 0.8333

A higher than 0.8 we consider a Perfect Circle in-game. So the shape in Figure 4 we would consider as one. Because we have a value that approaches 1.0, we can give more points depending on how well a circle was made. Values closer to 1.0 are generally better circles without much variation from the center.

Figure 5: With a big difference between minimum and maximum, the shape is likely not a circle!

minimum = 75 maximum = 258 circleness = 75 / 258 = 0.2907

Anything lower than 0.6 we don't consider circle enough. So it correctly doesn't approve the shape in Figure 5. We couldn't be too strict with the thresholds as it would be frustrating to play. This results sometimes in non-circular shapes being approved, but I think in most cases they take more effort compared to a normal circle.

Figure 6: Wrong shapes being detected

This isn't a perfect solution, but I think it works very well for our case I think. Especially with the huge time pressure, I'm happy I could come up with something that worked so well. How would you have solved this? Are there any other (better) ways I'm not aware of? I'd love to know! :cowboy:

This is how my game looks like in the editor.

Though it's been only a bit more than a week since I last touched it, I probably would need some time to make sense of the project myself :sweat_smile:

When I'm developing I usually go to a weird creative trance and might forget how I implemented some of the stuff. But I guess that's not entirely unheard of the bigger the project-tree is.

The source is available for any Fusion-developer daring enough to take a look at that horrible mess!

And here's the concepts I made during COMPO when planning the game.

The first one I drew very early on. I planned the character to have an extendable limb as well as a full body, but the floating hand was more practical choice.

Hopefully I'll find the time and energy to develop the game further. I didn't have time to finish the "sprouting-mechanic" pictured in the concepts.

The creatures do start sprouting but they don't produce a flower that the player could eat.

The game is also missing a goal/finish-states so as of now it's essentially a playground/sandbox.

Had bigger plans for the music-player/HUD so it would affect the gameplay-attributes in different ways.

(and speaking of that; for anyone interested I made an in-depth write-up about audio-production earlier.

Keeping my hopes up that there'll be a post-jam version and/or updates at some point.

But don't be holding your breath, tho!

:mapleleaf: :fallenleaf:

Hey everyone!

We’re excited to share some new updates for our game, Turn of Taurtarus!

Since the original submission, we’ve made some quality of life improvements. Here’s what’s new:

• Character Animations: Both forms of Humans and, of course, the Minotaur now have animations to make them just a little bit more alive.

• Lighting: We’ve introduced a new lighting system to make the maze even more atmospheric. The shadows and flickering torches are mostly for visual purposes only, but we believe, add quite a bit of vibe to the maze crawl.

• Score Popups: To make your scores easier to understand, we've added the popup clarification of the point formula, helping you understand how to get better outcomes!

If you haven’t played Turn of Taurtarus yet, now’s the perfect time! We’d love to hear your feedback!

Nebulate.me

Hey guys!

If you haven't already, we would really appreciate it, if you take your time and test our game, leave a comment and maybe some rating. Bunnies are waiting for you :smiley:

Play & rate our game: https://ldjam.com/events/ludum-dare/56/the-pasture

Thank you so much! :hearts:

Best regards @nivbeth, @fis & @johncoffee