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
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
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:
I also try to explain other things like:
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?
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:
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:
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:
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:
All of these choices can have vastly different development cost and effects on the gameplay.
Some challenges I can see already:
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:
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.
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.
unfa Here's a few questions that need to be asked that will hopefully provide an explanation of why I think that:
On the whole, the questions are fair. But most of them have already been answered.
I'll digress a little on
I might try to make a shooter, but only as a tutorial for mastering Godot. Since it's far enough away from the subject matter of my main project.
That's why I haven't thought it through or considered it too thoroughly. Only rather superficially.
unfa Liblast is not going to be an arena shooter
Not (to be, to be like) is a very vague formulation. It is suitable in very rare cases. For example, in opposition to some unambiguous evil. "We're not Steam and we're not Google. We don't spy on users and we don't harvest information about them!" — that's clear and convincing. In other cases, a positive agenda is desirable — what it looks like and by what. Otherwise it looks like: "We're not redheads!" — "Which ones? Blondes, brunettes, or maybe bald?"
Increased vertical mobility with a jetpack
Levels that utilize the verticality
Now that's another thing! Vertical fights are quite an appealing (maybe) idea. Well, exactly, it could be described. "It's where you fly a satchel, down a healthy well!" I guess that's how you could define "Wells and Mines." Only the demonstrations in the video don't emphasize that point. Maps, then, should highlight and play around with this feature, for example: several deep rocket wells connected by intersecting tunnels or a quarry:
Since it takes place on small planets or asteroids, gravity is low there and the use of a jetpack is fully justified.
You can even introduce a surprise or two:
unfa is it static pre-determined destruction is selected spots and ways
is not destructibility, but hidden doors.
It is desirable to make the destructibility total.
Let me tell you how the battles in Red Faction 1 took place. At the beginning of the battle, immediately broke through the walls in a few places. Where the walls were the thinnest. Then, over the course of the battle, other, longer passages were broken through. It was impossible to destroy everything (in general) even in quite long fights — there was not enough ammunition. And it wasn't particularly about destruction — people were very worried that I was going to go nuclear. The usual situation, when a player with a grenade launcher is trying to break through a thick wall, and his opponent runs around him along the corridors and cuts him off with a machine gun. That is, to destroy the level, so that it ceases to be like himself — you can, but only in theory.
Red Faction 1 was made over 20 (twenty!) years ago! I shyly hope that technology has advanced slightly in places since then.
Perhaps Godot 3 was not very suitable for online shooters. Godot 4 made a lot of changes to handle the network.
Here experimented with destructibility.
unfa character classes, weapons
Balance weeps bitterly. 
The more I think about it, the more I come to the idea that it would be most optimal if the robots were like the suit from Crysis.
Or it is possible to actualize the scenario. The battle for resources on the Moon is a great idea and is almost a reality.
Tomcat
Interesting ideas!
The destruction in the example you've linked seems to be done on a single cube, and the game level is built from these cubes. If this would be extended to a comprehensive set of elements and tiles then we could have destructible buildings. However doing things like Red Faction did would require using CSG. It could work, but I have not tested it. I have seen 3D modifiable voxel-based terrain done in Godot 3 a long time ago, so that would also be possible (digging tunnels etc).
At one game studio I worked on a game that had destructible buildings, though I worked as a sound designer and 3D artist, not programmer. I did have a bit of a look into how the destructibility was implemented. It wasn't based on dynamic mesh generation, but pre-determined destructive points. You could make some holes in buildings but it wasn't exactly where you hit as it had to snap to the nearest predetermined destruction point. When enough of the building was destroyed, it all fell down into rubble. The also was a hierarchy of destructibility so that if you destroyed support for a different part of a wall - it'd break too. Destroyed walls wouldn't create rigid bodies, only particles. So no moving rubble, which would impede player movement and cause performance issues.
Terrain was done with a heightmap and explosions would just dig holes in it (no voxel terrain).
All of this I find exciting and fun to tackle but the reality is Liblast would need at least one consistent, dedicated contributor who'd dive into this and work with me on a weekly basis - do research, prototype, implement and maintain it.
It's because there's a lot of work to be done with the basics of the game and until that is done I won't be able to focus on such a huge undertaking - if I did the game would not be ready for a 1.0 release in 2023 and I aim to do that (minimum viable product). Being stuck in development hell for half a decade due to feature creep is not something I want to endure.
So I am open to try and test fully destructive levels, but I can't directly do it.
I also think it is something that can be added even after 1.0 - however it would cause massive gameplay changes, interacting with other game systems like responding to weapon damage, changing collision of objects, updating navmeshes (for bots) and handling lighting which I think would unfortunately have to be fully dynamic (and hence - very expansive, contradicting one of the key goals of the project) or very ugly.
This would need a lot of prototyping and development. The game as it is designed now is something I can finish even myself in a reasonable amount of time. Fully destructible environments in a fast-paced multiplayer game presents so many challenges and unknowns that without a dedicated developer it's not feasible.
So if anybody wants to give this a shot - let me know!
I don't expect someone like this will come around though - and if they do, they'll probably do some basic work and disappear after 3 weeks, or 2 months tops never to be heard from again, or they will not be able to dedicate more than 2 hours per month, which is not enough to get something of that magnitude done. That's just how it is - nobody gets paid to work on this, and not that many skilled and experienced people have time to do hobbyist projects like this. I have not met someone with the same drive for this project that I have yet - which is completely understandable - I am very thankful for all the contributions which are helping the game immensely, but this feature is just too big for me to believe someone would just come around and take responsibility for it.
But there's no harm done - I don't see a reason why this couldn't be done later as separate game mode or a mod or update. That would present extra challenges in itself, but for sure way less than implementing full destructibility in the first place.
Heck - I will work to make Liblast capable of being modded to support something like this!
I think your ideas for the story however are very useful as stripping it down will indeed grant a larger creative license to make interesting environments, like in Unreal Tournament.
I'll have to do another story rewrite with this in mind, but I want to get some other thing done first.
All in all - thank you for your input!
unfa This would need a lot of prototyping and development.
This is certainly the case. But it contradicts this:
unfa I also think it is something that can be added even after 1.0…
I guess it's too big a change to just make in the game. Either the game originally includes destructibility, or it will be a completely different game. And pulling two projects… well that's quite difficult… I've heard…
unfa So if anybody wants to give this a shot - let me know!
Changing the landscape for my project is important and I will explore it over time. That's what I want to accomplish:
As far as matching it with the destructibility you want… well, something in common will probably be found.
For the dynamic destructibles you might want to pester some library developers who have the dedication for that type of stuff. There's also an indie dev by the name of Owen Deery who has a custom built engine with destruction in it, so maybe asking there could lead somewhere.
Modders may take up the challenge if there's enough of a stub for mesh fracturing dynamics or something like that and then begin expanding on that. Modders are usually motivated by changing or mixing existing core structures in a game or a series of games, so maybe you have to make it somehow compelling enough of a vision to negotiate the terms that way.
I hope that you can make it happen
EDIT: couple words
New development update!
YouTube:
PeerTube: https://video.hardlimit.com/w/ej5QUtUuYTEPBxKCjcVTyh
If anybody wants to test, here's a little preview build before 0.1.6 release is ready:
https://wormhole.app/E5DmR#ryMO-0wQMxS8VYy8teOKkg
(will be up for 24 hours)
Notable changes:
New release! 0.1.6 pre-alpha is here!
https://codeberg.org/Liblast/Liblast/releases/tag/0.1.6_pre-alpha
A changelong is coming soon
It's now possible to gib (explode) dead characters
https://codeberg.org/Liblast/Liblast/releases/tag/0.1.7_pre-alpha
It's now also possible to play in your browser: https://play.libla.st
It's highly experimental though so don't expect much 
https://codeberg.org/Liblast/Liblast/releases/tag/0.1.8-1_hotfix_pre-alpha
New development update video:
(YouTube)
https://video.hardlimit.com/w/dABmyTyZHPZJi8PQcAixB6 (PeerTube)
Also a poll/discussion about a possible reviving mechanic:
https://mastodon.gamedev.place/@liblast/109863859009926487 (Mastodon)
New original menu music!
https://mastodon.gamedev.place/@liblast/109894532663549919
Downloads and changes:
https://codeberg.org/Liblast/Liblast/releases/tag/0.1.9_pre-alpha
More details:
https://opencollective.com/liblast/updates/liblast-0-1-9-pre-alpha-release
unfa, would you have any interest in joining a forum discussion at the Xonotic forums?
You could share details about your project, what type of help you need, etc.
Here's a quick release to fix the worst bugs in the previous one
https://codeberg.org/Liblast/Liblast/releases/tag/0.1.9-1_hotfix_pre-alpha
I've finally sat down to write the 3rd draft of the story - very stripped down compared to the previous 2 drafts.
Thanks so much for your input, I think this one will work better for the game than the previous two!
https://codeberg.org/Liblast/Liblast/wiki/Story-&-Lore-%5BSPOILERS%5D
The projects is now undergoing a full rewrite/refactor/overhaul/redesign
So if you're interested in contributing - it's a good time to get in touch, as we've got a new core team formed (currently 4 strong) and we're seeing how we can divide the work and use our talents in the best way possible.
Contact info is under that video.
You'll also find links on our website libla.st.
Hey, it's great to see this project still going! Sometimes a big refactor is necessary to be able to scale things. Hope to see more on this project in the future!
nice to see u r still using my weapon design
When I found this some time ago, I always felt I need to make a map for it, so I started with my first one a few days ago with a blockout.
Meanwhile I already started some modeling too, with the goal to also create some usable modules and objects, including later modules not used in the map for more unique maps.
Oh.. nice!
some more progress on my map, getting slowly adding 2 more images from until now unseen spots
, plus I already did another map blockout, for a crazy and really tall map
Does the game contain option to turn off textures and use picmips? similar to xonotic https://xonotic.org/guide/#picmip-and-simple-items
DJMaesen Yeah! It'll probably need to go at some point once we figure out an entire rooster and a good workflow for it - the gun looks nice but it took me way too much work to finish it
rubberducky some more progress on my map, getting slowly adding 2 more images from until now unseen spots
, plus I already did another map blockout, for a crazy and really tall map
You've got some incredibly cool designs here! I can't wait to put them into the new game and see how they feel!
kuligs2 Does the game contain option to turn off textures and use picmips? similar to xonotic https://xonotic.org/guide/#picmip-and-simple-items
We don't have such a feature. Altering texture size is in itself an oddly hard thing to do in Godot BTW.
️
