I'd been wanting to do some multiplayer game dev, so this theme is perfect! I'm making a web game where you can control a blob and shoot at other blobs. Still rather unfinished, but playable here. I think the networking… kinda works?

🐮 🐮 🌿
Networked multiplayer racing!

The 13th Kajam coincides nicely with the Dos Games June 2023 Jam, so maybe I'll make a DOS based entry. This might make any kind of networked realtime multiplayer quite complicated to implement, unless the game is hosted on a BBS or something. Maybe I'll create a 'play by mail' game where each player takes their turn and then emails the save to the next? Interested to hear what everyone else's ideas and plans are

The jam is over. Long live the jam.
Great job everyone on submitting 21 awesome games. And a big "thank you" to everyone for playing the game of reviewing and rating and commenting each other's entries. You can find the full rankings below.

Solo winners | Team winners | Unranked games

Big congratulations to all the winners!

Dates of the next Events

The next Kajam will be a Multiplayer Kajam. After the awesome success of the last Multiplayer Kajam, we decided to go for another round in the month of June 2023 for one month of relaxed gamedev and a joint online gaming session. So make sure to book the date. Hope to see you then :)
Click

In September we will have a feedback fortnight and End of October there will be another Alakajam, but there will of course be separate announcements for those events.

If you want to stay up to date, join us on Discord

The Theme for the thirteenth Kajam is “Remote Multiplayer”. This relaxed, month-long event will start on the second of June 2023 and last until the second of July. There will be no ratings, but a dedicated gaming session after the jam.

https://soundcloud.com/laguna_999/kajam13-keynote-multiplayer

What does “Remote Multiplayer” mean?

By definition multiplayer means that more than one person can play in the same game environment at the same time. Remote means that you play together over some sort of network and that you don’t have to sit next to each other.

What might sound as a daunting endeavor, is the chance to start thinking about games you usually wouldn’t do on a GameJam. Normally GameJam entries specialize on singleplayer experiences.
However multiplayer games allow for quite some different gameplay and a lot of unique situations for, well, multiple players.

This Kajam is all about multiplayer.
Let’s learn about the technical details of multiplayer games, like network protocols, serialization, buffers, lag prevention and other topics!
And most importantly: Let’s have some fun while creating and playing multiplayer games together!

What are the rules?

For this Kajam you can work solo or in a team.
You have four weeks to create and submit your entry, starting on the second of June 2023 and ending on the second of July.
Every Language, Framework or Engine is allowed.
The use of third party assets is allowed. You can even add multiplayer functionality to an already finished game!

Detailed rules here

Now, start your engines and join this Kajam!

The gaming session sounds great! How can I join?

Thank you! The gaming session will happen shortly after the end of the Kajam. A poll for the date will be sent out right after. We will meet online at the alakajam discord server and have fun playing the games which were created during the jam and have a great time together. You are very welcome to join even if you did not take part in the jam.

I will try and put up a post mortem at some point. Maybe I'll even get a finished game out.

For now I'll try to play and rate as many games as I can.

I knew I wouldn't have enough time, but I also know I can make quick simple games in a short amount of time. So of course, I decided to make an open world multiplayer roguelike deck builder, that should be quick and easy! I am not certain if I wrote a single line of code, but I did throw a lot of things in to Unity and made a mess. So, there is no playable game, but at least I can put up a screenshot.

The images are all done via AI programs (specifically Diffusion Bee), except the lizard comes from the Liberated Pixel Cup Character Generator and the card frames come from CraftPix

I do have a theory that game jams are not always about making useful things, but just taking ideas and throwing them at the wall and seeing what happens. It's art, as they say. So, there you are.

That's it, all the games are in - well done everyone! Now it's time to play and rate each other's games!

Constructive feedback is one of the best ways to learn and improve your game design skills, so please dish it out in buckets. If you haven't submitted a game yourself, you can still play games and leave feedback, the only thing you'll miss is the ability to rate games - so please do play and comment everyone!

