|
Captain Pike posted:I have recently read an article which states that while UDP should be used for most messages (such as player movements) TCP should be used for very important messages, such as player-deaths. (UDP messages aren't 100% guaranteed. If a player gets killed, but never gets this message, he will still be wandering around the map) As has been said, you can implement your own reliable messaging framework on top of UDP. I know some commercial engines do it this way, and if I recall correctly from reading the docs, Microsoft's XNA framework implements its reliable networking this way too. This book isn't specifically about game networking, but if I recall correctly, it has a chapter on networking which is useful for understanding different techniques (non-blocking sockets, threaded, etc) http://www.amazon.co.uk/Core-Techniques-Algorithms-Game-Programming/dp/0131020099
|
#
¿
Mar 10, 2008 16:10
|
|
|
|
| # ¿ May 7, 2024 05:55 |
|
|
Strumpy posted:In general though I'm not totally sold on the whole 'scripting makes things easier' front. Sure you may save some time compiling but I think it takes much longer to track down and fix bugs. Yeah I'm in two minds about this. Having worked on projects with scripting languages in the past. On one hand, if you do it right, it's great for debugging to just be able to write a lua or python script that creates an easy test-case for a bug you're working on. It's also pretty good to be able to easily throw something together, and move the slower stuff into C++ if it works out. On the other hand, a lot of the justifications for scripting languages fall flat on their face in reality, in my experience. The idea of designers being able to write their own scripts is great in theory, but in my experience, designers don't really want to be programmers, they just want tools that let them express their vision. The grand vision of designers creating scripts, just tends to turn into programmers having to do the more difficult stuff for them, and having to do it with inferior tools. Trying to explain object-oriented programming to a designer, that really, to be fair, shouldn't have to know about such things. Not fun. Scripting languages can come with their own set of hard to track down bugs too, Lua I'm looking at you. Spending an hour trying to figure out why the game is broken, only to find that someone accidentally mispelled a variable-name somewhere, that Lua just assumes is a new variable. Not fun. To be honest, I think visual languages like the Unreal engine's "Kismet", are a better way to go. Can't say I've had any experience of using Mono for scripting, but I imagine being able to use C# as a scripting language would make things much less painful. The Oid fucked around with this message at 13:34 on May 4, 2010 |
|
#
¿
May 4, 2010 13:28
|
|
|
Hubis posted:I imagine it gets annoying at the interface between the scripting language and the engine hooks. Also potentially a recipe for bugs if you have developers that have to work both in C++ and Lua, as it's very easy to forget when switching between them.
|
|
#
¿
May 6, 2010 00:14
|
|
|
Corrupted Cable posted:Lately I've been wondering how character creation sliders ( like those in oblivion and most of todays new games ) are coded/done. I searched around and found very few articles on the subject. Generally this is done by blending between different skeleton configurations, and vertex morphs, based on the slider values. So you'd have a variant of the player mesh, for each extreme of the slider, and just blend between the different variants, based on the relevant slider values. Similarly for the skeleton, you'd have a variant for a very tall character, a variant for a very fat character, etc, and blend between them appropriately. The Oid fucked around with this message at 23:59 on Jun 6, 2010 |
|
#
¿
Jun 6, 2010 23:51
|
|
|
Rocko Bonaparte posted:How would I have the spear slide through the players hands for a thrust? All I have here glues the weapon to a hand and that's that. I also have the figure out how to add animations for working with a spear and two hands; I'd probably want to play with the UE5 mesh for a long time, and I've heard of animation packs that just add new animations, so I'm hoping I can somehow slap that pawn in Blender and add some new animations. Then again, I'd have to do that with a prop spear to make sure they're coherent. Oh boy oh boy! An alternative to parenting the spear to the hand bone, would be to parent it to a different bone that's animated in such a way that the spear slips through the player's hands. (Similarly, in an FPS you might want to have stylish reloads that spin the weapon around or throw the gun in the air temporarily or something like that) I believe the ik_hand_gun bone is a good choice for this. Just be careful with some animations from the asset store though, because I've seen some asset packs just have that bone floating out in the middle of nowhere. Though usually that's just the asset packs that are intended to be used for unarmed players in my experience. For creating your own animations, there's also the possibility of animating in engine using Control Rig, instead of using an external application like Blender. If you look on YouTube, there are some good tutorials for this. The Oid fucked around with this message at 03:02 on Mar 20, 2024 |
|
#
¿
Mar 20, 2024 02:59
|
|
|
You certainly can grab the UAnimInstance/Animation Blueprint and push data to it, but there are multiple reasons not to do so. For one, if your player doesn't really know anything about their AnimBP, then you can easily swap it out for another one without having to rewrite anything (what if you have a player that is an old man and has a completely different animation set?). In software it's generally cleaner to have a one way relationship where only one side knows about the other, and the other side is completely agnostic. Secondly, Unreal has relatively recently added a way for anim blueprints to grab the data it needs in a threadsafe manner, which means that the Animation Blueprint can be parallelized instead of having to line them all up and update them one at a time (which can be a performance bottleneck in a lot of projects). For this to work safely, you want the AnimBP to be able to grab what it wants, when it wants and not have other classes potentially changing information while it's updating. Re: Grabbing information from the controller. This doesn't make a difference if you're making a single player game, but I would grab information from the pawn instead. In multiplayer, your controller only exists on your machine and on the server, which means that AnimBP's for remote players won't work.
|
|
#
¿
Mar 26, 2024 16:20
|
|
|
|
| # ¿ May 7, 2024 05:55 |
|
|
Rocko Bonaparte posted:First, can I get some recommendations for two-handed weapon animation? I am still struggling to figure out how to do this two-handed spear thrust well. I'm stuck on the approach for sliding the spear down the front hand--instead of both hands clenching to spear and jamming it. I'm guessing I should just stick to a single weapon bone and coordinate its animation in tandem with the player animation; it wouldn't be anchored to any of the player bones. I have seen some stuff about weapon IK but it's mostly animating the player holding a rifle and trying to bop somebody with it. I don't see anything for sliding something down a hand. I assume that kind of thing is just a pain in the rear end. Yeah a lot of the resources online that talk about weapon IK bones are going to talk about their primary use case, which is making sure that your player's hands stay on the weapon, even when you're blending a bunch of animations together, or retargeting to a skeleton with different proportions (which may cause one of the hands to become misaligned with the weapon). Typically the two IK hand bones ik_hand_l and ik_hand_r will be animated to follow the hand bones perfectly (but they don't have the same problem as the actual hand bones because they come straight off the root bone, so aren't affected by the transforms of other bones all the way down the chain from the pelvis to hand_l and hand_r.). For this use case you typically use IK nodes to make the hand_l and hand_r bones follow the ik_hand_l and ik_hand_r bones. (Just giving you context here, I wouldn't worry about this side of it right now, cross that bridge when you come to it). The ik_hand_gun bone should be animated in such a way that it has the proper offset from the hand that you want the weapon to have. But a bonus of attaching your weapon to the ik_hand_gun bone instead of the hands, is that you can animate that bone in any way you want without affecting the hands at all. Say for example your animation animates the ik_hand_gun bone to rotate relative to the hand that's holding the weapon, the weapon will now spin in the character's hand, because it's following the transform of the ik_hand_gun bone, not the hand bone directly. (For example, a fancy handgun reload animation that spins the gun around like Robocop) Or, more relevant to your use case, if the ik_hand_gun bone moves relative to the hand bones, then the spear will appear to slide through the character's hands. Rocko Bonaparte posted:This could be getting stupidly pedantic, but I wanted to double check something first. I thought I had my animation Blueprint grabbing the 3rd-person controller, instead of having the third-person controller grabbing the animation Blueprint. Or do you mean having the third-person controller Blueprint play an animation montage means I'm pushing data to the animation Blueprint? Oh I just meant for the Anim Blueprint getting information that it uses to drive its normal state machine (walk, run, etc). It's expected and normal that montages will get triggered externally. The Oid fucked around with this message at 07:00 on Mar 27, 2024 |
|
#
¿
Mar 27, 2024 06:58
|
|