Hope you enjoy this devlog! Little progress was made due to semester 2 of university but I’m happy with these changes. I forgot to mention that I also made the player come to a stop quicker when landing on the ground, so that should help reduce the slipperiness. I’ve got until March next year to put as big of a dent into the project as possible. On to the AI and combat! Thank you for all your supportive and insightful comments :D
I never expected to appear on a devlog video of an indie game, let alone as feedback. You've truly gained my respect, and not because I appeared in it but because you actually took the time to take the advice people sent and thought about it instead of thinking that you are instantly superior to everyone when it comes to your game, you even went as far as exploring the ideas of the feedback/advice we gave even if you didn't end up using it. For example, in my case, I suggested IK's and understandably so you didn't use them since the creative freedom may be limited or make things not turn out the way you exactly want to, yet you still kept that piece in the video informing of your intentions with the game and making it easier to give better feedback/advice That deserves much more merit than is given and indie developers should take notes from it. Anyway much love and good luck with the project!
As a programmer myself, I seriously suggest you keep learning animation because that's the meat of an action game. Understanding animation principles and tools is the key to success to develop an action game. These knowledge teach you how to make these assets, but that's not important because you can always delegate the task to someone else. The more important part is it gives you an eye for good animation, thus makes you write better animation-related code, which in essense is the whole game!
Good point! I do love learning about animation principles so TH-cam videos and GDC talks about animation I do give a watch. I agree with you that I should be able to at least know what looks good so that I can effectively communicate with artists I work with. Thanks for the comment!
@@Snaiel Actually most complicated animation code is just trying to make an animation with code because fixed hand-authored animation cannot adapt to dynamic game play. That's why Unreal introduced ControlRig and in-engine rigging.
Hey man, lots of respect for taking the criticism like a champ. It takes a lot of maturity and humility to accept it. So good job! I wish you the best of luck with your project going forward!
These videos have been very inspiring. I hope you are able to continue finding the time and motivation to continue the project and devlogs! Great work!
I think the reason the sprint animation appeared to not blend is that the camera zooms out in a way that is not proportional to the speed. That makes it feel like you're entering "Running Mode" and less of actually running. (I'm not saying to actually tie zoom with speed, just delaying the zoom until the running animation/speed has properly started).
i really like the game idea, the work you put in and especially the fact, that you take criticism/feedback and actually implement it too. So here is more feedback, after i played the demo in your description: 1. when i don't move and press dodge, it would make more sense imo, if i would dodge backwards instead of forward, since if i fight an enemy that swings at me, i want to dodge away from his attack and not into it, even with s 2. for the parkour it would be cooler, if i can still jump a split second after i walked over the edge, instead of falling down immediately. I watch a lot of devlogs and play a lot of games and from what i know, a lot of games do this. It makes the parkour feel more forgiving (or maybe it's a skill issue from my side, idk) 3. the camera should follow the player faster, when i sprint to the left or the right. Currently i don't really see where i am sprinting at, when i don't sprint forward. 4. the movement still feels a bit stiff somehow, but unfortunately i don't have any idea/solution for this 5. (just a small thing i assume you would add sooner or later anyway) i miss an animation when i fall/jump off something high
About the dodge while on the jump state. I'd suggest using a Timer with the wait time equals to the maximum dash buffer you want to give to ghe player. When you are in the jump state and press dash, you start the timer, when you enter the grounded state, you check if the timer is running, if yes you should dash, else you enter the walk or idle state
Awesome video man! Im also trying to make a 3rd person game in Godot and you've gone over alot of the issues I need to address soon also. Really helpful since this is my first venture into game dev. Thanks alot! Really excited to see what you do next
I'm too tired to coherently explain it atm, but I highly recommend pulling the camera down a little bit and then angling it up a bit to compensate for its new position. I've spent a lot of time thinking about how the gameplay feel of the various soulslikes changes based on how they have their default camera set up and positioned. The way you currently have the camera positioned works well as a Locked On camera (though against really large enemies it'll benefit from automatically pulling out to keep the whole thing in frame and maybe tilting a few degrees up). Another "small" gamefeel thing I'd suggest trying would be making the camera automatically pull in a bit when you're locked on and backing up, and pulling out a little bit slightly after your character starts sprinting. My final thing is to maybe take a look at how the camera works in Breath of the Wild and Tears of the Kingdom. Idk how it works but when you're locked onto something the camera will do ANYTHING to keep both Link and the target in frame, while still letting you rotate it freely, and honestly it feels a lot better than how it works in any of the Soulslikes. It still has problems (my biggest one being the default angle locking on forces you into being at an angle that makes it a crapshoot on if you're going to backflip or side hop) but in my theoretical Soulslike that'll never be made I'd probably replicate and improve on those over how Souls does it. - Also yes, the Souls games all use input buffers. TL:DR DS1 is extremely aggressive and ER is a bit less aggressive, while the others vary between "kinda noticeable" and "not noticeable". Generally the implementation in both is disliked because people are mashers by nature, so being screwed by actions you input a second ago (or longer >_>), possibly while you were panicking, feels really bad most of the time. Implementation that aggressive does have a place if you're trying to enforce precision from your players, but generally people will like the gamefeel more if the implementation is closer to like 1/3rd of a second at most because it lets them buffer actions they know they want to do while getting ready to do other actions afterward while the animations play out, though it also depends on the individual action(s) in question. Basically, be really careful with your buffer queue(s) and experiment with it and how it prioritizes the inputs it receives.
It's nice to see a ACTUAL indie dev without a massive studio behind them. Not to call anyone out, but there's only so much I can learn from a big studio as a lone indie dev.
fromsoft uses root motion to move including all attacks. but they use several functions in the animation to modify that movement like to change your rotation velocity when attacking or homing towards the target, to shoot bullets, to create (or activate) hitboxes (also hurt boxes), hide\show parts of the model, etc. this method is usually called TAE "Time Act Events" if you wanna know more about souls systems you can watch some modding tutorials on ds3 or ER
also you can chain blend nodes to blend more than one animation! this can start branching into a lot of combinations tho, so it may be better to do via code
Feedbacks really important and as you said we kind of become blind to some issues after a while and not even realise it. Currently i'm making my first pc game called Hell Runner and after i put it on steam as early access negative reviews literally display things i not even think as issue XD Thanks God after fix them and add this they suggested negative reviews gone :D 1:50 i also added lots of things where player try to do an action but cant so i make game remember that actions for a really short time so they can be executed when possible like jump, hookshot, wall jump.
The code you used for dodge on land, is actually the exact same for jump input buffer. Platformers have this for jumping instead of dash. They also have coyote time... if you wanna put more time and effort into the movement. Though in souls games they are made with the intention without this to make them feel less agile, and heavy (but more realistically theyre not making a platformer so probably didnt think of it) Honestly. Id keep dodge for tap, hold for sprint. Versatile verbs and all. Makes it feel more fluent. If ya dont get state machines still, i could probably send some screenshots of my methods of using them. Its very helpful for running different functions when walking to falling and such. Allowing a lot more control, and trust me, it might not seem necessary now, but when you got 1k lines of code youll regret not using them xD The circular velocity is genuinely hard. Out of all my time programming intense mechanics, the hardest was probably a perfect circle movement using kinematic controller for a 3D platformer prototype. Hell, the rollback was easier to set up. The reason it turns into a spiral is because when on the edge of a circle, right isnt right on the circle. Right will step outside. So youre constantly walking out of the circle and moving away. You need to "drift". So youd also need to step forward based on distance (bigger circles aka bigger ranges, require a more step forward). But so far my most accurate code is setting position rather than velocity. Look in cos/sin math. If you dont want Steam on PC for productivity, make an alternative account on your computer. One for developing, one for gaming. Have steam inside that account.
Great job! for better grounding of animations you could check on only making transitional animations, and also check the actual root motion distances of movement and speed/slow the animations accordingly. Also noticed your lerp has a constant value on weight, maxing it a sort of exponential decay, maybe it was intended, but if you want a more grounded blending when landing you can set the lerp weight to be calculated from the distance to ground.
Hey, Ive only watched your devlogs up until this video but what I find will help you with having to change things based on players criticism is adding a settings menu so people with different likings and playstyles can adjust accordingly instead of just hard coding it in.
As someone who used to be Finite State Machine (FSM)-phobic, I will tell you now that after learning it, it completely changes the game from spaghetti code to something that can be scaled and finished. I know this is a hobby project, but I strongly recommend maybe making a very basic FSM on a blank project, if not but to just learn what the concept is. I'm not sure how it works in Godot, so you may need to interpret this differently, but the bare bones is that you have your character controller that is always in a given state. These states contain at least four functions: a start(), an update(), an ending(), and an animation(). The character controller needs to be given the ability to communicate to the state and vice versa -- so in this case, the character controller tells the state player input (update()), while the state will tell the character controller to transition to a different state (start()/end()), move (update()), change animation (animation()), etc. Using your falling animation as an example: 1. Character is in an IDLE state. 2. You can separate the IDLE with a WALKING state (this would be scalable for like, directional attacks, but you can keep it basic and have the movement coded in IDLE). 3. Player walks off a ledge, the IDLE/WALKING state identifies that the player is no longer grounded, then tells the character controller that it should enter a FALLING state. 4. FALLING identifies when the character is grounded, then transitions back to IDLE. This is scalable because you can dictate things like "no attacks can be done while falling" because the FALLING state does not have any code to tell it to do so. You have to think that in real life and even from a player's perspective, a human can only do one or two things at a given time, so the state machine gives you guardrails so you're not, say, executing a grappling hook while in the middle of a dying animation. Then once you start getting into subclasses/inheritance, you open the doors to so many other possibilities -- having a RUN state inherit from WALK, etc. You can even pass variables between states (e.g. RUNNING state stores velocity, and then the JUMP state inherits said velocity but can add a multiplier to decay, etc.) By design, FSMs give you the ability to have different abilities branch off (running attacks are different from walking attacks, etc.) and also gives you the ability to have intermediary states like STUN/STAGGER or KNOCKDOWN. And if you decide to delete features later on (e.g. ROLLING state or SWIMMING state), you don't have to fix other code related to it because they were engineered to be independent from the start. FSMs aren't just limited to the characters. You can use them for AI, cutscenes, camera movement, menus, bootstrapping, etc. It is an essential programming pattern (among a few others) that will save you A LOT of headache in the long run. Sorry, just wanted to give you an aggressive nudge in a direction because I've seen the light and need to preach it to others. Totally get if this sounds uncomfortable, so don't take this like I'm saying you need to be doing this. I believe the example everyone shares is that Celeste's character controller is like a billion lines of code on a single script, so whatever works works.
@@Snaielthere is a guy called shaggy dev that has two videos on Finite state machine on Godot. One basic one implementing the idle abd walk state and an advenced one dealing with signals and multiple objects
Learning the basics of FSM also helped me a lot. I used to feel confused while coding, but now I can organize my thoughts into clean code. I'm also trying to use the concept of SignalBus. SignalBus is an autoloaded class where you can define signals that are global. For example, I'm building a space invaders copy and both player and enemy can fire projectiles . I created a ProjectileFactory that connects to the SignalBus.connect("fire", on_fire). And on the player and enemy I call the SignalBus.emit_fire() that I implemented to abstract the emitting action
Indeed criticism is very hard to digest for some people (myself included 🤣). You did a phenomenal job in improving the overall feel of the char controller. Looking forward to playing this game on launch.!
About the head in your attack animations, try using inverse kinematics to make it looking forward, but I'm not sure how will it works when it comes to your target lock system. I do also agree that you need to learn some state machine patterns in a different project to learn it. I'm currently in that phase of learning and that thing still not sinking on me yet. Take your time and pacing in developing your game, and I appreciate your progress.
ooo good idea. It might also give me additional functionality to specify what the player might be looking at as well. We'll see... Trying out FSM on a blank project is definitely on my todo list now!
@@Snaielyeah, IKing the head to an invisible object that you either have floating in front of the model or sitting on your lock-on dot is pretty helpful for making the character look better animated than it is. Also useful for making/prototyping cutscenes with less actual animations involved.
I would HIGHLY suggest skipping a character entirely at this stage. Animations are crucial to get the feeling right, and if there's no way to get specialized ones for your project - then skip them. Use a cube with a floating sword instead. It's super easy to animate, you can even make it code based. That you way you don't have to rig or animate at all. Believe me, I was in your shoes some time ago. Bad animations will prevent otherwise good mechanics. Going for the cube is probably the best thing I have ever done in gamedev. Just make sure to give it feedback, like tilts, size changes etc. So that it still communicates with the player. Regarding player movement speed, build an "ideal" level before fully commiting on which speed you want. Changing to a jog is great, but player speed is ultimately highly dependent on the levels. In an empty greybox area, you're always "too slow". Yet even in a completed level, some players always feel like you should move faster, and they will never be satisfied. So just make sure the speed matches the levels and the vibe you're going for! :)
Dont worry about the spiral.. If you take Elden Ring or Sekiro, they move in a spiral too... It fells weird because you dont have an enemy moving towards you... get Elden Ring and lock target on a turtle that doesn't move, you will see that is a spiral movement too...
the enemy orbiting issue is because of the camera lerp. in ds they just have a small damping of the camera while the player strafes, while you have quite the lag. other than that, the player doesnt orbit perfectly in ds, that would take control away from them. instead, they just keep moving left and right based on the camera rotation itself (just with a much smaller damping than you have)
Hey, so I hopped in seeing this in my recommended videos while on autoplay. I noticed animation and rigging was not your strongsuit. If you want realistic attacking animations, consider a low budget MOCAP solution. if you have a relatively large room, with a very clear background, you can set up 3 or 4 cameras pointing at an actor, using a budget MOCAP suit made from a full-body greescreen suit, with a little masking tape for marking axis points. There is an example somewhere on TH-cam for it, and if your character rig is FBX or blend files, as long as they are pre-rigged, animation may be as simple as adding the mocap to it. Also, props on taking criticism like a beast! You're the type of indie dev I like to see starting a passion-based project.
the game looks great! the only problem I see is that the character shouldn't have acceleration. souls' games are supposed to feel snappy. cause of the amount of dodging and such in the gameplay. I recommend not having acceleration added at all. this will also make the animations seem snappier. when you stop. you want the player to feel in control of the player. not slide a bit afterwards. this might become annoying to players. especially if you have 3d platformer elements. acceleration and deacceleration feels nice in fps game and others. but I'm not sure. I think add something like how super Mario does it where Mario amps up his speed before walking. then it disables the acceleration afterward to have more precise movement. other than that, I think youre doing a wonder job. remember to just stay motivated and have fun!
But I think it depends on which vision he has for his game. I assume he's not trying to make a 1:1 copy of soul games so having small differences making his game stand out is a great addition. After all the goal is to be "inspired" by souls game not copy them. So I depends on what vision he has for his gam
Love the progress so far. I only have a few bits of feedback, 1. (and this may be something that you just haven't touched yet, given how early you are in the project), the attack feels like it doesn't have much feedback. Also, the attack feels a little slow given the weapon size. The attack is also very flourishy, although that may be the vibe you're going for 2. The acceleration/deceleration feels a little slow, which gives movement a slippery feel, that I'm not sure is desirable in a game like this. And finally 3. Adding coyote time could help with making the platforming a little more forgiving.
Maybe it's a bit late, but what I see alot in the before version, but still in the improved ones is the feet gliding. Maybe you could look into IK animations so the feet dont glide
In all honestly root motion should be used veeeery sparingly. It's really good for vaulting (almost necessary), heavy attack animations, and dodging. But other than that the only good root motion navigation system I've ever used is red dead redemption 2, and I still have complaints about that.
Will the lerp functions vary at different FPS on different machines? You could use the delta to smooth it and keep it stable regardless of how many frames are rendered
When it comes to the orbit movement around a locked on object I'm definitely not qualified to give you specific advice, however still here is my idea: What if instead of a circle we use a regular polygon? 1) rotate player to face the object 2) decide the number of sides you polygon should have (n) (This will depend on the tick rate of the simulation probably, and if Godot updates it's physics per frame instead of a fixed tick rate than "n" will likely depend on the frametimes. 3) (((n-2)x180)/n)/2 gives us the angle between the direction the player is facing (object we want to orbit around) and the direction the player should move to (the next corner in the n regular polygon). Maybe you can use that angle to rotate the forces that are applied to the player controller.
From just watching, it looks like the movement needs to be a bit more snappy. Like, make moving and dodging a bit faster, less of a start up to make it feel more responsive. Animation could play a big part of it, so take it with a grain of salt. I would watch some references to see how to make the attacks just feel better. The dodge needs to look more obvious you are dodging, but im assuming you havent added it in yet. Maybe even make it go farther? You'll be able to tell better if you work off of the animation. Like how the dark souls dodge is a roll, and the bloodborne dodge is a dash. I think they are different distances, but they both seem like a longer dodge than the one you have. One thing I just noticed about the walking animation, is that the sword looks like it has no weight. Maybe you havent added that in yet, but its like hes running with the sword model just placed in his hand so It looks a bit off. Try walking like your character animation in real life, but hold a stick or something sword like and see how the weight effects how you move your arms. Also the feet seem slippery, somewhat in general, like landing after a jump, turning and walking, just needs some polish in general. Sorry, I dont mean to make it sound like im just saying "Just make the animation better" But of some issues I see might be fixed just by polishing them up. Also small tip. Adding sounds can make everything just feel better, even if you change nothing about the game itself. Good luck on your game! This was my first time seeing anything about it so take everything I just said with a grain of salt!
i think a lot of some of the hardcoded checks you are doing could be eliminated by having a land state! you are doing things with timers to ensure you don’t slide on landing, and using raycasts to check if you are about to land. having a “land” state with a oneshot animation might help, that’s how i do my character controller
for example, rather than falling if you aren’t about to land, you could just always transition to falling after jumping, but if you hit the ground transition to land. and be able to transition to land from jump or fall
Yes that is the current behaviour! If you lock onto someone you can hide behind a wall and It'll stay locked on even with no line of sight. Now that I mention it, I need to add conditions that will actually remove the lock on such as getting too far away. Thanks for the comment, that's a new task for the todo list!
To decouple top and bottom animations for characters in Unity without using separate meshes, you can structure your character model with separate bone hierarchies for the upper and lower body. Rig each part accordingly and create distinct animation clips for upper and lower body movements. Utilize an Animator Controller with parameters such as "UpperBodyState" and "LowerBodyState" to manage independent animations. Implement blend trees for smooth transitions and use scripts to control Animator parameters based on user input or game events. This approach allows you to animate the top and bottom parts of the character independently without requiring separate meshes.
I think a raycast would help alot more to detect the distances between the player or the ground so base on how far from the ground they player is on click of the dogde it would work or not
Hey there is a lot to f feedback I have on the animation. I’m a senior gameplay animator as a profession. I think using the mocap you have is alright but you might want to learn the basics of motion builder to modify it a bit. It will let you modify the animation (adjust a pose on a layer) Pin limbs scale playback speed etc. set your animation and states up on a state machine. Look into scaling the playback speed of your animation based on the translation of the character when walking and running so the feet don’t slide around (you don’t need ik) especially for a souls.
hello, i tried opening up the demo in godot 4 and couldn't get it work, it just kept saying that the main scene failed to load. Do you know of any solutions? yours is the only soulslike character controller template i could find that has blocking implemented which is exactly what i need to make a "100% efficiency boss learner" proof of concept.
@@Snaiel oh ty that fixed the problem but after looking through the project i realised i've severely underestimated how complex a project of this type would be 😅and that to do what i want to do requires a very fundamental understanding of the project. your project has definitely come a long way already 👍
In regards to the movement seeming slidey and the walk/run transition seeming kinda jank, it might be good to have your speed have some wind up (e.g. look at dark souls where there's a small transition period between running, walking, and standing still), could be done through acceleration or interpolation of velocity, with a bit of blending to match. It really feels like there just needs to be a bit more friction and weight to some of the movements (especially stopping).
I really hope you just install the steam deck dev kit software as it already just uses an ftp solution. Buuuut you will need to download steam that im just hearing you talk about. If it make you feel better, on my get work done partition I do have steam installed but the dev kit is the only app installed. Wow wow! Neat update! you and I have similar goals my friend! But i’ve been going the learning to model and animate route first. I coded when I was in high school and a few hobby things but I guess I’m doing animation stuff first. Played a bit with godot and I’ve chosen it as my go to when I’m at that point. If you do break down and learn animation stuff, don’t give up. Its one of those things where practice makes it go faster but i’ll admit i took an online class that i thought would be maybe a month and it took about 5-6. I plan on having all my animations root animations and also plan on trying to split animations into modular parts at the torso (for things that would be useful for). I got a clip on my channel showing it, as the time of this posting it should be the only public video. Keep at it!
Do you develop on the steam deck (like with an external keyboard and mouse) or do you just put it on the deck just for the examples (the only computer i have is a deck and i like making games also)
@@Snaiel 7:39 cool. I did see some confirmation when I saw the titlebar or wherever of the engine itself and how it looked like gtk (I may be wrong) but also second guessed myself when I saw the taskbar or whatever and figured you must be using gnome which isnt on the deck
If you are more into coding than animating, why not look into doing more procedural animation like they did in Overgrowth? They have made some excellent talks, videos and articles on the topic. It is a very challenging approach to doing animation, but very rewarding for the amount of control it gives, especially over transitions and blends (including head facing direction).
ah thanks for bringing up Overgrowth. I'll have a look through their content and into procedural animation a bit more. I remember watching their GDC talk a few years ago, definitely gonna rewatch it now!
@@Snaiel Also, just found this out, apparently they've made Overgrowth open source! Can be easily found on Github, so I'm having a sniff around in it as well being likewise interested in procedural animation for my projects (non-humanoid animation is a pain).
I don't really understand why you do the raycasting thing with the falling animation. I mean that the way the character transitions from the falling pose to the standing pose doesn't make sense IMO. The reason why the falling pose looks the way it does is because the character is anticipating a landing where the knees will have to bend to absorb the g forces over a distance. It would make more sense if you delete the ray casting thing and make the character transition into a landing animation when it touches the ground again. Basically just a crouch down and a stand up.
I agree that my current implementation does not include the follow-through of the jump animation where the character should be bending their legs to absorb the impact. Thanks for bringing this up, I'll definitely look into getting the legs to bend a bit afterwards. When someone is about to land on the ground, they are anticipating this either way and that's when they extend their legs. That's why I have the raycast - to simulate the character anticipating their landing and so they extend their legs just before touching the ground. There is a transition time going from falling to idle/walking/running. So if I were to transition out of the falling animation only when I touch the ground, there is a moment where it looks like I'm still falling but I'm on the ground. This is what I tried first before the raycast method. Even if I wanted to bend the legs once I hit the ground, that means I would need to have straight-ish legs before actually touching the ground right? So the raycast is there to ensure the legs are extended before landing. Does that make sense? Sorry if I've been a bit long-winded.
I just stumbled upon this video and, before I go through it, I wanted to ask: Why can you jump? Are you going to get to higher areas if you jump on places? BIG red flag: Locking dodging and sprinting to the same button HAS to be something you think about before even working on the game. The difficulty of these action RPGs would go down massively if you had an individual bind for both sprinting and dodging. Another red flag: Buffered input systems are not always a good idea.
@@Snaiel Another example of putting two inputs on the same place is Wo Long. In that game, if you press B/Circle once you attempt to parry an attack, but if you press it twice in a short time frame you dodge. This means that mashing is severely punished, and your inputs must be deliberate. What happens if suddenly, in Sekiro, parrying was its own input rather than being a timed block? That means you could just block and attempt to parry anyway, but still be blocking in case you miss the parry. I also think it's very important to choose what kind of game you're trying to make. You must wonder why Elden Ring doesn't feature a parry system, like in Sekiro. A game you can draw inspiration from that has animation cancels, dodging, blocking, parries and deflects is Stranger of Paradise: Final Fantasy Origin. It's probably my favorite action RPG ever. And I find it the most complete package of both defensive and offensive combat systems.
Biggest complaint I have is something that, once you notice it, you can't unnotice it and you look for it EVERYWHERE. ... the feet..... they slide when planted.... This is highly non-physical. Since 90% of what you are doing here is bipedal locomotion of human actors, I would agree with the statement that you should pursue the use of the root motion animation as that is the best answer for traditional (manual) animation using purely humanoid actors. However.... I feel you discounted IK procedural animation a little too early. It's a bit more setup, yes, but from what I have seen it "automagically" solves a ton of animation problems you are currently fixing by "hand tuning." It is also way more scalable, both vertically (what you can make one character do) and horizontally (the other things you can animate). The best part is it's self synergistic. That is, as you add more layers, it gets better, not worse. There is a (sadly very short) GDC talk from years ago about the animation system made for the game "Overgrowth" that is the absolute bees knees on the subject, I suggest you check it out. (I will retract all of this in so far as, you are already pretty deep into your own system here that it's probably better to save the IK procedural animation for a hypothetical project 2.0 instead.) I'm a huge fan of state machines, I use them all the time in embedded system programing.... Don't use state machines for animations. Remember in the first part of the first video, where you showed that giant mess? THAT, that is where state machines will take you. Don't do it. I think your orbit is "good enough" as is, considering you have bigger issues. Even so... and it's kinda hackey, but you can parent your character to your lock target upon locking. Then, change the controls such that your distance to the target is just a change in radius, then use your strafe left/strafe right command to rotate that object. This should work because any object that is a child of another rotates with it's parent. (If I am remembering correctly.) Since Godot 3 you can have a spatial material with either alpha transparency or pixel dither transparency fade out/in. Only caveat is you have to set it up for each material, doesn't blanket apply to a whole node. Your idea for building up input buffering while you build up combat mechanics is the correct path and don't let anyone convince you it's not. Input latency and action correctness is a spectrum, and you don't want to be on either extreme. Decoupling your code can be easier said than done as it requires understanding the system, the language, and the problem. The hardest part is figuring the right timing to start refactoring. Refactoring early sounds smart, but strongly implies that you already know the final structure of a project you haven't even built. Doing it too late and you will get past a point where it's already so unmanageable a full rewrite will feel easier. (A trick that works for me is getting away from the project, sitting down and sketching out *with literal pencil and paper* a sort of abstract framework of your project as you think of it conceptually. Really visualize it just from memory, and try and put that visual into sketch form. The idea is, there are going to be parts you remember, and parts you don't. The parts you don't remember likely should be private to the object/script file. The parts you do remember clearly should likely be the interfaces between objects/script files.) Anyway... it's 3AM, and I should probably be refactoring MY OWN code..... 😅
Thanks for the comment!! Your thoughts are incredibly helpful. Everyone has been so nice and constructive I'm excited to show you all my progress haha. The guidance from comments such as yours is amazing.
Maybe I'm being cynical, but I hope you reconsider some of your approaches. It feels to me that, while you are aware that you may regret some design choices in the future, I would more liken the issue to a planning one. I know it is nice to be able to get in the code and trial and error things, but I assure you, planning is everything. If my comment seems vague, an example I see of your approach needing work, is in how you chose to lerp the player movement. Now, lerping is fine in theory, making things feel smoother, but from experience it often results in a sluggish feeling to people new to your game. Often, lerps should be done very minimally and very few and far between. If your players feel like dashing grants them more control over their character than simply walking/running, you're doing something wrong (unless that's a style choice).
I appreciate the cautionary advice. I’ll try to plan more and put more thought into the design aspect of things. Have you tried the demo? I’d like to think I use the lerps to make the character feel in the sweet spot between sluggish and unnaturally snappy. It feels different to sekiro or elden ring for better or for worse. I apologise if I am sounding too defensive. I hope I explained myself well enough. Thank you nonetheless for the comment, some cynicism isn’t bad as it ensures that I don’t get too ahead of myself haha.
Hope you enjoy this devlog! Little progress was made due to semester 2 of university but I’m happy with these changes.
I forgot to mention that I also made the player come to a stop quicker when landing on the ground, so that should help reduce the slipperiness.
I’ve got until March next year to put as big of a dent into the project as possible. On to the AI and combat!
Thank you for all your supportive and insightful comments :D
I never expected to appear on a devlog video of an indie game, let alone as feedback.
You've truly gained my respect, and not because I appeared in it but because you actually took the time to take the advice people sent and thought about it instead of thinking that you are instantly superior to everyone when it comes to your game, you even went as far as exploring the ideas of the feedback/advice we gave even if you didn't end up using it.
For example, in my case, I suggested IK's and understandably so you didn't use them since the creative freedom may be limited or make things not turn out the way you exactly want to, yet you still kept that piece in the video informing of your intentions with the game and making it easier to give better feedback/advice
That deserves much more merit than is given and indie developers should take notes from it.
Anyway much love and good luck with the project!
As a programmer myself, I seriously suggest you keep learning animation because that's the meat of an action game. Understanding animation principles and tools is the key to success to develop an action game. These knowledge teach you how to make these assets, but that's not important because you can always delegate the task to someone else. The more important part is it gives you an eye for good animation, thus makes you write better animation-related code, which in essense is the whole game!
Good point! I do love learning about animation principles so TH-cam videos and GDC talks about animation I do give a watch. I agree with you that I should be able to at least know what looks good so that I can effectively communicate with artists I work with. Thanks for the comment!
@@Snaiel Actually most complicated animation code is just trying to make an animation with code because fixed hand-authored animation cannot adapt to dynamic game play. That's why Unreal introduced ControlRig and in-engine rigging.
*laughs in mixamo*
As someone that is trying to make a third person action game on godot 4 this is very inspiring and motivating, keep up with it!
Hey man, lots of respect for taking the criticism like a champ. It takes a lot of maturity and humility to accept it. So good job! I wish you the best of luck with your project going forward!
That looks amazing, and is very inspiring! Glad to know that you can make a prototype this far without much 3d modeling!
These videos have been very inspiring. I hope you are able to continue finding the time and motivation to continue the project and devlogs! Great work!
I think the reason the sprint animation appeared to not blend is that the camera zooms out in a way that is not proportional to the speed. That makes it feel like you're entering "Running Mode" and less of actually running. (I'm not saying to actually tie zoom with speed, just delaying the zoom until the running animation/speed has properly started).
i really like the game idea, the work you put in and especially the fact, that you take criticism/feedback and actually implement it too. So here is more feedback, after i played the demo in your description:
1. when i don't move and press dodge, it would make more sense imo, if i would dodge backwards instead of forward, since if i fight an enemy that swings at me, i want to dodge away from his attack and not into it, even with s
2. for the parkour it would be cooler, if i can still jump a split second after i walked over the edge, instead of falling down immediately. I watch a lot of devlogs and play a lot of games and from what i know, a lot of games do this. It makes the parkour feel more forgiving (or maybe it's a skill issue from my side, idk)
3. the camera should follow the player faster, when i sprint to the left or the right. Currently i don't really see where i am sprinting at, when i don't sprint forward.
4. the movement still feels a bit stiff somehow, but unfortunately i don't have any idea/solution for this
5. (just a small thing i assume you would add sooner or later anyway) i miss an animation when i fall/jump off something high
About the dodge while on the jump state. I'd suggest using a Timer with the wait time equals to the maximum dash buffer you want to give to ghe player. When you are in the jump state and press dash, you start the timer, when you enter the grounded state, you check if the timer is running, if yes you should dash, else you enter the walk or idle state
Awesome video man! Im also trying to make a 3rd person game in Godot and you've gone over alot of the issues I need to address soon also. Really helpful since this is my first venture into game dev. Thanks alot! Really excited to see what you do next
I'm too tired to coherently explain it atm, but I highly recommend pulling the camera down a little bit and then angling it up a bit to compensate for its new position. I've spent a lot of time thinking about how the gameplay feel of the various soulslikes changes based on how they have their default camera set up and positioned. The way you currently have the camera positioned works well as a Locked On camera (though against really large enemies it'll benefit from automatically pulling out to keep the whole thing in frame and maybe tilting a few degrees up).
Another "small" gamefeel thing I'd suggest trying would be making the camera automatically pull in a bit when you're locked on and backing up, and pulling out a little bit slightly after your character starts sprinting.
My final thing is to maybe take a look at how the camera works in Breath of the Wild and Tears of the Kingdom. Idk how it works but when you're locked onto something the camera will do ANYTHING to keep both Link and the target in frame, while still letting you rotate it freely, and honestly it feels a lot better than how it works in any of the Soulslikes. It still has problems (my biggest one being the default angle locking on forces you into being at an angle that makes it a crapshoot on if you're going to backflip or side hop) but in my theoretical Soulslike that'll never be made I'd probably replicate and improve on those over how Souls does it.
-
Also yes, the Souls games all use input buffers. TL:DR DS1 is extremely aggressive and ER is a bit less aggressive, while the others vary between "kinda noticeable" and "not noticeable". Generally the implementation in both is disliked because people are mashers by nature, so being screwed by actions you input a second ago (or longer >_>), possibly while you were panicking, feels really bad most of the time. Implementation that aggressive does have a place if you're trying to enforce precision from your players, but generally people will like the gamefeel more if the implementation is closer to like 1/3rd of a second at most because it lets them buffer actions they know they want to do while getting ready to do other actions afterward while the animations play out, though it also depends on the individual action(s) in question.
Basically, be really careful with your buffer queue(s) and experiment with it and how it prioritizes the inputs it receives.
Thank you this is absolute gold
state machines are the goat! definitely give it a try if managing states gets unwieldy or hard!
overall really great devlog, really enjoyable
It's nice to see a ACTUAL indie dev without a massive studio behind them. Not to call anyone out, but there's only so much I can learn from a big studio as a lone indie dev.
fromsoft uses root motion to move
including all attacks.
but they use several functions in the animation to modify that movement
like to change your rotation velocity when attacking
or homing towards the target,
to shoot bullets,
to create (or activate) hitboxes (also hurt boxes),
hide\show parts of the model, etc.
this method is usually called TAE
"Time Act Events"
if you wanna know more about souls systems you can watch some modding tutorials on ds3 or ER
also you can chain blend nodes to blend more than one animation! this can start branching into a lot of combinations tho, so it may be better to do via code
Feedbacks really important and as you said we kind of become blind to some issues after a while and not even realise it. Currently i'm making my first pc game called Hell Runner and after i put it on steam as early access negative reviews literally display things i not even think as issue XD Thanks God after fix them and add this they suggested negative reviews gone :D
1:50 i also added lots of things where player try to do an action but cant so i make game remember that actions for a really short time so they can be executed when possible like jump, hookshot, wall jump.
This was interesting to see, and high quality video! Good luck to your channel and awesome project. 👍
thank you :D
I think your piercing attack and free fall animation are pretty cool :)
The code you used for dodge on land, is actually the exact same for jump input buffer. Platformers have this for jumping instead of dash. They also have coyote time... if you wanna put more time and effort into the movement. Though in souls games they are made with the intention without this to make them feel less agile, and heavy (but more realistically theyre not making a platformer so probably didnt think of it)
Honestly. Id keep dodge for tap, hold for sprint. Versatile verbs and all. Makes it feel more fluent.
If ya dont get state machines still, i could probably send some screenshots of my methods of using them. Its very helpful for running different functions when walking to falling and such. Allowing a lot more control, and trust me, it might not seem necessary now, but when you got 1k lines of code youll regret not using them xD
The circular velocity is genuinely hard. Out of all my time programming intense mechanics, the hardest was probably a perfect circle movement using kinematic controller for a 3D platformer prototype. Hell, the rollback was easier to set up. The reason it turns into a spiral is because when on the edge of a circle, right isnt right on the circle. Right will step outside. So youre constantly walking out of the circle and moving away. You need to "drift". So youd also need to step forward based on distance (bigger circles aka bigger ranges, require a more step forward). But so far my most accurate code is setting position rather than velocity. Look in cos/sin math.
If you dont want Steam on PC for productivity, make an alternative account on your computer. One for developing, one for gaming. Have steam inside that account.
Also im a professional 3D artist and animator if ya looking anytime soon xD
Can do cheap proto-typy stuff in the mean time if youd like!
Thanks for the insight! I’m definitely on the lookout for animators, my discord is @snaiel if you want to keep in touch :D
This is looking dope dude.
Going to keep my eyeball on this (if you want some sounds or music I can at least make some placeholders).
Great job! for better grounding of animations you could check on only making transitional animations, and also check the actual root motion distances of movement and speed/slow the animations accordingly. Also noticed your lerp has a constant value on weight, maxing it a sort of exponential decay, maybe it was intended, but if you want a more grounded blending when landing you can set the lerp weight to be calculated from the distance to ground.
Hey, Ive only watched your devlogs up until this video but what I find will help you with having to change things based on players criticism is adding a settings menu so people with different likings and playstyles can adjust accordingly instead of just hard coding it in.
Love it , its getting better !
As someone who used to be Finite State Machine (FSM)-phobic, I will tell you now that after learning it, it completely changes the game from spaghetti code to something that can be scaled and finished. I know this is a hobby project, but I strongly recommend maybe making a very basic FSM on a blank project, if not but to just learn what the concept is.
I'm not sure how it works in Godot, so you may need to interpret this differently, but the bare bones is that you have your character controller that is always in a given state. These states contain at least four functions: a start(), an update(), an ending(), and an animation(). The character controller needs to be given the ability to communicate to the state and vice versa -- so in this case, the character controller tells the state player input (update()), while the state will tell the character controller to transition to a different state (start()/end()), move (update()), change animation (animation()), etc.
Using your falling animation as an example:
1. Character is in an IDLE state.
2. You can separate the IDLE with a WALKING state (this would be scalable for like, directional attacks, but you can keep it basic and have the movement coded in IDLE).
3. Player walks off a ledge, the IDLE/WALKING state identifies that the player is no longer grounded, then tells the character controller that it should enter a FALLING state.
4. FALLING identifies when the character is grounded, then transitions back to IDLE.
This is scalable because you can dictate things like "no attacks can be done while falling" because the FALLING state does not have any code to tell it to do so. You have to think that in real life and even from a player's perspective, a human can only do one or two things at a given time, so the state machine gives you guardrails so you're not, say, executing a grappling hook while in the middle of a dying animation. Then once you start getting into subclasses/inheritance, you open the doors to so many other possibilities -- having a RUN state inherit from WALK, etc. You can even pass variables between states (e.g. RUNNING state stores velocity, and then the JUMP state inherits said velocity but can add a multiplier to decay, etc.) By design, FSMs give you the ability to have different abilities branch off (running attacks are different from walking attacks, etc.) and also gives you the ability to have intermediary states like STUN/STAGGER or KNOCKDOWN. And if you decide to delete features later on (e.g. ROLLING state or SWIMMING state), you don't have to fix other code related to it because they were engineered to be independent from the start.
FSMs aren't just limited to the characters. You can use them for AI, cutscenes, camera movement, menus, bootstrapping, etc. It is an essential programming pattern (among a few others) that will save you A LOT of headache in the long run.
Sorry, just wanted to give you an aggressive nudge in a direction because I've seen the light and need to preach it to others. Totally get if this sounds uncomfortable, so don't take this like I'm saying you need to be doing this. I believe the example everyone shares is that Celeste's character controller is like a billion lines of code on a single script, so whatever works works.
holy cow, thank you for your explanation. Your idea of implementing a FSM on a blank project is great. I really appreciate all of this.
@@Snaielthere is a guy called shaggy dev that has two videos on Finite state machine on Godot. One basic one implementing the idle abd walk state and an advenced one dealing with signals and multiple objects
@@Snaielsearch for the shaggy dev starter state machine
Learning the basics of FSM also helped me a lot. I used to feel confused while coding, but now I can organize my thoughts into clean code. I'm also trying to use the concept of SignalBus.
SignalBus is an autoloaded class where you can define signals that are global. For example, I'm building a space invaders copy and both player and enemy can fire projectiles . I created a ProjectileFactory that connects to the SignalBus.connect("fire", on_fire). And on the player and enemy I call the SignalBus.emit_fire() that I implemented to abstract the emitting action
I saw this idea with the CoffeeCrow channel "how to create or spawn bullets in Godot"
Very cool. One day I will get into this side of things but for now I am more in a Grey box side.
+ Probably one of the best devlogs I've seen so far.
Indeed criticism is very hard to digest for some people (myself included 🤣).
You did a phenomenal job in improving the overall feel of the char controller. Looking forward to playing this game on launch.!
About the head in your attack animations, try using inverse kinematics to make it looking forward, but I'm not sure how will it works when it comes to your target lock system. I do also agree that you need to learn some state machine patterns in a different project to learn it. I'm currently in that phase of learning and that thing still not sinking on me yet. Take your time and pacing in developing your game, and I appreciate your progress.
ooo good idea. It might also give me additional functionality to specify what the player might be looking at as well. We'll see...
Trying out FSM on a blank project is definitely on my todo list now!
@@Snaielyeah, IKing the head to an invisible object that you either have floating in front of the model or sitting on your lock-on dot is pretty helpful for making the character look better animated than it is. Also useful for making/prototyping cutscenes with less actual animations involved.
I would HIGHLY suggest skipping a character entirely at this stage. Animations are crucial to get the feeling right, and if there's no way to get specialized ones for your project - then skip them.
Use a cube with a floating sword instead. It's super easy to animate, you can even make it code based. That you way you don't have to rig or animate at all.
Believe me, I was in your shoes some time ago. Bad animations will prevent otherwise good mechanics. Going for the cube is probably the best thing I have ever done in gamedev. Just make sure to give it feedback, like tilts, size changes etc. So that it still communicates with the player.
Regarding player movement speed, build an "ideal" level before fully commiting on which speed you want. Changing to a jog is great, but player speed is ultimately highly dependent on the levels. In an empty greybox area, you're always "too slow". Yet even in a completed level, some players always feel like you should move faster, and they will never be satisfied. So just make sure the speed matches the levels and the vibe you're going for! :)
You can add a target to head bone to look where you need it to look. Like points of interest. Or while attacking.
Dont worry about the spiral.. If you take Elden Ring or Sekiro, they move in a spiral too... It fells weird because you dont have an enemy moving towards you... get Elden Ring and lock target on a turtle that doesn't move, you will see that is a spiral movement too...
the enemy orbiting issue is because of the camera lerp. in ds they just have a small damping of the camera while the player strafes, while you have quite the lag. other than that, the player doesnt orbit perfectly in ds, that would take control away from them. instead, they just keep moving left and right based on the camera rotation itself (just with a much smaller damping than you have)
good job , updates look great
Hey, so I hopped in seeing this in my recommended videos while on autoplay.
I noticed animation and rigging was not your strongsuit. If you want realistic attacking animations, consider a low budget MOCAP solution. if you have a relatively large room, with a very clear background, you can set up 3 or 4 cameras pointing at an actor, using a budget MOCAP suit made from a full-body greescreen suit, with a little masking tape for marking axis points.
There is an example somewhere on TH-cam for it, and if your character rig is FBX or blend files, as long as they are pre-rigged, animation may be as simple as adding the mocap to it.
Also, props on taking criticism like a beast! You're the type of indie dev I like to see starting a passion-based project.
the game looks great! the only problem I see is that the character shouldn't have acceleration. souls' games are supposed to feel snappy. cause of the amount of dodging and such in the gameplay. I recommend not having acceleration added at all. this will also make the animations seem snappier. when you stop. you want the player to feel in control of the player. not slide a bit afterwards. this might become annoying to players. especially if you have 3d platformer elements. acceleration and deacceleration feels nice in fps game and others. but I'm not sure. I think add something like how super Mario does it where Mario amps up his speed before walking. then it disables the acceleration afterward to have more precise movement. other than that, I think youre doing a wonder job. remember to just stay motivated and have fun!
But I think it depends on which vision he has for his game. I assume he's not trying to make a 1:1 copy of soul games so having small differences making his game stand out is a great addition.
After all the goal is to be "inspired" by souls game not copy them.
So I depends on what vision he has for his gam
@mrbob4104 I get that, but the point of having a "inspired" game is to make the game feel like the game its inspired by.
Love the progress so far. I only have a few bits of feedback, 1. (and this may be something that you just haven't touched yet, given how early you are in the project), the attack feels like it doesn't have much feedback. Also, the attack feels a little slow given the weapon size. The attack is also very flourishy, although that may be the vibe you're going for 2. The acceleration/deceleration feels a little slow, which gives movement a slippery feel, that I'm not sure is desirable in a game like this. And finally 3. Adding coyote time could help with making the platforming a little more forgiving.
Maybe it's a bit late, but what I see alot in the before version, but still in the improved ones is the feet gliding. Maybe you could look into IK animations so the feet dont glide
Have you tried to use Cascadeur to make the animations? I'm not an animator but I was able to make some descent animations using Cascadeur.
In all honestly root motion should be used veeeery sparingly. It's really good for vaulting (almost necessary), heavy attack animations, and dodging. But other than that the only good root motion navigation system I've ever used is red dead redemption 2, and I still have complaints about that.
Will the lerp functions vary at different FPS on different machines? You could use the delta to smooth it and keep it stable regardless of how many frames are rendered
I lerp inside the _physics_process function in Godot (like the FixedUpdate method in Unity). This means it will always run at 60fps.
For Input buffering, I know there is really nice plug-in for it for Godot
When it comes to the orbit movement around a locked on object I'm definitely not qualified to give you specific advice, however still here is my idea:
What if instead of a circle we use a regular polygon?
1) rotate player to face the object
2) decide the number of sides you polygon should have (n) (This will depend on the tick rate of the simulation probably, and if Godot updates it's physics per frame instead of a fixed tick rate than "n" will likely depend on the frametimes.
3) (((n-2)x180)/n)/2 gives us the angle between the direction the player is facing (object we want to orbit around) and the direction the player should move to (the next corner in the n regular polygon).
Maybe you can use that angle to rotate the forces that are applied to the player controller.
From just watching, it looks like the movement needs to be a bit more snappy. Like, make moving and dodging a bit faster, less of a start up to make it feel more responsive. Animation could play a big part of it, so take it with a grain of salt. I would watch some references to see how to make the attacks just feel better.
The dodge needs to look more obvious you are dodging, but im assuming you havent added it in yet. Maybe even make it go farther? You'll be able to tell better if you work off of the animation. Like how the dark souls dodge is a roll, and the bloodborne dodge is a dash. I think they are different distances, but they both seem like a longer dodge than the one you have.
One thing I just noticed about the walking animation, is that the sword looks like it has no weight. Maybe you havent added that in yet, but its like hes running with the sword model just placed in his hand so It looks a bit off. Try walking like your character animation in real life, but hold a stick or something sword like and see how the weight effects how you move your arms.
Also the feet seem slippery, somewhat in general, like landing after a jump, turning and walking, just needs some polish in general.
Sorry, I dont mean to make it sound like im just saying "Just make the animation better" But of some issues I see might be fixed just by polishing them up.
Also small tip. Adding sounds can make everything just feel better, even if you change nothing about the game itself.
Good luck on your game! This was my first time seeing anything about it so take everything I just said with a grain of salt!
I'd love to work on this project someday, as an animator and or even character artist.
i think a lot of some of the hardcoded checks you are doing could be eliminated by having a land state! you are doing things with timers to ensure you don’t slide on landing, and using raycasts to check if you are about to land. having a “land” state with a oneshot animation might help, that’s how i do my character controller
for example, rather than falling if you aren’t about to land, you could just always transition to falling after jumping, but if you hit the ground transition to land. and be able to transition to land from jump or fall
With the lock on maybe some lenience would make it seem consistent so if you peek in and out of LoS quickly you don't have to re-lock on every time
Yes that is the current behaviour! If you lock onto someone you can hide behind a wall and It'll stay locked on even with no line of sight. Now that I mention it, I need to add conditions that will actually remove the lock on such as getting too far away. Thanks for the comment, that's a new task for the todo list!
3:21 you should decouple the top half of the body and the bottom half. u don't want the animations to be coupled
also, consider making the character lean when changing direction
To decouple top and bottom animations for characters in Unity without using separate meshes, you can structure your character model with separate bone hierarchies for the upper and lower body. Rig each part accordingly and create distinct animation clips for upper and lower body movements. Utilize an Animator Controller with parameters such as "UpperBodyState" and "LowerBodyState" to manage independent animations. Implement blend trees for smooth transitions and use scripts to control Animator parameters based on user input or game events. This approach allows you to animate the top and bottom parts of the character independently without requiring separate meshes.
I think a raycast would help alot more to detect the distances between the player or the ground so base on how far from the ground they player is on click of the dogde it would work or not
Hey there is a lot to f feedback I have on the animation. I’m a senior gameplay animator as a profession.
I think using the mocap you have is alright but you might want to learn the basics of motion builder to modify it a bit. It will let you modify the animation (adjust a pose on a layer) Pin limbs scale playback speed etc. set your animation and states up on a state machine. Look into scaling the playback speed of your animation based on the translation of the character when walking and running so the feet don’t slide around (you don’t need ik) especially for a souls.
Where are y'all getting that blue test character model?
www.mixamo.com
this model is called "Y Bot"
hello, i tried opening up the demo in godot 4 and couldn't get it work, it just kept saying that the main scene failed to load. Do you know of any solutions? yours is the only soulslike character controller template i could find that has blocking implemented which is exactly what i need to make a "100% efficiency boss learner" proof of concept.
I explained this problem at 24:19
check out github.com/Snaiel/Godot4ThirdPersonCombatPrototype/issues/3
@@Snaiel oh ty that fixed the problem but after looking through the project i realised i've severely underestimated how complex a project of this type would be 😅and that to do what i want to do requires a very fundamental understanding of the project. your project has definitely come a long way already 👍
thank you. good luck on your game dev journey!
I wish there was templates like this in godot's marketplace, is the target an actualy game, or a market product?
an actual game :D
In regards to the movement seeming slidey and the walk/run transition seeming kinda jank, it might be good to have your speed have some wind up (e.g. look at dark souls where there's a small transition period between running, walking, and standing still), could be done through acceleration or interpolation of velocity, with a bit of blending to match. It really feels like there just needs to be a bit more friction and weight to some of the movements (especially stopping).
I really hope you just install the steam deck dev kit software as it already just uses an ftp solution. Buuuut you will need to download steam that im just hearing you talk about. If it make you feel better, on my get work done partition I do have steam installed but the dev kit is the only app installed.
Wow wow! Neat update! you and I have similar goals my friend! But i’ve been going the learning to model and animate route first. I coded when I was in high school and a few hobby things but I guess I’m doing animation stuff first. Played a bit with godot and I’ve chosen it as my go to when I’m at that point. If you do break down and learn animation stuff, don’t give up. Its one of those things where practice makes it go faster but i’ll admit i took an online class that i thought would be maybe a month and it took about 5-6. I plan on having all my animations root animations and also plan on trying to split animations into modular parts at the torso (for things that would be useful for). I got a clip on my channel showing it, as the time of this posting it should be the only public video.
Keep at it!
you will definitely need state machines in the future :) it's easy peasy, if not for animation, maybe you will need it for AI behaviour.
Yep you’re right. You’ll be happy to see what I’ve done in the next devlog :D
Do you develop on the steam deck (like with an external keyboard and mouse) or do you just put it on the deck just for the examples (the only computer i have is a deck and i like making games also)
I just put it on the deck for examples and to test the controller support
@@Snaiel 7:39 cool. I did see some confirmation when I saw the titlebar or wherever of the engine itself and how it looked like gtk (I may be wrong) but also second guessed myself when I saw the taskbar or whatever and figured you must be using gnome which isnt on the deck
@@hudsonator7259 oh yeah I use Ubuntu on my PC!
If you are more into coding than animating, why not look into doing more procedural animation like they did in Overgrowth?
They have made some excellent talks, videos and articles on the topic.
It is a very challenging approach to doing animation, but very rewarding for the amount of control it gives, especially over transitions and blends (including head facing direction).
ah thanks for bringing up Overgrowth. I'll have a look through their content and into procedural animation a bit more. I remember watching their GDC talk a few years ago, definitely gonna rewatch it now!
@@Snaiel Also, just found this out, apparently they've made Overgrowth open source! Can be easily found on Github, so I'm having a sniff around in it as well being likewise interested in procedural animation for my projects (non-humanoid animation is a pain).
Well done! This looks a lot better.
Are you in need of an animator? I primarily use Blender, and have been animating for games for 14 years.
Hello! Do you have discord? Mine is snaiel
What language are you coding in? I’m just getting started learning LUA and it looks like it a bit lol. Just curious
GDScript in the Godot engine!
Can you link the discord?
Sorry I don't have a discord server set up yet, but my username is snaiel if you want to message me at all
I don't really understand why you do the raycasting thing with the falling animation.
I mean that the way the character transitions from the falling pose to the standing pose doesn't make sense IMO.
The reason why the falling pose looks the way it does is because the character is anticipating a landing where the knees will have to bend to absorb the g forces over a distance.
It would make more sense if you delete the ray casting thing and make the character transition into a landing animation when it touches the ground again. Basically just a crouch down and a stand up.
I agree that my current implementation does not include the follow-through of the jump animation where the character should be bending their legs to absorb the impact. Thanks for bringing this up, I'll definitely look into getting the legs to bend a bit afterwards.
When someone is about to land on the ground, they are anticipating this either way and that's when they extend their legs. That's why I have the raycast - to simulate the character anticipating their landing and so they extend their legs just before touching the ground.
There is a transition time going from falling to idle/walking/running. So if I were to transition out of the falling animation only when I touch the ground, there is a moment where it looks like I'm still falling but I'm on the ground. This is what I tried first before the raycast method.
Even if I wanted to bend the legs once I hit the ground, that means I would need to have straight-ish legs before actually touching the ground right? So the raycast is there to ensure the legs are extended before landing. Does that make sense? Sorry if I've been a bit long-winded.
I just stumbled upon this video and, before I go through it, I wanted to ask: Why can you jump? Are you going to get to higher areas if you jump on places?
BIG red flag: Locking dodging and sprinting to the same button HAS to be something you think about before even working on the game. The difficulty of these action RPGs would go down massively if you had an individual bind for both sprinting and dodging.
Another red flag: Buffered input systems are not always a good idea.
Yeah jumping opens up the ability to do some light platforming but I was also thinking of incorporating it into combat to dodge certain attacks.
@@Snaiel Another example of putting two inputs on the same place is Wo Long. In that game, if you press B/Circle once you attempt to parry an attack, but if you press it twice in a short time frame you dodge.
This means that mashing is severely punished, and your inputs must be deliberate.
What happens if suddenly, in Sekiro, parrying was its own input rather than being a timed block? That means you could just block and attempt to parry anyway, but still be blocking in case you miss the parry.
I also think it's very important to choose what kind of game you're trying to make. You must wonder why Elden Ring doesn't feature a parry system, like in Sekiro.
A game you can draw inspiration from that has animation cancels, dodging, blocking, parries and deflects is Stranger of Paradise: Final Fantasy Origin. It's probably my favorite action RPG ever. And I find it the most complete package of both defensive and offensive combat systems.
Thank you, this is extremely insightful!
Biggest complaint I have is something that, once you notice it, you can't unnotice it and you look for it EVERYWHERE.
... the feet..... they slide when planted.... This is highly non-physical.
Since 90% of what you are doing here is bipedal locomotion of human actors, I would agree with the statement that you should pursue the use of the root motion animation as that is the best answer for traditional (manual) animation using purely humanoid actors. However....
I feel you discounted IK procedural animation a little too early. It's a bit more setup, yes, but from what I have seen it "automagically" solves a ton of animation problems you are currently fixing by "hand tuning." It is also way more scalable, both vertically (what you can make one character do) and horizontally (the other things you can animate). The best part is it's self synergistic. That is, as you add more layers, it gets better, not worse. There is a (sadly very short) GDC talk from years ago about the animation system made for the game "Overgrowth" that is the absolute bees knees on the subject, I suggest you check it out. (I will retract all of this in so far as, you are already pretty deep into your own system here that it's probably better to save the IK procedural animation for a hypothetical project 2.0 instead.)
I'm a huge fan of state machines, I use them all the time in embedded system programing.... Don't use state machines for animations. Remember in the first part of the first video, where you showed that giant mess? THAT, that is where state machines will take you. Don't do it.
I think your orbit is "good enough" as is, considering you have bigger issues. Even so... and it's kinda hackey, but you can parent your character to your lock target upon locking. Then, change the controls such that your distance to the target is just a change in radius, then use your strafe left/strafe right command to rotate that object. This should work because any object that is a child of another rotates with it's parent. (If I am remembering correctly.)
Since Godot 3 you can have a spatial material with either alpha transparency or pixel dither transparency fade out/in. Only caveat is you have to set it up for each material, doesn't blanket apply to a whole node.
Your idea for building up input buffering while you build up combat mechanics is the correct path and don't let anyone convince you it's not. Input latency and action correctness is a spectrum, and you don't want to be on either extreme.
Decoupling your code can be easier said than done as it requires understanding the system, the language, and the problem. The hardest part is figuring the right timing to start refactoring. Refactoring early sounds smart, but strongly implies that you already know the final structure of a project you haven't even built. Doing it too late and you will get past a point where it's already so unmanageable a full rewrite will feel easier.
(A trick that works for me is getting away from the project, sitting down and sketching out *with literal pencil and paper* a sort of abstract framework of your project as you think of it conceptually. Really visualize it just from memory, and try and put that visual into sketch form. The idea is, there are going to be parts you remember, and parts you don't. The parts you don't remember likely should be private to the object/script file. The parts you do remember clearly should likely be the interfaces between objects/script files.)
Anyway... it's 3AM, and I should probably be refactoring MY OWN code..... 😅
Thanks for the comment!! Your thoughts are incredibly helpful. Everyone has been so nice and constructive I'm excited to show you all my progress haha. The guidance from comments such as yours is amazing.
scripting language used?
The game engine being used is Godot and the scripting language is GDScript!
5:40 Hey I'm actually a professional animator. Want to collaborate?
You desperately need to read up on the state pattern.
In particular a hierarchical state machine implementation.
ok thanks
Huh, you don't have Steam downloaded yet you have an entire Steamdeck? Color me surprised. lol
Maybe I'm being cynical, but I hope you reconsider some of your approaches. It feels to me that, while you are aware that you may regret some design choices in the future, I would more liken the issue to a planning one. I know it is nice to be able to get in the code and trial and error things, but I assure you, planning is everything.
If my comment seems vague, an example I see of your approach needing work, is in how you chose to lerp the player movement. Now, lerping is fine in theory, making things feel smoother, but from experience it often results in a sluggish feeling to people new to your game. Often, lerps should be done very minimally and very few and far between. If your players feel like dashing grants them more control over their character than simply walking/running, you're doing something wrong (unless that's a style choice).
I appreciate the cautionary advice. I’ll try to plan more and put more thought into the design aspect of things.
Have you tried the demo? I’d like to think I use the lerps to make the character feel in the sweet spot between sluggish and unnaturally snappy. It feels different to sekiro or elden ring for better or for worse.
I apologise if I am sounding too defensive. I hope I explained myself well enough. Thank you nonetheless for the comment, some cynicism isn’t bad as it ensures that I don’t get too ahead of myself haha.
>memedot
are you a climber
You sound just like Climb Refine
yep that's me haha. super cool if you like climbing and game dev as well. probably a small overlap between niches!
Yeah thats actually sick. Those are like my 2 favorite things@@Snaiel