Universal Fighting Engine Forum Universal Fighting Engine (UFE), a fighting game toolkit for Unity 3D |
You are not logged in. Please login or register.
Universal Fighting Engine Forum → Posts by Starcutter
I'm a bit behind since the original came out over a year ago, but I made an Among Us fangame with this engine!
itch.io download link
version 2.0 Trailer
(I'm still working on my main game, but I ended up spending WAY too long on this side project haha)
I bet in ProjectileMoveScript's update, you could have a check for if either of the players currently have no HP, and then set destroyMe to true. I believe that should work.
I'm thinking of trying to add more style to my game, and there's only so much I can do with text. Would anyone know where to start with displaying this kind of animation on round start/perfect/KO/etc?
Which scripts and where in said scripts are the relevant changes? I'd like to get some of these fixes into my project but I've heavily modified the source code so much that it'll fundamentally break my game if I just update like suggested. I'll have to manually add the new lines of code, which isn't too bad, but it'd help a lot if I knew where to look!
Specifically, I'm looking to add the network changes and fixes into my old build!
I had an idea, I'm currently trying to implement this myself but I thought I'd share it here too.
Sometimes my game likes to desync. It doesn't happen every game, and most of the games go by without a desync. That said, it's very annoying when it happens. After much thought, I figure this might be a good failsafe rather than just flat out disconnecting.
Ideally, it'll just turn off rollback for the rest of the round and then resume at the start of the next round. If anyone has an idea about how to go about doing it, I'm all ears! Currently trying to figure this out on my own for now though.
I imagine the code for this is in Flux Capacitor, I'll take a jab at it.
Probably not what your looking for but, Photon 2 can network strings.
okay, but how can I go about doing this? I'm completely lost.
I'm wondering if there's any easy way to send and receive simple variables online.
For example, I'd like to save a string to one of the scripts, and have that string sent over to the other player, while also receiving their string they have set too. These would be player IDs.
I just wonder if there's any way to get variables over so I can have stuff like player names displayed in-game.
I remember having an issue with this too! I think it's an issue with how limiting projectiles on screen works. Try disabling limiting projectiles to see if that works.
For my project, I remember having to go into the code and adding a check to see if the projectilemovescript wasn't null or something similar, but that was months ago. Either way I'm confident it has to do with the on-screen projectile limiter.
I just worked from a backup and re-implemented everything since my backup and now it's working fine?? Unfortunately, it seems like I'll never know what caused this bug...
I was testing my game today and found a new bug with it. If player 1 (only happens to player 1) taps right, it inputs whatever forward is twice. it just automatically does it. This causes issues as I have Dash mapped to double tapping forward.
I want to stress that P1 presses RIGHT, causing FORWARD inputs, regardless of screen side.
As far as I know nothing I coded into the game is causing this as I've reverted all my code since this bug has shown up and the bug has persisted. I think it could be an issue with Rewired, but I'm not sure.
I started messing around with it, but I don't think it works properly as of the current update.
Unfortunately, I don't think this is going to be of help as I'm trying to locate code to edit the spawn point in the pre-existing code, not spawning new particles from my own scripts. Thanks though!
I'm trying to figure out how to get hit effects to spawn in the center of the hitbox. Currently, that's how the circular hitboxes work, but for rectangular hitboxes the hit effects spawn at the origin point of the hitbox (The bottom left corner)
Is there some way I can check if the hitbox is rectangular and offset the spawn point by half the width and half the height, resulting in the particle spawn point being centered?
I've looked through plenty of the scripts where I thought I'd be able to find this but I can't find the exact code where it determines the hitsparks spawn point.
Oh! I've seen your stuff around on Twitter! It's looking really good and I hope it plays as well as it looks!
To actually answer your question, I'm sure that completely creating menus from scratch is entirely possible. It would be a lot more complicated and you would need a lot of custom code I believe.
If there's anything, I'd recommend starting with the UFE menu system, or at least doing mostly everything from what UFE would consider as the main menu prefab. I don't think there's a lot of resources on this topic so I wish you luck!
I did something like this using a gauge. For airdashes, I just assigned airdashes to use up an entire gauge (I used gauge 5) and then I coded in DefaultBattleGUI (Probably easier in ControlsScript.cs) to have the gauge to be maxed out if the character is grounded. That may be more up your alley...?
I don't believe this is a fixed bug, unfortunately.
I'm also getting double accepts, but only when using certain controllers. Keyboards and normal controllers seem to work fine, but fighting/arcade stick controllers have a double-input issue. It seems to be only affecting accepts, as canceling and moving the cursor seem to work fine.
EDIT: Actually, upon further reading, I'm not sure my issue is the same as the one described here. My inputs are registering fine in training mode. I will say that in my case it appears that multiple different input systems are attempting to control the menus, as on gamepad both A and Y work as accept for some reason. Is there a known issue of switching to CInput having odd side-effects with the Unity Input System or something?
So there's a way to have sticky particles (Which are particles that move with the player), is there any way to copy that behavior to projectiles? That way we could make it look like projectiles orbit the player or have a constantly active hitbox surrounding the player.
I'm fairly certain that you could quite easily code in a way to have everything in the UI as the child of a gameobject and then have that gameobject setactive true/false when you want it in the DefaultBattleGUI.cs script
I'm pretty sure that it's a hard coded in mechanic of the game that if your character lands while being in stun, they'll go into knockdown.
For the projectile thing, you could try setting the hitstun to "reset hitstun," and set it very low amount of hitstun, but I'm not sure if that's what you're looking for
I have been having an issue for about half a year where blockable areas wouldn't line up properly with the gizmos when on the right side of the screen. This was solved by my having a huge blockable area on my moves, but this didn't quite work for projectiles.
I recently stumbled across the area in code causing this issue!
in ControlsScript.cs, there should be a line of code that looks like this:
if (!opControlsScript.isBlocking
&& !opControlsScript.blockStunned
&& opControlsScript.currentSubState != SubStates.Stunned
&& CollisionManager.TestCollision(opControlsScript.HitBoxes.hitBoxes, myHitBoxesScript.blockableArea, opControlsScript.mirror > 0, mirror > 0).Length > 0)while this looks harmless, it's actually only checking for if your character is on one side of the screen! To fix it, I just replaced it with this:
if (!opControlsScript.isBlocking
&& !opControlsScript.blockStunned
&& opControlsScript.currentSubState != SubStates.Stunned
&& (CollisionManager.TestCollision(opControlsScript.HitBoxes.hitBoxes, myHitBoxesScript.blockableArea, opControlsScript.mirror > 0, mirror > 0).Length > 0
|| CollisionManager.TestCollision(opControlsScript.HitBoxes.hitBoxes, myHitBoxesScript.blockableArea, opControlsScript.mirror < 0, mirror < 0).Length > 0))There's also the same line of code in ProjectileMoveScript, and updating that should fix the inconsistent blockable areas on that side too!
I have no idea if this is new information or not, but I'm posting it just in case it is!
I wasn't using any sort of meter drain to initiate my stances, unfortunately. That being said, I found some relevant code regarding stances in MoveSetScript.cs. Since the character in question was intended to stay in their new stance for the rest of the game (including between rounds) I just made the code in that script that resets the stance back to stance 1 not apply if the stance was stance 2. Not a very elegant workaround, but now it works the way I want it to.
Is it possible that you're applying too much hitstun? I believe that air recovery options only happen when the player getting hit no longer are stunned.
I've been working with UFE for a little under a year now, and I've been dissatisfied with certain features & aspects of the engine's code. I believe it's lacking critical features present in modern fighting games, such as a buffer system to execute moves immediately after wakeup or after "Takeoff".
I believe that having a way to input a move during a basic move and have the move file executed immediately after the basic move is complete is something that would be vital for games made in UFE to be up to modern fighting game standards. Currently, partially because of this limitation UFE seems to have, "Tiger Knee" inputs do not seem to work. (Tiger knee inputs are when you do a motion input, followed by a jump and THEN a button in order to do an air move as close to the ground as possible. nearly all good fighting games are capable of this type of input.)
In addition to that, I think the input system needs a lot of work, a big factor my playtesters have complained about frequently is the fact that in order to have motion input moves be executed, the engine requires a direction input to be held at the same time as the button. In other modern fighting games, there's a small window where after releasing the stick back to neutral a command input can still be executed.
I've gone in and made various attempts to fix these kind of issues myself, and there are definitely other issues I have with UFE that I HAVE been able to solve (but not the couple here that I have outlined), but it would really be beneficial if the engine itself was updated to fix at least these couple of issues I have with the engine.
I appreciate UFE because I would not have been able to get so far into development without it, but attempting to polish the gameplay is an absolute nightmare on the coding side.
EDIT: So I've found out that TK inputs are in fact possible, oops my bad. That said, I still think it'd be easier if we could input the last button press of the move during takeoff and still have the move come out.
So I have another unity asset I'm trying to use, and I've discovered an interesting issue. The namespace from the new code I have does NOT like to play nice with UFE's scripts and vice versa.
I'm getting an error like this:
error CS0246: The type or namespace name 'Drawing' could not be found (are you missing a using directive or an assembly reference?)Does anyone know what could be causing this issue? because the namespace there definitely does exist.
(The unity asset I'm trying to use is Aline by the way)
EDIT: Figured it out, I had to go in and manually add the assembly reference to UFE3D.
Universal Fighting Engine Forum → Posts by Starcutter
Powered by PunBB, supported by Informer Technologies, Inc.