If you want to try a horror game thats it!

-> The Blueberries Dawn <-

Week 2, time to try the games finished in a weekend! Come by my stream at https://www.twitch.tv/vorceshard if you want to see fresh games in action made for Ludum Dare 56. If you want to see your game played, let me know your username in the chat so I can look your game up.

If you've been on Twitch at all this past week, you may have seen our game being played by creators in the community.

We've gotten a lot of helpful feedback, and it's been great to see players enjoy their time with Poppet. If you’ve got a moment, check out these links to hear what some awesome creators have to say about their experiences: - ColeSlawski - Ategon - RookRules - Tobugis

Poppet was a big undertaking for our small team, and it definitely came with its challenges. But we’re really proud of what we’ve created. We're truly grateful for the incredible response from this community and appreciate all the feedback from our players.

There is still time to rate, so please, If you haven't had a chance to play our bite-sized survival horror, be sure to give it a try. You will not be disappointed.

PLAY POPPET

I was out of town most of last weekend and so couldn't help my team with our game as much as I'd have liked...and I also haven't been able to start playing and rating everyone else's games until yesterday! Usually I alternate between the danger zone and whatever blog posts I read. There's been a lot of creative entries, with more logical takes on the theme than some previous years. Also, the community has been awesome.

In any case, if you want/need some plays, leave a comment and I'll try to knock it out over the next couple of days. If you have time, try playing Slime King, too!

https://ldjam.com/events/ludum-dare/56/slime-king

Leave you (web)-game in the comments and i will play it aswell.

Play Survival of the Shadowlings in your Browser now!

Survival of the Shadowlings is a Lemmings type puzzle game with 10 increasingly harder levels.

Help those little fellas to survive.

Example of a level:

(Now that I can post on the public thread)

Go Check our ~~Game~~ Late Show about absolutely everything except Tiny Creatures Because as we all know

THEY DO NOT EXIST

GNews TV Late Show Here

Sadly, I didn't have the time to play others' games and promote our own Backpack Dungeon yet, so I was kinda shocked when one of my friends told me today they've cleared the whole thing!

Here's the screenshot they've sent me:

