Hello everyone!

On Sunday, 13th of June at 16:00 UTC (18:00 Berlin Time)
Thunraz, Laguna and I are going to stream the awesome results of the Multiplayer Kajam.
https://www.twitch.tv/oobloodyorangeoo

We are looking forward to see you on stream! :)

Hello all!

Are you working on your game, hoping some day that it will be finished, trying to get it done? Join our secret game club, where you will find others who are working on their games as a sort of motivational club! Once a week, we have a meeting, in which we tell our stories, whether good or bad, and we support each other and listen to each others problems and show off our successes.

You can find more details hidden in the secret text document at http://laaph.com/tmp/gameclub.txt. If this sounds like a thing you would like to join, go to that link, follow the sekrit instructions found within, and ask me to add you to the server.

I hope to see you there!

Hi there,

So there is finally some progress. Not so much on the gameplay side, but the underlying mechanics are getting fleshed out quite nicely.

As we are aiming for a SHMUP game, the client really needs to feel responsive. This will be achieved by some clever client side prediction. This will only roughly be described here. For a full introduction, I recommend you this awesome tutorial here.
Basically the server but also every client runs on it's own pace and a slow client should not block the server or other clients. This means that some sort of lock-step implementation will not work for us.
Due to network lag, the client will always be behind the server and there is basically nothing that could prevent it. The idea is that the client predicts the movement for a certain frame 60. Then it sends out the input state for this frame to the server. Simultaneously the gamestate for frame 55 has arrived (due to network lag this will always lag some frames behind).
The solution now is that the player locally stores the game state as well as the input state for the past frames.
The number of stored input frames as well as the framerate determines what input lags you can compensate.

If a mismatch between the locally computed frame 55 and the received frame 55 from the server is detected, the client code now needs to roll back its simulation to frame 55 and re-simulate the input up to frame 60. This will then be used to display the player position.

To simulate network trouble, you can use a tool like clumsy. This allows to add arbitrary lag, dropped packets, throttle, limited bandwidth or even message corruption to your in or outgoing network packets. It works for ipv4 and ipv6 and supports udp and tcp. This is very handy for testing purposes.

Progress!

After Game Center match making, I now have some interactivity: choose your ship's heading and thrust.

• It's a lockstep setup with input delay (currently two steps). Only input is synchronized between clients;
• Simulation updates every 0.1s (and waits if input doesn't come in);
• The "physics simulation" should be deterministic if Double acts the same on all iPhones/iPads.

Improvements:

• It's not a game yet: no win/lose condition;
• When it comes to network: current implementation uses tcp/ip and sends input as JSON to other clients. This should probably be optimized;
• There is no graceful end of game: only stop the process.

My current plan is to use the haxe programming language to create my kajam entry. In theory I can write a single codebase that can be compiled down to a headless (no graphics) server to run in the cloud, while having that same code be able to produce the playable version of the game. In order to get multiplayer support in the browser, I'll also be using websockets.

But more importantly I want to be able to quickly iterate on my entry during my free time, so I've set out to automate as much of the build and deployment workflow as possible. Nothing fancy, just a makefile that builds the server, deploys it to the remote server and launches it. I can then launch the client on my local machine and see messages passing between the server and client, which seems like a pretty important precursor to a remote multiplayer game. Testing with a local server on your development machine is OK but bypasses a lot of the issues that can occur with a 'real' server out on the interweb.

The test was successful but revealed that terminating the server on the remote server left a zombie process sitting on port 8000, which means that attempting to run the server again would fail as the port was unavailable. This behaviour didn't occur when hosting the server locally, so there's some instant proof that it's worth testing on as realistic a setup as possible. Hooray.

So I am joining the Multiplayer Kajam.

Tools that will be used:

• C++
• My self-written Jam Template, based on SFML
• Visual Studio & Visual Studio Code
• Aseprite for graphics

We will join in a team of three

• Thunraz
• BloodyOrange
• and Laguna

We started yesterday evening and already had some trouble with our ISPs. One was configured to use only IPv4, the other was configured for only IPv6 (with an ipv4 tunnel). We found a way around that, where the only restriction is that I cannot be the host, but we can work around that as local testing is still possible.

I wish everyone best of luck for the jam!

So, I finally managed to get working:

• Game Center Sign In in SwiftUI
• Matchmaking
• Start a match
• Exchange data between clients (just some strings with random data for now).

This means I can start making a multiplayer game!

Because Game Center is strictly peer-to-peer out of the box, I'll try and implement a deterministic lockstep mechanism. Hopefully the Swift Decimal type is stable accross architectures.

This is a living list, gathering links suggested by the community. Please share your recommendations in the comments section or Discord, I'll update this post accordingly. Thanks!

General purpose

• What Every Programmer Needs To Know About Game Networking
• Making a Multiplayer FPS in C++: Series of articles about designing the networking for multiplayer games. The examples are in C++ but the solutions can be adapted to other languages.

Unity

• Mirror (Docs, Pong example): Free Networking API designed to be ease of use, it reportedly has a good reputation.

• Mirage: An allegedly improved fork of Mirror, with more features

• Photon Bolt (Official tutorial): Offers cloud hosting for game servers, with a free plan that is more than enough for a jam game.

• Forge Networking Remastered

• Article: Choosing the right netcode for your game (compares MLAPI, DarkRift 2, Photon PUN, Photon Quantum 2.0 & Mirror)

C/C++

• Beej's guide to network programming: A popular and thorough introduction to networking in C
• Curated list of networking resources for C

I just finished a video that covers and explains the development of Wandering Soul from the top level!

Didn't make it up in time for the 48hr deadline, but at least uploaded for the Unranked section. Although I think I must have accidentally set it up as Solo and now I can't change it, maybe Monsieur Admin can help me set it to unranked as it should be please :) ?

I feel like I should post something about lessons learned, but I make the same mistakes every jam so lets not pretend next time will be any different.

• Used the less than most stable version of Unity that gave me no benefits and might have wasted a bit of time wondering why setting the font sometimes worked and sometimes didn't.

• Spent too long drawing pixel art tilesets that didn't actually work anyway, too much time drawing assets that are hardly ever seen and not enough time with the ones that fill the screen like 95% of the time.

• Gameplay is not that interesting, didn't worry too much about combat not being that exciting because I thought "ah its not really about the combat" but actually didn't have time to add that non combat stuff anyway, so it sort of is about combat, but either way if you have a mechanic you might as well make it as interesting as it can be, and if I had spent more time play testing earlier I might have realised there was some quite easy stuff I could have done to make it more strategic and interesting.

Anyway next week starts the 7 Day Roguelike so maybe I'll make a sequel for that and expand it with some more interesting mechanics and maybe even procedural levels.. sounds like a stretch already.

Anyway despite all the usual issues I still had a lot of fun making a thing

P.S I'm still working on the previous raycasting jam too ….if that ever gets to be playable I'll post a link.