Advice to anyone showcasing your game. Put some screenshots front and center on your landing page. Most people have limited attention spans, and you have just a few seconds to get a visitor’s attention.
Did you notice this page is a git repository on Codeberg and that a screenshot is right at the top of the repo readme, the first bit if content they control? It's not a marketing landing page.
Yeah, I think he (like me) is wondering why this is the page that OP decided to post to HN for this game and not something with some valuable information about the game.
It's not like we're all going to go download the source code and start playing or contributing to a game we've never heard of and know nothing about.
Given the state of the project, they are mostly looking for contributors instead of players, so linking to the codeberg page is actually the right thing to do, I'd think.
It's interesting because there's not a lot of Godot 4 game examples out there (Godot 4 being still in Alpha and it has many API changes versus Godot 3). The target audience is indie game developers, not gamers. So linking the repo makes sense.
Hi! I'm unfa - I'm the Liblast project lead :)
There's a small team working on the game at the moment.
We had no idea our game has been linked on Hacker News, but we've got a lot of people coming to play and talk about the game today, some expressed will to contribute - that's fantastic :)
We're in quite early stages of development, as the game is far from feature complete and stable - working on Godot 4 engine which is still very much in development doesn't make that any easier, but we're helping the Godot team fix issues as we go.
> It's not like we're all going to go download the source code and start playing or contributing to a game we've never heard of and know nothing about.
Personally I’d love a new “party FPS” on consoles that handles split screen deathmatch competently with bots. There are almost no games on current consoles that do this AFAIK, and the few that do are ports from older systems (e.g. Perfect Dark).
People seem to remember the good old days of local DM with friends in Goldeneye and old Halo games pretty fondly, so I’m not sure why there are a million new retro indie FPSes but seemingly nobody targeting this niche.
The control clunkiness is part of the advantage of it being a party FPS, because it compresses the skill spectrum. The difference between a strong and weak Goldeneye player is considerably less than the difference between a strong and weak player for twin stick FPSes.
We're very happy that our game was hilighted in this community, and we've seen lots of new people trying out the game, getting in touch, asking how they can contribute - that's awesome.
Thank you :)
If you're interested in what the game is about and why should you care about yet another open-source multiplayer FPS, this video I made should answer that question for you:
https://youtu.be/JAQH2AVvKhU
The game is quite limited still, but we've got a small team and just today we've had another team meeting and we've just started working in 2-week sprints. If anyone's interested in contributing - here's a public channel on my Rocket.Chat server where you can reach out: https://chat.unfa.xyz/channel/liblast
Note that the server is mostly about open-source audio production as that's what my primary YouTube channel is about :)
I enjoy it and have (some,little) experience with it. I'd love to team up to build a little project. I'm good at project management and I can propose mechanics. I also can (little) code.
j at costantini dot pw . Italian time zone.
Hey, I'm unfa - I am the lead of the Liblast project.
If you're looking for a project to join, we're looking for contributors :)
In this video I talk about what do we want to achieve and why:
https://www.youtube.com/watch?v=JAQH2AVvKhU
Yeah, we hope the game will be useful learning or forking material for other libre or indie game developers.
We wanted to make something fully original (even if open-source) and using the best libre technology available. Hence: Godot 4.
We're tired of endless boring Quake clones and rehashes on the same old engines.
If you'd like to learn more about why this project exists and what do we want to make, this video explains is:
https://youtu.be/JAQH2AVvKhU
Xonotic has been around for a long time. It's a fork of Nexuiz before the devs rewrote Nexuiz in CryEngine 3 and took it closed source and commercial.
Honestly I think it's probably the best libre FPS out there. I wish it was more popular, but considering how poorly the new Unreal Tournament did, I honestly think the general gaming community isn't interested in quake style games anymore.
Another sort-of-game I like is AlephOne, which is an open source implementation of the engine for Bungie's Marathon games. I believe Bungie released all the marathon assets as "free for non-commercial use". There's also some very fun open source campaigns on it.
I've been playing Xonotic for many years, but there's some things that I believe are holding it back. Same goes for other libre FPS games we have like Alien Arena, Sauerbraten, Tesseract, Red Eclipse, Warsow/Warfork ...
If you're interested, here's a video where I discuss that:
https://youtu.be/JAQH2AVvKhU
I would love a modular version, where maybe you allow reuse of some of the networking features under MIT. But I also understand not wanting to spend a year or so of your life for some opportunists to just rebrand it and sell it.
Even though I'll probably work with Unity for now, I'd much rather there be some competition in the space than not.
We're licensed under AGPL + CC-BY-SA in order to ensure the game cannot be hijacked and rebranded, but also to make sure it will stay open-source (including any server-side software) in case whoever wants to fork it.
The game may possibly become a template/baseline for other games to be made based on it in the future, as there's a lot of common features need for multiplayer FPS games, and re-implementing all of them every time you have a cool idea is kinda silly. So we hope a lot of indie game devs will want to fork our project and have some fun with it.
Though we still have a long road in front of us - there's a lot that needs to be done!
If you'd like to be a part of this project - we're looking for contributors, especially GDScript programmers :)
I'll take a look at the code when I have a bit of free time.
I consider myself to be a pretty good programmer, I do love python, which I believe GD script is basically based on. But I haven't touched Godot at all so I don't think it would be a good idea for me to immediately start putting in PRs.
Keep going though, we desperately need more competition in the engine space. Unity is good for now, but the company itself becomes more and more hostile to developers every single day.
We've have been bundling Godot binaries, but that's already been cleaned up.
We're hosting the currently used builds on a VPS now, you can get the current one by running the `download.sh` script in `Godot` subfolder in the repo. This lets the Liblast team easily update the editor and stay in sync.
Unless you're talking about something different? :)
yeah, I kind of know vulkan is picky since it is very close to the hardware, the hard lockup is never far away, and better use it in a very conservative way, no fancy stuff.
Aside of this, there is also the distribution of binaries with best compat across linux based OSes. For instance, with GNU symbol versioning and IBM/redhat symbol version frenzy, 1.5 year old glibc distros won't run games built with a today glibc (aka shooting linux gaming in the foot).
The idea is to iron out such issues:
- pure ELF64 set of binaries, namely does not use main(), but the hw ABI entry point (on linux/sysv this is almost a straight main()). Manual linking of the game binaries (don't rely on the compiler driver default objects).
- all distributed binaries should "libdl" everything they need from the system, including the libc. It means only libdl should be in the ELF static loading section (except the distributed SOs), and all binaries should have only dlopen/dlsym/dlclose undefined symbols in the ELF dynamic section (except the symbols from the distributed SOs).
- don't use ELF symbol based TLS (Thread Local Storage), but pthread TLS, because ELF symbol based TLS is nasty (would need to parse the ELF headers to get some offsets then call the ELF ABI TLS func to resolve to the TLS variable).
- static link as many as possible "libdl-ized" third party libs, and yes, this include a libdl-ized fork of the static c++ runtime you use, since godot is c++.
- wayland(libxkbcommon)->x11(libxkbcommon-x11/xcb) fallback
- vulkan->GL(->CPU) fallback
- libasound only (pipewire/pulseaudio will be hidden behind the alsa API if there, and it could be dmix/dsnoop).
- joystick support directly via /dev evdev devices, and hotplug with direct kernel netlink event (avoid like hell udev) or inotify or polling the /dev/input directory.
If this work, distributed binaries should be rock solid in time and across many types of linux based OSes (even musl lib one, in theory).
Well... As a favour in return (:]), though the code is still early, what do you think of Godot 4 when compared to 3? I'm trying to finish a project with 3, because I know how unstable the master branch can get, but wonder if 4 will be worth the hype?
Godot 4 brings a lot of revolutionary changes.
Apart from simple things like Copy/Paste for nodes in the editor between scenes and being able to have multiple windows, there's big stuff like:
- the Vulkan renderer being able to scale up much more than OpenGL
- Automatic LOD system that generates and automaticlaly uses decimated models to remove unnecessary geometry detail at distance
- Occlusion culling, doing what BSP room culling in Godot 3 does only better and with less manual work involved (Liblast is using that to separate rooms) - also being suitable for outdoor environments
- Fully real-time global illumination with SDFGI + physically-based sky texture = easy day cycle with fully dynamic indirect lighting
- Volumetric fog + fog volumes that can be controlled with custom shaders
- Much more powerful GPU-accelerated Particles with collision and forcefields
- Fully dynamic shader-based projection decals allowing for detailing the world or adding dynamic destruction marks in the world
- Overhauled networking with a new Scene Replication function, making multiplayer development even higher level in Godot 4 (we still need to update to use that one)
- countless more improvements
The downsides are bugs, crashes and the fact that things still change a lot so sometimes we need to update our code to the new GDScript syntax etc :)
This is more of an educational/for the sake of it project than anything else. Something that fits in perfectly here. It's not trying to attract 9-year-olds who scream insults about your mother down the mic at you.
I very much understand that having "libre" in the name throws you off, because that phenomenon is a part of why we're doing this project :)
Most FOSS games don't have an original idea and don't have a good direction. A lot of open-source games are just inferior remakes of existing proprietary games.
We intend to do something different and hopefully something much better.
But we're very early on this path still.
If you'd like to learn more about why this project exists and what is the idea behind it, here's a video where I explain just that:
https://youtu.be/JAQH2AVvKhU