(And yes, that's the maximum depth one can reach in the uploaded build)

Anyone else with similar experiences?

We made chaotic garden adventure with tiny creatures as entry for Ludum Dare 56! Prepare for Winter and check out the game here: https://gamejolt.com/games/my-crazy-little-garden/930392

Aiming to get more people's games out of the danger zone. Play a few more games so we have more who place in Ludum Dare 56 catagories and more who can potentially find and play We Love the Boys!

Play the game here: Karma Keepers

In the late game of Karma Keepers, you’ll see thousands of entities on screen. Each entity is made up of several components, like clothing with specific colors, shadows, and more. One of my main goals was ensuring the game runs smoothly no matter how many elements are being rendered, so I put a lot of effort into optimizing the game to handle this without sacrificing performance.

The game is built with Rust using a custom engine that exports to WebAssembly and WebGL2. This, by itself, makes it very performant compared to alternatives using interpreted languages.

But often, the real challenge is not the language, but the game’s logic. In Karma Keepers, there are four main elements to render: parallax backgrounds, sprites, geometric shapes, and text. Each element has its own transformation matrix and color properties, so it's crucial to handle how they’re drawn and in what order.

I'm using a technique called Sprite Batching, which I apply to everything: parallax patterns, sprites, text, and even shapes. Batching means sending all elements to the GPU at once, avoiding multiple draw calls. This matters because communication between the CPU and GPU is slow. By telling the GPU to draw 100 elements at once, instead of issuing 100 individual draw commands, performance improves significantly.

Each batch is defined by certain rules. Usually, if the resources differ from the last, you need to create a new batch. In our case, a new batch is required if the shader changes, the texture bound to the GPU is different, or the projection matrix is updated. Karma Keepers uses the same texture for all sprites. They are packed into a single texture atlas, and each sprite knows the coordinates of the element it needs to draw, so there’s no need to switch textures for each sprite. Text, on the other hand, uses a separate texture that updates based on the text to be rendered.

As for matrices, all transformations are computed on the CPU. While this is slower than doing it on the GPU, it allows us to bundle all vertices into the same batch more easily, simplifying the rendering process.

To optimize further, I divided the rendering into two phases: the game world and the UI.

Game World:

1. First, the parallax background is drawn. This is a single draw call since it's the only background on screen.
2. Next, all the sprites (souls, their clothes, and shadows) are rendered. For each, I calculate the transformation matrix and apply the appropriate color.

UI:

1. The Blessings and the progress bar are rendered as sprites.
2. Then, shapes like background rectangles for the Blessings are drawn.
3. Finally, all the text is rendered.

By organizing the rendering in this way, the entire game is drawn in just five draw calls, which is a very low number.

To avoid drawing off-screen elements, I also check the camera bounds. Anything outside of the view is skipped, saving processing time and avoiding unnecessary data being sent to the GPU.

CPU side optimization:

The main CPU challenges are handling transformation matrices, colors, and collisions. But within reasonable limits, this is relatively fast. I'm using simple AABB (Axis Aligned Bounding Box) collisions, which aren't very complex. They keep souls from overlapping and allow entities to push each other when you're guiding them with the mouse. The collision system is based on simple rectangular bounds, with entities having a "force" to determine their push strength, guiding souls have a bit more force so they can move others.

And that's it! No magic, just organizing the code to make it easier for the GPU to process. There's still room for optimization, but it's more than enough for this game at this stage.

Thanks for reading, and don't forget to play the game! Appreciate the support!

Here are some concepts from our game about Stuart. Created by @fooorsh.

You can play it here: https://ldjam.com/events/ludum-dare/56/stuarts-perfect-day

Appreciate your thoughts and feedback!

I browsed through some games, which at the moment haven't got a lot of ratings. So I thought I present some of them to you. They are very different from each other, so maybe you find something to play. :)

• Animal Arcade: Short game and very fast pace. (13.1 ratings received / by @jakob-meier, @5hin3, @acid) https://ldjam.com/events/ludum-dare/56/animal-arcade

• Backpack Dungeon: Relaxing, chill gameplay. (just 3 ratings / by @dragonayzer, @tabera, @neon-glass) https://ldjam.com/events/ludum-dare/56/backpack-dungeon

• Tiny Flings (COMPO): Shooting a person using gravity to get to the goal. (13 ratings / by @shoalmuse) https://ldjam.com/events/ludum-dare/56/tiny-flings

• Luck of the Draw (COMPO): Multiplayer mode! Board game with dices as weapons. (12.7 ratings / by @cruise-elroy) https://ldjam.com/events/ludum-dare/56/luck-of-the-draw

• 1D-Puzzle (COMPO): Imagine the ball is a bug, so it fits the theme. ;) (13.4 ratings / by @a-bond) https://ldjam.com/events/ludum-dare/56/1d-puzzle

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.

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.

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.

I made a cozy sim game about a tribe of tiny creatures developing their village while you interact with them. Sadly I didn't have enough time to add much challenge and I wanted to have more player interaction involved.

The post jam build has an added challenge and goal:

-There is now a rival tribe you must defeat by raising an army!

-More characters, items and interaction.

-Tweaked sim behavior and other fixes.

​-Additional polish

Jam and postjam versions can be found here: https://ldjam.com/events/ludum-dare/56/tiny-tribe

https://www.twitch.tv/xpmonsterx

Bring on stream more of your amazing games :)

Tiny news: I began making highlights and preparing for Youtube release. 16 games from the first day were already highlighted. I also took the liberty of making thumbnails for some of them that didn't have one. You check my highlights to see them. I hope everyone will be satisfied, but if not - you can send me your own to support@empyreans.net

Games played count: 49

Last games: 1. https://ldjam.com/events/ludum-dare/56/neckmeats-tiny-adventure 2. https://ldjam.com/events/ludum-dare/56/my-tiny-friend-and-i-went-on-a-puzzle-adventure-in-the-forest 3. https://ldjam.com/events/ludum-dare/56/monkepok 4. https://ldjam.com/events/ludum-dare/56/tiny-h-o-c-s-pro-creator

In the past my jam team had worked together on a game called Window Crawler for the brackeys jam, this was a game where you go through a dungeon but every time you exit a room a new room is generated in another window. (And then rooms can disappear leaving space for another room to generate)

After making it me and some other team members have wanted to do another Window based game and the theme for this jam seemed like a prime opportunity for doing so. After brainstorming for a bit we settled on an incremental type game where you take care of creatures in enclosures with each enclosure being a computer window.

Working with windows ends up causing some issues since its not a common workflow people deal with for games (especially for jams where everyone wants ideally a web build). The closest thing that people make to this sort of game are desktop companions, aka things that walk around your screen such as Desktop Goose. This means that there are at least some things to look at when making window based things but for things more oriented towards creating a game based around that there's not much help.

