Liblast - a FOSS multiplayer FPS game made with 100% open-source software
New update: 0.1.5 pre-alpha!
https://codeberg.org/Liblast/Liblast/releases/tag/0.1.5_pre-alpha
We've also had a public playtesting session, with 8 people playing together at one point (4v4). nothing crashed, the server seemed to be able to keep up. I call this a success!
- Edited
if i find some time i could make some fp weapons and animations for u if ur interested.
i like the foss idea of your project, id only ask to be credited in the contributors or credits menu.
the game doesnt seem to have an artstyle yet. would be fun to design some weird guns.
- Edited
DJM Hey, thanks!
I'd be really happy to work with you or gun designs
The game doesn't have a clearly defined artstyle yet, though I have some ideas. one of the primary goals I have in mind are:
- visual clarity and readability
- utilizing the PBR model but with restraint (mot detail in roughness and normals, leaving albedo on low contrast to not be visually overwhelming and noisy).
- deliberate use of color
- Sci-Fi with self-aware humor
As for the weapons - I have some ideas base on the game's story, here's some resources:
- https://codeberg.org/Liblast/Liblast/issues/335 (weapon ideas)
- https://codeberg.org/Liblast/Liblast/wiki/Story-&-Lore-%5BSPOLIERS%5D (full story for context)
All contributors are listed here (I think adding an in-game credits screen that uses this is a great idea!):
https://codeberg.org/Liblast/Liblast/src/branch/main/AUTHORS.adoc
The game is licensed under AGPL + CC-BY-SA to protect the artist work (as well as game's openness in case of forks), while remaining an open resource for other FOSS games.
If you'd like to talk in a more immediate way, we have a chat channel on my Rocket.Chat instance:
https://chat.unfa.xyz/channel/liblast
Also available through Discord:
https://discord.gg/4hZZhf5x5D
- Edited
unfa The game doesn't have a clearly defined artstyle yetβ¦
Well the first idea is that it is desirable to make robots in the style of T-800 or Adam Smasher.
A Rocket Launcher or Grenade Launcher used to uh... blow holes in rock I guess?
It goes back to the idea of destructible levels.
A modified welder?
A weird flamethrower - some kind of short-ranged metal-melting tool for extracting metal ore, breaking heavy rock or stuff?
And that requires melting the affected enemy model.
All of this will make the game much heavier and more complex.
The big challenge however is to ensure game updates won't break existing mods.
I imagine this is extremely difficult to do.
Tomcat in the style of T-800 or Adam Smasher.
I'd be wary of using the style of others IP's not that it's a definite problem but it has the potential to be.
i only have discord.
that discord server is more about music or am i wrong? where do i post? in the subsection of liblast?
ive read the game design doc,
u want 3 types of playables, light, medium and heavy, each with a specific weapon and they all have the same secondary sidearm and melee weapon.
so thats' basicly 5 weapons as of now. i would stick with that as ive seen u want to support modding.
do u have some art references to give me a better idea what ur looking for? scifi pbr with minimal colors isnt saying much.
if i were u, i would stick with the proven working equivalents in fps games of knife, pistol, shotgun, smg or assault rifle, rifle(scoped or not), rocket (or grenadelauncher).
but in a scifi setting with a weird twist.
Megalomaniak I'd be wary of using the style of others IP's not that it's a definite problem but it has the potential to be.
Well, I meant for the characters to be more robot-like. Smasher's not a problem, is he? But he's, like, a T-800 in style.
- Edited
Tomcat A Rocket Launcher or Grenade Launcher used to uh... blow holes in rock I guess?
It goes back to the idea of destructible levels.
Game story and game mechanics are separate
That was an explanation of why are there weapons of this kind present in the game, not what they'll do in-game.Tomcat A weird flamethrower - some kind of short-ranged metal-melting tool for extracting metal ore, breaking heavy rock or stuff?
And that requires melting the affected enemy model.
Again: story explanation of weapon origins vs use in-game. No fluid physics for whatever you hit with the flamethrower if we'll have one
(unless someone comes around to make that work )
Tomcat The big challenge however is to ensure game updates won't break existing mods.
I imagine this is extremely difficult to do.
Yeah, this is going to require some prototyping and solid testing before it's marked as "good to go". Nobody likes when their work suddenly stops working because of a game update, though to some extent it might be unavoidable. But at lest it should be possible to minimize this.
Probably it'd require to codify versions and provide backwards-compatibility code to still read and work with data made on old versions of the game.
DJM that discord server is more about music or am i wrong? where do i post? in the subsection of liblast?
Yes, you are correct I've mentioned you in there before I read your reply here.
DJM do u have some art references to give me a better idea what ur looking for? scifi pbr with minimal colors isn't saying much.
I should try and make a moodboard - this is something on the backburner, as I'm mainly focused on getting the game functional, but art direction is something I want to treat seriously (I'm an artist after all) - I am hoping someone might want to help out with that - it'd speed things up.DJM if i were u, i would stick with the proven working equivalents in fps games of knife, pistol, shotgun, smg or assault rifle, rifle(scoped or not), rocket (or grenadelauncher).
but in a scifi setting with a weird twist.
Yeah that sounds like the best course, t least until 1.0 is out
So far there's a basic handgun and an SMG - these are all placeholders for now.
So you know that my idea was to have a light, medium and a heavy class for 1.0 (possibly more in the future, but it all has to be balanced and fun, not just hastily added in for the sake of having more stuff) with 1 unique gun each for version 1.0 of the game.
That's a minimum viable product really - if it's possible to do more, like add fun and balanced secondary modes to the primary guns fro each class or make unique secondaries - that's great!
I guess light class could maybe use something with limited range but high damage up close (the current SMG could be nice for that!). I want to avoid copying TF2's design...
The handgun would be the common secondary (kinda like the stock shotgun in TF2). It's probably a bit overpowered for that role at the moment.
Tomcat Well, I meant for the characters to be more robot-like. Smasher's not a problem, is he? But he's, like, a T-800 in style.
We have a custom humanoidal model that should server as the basis for all 2 classes for 1.0 (unless we can do more, but I am sticking to the mindset of getting MVP done, then taking up more).
I've come up with a lore explanation for the robots to be human-like, and I don't think we need to go very deep into making them look mechanical. Some slight paneling on a normal map and materials should be enough.
I should mention that I've decided to go with no gore for the game (that's partially why the characters are robots, and you don't see blood, but team-colored particles).
Both T-800 and Adam Smasher have a very sinister, imposing look, and I'm going for some more silly and a bit cartoon-like robots. With the wacky faces projected from their heads.
- Edited
unfa Again: story explanation of weapon origins vs use in-game.
When the explanation says one thing, and the game weapon behaves differently⦠well, this causes cognitive dissonance. Partly, a significant amount of negativity towards Cyberpunk 2077, quite rightly due to the fact that the promises of the developers far exceeded their modest capabilities. They were even forced to shamefully wiggle and excuses that they were "misunderstood".
so 3 weapons then.
say wich ones ud like and ill have a go at concept sketching them
- Edited
Tomcat promises of the developers far exceeded their modest capabilities
Ok, we can say the weapons were brought/manufactured on the asteroid because humans were expecting possible visit from a hostile alien race
And maybe even... they found the aliens after digging too deep! Maybe the asteroid is not "just some place" but a source of a rare element that humans and aliens crave?
Kinda like... tarydium from Unreal I...
Note that the backstory will not be explicitly told within the game - it only serves as a framework to allow building a coherent game world.
DJM so 3 weapons then.
say wich ones ud like and ill have a go at concept sketching them
Wow, awesome! I've spent some time coming up with the ideas for you, and I think I have a decent vision fro where this could go gameplay and balance-wise.
My 3 weapon ideas:
1. A Rocket Launcher (for the heavy class?)
Medium to long range, splash damage, self-harm up close
Triple-barreled! I initially thought of a single-barreled one, but after writing down the other 2 weapons I think a triple-barreled design will be much better and more flexible for the future. Primary trigger could shoot rockets full-auto relatively quickly, secondary could charge up a 3-rocket burst.
Inspirations: Doom, UT 2k4 / 4
2. SMG / Shotgun? (for the light class?)
Short to medium range, high damage up close.
I imagine a multiple-barreled-gun that could fire the barrels in succession like a minigun (but be less powerful and have a lot of spread - lie the current SMG), but it could also load up and shoot all the barrels at once for a shotgun-like effect. Inspirations: Duke Nukem 3D's Chaingun Cannon, UT's Flak Cannon (UT3 could be the best reference), Unreal's Minigun.
3. Energy/plasma weapon (For the medium class?)
Most versatile in regards to range, but not the most dangerous at any of them. Perfect medium weapon
The first firing mode could be a small energy projectile firing full auto - more precise but slower than the SMG, alternate fire could change up a more powerful projectile that'd be larger, consume more ammo but deal splash damage. To limit the gun's usefulness in long range, the projectiles could fizzle out at some distance or explode (we can say that it's shooting plasma balls, that are unstable and will collapse at some point in the don't collide with anything first.
Inspirations: UT's Shock Rifle, Q3A/Quake Live's Plasma Gun.
General visual design idea:
It'd be great to have a place for a dynamic display showing ammo count in 1st person view - I loved that in UT'99 and I still think these displays on Sci-Fi weapons are very cool - not necessarily functional but flashy
I've created a collaborative whiteboard* and put the reference images there for you:
https://excalidraw.com/#room=5c88f5aa2990ce7a95a6,vzdXtzEdz1gslMABLbO4Kg
Please let me know what do you think of these ideas.
Or just go nuts
- I've been using Excalidraw for this kind of stuff a lot. These collaborative boards stay online, boards made a year ago are still accessible, and we can also download the data and then just open an existing board from disk. Or even self-host this service if need be, because it's FOSS
pm me with your mail , id prefer discussing there further, ill start with the plasmagun, seems most fun to do to me atm.
also how will reloads be handled, will they include first person arms or will only the gun be visible?
DJM Ok, I've sent you a PM, thanks!
TL;DR I think we'll skip the hands in first-person, at least for now.
Currently we have hands visible, but they are not animated or even rigged, and not doing that would certainly lessen the workload. Some games don't bother and just have the guns floating in air. I guess suspension of disbelief takes care of that.
We could just lower the gun and not show any complex animations for reloads (a bit like the generic reload animation is now in the game).
The hand view models and more involved reload animations could maybe be added much later, after 1.0 is out, so I guess it'd be good to leave ourselves an option there, if it's possible.
I've completely rewritten the game's story to address issues risen here - this is draft 2 of the Liblast story:
https://codeberg.org/Liblast/Liblast/wiki/Story-&-Lore-%5BSPOLIERS%5D
If there are any glaring issues in my writing - please let me know
unfa I've completely rewritten the game's story to address issues risen here
The idea of warring robots is greatβ¦ But I suggest a radically simplified scenario. For example: in the distant future, wars between people are categorically forbidden β prohibited by law (as a state-criminal offense is equal to mass murder) and, in addition, they are morally unacceptable. But the competition between corporations has not gone anywhere and sometimes takes quite acute forms. So robots fight for valuable deposits on distant planets and asteroids.
Tomcat Thanks!
Your proposed story is much more broad, which I think would work, and probably even give more creative freedom. Too much perhaps.
I tried to make something more specific that'd also give more detail and direction for worldbuilding, that also creates bounds for developing something that is quite specific.
With a very broad story like you presented the players could ask legitimate questions like:
- Why are the robots human-shaped and not spiders, tanks or helicopters?
- Why do we use weapons clearly designed for humans and not hand-cannons, eye-lasers and kamikaze-missile robots?
And derive that clearly the game wanted to be about people fighting, but wanted to avoid having people in the game with no justified reason for that.
I also try to explain other things like:
- Why all factions use identical-looking robots and weapons? The real reason is lower development cost and easier balancing, but without a story explanation it's perfectly arbitrary.
Maybe it doesn't matter for many players, but to me without the bounds form the story the game could be pretty much anything - and also nothing. Creativity thrives on limitations!
I've had a discussion with my sister about this the other day - she argued that for example DOOM 2016 could not have a story at all, because the game is about shooting. I replied that players don't directly care about the story, but it is very much needed to provide a coherent, directed experience, otherwise Doom would be just a series of unrelated arenas and shooting whatever with whatever, a bit like Serious Sam 2. Maybe the shooting would still be just as good, but it would feel pointless and messy without having a very specific story underneath to guide the develoment and design. In Doom Eternal is seems the story became a bit more important and (for some) interfered with the gameplay - that's something I don't want to do.
Quake 3 Arena is an example of a game that has pretty much no story and the design is all over the place with characters ranging from hoverboard-riding cyberpunks to fat clowns to Doom Guy to eyeballs on legs. Some may like that but to me it always felt very jarring and disjointed. UT'99 while still having a very loose story felt much more coherent (not perfectly, - still quite disjointed sometimes) - it also had lots of lore available in-game for the locations, factions and characters. Sure, it is not important, but I think the game was better for it.
BTW, in the story I come up with I can also see places for a future wave-defense co-op mode (players vs environment) with say - alien bugs or robots swarming your colony that you try to defend.
Also please note that that the story I write is more meant as development documentation than anything that would be directly presented in the game (it could be but I am not planning for that - making an intro cinematic is a lot of extra work).
I'd love to know your arguments for using a much more stripped down story! Maybe I'm missing some serious issues with my approach?
- Edited
unfa I'd love to know your arguments for using a much more stripped down story! Maybe I'm missing some serious issues with my approach?
Well, these are deeper questions about gamedev, you can say in some way philosophical... I find it hard to answer in detail because of my poor knowledge of English, and the artistic translation is not always correctβ¦ Przepraszam, proszΔ pana.
First, the answers to the questions:
unfa Why are the robots human-shaped and not spiders, tanks or helicopters?
Easy. To make specific robots and, most importantly, to deliver them in place, even in the distant future - extremely expensive. That's why robots are made versatile both as soldiers and workers. Then we go back to your idea about the convenience of people being able to get there. That answers the second question as well.
unfa Why all factions use identical-looking robots and weapons?
And the same reason is the low cost of development. Primitive things that perform the same function look a lot like each other. You can even refer to the fact that one corporation makes robots, sells these robots to various other corporations that are engaged in field development and those are in conflict with each other. But later, if there is a desire, it will be easy to make them different and justify it.
I think the story should relate to the depth of the game:
- shooter? - less story - often it's superfluous. Just as long as it doesn't limit if you want to expand the game and add something to it.
- adventure and role-playing? - The plot needs to be worked out.
In my opinion, there is no need to complicate the plot beyond what is necessary. In a complex plot can be a lot of inconsistencies, and just gross mathematical errors with numbers on the order of. Large and complex plot, it is better to show a specialist in the relevant field. As an example - my plot for the game, which mentions hyperdrive Haim. In theory, it is there. Its practical implementation is subject to serious doubts. But FTL travel is absolutely anti-scientific heresy, so I thought its mention is possible.
I have other questions... for example... what is the difference between this game and others like it:
- OpenArena
- Rexuiz FPS
??
What would make people move from such games to you? As, my employer once asked me when I shared my business idea with him, "What's your competitive advantage?"
Destructibility is a very difficult thing to implement, but it's also very attractive.
Different opponents β different weaknesses and strengths β also arouse interest. This I say as a player who played WOT for several years before they were completely casual.
Just imagine: a person is trying to tell his friend or acquaintance about your game β how to introduce him, what he will highlight β what features?
β You can turn into a refrigerator there! β That's great! What else?
What is expected in the mods?
By the way, there was already an attempt to make multiplayer on Godot. Alas.
Tomcat Przepraszam, proszΔ pana.
AleΕΌ proszΔ bardzo!Tomcat Easy. To make specific robots and, most importantly, to deliver them in place, even in the distant future - extremely expensive. That's why robots are made versatile both as soldiers and workers. Then we go back to your idea about the convenience of people being able to get there. That answers the second question as well.
That makes sense!
Tomcat But later, if there is a desire, it will be easy to make them different and justify it.
Being future-proof is a great thing, especially is a project that might live and develop for decades (I hope!).
Tomcat As an example - my plot for the game
I've read all of it and I really like it! DeepL seems to have done a really nice job!
Tomcat I have other questions... for example... what is the difference between this game and others like it:
OpenArena
Rexuiz FPS
??
My idea for Liblast is outlined in detail in the Game Design Overview document here:
https://codeberg.org/Liblast/Liblast/wiki/Game-Design-Overview
TL;DR:
- Liblast is not going to be an arena shooter like Xonotic, Open Arena, Rexuiz, Red Eclipse, Warsow etc. Not a FOSS clone of Quake 3 Arena or Unreal Tournament or even a mashup of the two.
- Fast-paced but casual in nature - mechanics are designed to dampen steamrolling of individuals and emphasize a team effort
- Increased vertical mobility with a jetpack and possibly other class-specific movement abilities, but without excessive movement complexity (no wall-running, kicksliding or bunnyhopping)
- Levels that utilize the verticality to provide a bit of a different experience from most FPS games on the market nowadays
Tomcat Destructibility is a very difficult thing to implement, but it's also very attractive.
I agree. It is interesting, but very difficult to implement.
The game is in such early stages that it could be very well made to integrate that, but I am pretty sure I would not manage to do that alone in a reasonable timeframe outside of a very striped down approach. Here's a few questions that need to be asked that will hopefully provide an explanation of why I think that:
- does the destruction play a key role in the gameplay? Is the game about digging a tunnel for example? Is it about demolishing structures or preventing other team from breaking in and destroying your base? (that could be fun!)
- how deep does the destruction go?
- Is it surface-level (cosmetic surface damage, moving props that don't affect player movement or weapon hit detection, maybe windows breaking open)
- Does it allow creating new pathways (blow holes in walls and floors) but structural integrity cannot be altered (some walls floors or beams, cannot be fully destroyed, only damaged) like in Red Faction? Are there a few elements that can be destroyed (gates, doors, cracked walls), or every wall can be opened with an explosive?
- is it full destruction of buildings like in Red Faction: Guerilla?
- how is the destruction handled? is it static pre-determined destruction is selected spots and ways, or is it procedural, dynamic and needs to respond well to an infinite number of possible inputs?
All of these choices can have vastly different development cost and effects on the gameplay.
Some challenges I can see already:
- how to design a game level that will remain to be fun even when the layout can be altered by players?
- how to synchronize complex changes to the game world through the network efficiently and reliably?
- how to make the physics stable and performant in an unpredictable environment?
- how will the world lighting respond to destruction? Do we need fully dynamic lighting? Even SDFGI isn't made to handle altering world geometry. It an handle changing lighting, but not changing geometry
Rendering:
If the world is fully destructible, then we can't use any static lighting or it will just not work and look very ugly. However a fully dynamic lighting solution is very expansive to render so the game would either have to have almost no shadows, absolutely no indirect lighting etc or will have to be extremely demanding to play (currently Godot 4's SSAO, SSIL and SSR are very unoptimized and can't be used in production - if/when they get faster by a factor of 10 then it would become viable, but still only for people with decent GPUs).
On the contrary using Lightmpas can produce very pleasing results with really low rendering cost.
Physics:
If the world is fully destructible we might have a lot of active rigid bodies bouncing around, or in a simpler case - a lot of changes in collision shapes that affect players, projectiles and other objects moving through the world. Some challenges:
- Godot's Physics use floating point calculations - this means that they are not fully deterministic, so we can't rely on clients simulating the same event in sync and arriving at the same result (like in Zero:K for example)
- Lots of moving objects will require lots of network traffic to sync all these changes - it could be optimized using visibility filters to only send information about what's really visible, but it can still be a lot, when every frame we're tracking say: 10 players, 20 rockets, 40 plasma bolts, 20 player body bits, but also 30 falling wall chunks, 20 props flying, 10 explosions affecting voxel terrain and rigid level geometry and possibly all props and destructible elements as well...
All in all - I think destructible levels are an interesting and unique idea, but there' a reason why games very rarely do that, much less online games. It's a very large technical challenge, and I don't think I'm afraid I am just not up for the task as a sole programmer.
I think it could be done in a very limited fashion - using pre-determined objects and world elements that can be destroyed in fixed ways + destructible props that are purely aesthetic and don't really affect the game (so don't even need to bee synced through the network).
This could allow for making a game mode where you're defending a structure that has a number of destructible walls or windows/doors - it's possibly opened paths but these are fixed places. It would allow players to still control the situation and also we could still use static lighting for the most part keeping it performant.
I think there is some really nice fun to be had with this, but I think even without that the game will be plenty fun and will not be such a pain to develop
I checked this out but both the Github repository and the YouTube video seem to have been deleted. It seems they nuked this.
I've seen many FPS game project in Godot, some multiplayer but nothing even close to what I want to do with Liblast.
- Edited
I'll copy paste an idea for character models based on our discussion that I wrote in correspondence with @DJM :
As for the hands and characters in general - they are mass-produced perfectly agile humanoid robots used as workers and soldiers. They are designed as versatile industrial machines, that can operate the same equipment as people. I'd say they are pretty much human shaped, but with no unnecessary detail like muscles etc. They are covered with extremely resilient synthetic polymer "skin", but can have some protruding ports and widgets for maintenance access, charging etc.
My idea is the robot skin is by default matt white, possibly with small details as black printed model and serial numbers, some technical markings and possibly manufacturer's logo etc. Could also have a few lights to signal possible error codes for maintenance staff to check out etc.