This is my first alakajam, iam making games on my own for such a while and i wanna see what i can do in this jam.
iam really exicited for this jam. i will do as much as i can for this jam
I love to use opensource tools, and also to make opensource tools.
I love HAXE a cross platform programming language, and i really love to use HAXE.
so here is what iam gonna use to make my game.
OpenFl : haxe based 2d graphic library
Sublime Text 3: for programming
Piko Pixel: for drawing 2d sprites
Beep Box: for music and sound effects
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.
We are looking forward to see you on stream! :)
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!
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.
After Game Center match making, I now have some interactivity: choose your ship's heading and thrust.
Doubleacts the same on all iPhones/iPads.
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:
We will join in a team of three
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:
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!
Article: Choosing the right netcode for your game (compares MLAPI, DarkRift 2, Photon PUN, Photon Quantum 2.0 & Mirror)