This is a thread about a third-person shooter game featuring Alunya.
It is a free-and-open-source game made using Godot and Blender. Contributions are welcome.
The pre-alpha demo game (0.0.1) and its source files can be found here (read the description for instructions to play on Linux/Windows/Mac):
https://archive.org/details/EscapeFromCatalunya-0.0.1Current controls are:
WASD / Arrow keys = move in a direction
Right click = aim
Left click = shoot
R = reload
[top number keys] = change weapon
ESC = quit
Draft plot:
The game is currently based around Alunya evading Porky's hired army. Porky wants to make Alunya sign over merchandising rights for her likeness, and isn't afraid to
hire ancaps to get dirty. Avoid electric weapons and rubber bullets.
Additional levels may involve her resisting cancellation from reddit socialists and evading assault by the chinless horde.
The most immediate goals from here are:
>more levels/themes>bigger levels>more effort and detail in levels (doors, balconies and windows, plants, streets)>improved enemy logic and types (currently only two enemy types and they are pretty dumb, basically just a reaction time delay when a player is within range then aim towards the target and shoot. Improvements include a more realistic detection system, and actual navmesh pathfinding)>improved animationsI am unsure how collaboration would best work. Ideally we could just use git.leftypol.org but I believe there is currently a restrictive file upload limit. Maybe that should be changed.
>>14042I've only had exposure to basic hobbyist use-cases so far and it's been years since I've used Unity so this won't help much, but it's been pretty good so far. Similar basic interface and all so switching wouldn't be hard unless you're doing advanced or specialized stuff. I guess the only downside experience-wise I immediately noticed would be the far far far smaller online asset library and less community maturity (although there is still a decent amount of maturity, good online documentation, and probably more passion).
I think an online guide would be more helpful than this comment, there would probably be lots of comparison articles by experienced game devs. Just remember that things change somewhat quickly, so a year-old review may claim Godot doesn't have a feature that it now does. There are a lot of big missing-features/issues that "are fixed in 4.0" but it's gonna be Waiting for Godot as 3.4 was just released on 6 Nov (predictions for 4.0 were end of this year but I wouldn't be surprised if it were longer. I'm not basing that prediction on anything specific, just how software tends to release). Occlusion culling was considered a big missing feature;
"Although raster (pixel based) occlusion culling will not be available until Godot 4, some geometrical occlusion methods [e.g. portal occlusion culling] are being added to Godot 3."I found GDScript super easy to pick up (as I have Python experience, I didn't even need to look up any syntax documentation to mod and extend scripts). The example projects and some random tutorials were a lot of help in general.
Interaction between Blender and Godot has been pretty good. There is a work-in-progress Blender plugin for integrating but I've been just exporting animated models to .glb files and importing.
Oh great, just checked the changelog for 3.4.1 (26 November) and it looks like they fixed an issue that I spent too many hours trying to troubleshoot
(Rendering: GLES3: Fix particles emitting at old location GH-54733)). which caused bullet graphics fired in different directions in quick succession to fire at the previous target. This means less invisible shots! (part of the crappy coping workaround)
>>14035Have you though about adding a license file to the source code?
I couldn't find one.
>>14041oh i can make into 3D models
the problem is the gimmicks behind them
they need to be implemented not only into the game but also into the map design
but trust me is gonna be fun
>>14046I've added some in the in-game credits, but I would like some discussion about it because I didn't put much thought in to licensing.
The base code form the official Godot 3PS demo and some sampled code from the other Godot 3PS demo are both MIT. My contributions are currently GPL3. Thoughts?
>>14048>they need to be implemented not only into the game but also into the map designGo on. Even if, for some reason, not in this game I can try and demo it for you if it's not too complex.
anyone try speedrunning this yet?
>>14035needs raytracing
>>14050>needs raytracingIt has raytracing. That's basically all it has beyond proximity detection. It's just dumb raytracing that aims at your center rather than the point of collision and makes no attempt to predict movement.
>>14050>anyone try speedrunning this yet?I haven't but it's currently possible to do a pacifism run (no shots fired, no lives lost) and a 'flawless victory' with the AK-47 (no wasted bullets, no lost health). A 'pistol only' run is mathematically impossible in this version without dying or finishing the last couple off with the AK-47.
Time limits or ammunition constraints would be good challenges for difficulty levels.
It's a solid start but for some reason it lags to a crawl on my machine any time the enemies start shooting at me. Might have something to do with raytracing, if the plasma bullets are used as light sources
>>14052I would say prioritize tuning the movement/shooting mechanics so that moving around feels fluid and intuitive regardless of what you're navigating.
>>14051Agreed
also maybe run the panorama through an artistic filter in gimp so the modern elements are less immediately obvious lol
Cleaning up the codebase a bit, then I'll chuck it onto lefty git in a couple of days.
>>14051>>14055I just assumed it would be set in present day, PRESENT TIME, hence the storyline. Some old posters (real or inspired) would still be a nice touch.
And the panorama is more of a quick placeholder I found rather than anything definitive. There's a lot of room for improvement on that one.
>but for some reason it lags to a crawl on my machine any time the enemies start shooting at me.It does lag for me often the first time they shoot and the first time a bullet explodes, but then no problem after. It shouldn't be a raytracing issue, I think it's more the particles or associated effects. I haven't touched those, I should look into it.
What would you say are the biggest issues with the movement/shooting mechanics at the moment? I know the animation is crappy and rushed, anything else?
>>14056>What would you say are the biggest issues with the movement/shooting mechanics at the moment? I know the animation is crappy and rushed, anything else?Animation does do a lot for 3rd person, but I'd say you need more smooth transition on movement. Right now she goes from running around to a screeching halt when you aim. Having less of a jarring difference in movement speed would help, but ideally you'd have some kind of curve accelerating the movement speed between the two so it feels more natural. It feels pretty binary at the moment. There's a lot of complexity that goes into 3D character movement, especially if you have to see the character.
Another thing to consider is decoupling the actual character animation from the "actor" in the scene so that the player is moving an avatar that's highly responsive and tuned to gameplay while the animations are sort of a "mask" over that trying to match the movement but not actually relevant to the mechanics. This is easier to implement early on in the process and makes it easier to edit one thing without completely fucking up the other. Basically rather than responding to the direct input, the character animation reads the movement of the player object and takes that as input. It's more important to think in terms of system architecture at such an early stage to make it easier to work on later. Embed related. It's the overgrowth guy talking about how he did his animation system and basically step by step what I'm talking about. Doesn't have to be as in depth as this, but you get the principle. The first five or so minutes show you what you could do.
>>14058At the moment, the character movement (not including weapon actions) is literally determined by the animation root movement. That sharp stop is literally just the blend between the running animation and the idle animation. That movement paradigm is how it was in the base demo project and I didn't change that because it was simple and my goal at the time was a rapid PoC (it's actually the reason why the mercenaries don't move: they don't have a run animation).
I think this approach in the video is feasible and a good way to get nice results with less effort (unless someone helps out, it's one amateur in spare time among half a dozen other hobbies, so that matters). I'll try and establish some smooth basic movement for Alunya. Thanks for that.
I've never touched inverse kinematics before but it's a far way from where I am so it's always something I can do later. The basics should be easy to establish, the rest is visual icing on the cake that honestly doesn't matter until the gameplay is good.
Fun trivia: IIRC that Receiver revolver game mentioned was from the same 7DFPS jam that SUPERHOT's prototype was made for.
>>14060If I'm interpreting correctly, it can. For example, I do a reload animation filtered to only affect the arm bones, so it's the same animation when running or still. There's an AnimationTree system. So I can probably just have an animation for each weapon that requires it's own hand movements, and don't need to care about what the legs are doing. There's also blending between animations (which is why Alunya doesn't go from standing still to 100% running in one frame. I didn't make any transition animations for that, it's all the engine interpolating)
Are there any good resources for base character movement physics? I want to get that solid base at the start. I can find a thousand tutorials which are 'get a sphere, give it acceleration and velocity in relation to the camera' 20 LoC stuff, but the vid you linked had a multiple component system with two base spheres for example. I have no formal education in gamedev so I don't know best practices for that stuff.
>>14084what's wrong with pisscord?
Matrix asks for more stuff to get an account and i keep forgetting about it
>>14085you don't actually need to add an email to get an account, that's optional
just username and password
I spent a few hours trying to get animation controlled by code just to realize the seek function was in seconds and not frames. Once I iron out a few small bugs with running into corners, I should have some smooth code-driven motion to show off.
>>14083fbi.gov is a closed-source capitalist venture entirely controlled by a single company. While I personally think most of their employees have no ill intent, it is what it is.
Additionally, fbi.gov required me to give a phone number when I just wanted to view a room. I don't think it's fair to say matrix.org asks for more information.
Matrix is an open federated bring-your-own-client protocol, meaning developers and users have a lot more transparency and freedoms. If you look at the Leftypol Matrix rooms, you can see that many users didn't register on matrix.org. They're hosting their own servers (as in a literal server, not the misuse of that term fbi.gov normalized because le game lobbies)
This project will never have an official Discord room. We could use the Matrix room in
>>14084 but why not just use this board instead of making another private room? We're not big enough to need instant real-time conversation and the file constraints are far larger.
>>14104>I spent a few hours trying to get animation controlled by code just to realize the seek function was in seconds and not frames.Sounds like poorly documented/commented code if that wasn't readily apparent.
>Once I iron out a few small bugs with running into corners, I should have some smooth code-driven motion to show off.nice
>>14105Ever heard of the modding community?
>>14106Oh no, it's right there in the documentation. I just forgot and didn't refer back for a while. Remember to sleep, kids!
>>14105It should. That's why I will start by uploading it to a source code repo with a basic bug tracker and not a non-public instant messenger application which is a completely inappropriate tool for the purpose of asset collection and issue tracking.
>>14106 &&
>>14107* As in, it's original prototyping code I was writing, so it didn't have inline documentation like comments yet, and the online Godot docs did nothing wrong.
>>14036one of the easiest things to open up for collaboration is level design
if there's some kind of level editing tool or template level (with all the necessary components loaded) then other people could help with that
Just remaking a few animations (run, walk, strafe, reload), then I will upload a v0.0.2. Hopefully that will be done in the next day or two. Same level, just nicer character movement and cleaner code.
>>14172That would be good if others can help with that.
My current workflow with the level is:
>Blender project: catalunya-map.blend>make entire map>make sure all the objects that need collisions have '-col' or '-colonly' at the end (can be scripted if forgotten)>export as .glf (a default export file type)>import to Godot>manually re-add materials into their placeholders for each object (a bit of a pain. materials can be exported in the .glf to avoid this but massively inflated the game size and loading speed, as in, it's now 200mb instead of 600mb)>add player, enemies, waypoints, adjust world lighting>doneBUT if you're not making new objects (or are fine building them yourself), it can all be done in Godot:
>create needed object/s in Blender (like a house) and export>import house to godot and make it an asset, texture it<(those two steps might already be complete by me or others)>duplicate, retexture and position as much as wanted>doneSo once I have enough assets and textures, I could make a template someone could load Godot and create a level in there somewhat easily. Really quick and simple, and advanced users can add code just like normal.
I haven't figured out how to do DLC/addons yet
or considered the security of it; I don't know how much Godot could be abused for malware like file deletion or internet connection so one can just download custom levels instead of a whole new build, but that's not a priority yet.
>>14185 (cont.)
I will probably shift my workflow to the second one. There's not really a downside I can see and it makes updating assets easier (if I want to add windows to all the houses, I only need to change the house asset in Godot instead of adding them to every house in Blender) and user level creation easier.
>>14195>i'm not downloading a 600mb file.That's about to change:
>>14185>>manually re-add materials into their placeholders for each object (a bit of a pain. materials can be exported in the .glf to avoid this but massively inflated the game size and loading time, as in, it's now 200mb instead of 600mb)
>save all your textures as […] webpThat first release was just a rapid PoC, converting images will be done for the upcoming v0.0.2. The engine now defaults to WebP for lossless images and it's essentially recommended at this point.
I'm not building my own engine and I'm focusing on basic gameplay so I won't worry about manually implementing DXT decoding.
I do want to look into developing some conceptual ideas to distinguish this game, something beyond just a fun graphic theme. The cat-like nature of Alunya could provide some inspirational clues.
>>14218>>Is the name a escape from tarkov referenceIt wasn't a reference to any game, but that is a neat coincidence.
>>When will a mobile version be released??? Hadn't thought of it. Might actually be cool, but I would need to work on how to port the controls. What's a good way to do it? On-screen movement joystick and on-screen buttons for aim-toggle, shoot and reload? Good examples would be useful to see, since I don't game on mobile.
>>Why not use the cnt-Fia flagI didn't think too much about it, but the Estalada is one that might expect to be seen in a town in modern times, rather than a historical flag.
If I get around to adding some balconies and plants and a few more houses with flags (which I think should be my goal for next release), it could a nice easter egg among the others.
>>T-34 plsAs in the tank? I don't see vehicle-use happening for a few months at least, especially if the dev team remains one person. Cool idea, but priorities first.
>>14219Thanks!
>Still get lag at random times, usually when enemies shoot.Is it once when they first fire and once when it first explodes? Or random times?
I tried using a known hack to preload and cache the particle materials, but it doesn't seem to have removed the initial lag..
I will experiment with making a graphics option for simpler particle effects. Those energy blast bullets are literally the same ones from the TPS demo, somewhat of a visual demonstration of the engine in a dark environment, so it's a pretty intense object to render. The main bullet has a light and two particle generators (emitting 1000 particles/second) and the blast is made up of six emitters. On top of this, many of the above have emission shaders. So now that I look into it, it's a bit excessive for such a small, common object, and most of them can be safely disabled.
On another note: I wonder if I should replace those energy blasts with normal bullets (at least for the normal merc characters). The issue with that is that the current ones are slow and visible, providing an easier challenge the player can react to, where you can't prepare much for a bullet. You just get hit without warning or clear visibility.
>>14227>Is it once when they first fire and once when it first explodes? Or random times?Random it seems. I also get lag spikes when it seems like things load (at the beginning and when I enter the vicinity of enemies, before I see them).
>it's a pretty intense object to render. The main bullet has a light and two particle generators (emitting 1000 particles/second) and the blast is made up of six emitters.yeah that sounds kind of intense
i have a solid PC but if you have to render a bunch of complicated things at once of course it can slow things down
>I wonder if I should replace those energy blasts with normal bullets (at least for the normal merc characters). The issue with that is that the current ones are slow and visible, providing an easier challenge the player can react to, where you can't prepare much for a bullet. You just get hit without warning or clear visibility.This is a pretty fundamental game design decision for a shooter that informs the rest of the mechanics. The way you deal with slow projectiles vs fast projectiles or hitscan guns is completely different. The latter is about cover and tactical movement from place to place while the former is about nimble avoidance. You're talking about almost a shift in genre, between like call of duty or a bullet hell.
>>15918OP here, I've got a few projects I had to prioritize and I was the only active dev so this is effectively dormant. I'm more than happy to upload the Godot project to git.leftypol.org and write basic documentation so others can contribute, even if it's simple less-techical things like more levels or better graphics.
Its a cross-platform game engine so its pretty easy to get involved.
>>15968imagine being mad about a game
>What does your game offer those don't?First hand experience with Godot Engine and various game design concepts.
Any enjoyment you get from my education is incidental. Your opinion has no value.
>>15994I enjoyed looking over the v0.0.1 source. I didn't see this until after the author's indefinite hiatus post (Ukraine brought me back to checking overboard). I was gonna add gamepad controls as a goof, but when I started it looked like he actually had them set up already even though I don't think he told us that. I might look into what happens when an enemy starts responding to you, and see if I can make it less laggy (no guarantees). If you're not interested in open source game engines, I'm betting this probably isn't for you. That's fine, go jerk off to anime or whatever your thing is. Better yet, create something beautiful in a different domain. Or, if you're just feeling upset because you don't think you can do things like this and you're trying to bring others down to your level by pissing on what they create, try to follow a tutorial on making games in Godot. Don't offer criticism if you aren't competent enough to be constructive about it. I think the project as it exists has some major limitations, but that is to be expected. This isn't a finished game. In theory, be it this or another, the idea of a community-developed open source leftist shooter game sounds really cool to me. I like the idea that top-down projects sometimes break new ground, but bottom-up projects will eventually surpass them (see The Cathedral and the Bazaar:
https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar ). I understand that the author didn't get much initial response from people wanting to contribute, but one thing I would recommend is setting up a git repo of some sort before sharing a project like this. Doesn't have to be on github, github has the best network effects but you could do a free or self-hosted gitlab instead if you're allergic to Microsoft products. If I end up doing anything with this, I'll post a repo on a throwaway account somewhere for it. Having a git repo somewhere actually lowers the barrier of entry for contributing to people who are used to open source. I'd also recommend README and LICENSE files. OP seems to be able to teach himself arbitrary skills, and I feel like he should probably take a second to learn some git however it is that he learns things. He might get more engagement, even if still limited. I'll also throw out that one personal barrier to me contributing too much to this project would be that I'm already trying to hack together my own third-person shooter game in a godot, and while I really like the idea of cool leftist projects I also realpolitik like the idea of making money by selling video games given the world I live in, and it might be a lot easier for me to justify spending time on this if the game logic was more permissively licensed so that I could end up using it for multiple things instead of splitting time between two entirely different TPS engines based on godot so that I don't have to release the source for a monetized project down the line and have nobody pay for it in the various evil virtual game stores. I totally respect the author's licensing decisions, I'm just being real about barriers I see to contribution. You know, constructive criticism.
>>22402Again, no progress, but I do want to give some updates re: Godot 4.0 (which is now in beta. For non-nerds, that means since September they're no longer adding features, they're now polishing it and fixing bugs before release).
I feel safe to begin porting the project from 3.x to 4.0.
0) Looks like this issue [
>>14118 ] was mostly-fixed/fixed at least half a year ago. Yay!
1) Blender integration is apparently
far better existing now, which makes workflow much much easier.
2) Unity did a capitalism and merged with an analytics/ad company so Godot has had an influx of gamedevs. This matters because
unless some of you get involved this game is made by a hobbyist at best almost entirely relying on external resources. If people are releasing free assets like Waterways add-on and rigged characters, I can rapidly make nice-looking things without any real artistic experience or time spent.
Unique IPs: 37