Just comment them under this post and I will play them. I’d be glad if you could check out my game too. :smile:

HTML Version: https://jorbits.itch.io/overemployed-empire

https://ldjam.com/events/ludum-dare/58/ratbag

*Hey there! I’ve just figured out how to upload a web version of my game on itch! *

Thx for ppl leaving comments letting me know I could link an itch page. ToT Love you guys!

If you are interested in Antique Buying N Selling game you could try this!

Here is my play testing link :

https://shadowdogee.itch.io/the-big-collector

Here is my voting link :

https://ldjam.com/events/ludum-dare/58/the-big-collector

I’m still trying fix bugs, and play testing other games! But the process is a little bit slow, I’m working alone <3 I will still try my best!

:star2: *If you want me to play test yours plz leaving your link here :3 * :star2:
I’d like to try any type of the game!

I will slowly play all of them.

Thx for your comments again!!! :heart:

Check out my game: https://ldjam.com/events/ludum-dare/58/shiny-things

I'm looking for some webbased puzzle games to spend my evening on 🥰

I compiled the music I created during this game jam and uploaded it to Bilibili. Everyone is welcome to listen and give suggestions and feedback!

These music materials have also been uploaded to Baidu Netdisk (the link is pinned at the top of the comments section of the video) and can be obtained for free and used for any purpose. When using them, you only need to indicate the source in the material usage statement.

If you encounter any problems while obtaining the materials, you can wait for a day or two. I will also be uploading these materials to freesound.org soon.

https://www.bilibili.com/video/BV1UcxvzfEZK/

In development, we try to stick to the classic git flow. However, this is not something worth spending time on at a game jam. Therefore, all commits go to the Main branch. :)

Here, by the way, you can see an approximate schedule of work on the project. SAT: 10:37 - 00:32 SUN: 16:06 - 23:32 MON: 8:20-10:30 and 19:28 - 2:33

You can see that we had quite enough time to sleep, and working in Unity took about 30 hours out of 72 total time. :)

https://www.youtube.com/watch?v=quTthnVaLxo

Games played in order: https://ldjam.com/events/ludum-dare/58/revolution-nexus

https://ldjam.com/events/ludum-dare/58/crypt-creeper

https://ldjam.com/events/ludum-dare/58/spore-scout

https://ldjam.com/events/ludum-dare/58/glow-hunt

https://ldjam.com/events/ludum-dare/58/gibberwave

https://ldjam.com/events/ludum-dare/58/tow-truck-debt-collector

https://ldjam.com/events/ludum-dare/58/fair-trade

https://ldjam.com/events/ludum-dare/58/staying-alone

https://ldjam.com/events/ludum-dare/58/pure-soul

Why did you make such a mess?

At least don't touch the link

https://ldjam.com/events/ludum-dare/58/violets-home

Since LD57 I've made a bunch of little tools and libraries for my engine (built on top of SDL2) to help shave off annoying or time consuming parts of game dev. I thought I would do a few posts talking about them. The first one is for creating immediate mode UIs, simply called MiniLayout (and LAYN internally which stands for Layouts in Nim). It's inspired by Nic Barker's Clay after watching a video on him talking through his algorithm.

Programming interfaces is a slog. I find them especially limiting in a jam since often the quickest approach was to just hard code things, making any changes later on a time consuming chore. My goal was to end up with something with minimal boilerplate. Just describe what you want to draw, automatically support things like text, sprites and handling interactions.

Here's a simple example and the code used to generate it:

``` frame: style game.sprites.fancycornersframe size 160, HUG direction VERTICAL padding 16 gap 8 shadow 0, 2 shadow_color CLIGHTGREY

for i in 0 ..< 3: frame: interactive buttontag[i] if hovered(): style game.sprites.rowhovered else: style game.sprites.row width FILL padding 8 gap 8 align CENTER sprite: content game.sprites.little_face text: content "Hello world!"

draw(game.layout) ```

To quickly explain what some of this means: - A frame is a container. By default it hugs its content, lays them out horizontally and has no fill color or style. (A style is just a Sprite pointer that is then used for ninepatch drawing.) - Sections like frame:, sprite:, text: are macros which begin a new Element of that type, make any further Element declared within its children and automatically call close_element() at the end of the scope block. - Interactive elements are given a string tag, like interactive "my cool button" which can then be later used to check the state of that interactive element. (if get_hovered(game.layout) == "my cool button": ...) - The library knows the current element scope as you declare them, so you can easily set parameters based on the interaction state with simple checks like if hovered(): ..., if pressed(): ..., etc. - Dimensions can be set to FILL to automatically grow to fill any remaining space in the parent.

Calling draw(), which takes a pointer to the MiniLayout struct, is used to finalize the layout and do the calculations before drawing all the elements. The multiple passes used for calculations are very similar to Clay (so you can watch the video above for more in depth explanation for most of these): - Widths are grown and shrank. - Text is wrapped. - Heights are adjusted to fit content. - Heights are grown and shrank. - Positions are calculated. - Scroll requests are handled. - Interactive elements are cached for the next frame.

