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?
Liblast - a FOSS multiplayer FPS game made with 100% open-source software
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.
- Edited
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
the disclaimer.
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:
- the jetpack from a lucky (or unlucky — how you look at it) hit can explode (not too often).
- Gravity on different maps can be different, up to weightlessness.
Destructibility
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.
- There is one untested suggestion… that the passages could only be made by special machines, and the weapons, these passages could only be bombed, blocked… but this requires verification.
- Even cooler is saving changes on the map. The team broke through the tunnel and put the repair station and turret — the next battle begins with them.
The technical side (Materiel).
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.
- Edited
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!
Story changes
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.
[deleted]
- Edited
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
- Edited
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:
- Plasma Gun! (combo - shoot the large plasma ball with the small one!)
- Jetpack is now controlled with spacebar just like jump
- Various fixes
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
New release! 0.1.7 pre-alpha!
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
- Edited
New release! 0.1.8-1 hotfix pre-alpha!
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)