The primary game engine I work in is Godot and Godot ends up simplifying things a bit by providing a Window class you can use to create and manipulate Windows. For the enclosures I would first create a scene (aka prefab for those of you who work in unity) with the type set to Window and then spawn in a new instance of that scene every time I want to spawn in a new enclosure. Windows don't like having their position set before spawning in so the first thing a window does after spawning in is adjust its position to the correct spot.

This ended up bringing me to a set of windows that looks something like this. With one main window with the UI (and that would have creatures spawn in) and some enclosure windows that are spawned in (currently from a button press but eventually from an upgrade).

One person who was hanging around my stream chat then had a great idea which was to make the main window be the background of everything else. This was possible through making it a borderless window the size of the screen and then lets the ui sort of float in midair with the UI on the left and the buttons on the right. I then made this have a transparent background so that you could see the computer behind it.

One issue that arose that I ended up spending too much time trying to fix was getting the player to be able to use their computer while the game is running even with the large transparent window covering it. There is nothing currently in Godot that allows windows to completely pass through input and instead currently it just allows you to pass input to another window in the same application. This wasn't always the case though since in Godot 3 you could pass input and it ends up being a bug caused by a recent addition in Godot 4, mousepassthroughpolygon. This is a property on the Window class where you can define a region of the window that accepts mouse clicks. For some reason the addition of this completely broke the behaviour of passing through input to other applications so to fix it I ended up downloading the source code for Godot, removing that feature entirely and then recompiling the engine (as well as build templates so that it works on export). Compiling took around an hour which left me not able to do much other than art until that finished since it was overly laggy to run the game. But once it was done the issue was fixed and you could now use the computer while the game was running.

Interacting with another application would move that to the foreground covering the game so all windows that were part of the game I set to be always on top through the alwaysontop property in the window class.

To allow creatures to be dragged between windows I essentially duplicated the creature to every window whenever the creature is picked up (and then removed it from all apart from one when dropped). This allows the mouse to move to any possible window and it seem like its the same creature you are holding with it never going away (especially with the large transparent window in the background to cover the space between the enclosure windows). I also created the existence of a "wild" window that creatures would spawn in to replace my main window having that behaviour.

There would be some issues with picking up and dropping creatures in windows since letting go of the mouse over a window does not count as focusing on that window and focusing on a window eats up a click to do the focus before it lets you interact with stuff on it (aka pick up creatures). This had terrible UX since you then had to select on a window before being able to start moving a creature so all windows I made detect when they started being hovered over (godot has a signal for this) and when they are they auto focus.

I then ran into yet another issue. Since the main background window passed through all clicks to the applications behind it you could no longer click on the UI buttons in the top right. (These were buttons to pause, quit, and open the upgrade screen). To fix that I moved them to their own small borderless window that did not pass through clicks. This ended up causing a small bug in the final version of the game where that entire region could not have interactions behind it (which was mostly a problem for trying to close out of applications since it was over top of the x button in the top right). I likely would turn that into a non-borderless window in post jam and then allow it to be moved around to wherever the player wants.

Players could also minimize windows which would cause some bugs with the game mechanics relating to creature position. (By minimize here I mean minimize to the taskbar, not make smaller) You cant outright disable minimizing behaviours but you can maximize them again when it detects its been minimized which is what I did by checking its current state every frame.

At the end of all that I had a functioning Window system and could then expand on it a bit more with the actual game mechanics to make it more of a game.

There are a couple bugs that still remain in the game that I have to figure out solutions for. One of which is the fact that the background is black instead of transparent for many people (I have no idea what causes this) which then makes it so that they cant actually use their computer in the background. A second one is the fact that you can interact with all windows at the same time. What I mean by this is you can make a giant stack of all of the windows and interact with every single one on the stack, either with picking up creatures, collecting coins, etc. This ends up causing a duplication glitch which sticks a creature to your mouse and never lets you get rid of it (and making it so you cant use the quit button to quit out of the game)

I still want to make yet another Window based game so might try that in a future Ludum Dare or in another jam I participate in with the things I learned from this one. Especially since I only had a day to code things in this jam instead of using the entire 3 days.

For people who want to play the game made for this jam it is Window Creatures

And if you want to hang out on my streams I stream over on twitch at https://twitch.tv/ategondev and multistream to youtube at https://www.youtube.com/@Ategondev (will be streaming the Ludum Dare Score Chasers tournament when that occurs on Saturday)

That would be criminal not to hang out with these cuties right? :eyes:

Our game is still playable and waiting for your feedbacks, check it out if you have some time :smile:

Link: https://ldjam.com/events/ludum-dare/56/tiny-world-mayhem