A Unity ID allows you to buy and/or subscribe to Unity products and services, shop in the Asset Store and participate
in the Unity community.
Introducing the new Universal Render Pipeline and High Definition Render Pipeline subforums!
Unity 2019.3 Beta is out now.
Discussion in 'Made With Unity' started by n0mad, Mar 18, 2009.
More bimbos, please.
lol, I would have loved to
But poly number has reached the limit for this level
If I'd have more time, I would have solved this by creating billboard bimbos in the background.
(hey that sounds rythmic ! "Billboard Bimbos in the Background, yo")
Obviously you're a hardcore fighter fan, but it seems like your target market is a little different?
From what I can gather of your mechanics, timing and collision stuff you aren't aiming for frame level accuracy... is that correct?
How would you summarise your market?
Yes, I admit being what you can call the "hardcore" fan type in every games
(looking for absolute precision in gameplay, competitiveness, and complicated strategies)
Because I know hardcore fighting crowd is a niche, I designed Kinetic Damage's controls and mechanics either for those hardcore players, either people who just want to mash buttons.
I can't reveal 50% of the core mechanics right now, but basically being precise and strategic in your moves decisions will grant a fair advantage. While just searching the "push button = break face" feeling will work too.
I'm getting rid of complicated control mechanics, like quarter forward control types, 3 frames windows to perform a combo, etc.
You want to perform a special, just push the button.
Finger agility will still be requested, but will be more shifted toward right time decision making.
All while keeping intact the fast paced action, indeed (most strike launch times are below 0.25 seconds).
i'm also getting rid of anything we've seen in past fight games that could deteriorate the action intensity by abuse, like :
- projectiles (I hate to fight people who just flee to spam projectiles when they feel in danger, and I've seen a lot)
- grabs invulnerability (causing some player constantly searching to grab instead of looking for the right strike)
- turtling (people being constantly guarding)
- 20 seconds long combos (causing the victim being unable to play for 20 seconds)
- long infight cinematics, etc
I've really put a lot of effort to keep a perpetual mix of clash and decision making while fighting. I'm even thinking about putting a rule found in taekwondo which consists in giving a penalty if fighters don't exchange strikes within a 6 seconds time span ... I got yet to decide this
I also designed a lot of specials to have a counter ability (at a cost).
In short, I wanted people to give a real fight.
Additionally, I'd say that Kinetic Damage is absolutely not designed to be a competitor to existing fighting games, but more like a parallel experience.
I can perfectly see one hardcore fighting gamer to play both Street Fighter 4 for the agility based gameplay, and Kinetic Damage for its custom strategies and character evolution.
Existing fighting games focus on popular characters too, while Kinetic Damage focus on creating your own fighter, and making him/her evolve. It's a completely different feel and purpose.
In fact, timing is even more important in this game than any regular fighting game, because of some level of required management during the fight. I will expose those mechanics soon (when the fight HUD will be finished, in fact), but there's plenty of food for the brain.
I also designed every animation around a fixed template variation, so that chosing to perform strike X instead of strike Y is absolutely not a random decision for a player :
To say how much I was maniac about precision, the collision manager I was talking about 2 posts ago was specially made to force every transition to respect every strike duration.
Native interpolation via Animation.Crossfade() does crop the 2 animations due to interconnection, and would shorten each strike, leading to completely mess up all the balance I made with the Excel file.
With my manager, there is no more cropping, as animation 1 will put itself on an automatic ClampForever as long as it is not crossfaded with animation 2. When it's fully faded out, it returns in its Once wrap mode, therefore stops automatically.
Also, collision stuff is based on strikeBox vs hitBox, just like any fighting game, though.
1) hardcore fighting gamers who want to experience the same explosive, action packed fights but with a different gameplay and character approach
2) people who just want to smash some faces for short periods of times, wherever they are
When production cycle will be over, I'll produce some clear presentation videos, explaining everything in details. They will be available on kineticdamage.com for anybody who wants to learn more. Plus, the career mode will serve the learning purpose, taking players by the hand and ramping up their class knowledge.
Business Center Ruins, final state.
This is pretty damn cool man... this game has come a long way... I also love the Krav Maga demo too and it caught my eyes... if you are putting this on iPad, I will definitely buy it...
I had a hard time toying with Beast settings to bring some eye-catching lightmaps, it's like every knot little single nuance can change how the whole scene does feel ... I definitely give my respect to pro lightmappers who work on AAA huge scenes, they might become crazy at times, especially with the needed calculation time before seeing one single result.
Wait a min nomad, I thought you completed all levels already. Still working on art assets?
Past week + this week, I'm doing a second pass on every level, adding elements, refining, and reworking textures/lightmaps. I had to, because a recent test on an iPad screen would show some severe lack of details on certain levels.
Results are coming quickly, so it's not a big hit into dev cycle ;-)
You can test a comparison with old versions if you want :
Business Center Ruins before :
(Against now, in the previous post)
edit : crap, we can't really judge as the pics are too small ... But in short, lightmaps were badly managed (no real contrast), some parts of the view were filling empty, and some transparent textures did have aliasing. It wouldn't have caused any problem on tiny mobile screens, but iPad audience would have burried me alive
Loving this... keep this going. BTW, did you use Excel to do your spreadsheet for taking down data?
Using the Open Source version, Open Office
(but an Excel format, yes)
Sweet man... I need to start a spreadsheet for doing move names, move commands, and damage... i'm building all of the characters first with animation so this is a necessity...
It's a very tedious part of the design, I admit ... but necessary, so good luck
Wondering if my disorganization in this regard will effect me eventually I'm currently developing a side-scrolling brawler with fighting game style mechanics (combo strings) but been sort of haphazardly making things as I go along. It's worked for the most part so far
Of course I'm also using Playmaker so sifting through data is actually pretty manageable
It should be very ok imho, as hit data precision for single/co-op brawlers is not vital
It's not gamebreaking if said fighter can stunlock an enemy, as it's not meant to be PVP competitive play.
(This can be a breeze too, as it lets the animator unleash all his imagination on spectacular moves without having to check if it fits into hit data. More power to the artist ^^)
Night Mantis Club, final state.
I hope that booty wiggles.
More like booty waving ;-)
Ancient Shibuya, final state.
Station Spatiale de France, final state.
Just signed up to tell you that this looks awesome!
Your fighters have tons of character to them and the animation is smooth and visceral. Level design is also excellent.
I'm a big fan of fighting games like DOA and Tekken that are grounded but with a surreal version of reality like this one. When you do bring this out you have one definite customer right here!
Thank you very much guys
Transpacific Hovertrain, final state. All levels 100% finished, now on my way to finish the whole fight mode (95% finished).
As animation accesses are very, very frequent in fighting games (and as there are more animations to manage than other genres), I ran some test about which method to employ in handling an animation clip :
Another tip I found long ago, but never shared with the community yet, is how faking a string.Contains() by using IndexOf() + StringComparison.OrdinalIgnoreCase is 400% faster than the string builtin Contains() method.
Here are all the different Martial Arts combos !
Sound FX are just a rough, and a lot are missing (ambience, voices, other sfx, etc).
It's a lenghty video, but it covers absolutely every combos from all 8 martial arts
Just wanted to say that this thread has been an incredible read. As someone looking at getting my feet wet in game dev in the ios/android space its very inspiring to see the passion you have and the results you're creating as a single developer.
You're an inspiration! I am not a particularly big fan of fighting games but will definitely pick this up and check it out when it drops.
Wishing you maximum success!
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!
Thank you a ton, lightfalling
I wish you a successful road and a happy "welcome to indie dev !"
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!
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)
Hey Nomad...very nice video man... very nice... I can't wait to finally play this game
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" (©) !
Not bad... I'm still setting up hitboxes on my fighters... not a simple task either... may need to do some cleanup lol...
Yeah, making a fighting game is a monstruous task ...
I would never have guessed so back when I started.
I just hope I am setting up the hitboxes correctly...
BTW: I'm a Pro User now
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.
Thanks for your interest Rockysam, it's appreciated
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
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 :
|__ 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).
- 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):
HitBoxCollider.center = AnimatedHitBox.localPosition;
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.
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.
I hope it helps.
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.
- 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.
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.
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
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...
Get ready to become a millionaire !
Looks awersome, looking forward to try it, I am sure your hard work will pay off
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.
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
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.
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.
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).
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