Unity Community


View Poll Results: Which real martial art would you love to master ?

Voters
435. You may not vote on this poll
  • Muay Thai

    71 16.32%
  • Ninjutsu

    86 19.77%
  • Taekwondo

    44 10.11%
  • Tai Chi Chuan / Qi Gong Jin

    28 6.44%
  • Jeet Kun Do

    39 8.97%
  • Pencak Silat

    10 2.30%
  • Boxing

    30 6.90%
  • Shaolin Kung Fu

    99 22.76%
  • I don't like martial arts / fighting games

    28 6.44%
Page 15 of 28 FirstFirst ... 5131415161725 ... LastLast
Results 281 to 300 of 552

  1. Location
    Paris
    Posts
    3,730
    Quote Originally Posted by covcomm View Post
    I see you have characters grabbing and flipping each other, putting submission holds on each other, etc. How was this accomplished? The animations look very precise!

    Do you have an animation for the player matched with a complimentary animation for the enemy during the move? Or do you have some other method? How do place the characters relative to each other in the game space? Is there a Unity transform.relative command in the unity reference I should be studying?

    lol, I need help dude!
    It was all accomplished under Cinema4D, by just animating the grab first, and then the enemy reaction with a visual reference to grabber's anim (in synchornicity) in a separate anim file. In Unity, when a grab is performed, it automatically launches the appropriate enemy reaction on its target. For target placement, I created a routine that place the enemy on a constant relative position to grabber's transform, yes
    Last edited by n0mad; 03-07-2012 at 07:07 AM.


  2. Posts
    9
    Quote Originally Posted by n0mad View Post
    It was all accomplished under Cinema4D, by just animating the grab first, and then the enemy reaction with a visual reference to grabber's anim (in synchornicity) in a separate anim file. In Unity, when a grab is performed, it automatically launches the appropriate enemy reaction on its target. For target placement, I created a routine that place the enemy on a constant relative position to grabber's transform, yes
    Thanks man, I see those type of special moves in Operation Raccoon City, Lollipop Chainsaw, Ninja Gaiden 3, and hundreds of other AAA games. But I could never figure out how they were done. Now I've got a clue!


  3. Posts
    134
    Always love seeing progress screens/videos here.

    I think the characters should have some kind of shadow rendering, even a simple quad with a texture will help. It will help with making characters appear more grounded. Since it appears all of your stages are on flat planes it should be relatively easy to implement with negligible performance loss.

    You could also look in this dynamic projector shadow script. Tested it myself and it works well on Android barring some performance loss, I know you have very little performance to spare maybe have it as an option


  4. Location
    Paris
    Posts
    3,730
    Quote Originally Posted by MABManZ View Post
    Always love seeing progress screens/videos here.

    I think the characters should have some kind of shadow rendering, even a simple quad with a texture will help. It will help with making characters appear more grounded. Since it appears all of your stages are on flat planes it should be relatively easy to implement with negligible performance loss.

    You could also look in this dynamic projector shadow script. Tested it myself and it works well on Android barring some performance loss, I know you have very little performance to spare maybe have it as an option
    Yes Flat shadow was planned but not yet implemented
    Thanks for the link though ! I was reserving some time in the future to search for a similar script, but now you got this one handled to me on a silver plate, thank you very much
    (Switching between full shadow, flat shadow and no shadow will be part of the game's 3 levels of visual quality user can select in options)


  5. Location
    Boston, Ma
    Posts
    2,439
    Hey Nomad...very nice video man... very nice... I can't wait to finally play this game


  6. Location
    Paris
    Posts
    3,730
    Quote Originally Posted by Neptune_Imaging View Post
    Hey Nomad...very nice video man... very nice... I can't wait to finally play this game
    Thanks
    I've also finished implementing each Martial Art unique throw, it's kind of working quite well visually (in the style of Tekken's spectaculary throws, for reference). I could've made another vid for it, but I prefer to continue spending most time on finishing the stuff, so that people can finally play it
    (actually 7 days a week on it)

    "Soon" (©) !


  7. Location
    Boston, Ma
    Posts
    2,439
    Not bad... I'm still setting up hitboxes on my fighters... not a simple task either... may need to do some cleanup lol...


  8. Location
    Paris
    Posts
    3,730
    Yeah, making a fighting game is a monstruous task ...
    I would never have guessed so back when I started.


  9. Location
    Boston, Ma
    Posts
    2,439
    I just hope I am setting up the hitboxes correctly...

    BTW: I'm a Pro User now


  10. Location
    Paris
    Posts
    3,730
    Quote Originally Posted by Neptune_Imaging View Post
    I just hope I am setting up the hitboxes correctly...

    BTW: I'm a Pro User now
    Congrats
    You'll see, some Pro features are definitely a life changer for proper visuals ^^
    (RenderTexture for effects and fast texture creation, Beast Global Illum, low-level graphic functions)
    And of course, the profiler, which I couldn't live without ... 80% of the actual best optimizations I've come to create in my code wouldn't have been possible without Profiler sample analysis.


  11. Posts
    615


  12. Location
    Paris
    Posts
    3,730
    Thanks for your interest Rockysam, it's appreciated


  13. Location
    Paris
    Posts
    3,730
    It's been a while since I didn't post any dev blog, so here we go !

    Last week, I initiated the completion of the whole AI, and realized while creating/optimizing my functions that there was a vital parameter that the AI wanted at any time : a 100% precise estimation of where, when, and how efficient a given strike would land. And of course it had to take into account collision simulations.

    Fast forward : I was wrong in my approach to deal with collisions, so I rebuilt it from the ground.
    Before coming to the solution I'll explain later in this post, I wanted to give yet another try at Physics. During 3 years I attempted time to time to create a setup that would respect my character animations, while still being blocked if any collision occured.
    The problem I had to face with such a setup was my animated Hitboxes (reminder : I'm animating all the hitboxes in my 3D app for 100% precision at any given time in any movement).
    Basically, my colliders were kinetic, but I still wanted them to act as not kinetic .... Weird I know, but in fighting games where precision is what decides of their success, I hadn't any choice.

    But after burning my brain (again), I finally found ! So here is the setup, if you want to use Physics for "hard animated" colliders :

    Collisions, Solution 1 :
    Physics driven, with Animated Colliders


    Pretty simple.
    First, you have to animate your colliders, like explained in this post.
    Now, in order to make them work with Physics without losing your animations, and more important, without having your character go bouncing everywhere because of animation driven forces, here is the setup you have to make :

    In Unity, your character has to respect the following hierarchy :

    MainGameobject
    |__ Limbs models (if you didn't combine them inside a SkinnedMeshRenderer, which is recommended)
    |__ Animated Skeleton
    |__ Global Hitbox
    |__ StrikeBox (if there is only 1. If there are several, for punches, kicks etc, you can tie them to proper bones)

    By GlobalHitbox, I mean the whole cube surrounding your character. Its bounding volume, in short, but animated. Reminder : It's better for fighting games to animate the hitbox by hand, in order to control 100% of the zones where you can hit (same for the StrikeBox, which is the hitbox for sent strikes. See previous link for further explanation).

    Then :
    - In the MainGameObject, just create a Rigidbody, and a BoxCollider.
    - Same in StrikeBox
    - Put the Strike Rigidbody to isKinematic, and its Collider on isTrigger (to prevent it from sending the target to Pluton when a fast animated strike registers)

    Now, the last magic you have to perform is to create a LateUpdate() script to tailor the HitBox Collider to its animated counterpart. (LateUpdate in order to wait for the animations to update the transforms).

    and that script would be just like this (pseudocode for names, but you get the idea):

    Code:  
    1. HitBoxCollider.center = AnimatedHitBox.localPosition;
    2. HitBoxCollider.size = AnimatedHitBox.localscale * 0.2f;

    I don't know why I had to multiply the localScale by 0.2f, but it fits perfectly with this value.

    And that's it. Your character should collide with other rigidbodies, all while being very precisely animated. It means that changing the center/size of a collider by script doesn't register it as a movement in Physics engine, so you can freely change its proportion this way, without it being thrown here and there weirdly by its own kinetic energy.


    If you don't have the expected result, try to play with the Hitbox Rigidbody properties. I deleted that solution from my code as I found a much more efficient one, so I don't remember exactly the details. But the idea is there, and it worked for me.


    Collisions, Solution 2 :
    Code driven, with Animated Colliders


    The problem with physics is that it adds another layer of management in your code, with the required FixedUpdate() function all being unsynchronized with frameRate. For games that are not super intolerant towards any tiny lack of precision, it's not a problem. But as you surely noticed in Street Fighter 4, or other recent advanced fighting games, each frame counts. Plus with physics driven collisions, there are often some very quick movements that can make your character go through the enemy on certain specific situations.

    So finally I chosed the good old way : Full manual handling by code.

    The hierarchy setup is the same as above, except a few details :
    - HitBox Rigidbody & its BoxCollider are not put in MainGameObject, but directly inside the animated Hitbox object.
    - and they are put on isKinematic (but not on isTrigger)

    Following that, a simple guiderule to follow with that solution : Never, ever translate or change position of your character directly. Instead, each time you want to perform such operations, you store the values inside a persistant Vector3 (overwriting it for setPosition, and adding a direction to it for translates).

    Then, everything happens in a global LateUpdate() function (in your view manager, for example) :

    This LateUpdate() will be the place where you scan those "desired" positions for each character, and where you will apply them, all while taking into account any collisions.
    And for calculating collisions in this way, it's rather simple. In fact, you don't consider new positions as absolute anymore, but like instant translations (just like physics in fact). That means each time you want to set a new position, you calculate if there's a collision on the line drawn between new pos and old pos.

    So, the collision test function for each character would look like that :

    1) Test if actual char bounds intersect with enemy bounds
    2) Same, but translating char bounds to desired position
    3) if 1) and 2) didn't register any collision, just perform a HitBoxRigidbody.SweepTest() towards the desired position. And if collision, use the generated Raycast to know where to set the new position.

    The order in this is very important, as it optimizes the calculations to perform (testing 2 bound intersection is faster than a whole sweeptest). Basically, 1) and 2) are there because SweepTest doesn't register any collision if the rigidbody is already colliding your target. So the routine starts with this case, and then with a full linear collision test.

    In all 3 cases, if there is a collision, it's up to you to decide where to constrain the desired position. But usually, you can just put it on the border of the target's bounds (left or right, depending where the desired pos comes from).

    If you want to test a collision with multiple other surrounding colliders, it's still possible with SweepTest, as it returns the first collision on the road. The only problem would be non-sweep testing, like in 1) and 2), as there is no way for Bounds.Intersect to register any collision, you have to specify a receiver.
    So the workaround would be to clear 1) and 2), and replace it with :

    Create an OnCollisionEnter/Exit() routine on your HitBox, which would update a Boolean value in your collision engine above. So 1) and 2) would check this boolean, instead of trying a Bounds.Intersects(). The only downside would be that this boolean would be updated only in FixedUpdate timeframes, instead of the (often) more frequent LateUpdate, but it should still give you better control than the entirely Physics managed solution.

    That's it.
    I tested the performance for the base solution above (Bounds.Intersects+SweepTest) : 0.13 ms per full calculation (when collisions occurs).
    Basically this "desired Position" philosophy is bullet proof, as you completely control the final setPosition, even after tons of translations in a single frame.
    Of course, this is for 2.5D, but it can be adapted to 3D easily as translating is linear.

    Voilą,
    I hope it helps.


    UPDATE :

    Edit : I finally updated the system with a completely non-Physics driven one, without using a single collider at all :

    1) with an Editor script, I'm baking all the HitCollider and StrikeCollider animation curves into a static file (generating dictionaries of AnimationCurves for position and scale, *not rotation*, as bounds do not have rotation properties).
    2) at runtime, when I load a fighter, I just create those 6 AnimationCurves and store them inside every action data class.
    3) in a FixedUpdate() function, I generate a Bounds object with the 6 AnimationCurve datas, and save it in a specific manager class for each fighter. Then I just do a Bounds.Intersects(targetSavedHitBounds) to guess if a strike has hit the enemy.

    Pros :
    - as fast to load than a normal FBX animation
    - much faster to test collisions, and especially AI predictions : because whenever I want to test a position for example, the engine doesn't have to read the whole animation for rotation, etc. I just have to read the given position axis curve (ex : X-axis when I want to test a front collision). This is technically 180% faster than a classical Animation Play for such a collider (as explained above, I was using fixed animations to test precise collisions).
    - I can now predict absolutely every single movement, strike, future collision, or complex motion, with a very small overhead, without having to call Animation.Sample twice (1 for the setup, 1 for the return to current state). Sample() was quite consuming. Now I just have to read the AnimationCurve at a certain position in time, and calculate bounds intersection from it. This will be of great value for later online multiplayer implementation, as I will able to rollback any lag to a very specific, precise position, all while respecting different collision laws.

    Cons :
    I didn't find any yet Dictionaries are mega fast to be readen, so loading such a file is nearly as fast as loading the AnimationClip itself. Plus, the file by itself is kind of lightweight, as colliders animations don't need to be heavily keyframed, only having key position/scale waypoints.
    Last edited by n0mad; 10-06-2012 at 03:32 AM.


  14. Posts
    2
    I'm new here in Unity and seeing your thread gives me the motivation to actually start a game of my own. Incredible art and gameplay as I've seen in your videos!!

    I'll be following your game, this is simply amazing and motivating bro! Hoping for a great success for you!


  15. Location
    Paris
    Posts
    3,730
    Quote Originally Posted by boisk View Post
    I'm new here in Unity and seeing your thread gives me the motivation to actually start a game of my own. Incredible art and gameplay as I've seen in your videos!!

    I'll be following your game, this is simply amazing and motivating bro! Hoping for a great success for you!
    Holy cow, thank you a ton Boisk
    Honestly, I'm not sure I would have started Kinetic Damage if I'd knew development would last for more than 3 years, lol. But over time, I found the whole creation process so exciting that I just couldn't give up ^^

    I wish you a great success in creating your project ! And don't forget to keep realistic goals
    Last edited by n0mad; 04-01-2012 at 06:54 AM.


  16. Location
    Boston, Ma
    Posts
    2,439
    This is very interesting... I am still doing characters and Solution 2 is definitely a smarter way to go... aside from the fact that i have hitboxes parented to the bones of my models (will that be fine?) and I can just switch them off when the character is not attacking...


  17. Location
    Denmark
    Posts
    58
    Get ready to become a millionaire !
    Looks awersome, looking forward to try it, I am sure your hard work will pay off


  18. Location
    Paris
    Posts
    3,730
    Quote Originally Posted by Neptune_Imaging View Post
    aside from the fact that i have hitboxes parented to the bones of my models (will that be fine?) and I can just switch them off when the character is not attacking...
    Yes it should totally be fine, as long as you chose the right hitbox to test collision with in your collision routine (if you chose solution 2). For example it would be kind of overkill to test legs, arms and head on top of torso for not-go-through tests (Unless you have very specific sliding motions that can drive a char beneath the belt level of an opponent, and only if your standing poses potentially position the torso box above that very level).

    edit : I forgot to mention about solution 2 : the whole "desired position" philosophy is a huge advantage for network modes. This way your local host (say, Player1 if he's hosting the game) can be used as a validator for every movement, and therefore avoid any lag jittering.

    Quote Originally Posted by Zhapness View Post
    Get ready to become a millionaire !
    Looks awersome, looking forward to try it, I am sure your hard work will pay off
    Oh thanks, I'm not asking that much though
    (but of course it would be great, and maybe I could use some to build a serious console version)
    About the work, I'm actually feeling like the overall visual could get more improvements on a one-man scale. I'll dig into some more advanced shaders when I'll have some time
    Last edited by n0mad; 04-03-2012 at 11:29 AM.


  19. Posts
    134
    Quote Originally Posted by n0mad View Post

    Oh thanks, I'm not asking that much though
    (but of course it would be great, and maybe I could use some to build a serious console version)
    About the work, I'm actually feeling like the overall visual feels a bit average for actual indie games. I'll dig into some more advanced shaders when I'll have some time
    You can't expect to wear so many hats of development and excel in all aspects However you've done an admirable job. Being in a similar situation I already know ahead of time that my environment art skills will likely be underwhelming when I finally start churning out those assets.

    Success will depend on replayability and smooth and bug-free multiplayer, and exposure in the marketplace. Do you have a unique plan for pricing/marketing or will this be a simple "pay for everything" deal?

    One plan may be to have a free version w/ perhaps 2 fighting styles and limited avatar options and an in-app purchase to unlock the full content.


  20. Location
    Paris
    Posts
    3,730
    Quote Originally Posted by MABManZ View Post
    You can't expect to wear so many hats of development and excel in all aspects However you've done an admirable job. Being in a similar situation I already know ahead of time that my environment art skills will likely be underwhelming when I finally start churning out those assets.
    Actually, if it can cheer you up, I started that project with absolutely no knowledge at all in proper rigging/complex animation, and the only models I did in 3D before that were slot machines and 3 naked women
    But I tried some tutorials (well it's not for envionment, but if it can help : I learned a lot from this one in modeling), and learning curve became smoother and smoother.

    Quote Originally Posted by MABManZ View Post
    Success will depend on replayability and smooth and bug-free multiplayer, and exposure in the marketplace. Do you have a unique plan for pricing/marketing or will this be a simple "pay for everything" deal?
    I've spend a lot of GDD for replayability can't tell much for now as it's always better to discover with a real video, but I really made my best to build a solo game as interesting as multigame with 2 factors :

    1) an advanced AI. It won't be yet another "player = punch, AI = instant predictable reaction".
    I'm working to replicate what a real human would play by building every routine around 3 simple "fighter brain caracteristics" (had more before, but juiced it down) : Agressivity, Reactivity, and Analysis.
    Each time one of this carac is chosen in a decision, it gives the AI a panel of related strategies to apply.

    For example, Analysis lets the AI guess better what the opponent is trying to do (strike 25 = X+Y+Z outcomes),
    Agressivity measures the amount of risk to take in a decision (strike even if opponent is striking ? go to close combat ? etc).
    Reactivity decides of counters and overall reaction ability, but it also serves as a balancer between Agressivity and Analysis. Because such an AI scheme lets me change a whole CPU strategy in one second by just adjusting one of those 3 stats, Reactivity would dose if it's time for the AI to pour more agressivity, or more analysis, given the situation. Some decisions are even judging the average of 2 of these stats. All in all this model opens to tons of possibilities and AI extensions (decisions are based on Requests, which are overriden classes of one that takes care of all the creation/management logic. Plus they are Coroutine based, which lets me create tons of different very specific AI Decisions easily, like waiting for a move, a situation, a stat, etc).
    I'll make a full post about the AI when it will be over (in the forthcoming couple of weeks), but in a word I'm working on making it interesting, varied, and challenging to just trigger a fight with the CPU.

    2) the other axis I'm using to boost replayability is how the matches in solo are intricated together. It will use a system of events, where the victory (or defeat) would follow a mechanic that would give the player the will to run another completely different, yet always available, event.
    It's simple to implement, and if the mechanics are good enough they could make a solo session last for an hour (it's a casual game, so one hour is a lot).

    Quote Originally Posted by MABManZ View Post
    One plan may be to have a free version w/ perhaps 2 fighting styles and limited avatar options and an in-app purchase to unlock the full content.
    I thought a lot about this, and finally decided to judge by taking the stance of a gamer : as a gamer, I don't like DLC, and I don't like having to pay several times to enjoy 100% of a game. So right now the goal will be exactly what you wrote : Free short version (2 martial arts, one level, sparring matches only) + in-app full version purchase. I can't ensure it will happen at 100%, because I never coded inapp purchases, and still need to analyze the possible distribution outcomes.
    But it's what I'm aiming at
    Last edited by n0mad; 04-03-2012 at 12:17 PM.

Page 15 of 28 FirstFirst ... 5131415161725 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •