Liblast is a free and open-source multiplayer FPS game made with Godot 4 game engine and a fully open-source toolchain. The project is non-profit, but we do accept donations to cover server costs etc.
> "Liblast is a non-profit project aiming to build a free and open-source game using a *fully open-source toolchain."* > Never says anywhere what tools are in the toolchain
You're right. I should put that on the website. The exact toolchain is evolving, but the basics are not going to change much: - Godot Engine - Blender + free add-ons like DreamUV, TexTools - Material Maker + possibly custom nodes for the project - Inkscape for UI and other 2D artwork - Ardour for music and SFX + libre plug-ins like Vitalium, Surge XT, Geonkick, Airwindows, LSP etc. - unfa
Movie Maker mode as in all preset or did you find out how to use the cinematic renderer for real-time gameplay? If so let me know cause I am legit trying to see if this is even possible since I heard it technically was but with some performance degradation.
I also got to this point with godot, once I started doing client-server reconciliation it was troublesome due to the lack of types in gdscript, direct thread support and debugging. I restarted in c++ after that using enet and spdlog for debugging and made it through, but I hope you can make it through with godot!
having the server moving each character on input sync is quite a nice progress, congrats! ofc the client should move has well for seamlessness, but shouldn't the clients sync their positions from the server (as it's the "ground truth") and interpolate or tp if difference is above some threshold ? might eventually be easier to test before having the server handling orientation from client mouse input sync-ing but again quite a nice work there! from the project files I've seen everything is well designed and compartmentalized 😁
I can guess few things. There are video lesson for multiplayer. If I can remember you need to change the collision 2 instead of 1. It happen to me when spawning players. As for the spawning. I think it the remote and server is mixed up. Plus you need to set up debug GUI for testing. I can guess you need to store player list. Plus you need to broadcast and check for ID for players when assign and broadcasting. Just a guess.
So glad you guys are still putting your full effort into this rewrite! Sad that I can't in development anymore because of work. Looking forward to playing it when it's playable! ~kevs404
I am sure it will be possible at some point, but it'd most likely require re-building the level to work in Liblast. Also Xonotic uses the legacy shading model (Diffuse+Specular) while Godot is using PBR, so materials would need to be converted, or better - made from scratch. The game is being re- built with modding in mind, so there will be options :) - unfa
43:04 you transfer a hashed password from the client to the server and check it on the server without any additional calculations - theoretically this is not very secure, since if an attacker gains access to the database, you will have to force change all passwords, otherwise the hacker will be able to log in under any account simply by passing the password hash to the server. A solution to this could be additional password hashing on the server side, so that the server does not store the original data for authorization.
Hey, thanks for all the input on security! This implementation is long gone, and we'll be using a 4rd party FOSS solution called Nakama that will handle a lot of things for us. But of course the way we interact with it passing user credentials etc is still very important.
13:12 I think it would be easier to create not a black list of letters that are allowed, but a white list of characters. I don't think you would want to have a username with emoji or other special characters. I also think that it would be more convenient to put the list of prohibited usernames in a separate txt file or something like that, and load it once when the server starts. This way you can always expand the list of prohibited usernames, for example by adding curse words or something like that.
10:12 in fact, you are sending a response not to the person who sent the request, but to the person indicated in this request? It seems to me that this is not safe, since the client can replace this data, isn’t it?
That's correct. Yeah, using the `multiplayer.get_rpc_sender_id()` method to be certain about this would be better. Or even better - compare the two and note that there was a mismatch as that could indicate someone trying to mess with the system.
Funny how You called godot editor a game. It is not a game, it's the editor of the engine. But it feels good to use. For us indie developers godot simplifies some things that are really useful, and it is OPEN SOURCE
Do the shell casings write to depth and motion vectors? It's particularly interesting how the ghost trails only appear in front of the noisy normal mapped parts of the wall. The flat parts render correctly.
I love Godot, but I don't really understand why they chose to roll their own language and certainly don't see it as a pro for them. Not only do they have to waste huge resources maintaining, bug-fixing, evolving and create tooling for GD Script, but it kind of sucks for devs too because we have to learn a new language that becomes useless when we stop using Godot. Also it's indentation based 🤮
me as Android experience is so easy i mean very easy learn Godot why because if u watch short u ar now pro Godot engine and others engine cry in corner
Is the games bad performance the fault of Godot or the code? I am just curious the game runs quite bad on my powerful system, like 80 FPS which would be okayish but a lot of stutters. I have a RX 6800 and Ryzen 7 3700x. I am just curious because I want to make a game in Godot, but I want it to be performant at least even if I try to do a lot with it. I feel like GPU part is badly optimized in Godot or the game, have you done LODs etc.? How much thought did you put into it. I will say I am using the debug build, because for the life of me I couldn't get it to build and run for some reason on NixOS
4:04 I disagree that no other languages were suited. Lua has been integrated into game engines and used to make games for decades. Maybe Godot team could have focused on delivering more valuable features instead of inventing a scripting language that no one wants to learn.
Or maybe - Godot developers decided that the convenience of using an already developed language is not worth the frictions and hard edges that it will inevitably cause. It might also be that Godot is just not for you, because a lot of people don't have a problem with learning GDScript if that's what it takes to use this engine. And it's really not hard to get started. - unfa
7:20 Virtual Machines are your best friend.... and program into your code hash maps with keys and for shiggles slap in variable randomization sequences such that 3 variables = the real variable and those variables flip between each other such that it's unreadable to hex editors. Also watching for code injection in the registry for your game is pretty important. Don't host any data on the players client, all changes are made by function calls made by players client for actions, nothing more, nothing less and those functions must call on exact functions for an exact transaction that has a timer so they can't be spammed.
I think it's neat to have the "old" codebase visible as well as the new, cause as you'll work through this rewrite/refactor, people will be able to compare, see what you changed, how you changed it. Very important for people to learn by seeing refactoring in practice.
@@liblastI'm not a git expert sadly :/ Leaving the old code with assets available in some form would be neat for the reasons I mentioned, but then if you have cost/storage space issues, do what you can ! As I've mentioned on Mastodon, in any case, I wish the team the best for what's next for Liblast !
@@liblast One thing you could do is squash the history of the "legacy" branch into a single commit. This should help if there is a lot changed or removed assets/binary files in the history. So after the squashing, it would only take up as much as the current version of the project does. There are also many ways of hosting the files themselves separately from the code (but they are often a bit painful to use). If it sounds like something you want to try and you'd need some help, let me know
The fact that your fedi instance's COC is not just a single rule (don't post anything illegal) and it has a substantial defederation list discourages me from wanting to contribute. Without a commitment to free speech, the project is at risk of being dictated by cry-bullies. Emotional manipulators are a common reason for the demise of many FOSS projects.
I used dumpest way. It fits my game welll) actualy its pretty minimalistic and I like It class_name ButtonSounded func _ready(): connect("mouse_entered", mouse_enter) func mouse_enter(): core.sound().hover()
Is it something to do with when the text_changed signal is emitted? I'm also wondering if this script could be directly attached to the ui_theme? Sound should be an attribute of the button class.
Help me with the code please, Godot 4, MSAA simply doesn't give an error, but on the other hand it has no effect. This is a slide button: func _on_msaa_value_changed(value): match value: 0: RenderingServer.viewport_set_msaa_2d(Viewport, RenderingServer.VIEWPORT_MSAA_DISABLED) 1: RenderingServer.viewport_set_msaa_2d(Viewport, RenderingServer.VIEWPORT_MSAA_2X) 2: RenderingServer.viewport_set_msaa_2d(Viewport, RenderingServer.VIEWPORT_MSAA_4X) 3: RenderingServer.viewport_set_msaa_2d(Viewport, RenderingServer.VIEWPORT_MSAA_8X) 4: RenderingServer.viewport_set_msaa_2d(Viewport, RenderingServer.VIEWPORT_MSAA_MAX) Checkbox for FXAA: func _on_fxaa_toggled(toggled_on): if toggled_on: get_viewport().SCREEN_SPACE_AA_FXAA else: RenderingServer.VIEWPORT_SCREEN_SPACE_AA_FXAA