The voting phase lasts until March 12th, when the ratings will be counted and the top 3 of the solo and team categories will be crowned!

Go go go! Play and rate games!

Having taken part in every single main Alakajam event until now, it sometimes feels like I'm getting stuck in a rut. So this time, I decided to shake it up a little by (a) using the latest Godot 4 release candidate, instead of the stable 3.5, and (b) going full 3D instead of my usual 2D style:

I had a slow start due to other obligations, which gave me some time to think about the game design. Most of that made it into the final game, but I had some ideas that didn't work as well as I'd thought.

Originally I had implemented tiles with forks (three exit points). The idea was that the river goes down a slope, so the boat would always pick the most downwards direction. If there were multiple options, it would choose randomly. This means the player would need to take both possibilities into account until the boat had made it to the fork. However, it was still possible to make a corner where the river is forced to go upwards, which then wouldn't make physical sense. Should the boat get stuck, or start moving against the flow? Neither would be a great option. Moreover, I found during playtesting that it was easy to always point the "unwanted" exit point upwards so that it always got ignored. We could also say that the river is on a flat plane, and always choosing a random fork regardless of up/down direction, but this made the game too unpredictable.

The other idea that didn't make it was multiple boats. This would have interacted nicely with forks and joins: you'd have to make sure that the boats didn't collide. You could send both down the same path, making it easier to manage, or maintain two parallel paths to increase coverage for collecting stars. I think this idea could have worked, but didn't implement it because time was up.

Godot 4 was a very smooth experience. My entire X server crashed once, but that's unlikely to be Godot's fault; otherwise everything was pretty stable. The editor feels snappier than Godot 3 and has grown a couple of new useful features. I had some trouble with the export, but it turned out it was my own fault. I was listing files in the levels/ directory to enumerate levels at runtime, but didn't realize that the file names change upon export. Easily fixed with some hardcoding.

Working in 3D was the challenge. Having worked with Blender years ago in the days before the huge 2.5 overhaul, I had to re-learn it on the spot. Fortunately I only needed basic mesh creation and manipulation facilities; everything else could be done in Godot, including textures and materials.

Several hours went into writing shaders. The water shader is the most apparent one. It takes two noise textures, A and B, and lerps between them, using a sawtooth mix factor that ping-pongs between 0 and 1 over time. When the factor is 0, texture B (which is entirely invisible at that moment) is translated to a new location, and vice versa. This avoids a repetitive effect.

The other shader, which is not nearly as apparent, is the one that draws the terrain. The albedo comes from another noise texture, which is put through a gradient map to get some colour variety. Another noise texture is used as a normal map. That same texture is also used as a height map to displace the vertices. You might think I just produced three models for the three different tile shapes (straight, obtuse corner, acute corner), but no: the river is also carved out using the shader.

The water on each tile is just a single plane mesh that intersects the terrain. Unfortunately, that means you can see its edges glitching through the side of the tile sometimes. The obvious quick fix of shrinking the water mesh slightly resulted in the river having seams, which looked worse, and I had no time to fix it properly. The price for working in 3D, I guess.

All texture sampling is done in world space coordinates so that tiles and water match up seamlessly. However, for the tile queue on the right and the "ghost" tile attached to the mouse cursor, local coordinates are used so that these tiles don't seem to change while they move. As a result, when you place a tile, it switches from local to global coordinates and does change shape a little, so I put some smoke particles on top, tweened the vertical coordinate, and added some camera shake, all to make it less noticeable.

Changing the colour scheme for each level was an addition half an hour before the deadline. It's a pretty quick way to add some variety. Because it was done in such a hacky way, the colour of the river on the main menu also changes according to which level you last played, which is actually a bug but I'm branding it as a feature now!

Play it now!

I'm proud to say we uploaded it on time (kind of) .
It was a team effort and wow those were some very intense 48 hours.
The game is far from ready, but we handcrafted the pixel art, the story and the background music. Given that, I think the result is very good.

Enjoy playing! There's no tutorial level, so look out for an explanation in the description.