The last one is really important because otherwise you have this problem: How do you know what's interacted with during a frame if you don't know how the layout will be calculated until all the layout is defined and drawn? So my solution was that all interactive elements have a lightweight copy of some of their important details (like position, interactive tag, size) kept for the next frame, which does introduce a one frame latency but I think that's a mild tradeoff for all the other wins introduced.

The lack of boilerplate is achieved through a few means: First, Nim has a lot of flexibility in its syntax. foo(bar), bar.foo() and foo bar are all the same and just based on your preference. While I don't normally use the last style, it's great here to reduce noise and give the layout areas a distinct different style than the rest of my code. Second, MiniLayout internally has a single private struct that all the parameter procedure calls operate on. So width 100, which is the same as width(100), operates on LAYN.target.cons.size.x where target is a pointer to the current Element in scope.

A side benefit to this system is you can define and draw multiple layouts per frame as you like, in between drawing the rest of the game. There's no conflicts because after drawing we no longer care about any of MiniLayout's state (except for cached interactive elements).

There's tons more not covered here. Like frames can be set as scrollable and automatically clip their scrolled content, interactive elements can automatically be navigated through on controller/keyboard with no additional code, absolute positioning with parameters like position RIGHT, TOP, text wrapping, etc, etc, but thought I'd keep it brief.

It's been a blast working on it so far and excited to use it more in the future!

Give a try to play my game in Web (HTML5) here!

Is this cover more eye-catching?

Play and rate Keklik, https://ldjam.com/events/ludum-dare/58/keklik

Day 1:

Work began, as it often does for us, with capsule people.

I often use these capsule people as placeholders during development as stand-ins until proper models can be made. In this case, they fulfilled their role as I implemented the first person controls. It'd been awhile since I'd made FPS controls from scratch so it took a little while, but eventually we nailed it.

The player and zombies were simple low-poly models to save time. I'm always wary of rigging an armature, but thankfully there was no issue this time - it worked as intended the first time. I don't remember why or when ragdoll physics became a mandatory feature in our game, but at some point it did, so I had to figure out how that system worked. This results in a range of goofs and gaffes, from characters melting to them going into spastic fits.

We eventually ironed out that the character animation system needed disabled along with the main capsule collider to prevent the model from going haywire. We also had to worry about the bodies trapping the player, so it was decided that the player wouldn't collide with the enemy models after they died, making body collection easier and preventing the player from getting stuck. At this point I began modeling the buildings for our city, and we shortly ran into a problem.

After making our hospital, I thought I might have spelled the word "HOSPITAL" wrong on the building, but blew it off as me being self-conscious. However, when @floata3 pointed out the same thing, it became an issue. We spent a good while trying to convince ourselves it was correct, even Googling it multiple times to confirm, but it never did look right. It was at that point we decided we were tired and needed to break for the evening.

Day 2:

Reconvening in the morning, work began on making the city zones that would comprise the individual levels. Rather than make them in Unity, I opted to build the levels completely in Blender and import them each as a single monolithic mesh.

Day 2 was almost exclusively level creation because each map took a good while to build and test. I did have to problem solve the difficulty level mechanism, since we'd decided to have the Easy difficulty only play levels 1 and 2, while Normal did levels 1 to 4, and Hard took the player to 1 through 6. My solution was tied into how I tracked the difficulty. The difficulty was logged as an integer, 0 for easy, 1 for normal and 2 for hard, so I created a list of next scenes for the game to go to after completing a level, and had it select the one corresponding to the difficulty level (i.e. Easy selected option 0 from the list, Normal selected option 1, etc.). A simple, somewhat elegant solution to a fairly simple problem.

Day 3:

The third and final day was audio day. I needed to record voices for the zombies and source a gunfire sound effect. I tried multiple ways to create a gunfire sound, but the best I could create sounded like a cap gun rather than a proper pistol, so I broke down and went to Freesound.org for a gun sound effect. @floata3 came through with the music, and with that, we were largely done. The final detail was a pair of volume sliders on the title screen, to accommodate individual players' preferences.

With that, Zombody's Business was complete, and its fate is now in all of your hands. If you haven't given it a shot, now would be as good a time as any!

Need more ratings to push me over the 20 mark in all categories. Pretty proud of the game this time around, so definitely want to get placed.

Play the game here: https://ldjam.com/events/ludum-dare/58/greedydude

Hi it’s us again lol
We made a game about mushrooms (and probably dog 🐕)

✅ timer hates you
✅ upgrades love you (and probably dog 🐕)
✅ in the end… Shroomageddon!

👉 Go play, become fungi!

PLAY our game

1.

2.

Monsters in Jars

Changelog 1.1

Small fixes for the ​​controls​​ and camera during Ludum Dare.

https://www.youtube.com/watch?v=b2QWXRexg

Hey, so, this are my game's current ratings: It's certainly better than what i had last year in LD 56 by this point, but i would very much appreciate it if i can get to 20 ratings, i'd honestly say there's a lot of better games than mine on this jam, but i still feel proud of what i was able to make. You can try my game here (i'd very much appreciate it): https://ldjam.com/events/ludum-dare/58/collectants