This is my first game jam ever and I'm super excited.
The documentation states:
You are also allowed to use:
how does this apply to my own pre-made fonts?
Graphics Library: PyGame
IDE: PyCharm (community edition)
Sfx: I don't know yet…
Graphics: Px Editor 4.2 (improved version of @DaFluffyPotato's Px Editor 3 )
I will not be able to do anything on Sunday so here are my goals:
This will be my first Alakajam I've ever done! I've done Ludum Dare before and also gm48() but I haven't worked on a game in a while and I want to get back into the swing of things. I'm fairly busy this weekend so we'll see how much progress I'll make. I always set my scope too large when doing game jams, so my primary focus is going to keep reeling in my scope so it'll be possible for me to finish. I'm excited to see what everyone makes, have a good jam!
My first Alakajam - joining solo to spend my weekend doing something creative! I've dabbled with some games a bit at home but never really finished anything so this will be good to be forced to finish something against my will.
Game Maker Studio 2 for code/graphics
Audacity + lots of distortion for audio (and whatever else I can cobble together)
Looking forward to seeing what everyone comes up with :)
Well it's supposed to be raining the whole weekend so there's a good excuse to avoid people for a while :)
This time I think I'll go with C++ and SDL2. My previous jams were done using LÖVE which is great, but a bit unpleasant to debug. I think I'll go with something really simple this time though.
Stuck at home for a few weeks as I recover from a minor surgery, the 12th Alakajam seems a lot more fun than lying in bed all day : )
I've never entered an Alakajam before, but the community, website, and everything overall looks super nice. Good luck everyone!
graphics: blender (3d) / libresprite (2d)
sound: fl studio, bfxr, audacity
also running herbstluftwm & manjaro
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.