[Project] Third Person Shooter

SerraAvenger

Cuz I can
Reaction score
234
the cam pops too much for me. There is a small problem with cliffs too.
I guess the cam popping is not really fixable and is a product of my n years old graphics card... Some X800GTO stuff :D
 

wingdnosring

New Member
Reaction score
16
the cam pops too much for me. There is a small problem with cliffs too.
I guess the cam popping is not really fixable and is a product of my n years old graphics card... Some X800GTO stuff

I recently upgraded from a card similar to that, but I can tell you that 'popping' is visible across all systems.

The issue is that I pan the camera to a point with an x offset from the marine every 0.03 seconds. Actually I think the currently uploaded version might be 0.01. Panning doesn't take much time, but while the camera adjusts itself the mouse input gets cut off. This means that for a fraction of every 0.01 seconds, the camera is adjusting itself and you're unable to change your look angle. I don't know of an ideal solution for this yet.

I reckon it might have something to do with the (Custom value 2 of (Attacking Unit)) * 33.3 but I don't know what the custom value 2 is. Even if it is 1, that is still gonna put yr bullet really high up.

Actually can you define all of those terms for me? Then I could probably give you a better idea of what it could be.

Unit - Change (Picked unit) height to (((Air height at Bullet_Temp_Creation_Point_Comp) + (0.6 + BulletHeightTempComp)) + ((((Custom value 2 of (Attacking Unit)) * 33.3) * (Sin((90.0 - (Asin(ComputerHeightAngle[4])))))) / (0.0 + ComputerHeightAngle[4]))) over 2.5 seconds

That red part is simply the height of the bullet origin, so you cna just ignore its involvement.

As for the variables:

Bullet_Temp_Creation_Point_Comp = where the bullet gets created upon firing
BulletHeightTempComp = a random value between the negative and positive version of weapon recoil
Custom Value 2 = the bullet speed of the character's weapon
ComputerHeightAngle[4] = the law of sines: (Pythag result*height difference) / sin90

Ignore the red portion.
 

onisagi

New Member
Reaction score
6
your map is coming along nicely.

your stuttering actually isn't from the offset, because it would still stutter even if the camera wasn't told to offset to the side. I would think the reason is because of the different update speeds. Your mouse movement of the camera side ways is much faster than the trigger updating the player's face-angle. Most of the stutter happens on your player's unit, so the main problem must be from the way you're updating the unit's angle, add a little more blend/duration maybe?

as for your problem with enemy firing height... the math isn't too hard. Enemy's just need to detect your unit, then find height difference. If below it'll deduct bullet height, and increase bullet height if above, by a time step until it reaches the difference.

I'mma need to look at your triggers to figure out what's wrong exactly, wen i find the time...
 

wingdnosring

New Member
Reaction score
16
Ah, welcome back onisagi :). Yes, it is coming along quite nicely, though the grenade didn't work out quite as planned. I'll be working on that again shortly :S.

The height isn't quite as simple as you think. Don't forget that if the missiles miss the marine, they have to continue upwards beyond him.

[Edit]: Aha! I *may* have figured it out. A problem that has plagued me since the beginning of this project has been the slow response time on changing height. I always thought this was simply an unfortunate cosmetic issue, but now I think it's actually causing the problems with bullet height. All of my missiles start at height 10. Upon creation, I lower them to 0.6 above terrain height. The problem is that quite often, they don't actually reach 0.6 above the terrain. They are immediately switching to the bullet height I mentioned before, long before they reach their first stop (0.6+th). I can put in a temporary fix for now, for the purposes of testing, but I need a long-term solution for this.
 

Tangd357

New Member
Reaction score
0
So you don't mind if we use your weapon system, wingdnosring (since you did put up the tutorial and all)? Mines pretty fail and I just can't wrap my head around the shooting process (not particularly are professional mapper).
The main thing I'm interested in is mainly just the shooting projectiles. The cover system and whatnot isn't really going to fit into my map.
I'd give credit for your efforts of course, you've done a great job. ^^
 

wingdnosring

New Member
Reaction score
16
Well, as I've said, it is a work in progress. I will keep uploading newer versions as I go along, so you may want to wait until I have a more solid version out.

But no, I have no problem with people modding this system. I set out to do two things:

1) create a basic system that people will be able to use come retail launch day that makes third person shooters easy and quick

2) create the base for a game I intend to create come launch day

The goal all along was for other people to go ahead and use it!

And thanks, it's nice to know my work has been appreciated and naturally, I would appreciate having my name mentioned in there somewhere.
 

SerraAvenger

Cuz I can
Reaction score
234
The goal all along was for other people to go ahead and use it!

Perhaps you should make it a library rather than whatever it is right now. It should have an interface to create weapon types, spawn weapons/ammunition on the map, and register a unit as the owner's "shooter". Getting the weapons a player currently has and being able to modify them would be great, too. I guess there's a couple of other stuff, but right now this isn't really a flexible, portable system - it's some stuff integrated into a map.
Not that it would be bad or anything, I just think it's not the right way to share code : /
 

Dave312

Censored for your safe viewing
Reaction score
269
Unit - Change (Picked unit) height to (((Air height at Bullet_Temp_Creation_Point_Comp) + (0.6 + BulletHeightTempComp)) + ((((Custom value 2 of (Attacking Unit)) * 33.3) * (Sin((90.0 - (Asin(ComputerHeightAngle[4])))))) / (0.0 + ComputerHeightAngle[4]))) over 2.5 seconds

That red part is simply the height of the bullet origin, so you cna just ignore its involvement.

As for the variables:

Bullet_Temp_Creation_Point_Comp = where the bullet gets created upon firing
BulletHeightTempComp = a random value between the negative and positive version of weapon recoil
Custom Value 2 = the bullet speed of the character's weapon
ComputerHeightAngle[4] = the law of sines: (Pythag result*height difference) / sin90

Ignore the red portion.

The formula you are trying to use is very confusing. There should be a much easier way of calculating the new height. Also I'm rather confused about why you are dividing by the angle at the very end.
 

wingdnosring

New Member
Reaction score
16
Perhaps you should make it a library rather than whatever it is right now. It should have an interface to create weapon types, spawn weapons/ammunition on the map, and register a unit as the owner's "shooter". Getting the weapons a player currently has and being able to modify them would be great, too. I guess there's a couple of other stuff, but right now this isn't really a flexible, portable system - it's some stuff integrated into a map.
Not that it would be bad or anything, I just think it's not the right way to share code : /

Indeed. But it is still in developmental stages. How would one go about setting up a 'library' like you're suggesting? Ideally, I'd like people to be able to look at my triggers, to see how I did things and why. If it requires true C++ code, there's no way I could pull it off. I have no formal education in math, science, or programming. Everything I know is self-taught. Unfortunately, C++ is not one of the areas I've delved into yet.

The formula you are trying to use is very confusing. There should be a much easier way of calculating the new height. Also I'm rather confused about why you are dividing by the angle at the very end.

Yeah it is. It's the formula I was using for the player's bullets, but I'm starting to think I'll just need to do the computer's missiles differently.

For the purposes of explaining it, I was using the Law of Sines.

That means that on a standard triangle using sides a,b,c and angles A,B,C that are opposite their lower case equivalents, the following statement is always true:

a/sin A = b/sin B = c/sin C

Since I know the distance travelled before reaching (in the player's case) the percieved depth of the aiming recitcle (weaponbulletspeed[currentweapon] * 33.3) and I know two angles (pitch of the camera and the 90 degree angle that must be in the triangle) it can be solved.

so, how do you solve for a side? Simple:

a/sin A = b/sin B
a = (b*sinA)/sin B

It is also important to note that the third angle, which is presently unknown, can also be solved. In triangles, all angles add up to 180. Therefore, with a 90 degree angle and the camera pitch known, the third angle should be 90-camera pitch.

That led me to the player's version. For the computers, I simply replaced weaponbulletspeed[currentweapon]*33.3 with custom value 2 of picked unit *33.3, which is the exact same thing. Since the camera angle couldn't be used, I attempted to find the angle of attack through the methods I mentioned earlier.

Now I'm wondering if I shouldn't just detect the slope of the angle between attacker and attacked units and simply raise the missile by that much every 0.03 seconds...

And it turns out I was wrong. The initial height change was part of the problem, but I've put a temporary fix in place and the bullets are still missing.
 

SerraAvenger

Cuz I can
Reaction score
234
Indeed. But it is still in developmental stages. How would one go about setting up a 'library' like you're suggesting? Ideally, I'd like people to be able to look at my triggers, to see how I did things and why. If it requires true C++ code, there's no way I could pull it off. I have no formal education in math, science, or programming. Everything I know is self-taught. Unfortunately, C++ is not one of the areas I've delved into yet.

You can simply create a library in the triggers module = )
When you're in the triggers module, you should see two libraries in the top left corner of the window:
Liberty and Built-In.
If you don't, you probably have to allow libraries to be shown in the editor.
Ctrl+Shift+L (for Library) can do the trick, or you can simply press the left red square button in the button list. (Next to the module buttons)

Once you're there, simply right-click, go to library, and then to "New Library". Name it something specific, like TPSLib.
Then right-click on the library, go to the "Library" submenu and then go to "change library id". The library id should be a unique identifier.
Probably you want to name it something that contains your name and a mix of letters that define the library, eg wtps or tpsl. Note that only four characters are allowed.
Once you've done that, you can start clicking.

One of the big advantages is that you can define functions and variables and other stuff as "internal", which will not display them from outside the library in GUI and will not allow you to use these from galaxy either.
 

wingdnosring

New Member
Reaction score
16
Very cool. Sounds like a good idea once I get things a little more stable. I'll just leave it as is for the time being though. I can move any already made triggers into a library later, right?
 

onisagi

New Member
Reaction score
6
you can always use a modified seeker missile for enemies, remove its homing step and adjust its speed. Then make it the normal attack of a bad guy. If you make the area damage smaller or non-existent you can dodge enemy bullets if the travel speed isn't too fast.

Make sure to make the model smaller... or use a different one, a giant ball flying at you looks like someone is firing cannon balls.
 

wingdnosring

New Member
Reaction score
16
Hehe. I don't think that would work. Does it detect cliffs? Can it detect cover?

Regardless, I actually just got enemies firing properly :). Ended up going with a whole new formula. Now my problem (because, YES, there is always a problem) is that I continue to take damage behind cover. Very significant damage. I've been wracking my brain for a couple hours on this new problem now and rewritten my missile travel triggers about three times...but I feel like I'm getting close ;)!
 

onisagi

New Member
Reaction score
6
yes, you can make bullets that don't ignore terrain, as for detecting cover, i'm sure you can make a validator to check for whatever you made your "cover" from, an actor? Maybe detect cliff level change?

i only purpose it because if you've seen seeker missile in action, its got really smooth up/down slope movement.

Very little is impossible with the data module, you just gotta get use to using it; look at diverse tutorials that make use of custom data module weaponry. The "Event +" field alone opens up seemingly limitless possibilities.

As for getting hit behind cover... don't you kill bullets that hit cover first before hitting your player?
 

wingdnosring

New Member
Reaction score
16
Yeah, got it solved now, but it was a little more complex than that.

The bullets would prioritize based on what unit (destructible or otherwise) was CLOSEST to them. I had to rewrite the trigger several times to make them successfully give a higher priority to destructibles. I feel that cover is a little TOO helpful now in some cases, because the chances of computers successfully hitting your head over cover is rather slim, but it's better than getting shot through the cover :).

By the way, I have a question regarding the data editor. Right now, I have the marine's shields set to a 6.0000 second delay before recharging. This means he has to avoid getting hit for 6 seconds for his shields to come back. Unfortunately, I based my computer firing triggers off of "A unit gets attacked" and changed my enemy unit's damage to 0, with high range. So basically, they hit you for 0 damage over and over again to initiate their bullet creation. Is there any way to change that delay field to him taking 0 damage, rather than not being attacked? I hope you can understand my quesiton, because I didn't articulate it all that well.

Also, how do you shut off that annoying voice when one of your units gets attacked?

[Edit]: Darn you! Now I want to see how it looks via the Data Editor. But its so much work to try something that's already working. I'll need duplicates of all my missiles, custom attacks for each unit....:( I bet it would work better too...anything in the Data Editor will always look better/be smoother since it's created directly by Bliz to work with their engine.

[Edit 2]: Alright, I did all you said with the seeker missile alterations for testing purposes, but I have two issues that I can't figure out due to my unfamiliarity with the data editor:

1. Getting the missile to detonate upon impact with cliffs or destructibles. Doodads would be nice too, but I don't know if that is possible.
2. Removing that targeting beam when the missiles are incoming.
 

onisagi

New Member
Reaction score
6
I took a look at your latest version, you still haven't implemented this to shut off the hp bars floating around your units ->
Action: Set unit state
unit: your unit
state: status bar
value: off

btw, i don't think i'll ever get around to that FPS camera fix i talked about. One big reason i like helping you is i'm just too lazy to make it myself, and i'm hoping you'd be the one to actually make this FPS library come true for the masses. I'm a big proponent of SC2 Galaxy Editor's abilities, i'd really like to see as much good come from this tool as possible.

My initial idea to smooth out the camera movement, was actually to apply a controller to calculate and "blend" the movement of each coordinate. Unfortunately, this would still fall victim to the minimum period limit and i could imagine other problems that could arrise... so...

i've since thought about other ideas, like speeding up the game speed using the galaxy function that was recently made popular by its bullet-time applications: http://www.youtube.com/watch?v=Y_1U7ar2ha, and scaling every other animation back down to normal speed, then your camera might update faster? Or i could just be totally wrong.

Btw, you can smooth your turning a little bit by putting this in to do the turning instead of forcing unit to look:
Issue Order
Unit: PlayerUnit
Order: Order Targeting Unit
Ability Command: Turn
Unit: TargetUnit
Queue: Replace Existing Orders

or alternatively it could target points with an offset to camera yaw. See if this can help you smooth out the turning? Your invisible actor is something i thought about using some time ago, but a little differently. How integrated is this invisible actor, or can you use this action instead? So you can test different configurations and see if one will lessen the stutter.

Also i've been testing different ways to lesson your unit stuttering from your instant move action. I'll let you know if i find something.

And i'm not sure what you're asking exactly, can you post your current test map so i can see how its reacting. And try to articulate better? Are you saying that the enemies are actually still trying to shoot you and causing your HP to never try to regenerate?
 

wingdnosring

New Member
Reaction score
16
There it is :).

The invisible unit was an idea I had a while back to try and force the controlled unit's body rotate up and down to face a target. To my dismay, it turns out the marine can't have certain parts of his body locked onto other actors :S. I used to have him face the yaw of the player's camera and it had roughly the same effect.

You'll notice that some of the triggers are a little messy in this early version 6. This was due to all my trial and error with bullet height and whatnot, but don't worry, I'll be cleaning it up before I upload it to the first page. A few other things have been temporarily reverted (like accurate impact effects), so don't be put off by them.

The trigger in question is Bullet Creation Computer within the Shooting folder. I considered stopping the units and running the trigger every time they acquire an attack order, but that presents difficulties with a cooldown :S. Basically, the trigger runs every time my marine is hit by an invisible 0 damage weapon. The 0 damage still restricts shield regeneration though :S.

Check the UI & Dialogs trigger. I did try hiding status bars but it didn't seem to work. Do I have to hide them every time Alt is pressed? I thought it was just something I could set like hiding/showing that would remain constant forever.
 

onisagi

New Member
Reaction score
6
I added this into your map initialization, and it successfully removed all HP bars of existing units. If you plan to spawn units, you just need to call the "Turn status bar state off" on last created unit to automatically turn off hp bars.

Unit Group - For each unit "Unit_variable" in (Units in (Entire map) having alliance Any with player Any Player matching Excluded: Missile, Dead, Hidden, with at most Any Amount) do (Actions)
Unit - Turn "Unit_variable" Status Bar state Off

You need to create a local variable inside your trigger to step through each unit on the entire map

Btw your enemy's shooting AI is insane... if you ever stand still they'll all hit you 100%. In most FPS/3PS games i believe they either slow their projectiles down so they're somewhat dodgeable, or make the projectiles slightly faster and make it so they "spray" an area randomly, instead of pinpointing you immediately.

If you're gonna have cover, it should be limited to things that are taller than you and covers your whole body, because right now the cover is working "too well" like you said, they can't even shoot you wen yur in plain view. Being able to shoot inside cover feels overpowered right now. Some covers are gonna be breakable ya? Alternatively, you could make it so cover only works... while you're holding the "cover" button, and wen yu release it you'll be in shooting mode, and anything that doesn't hit the rocks in front of you will hit you, that would be like arcade Police 911/Time Crisis influenced.

You probably already know your nades are acting funny... I think its the way you calculated gravitational acceleration, gravity needs to be stronger, you can tell because the projectile flies really high... or really far horizontally before falling. That's like moon gravity. And you should add a glow effect to it and give tribute to Halo, since it sticks like plasma grenades xD

Commenting more helps you develop faster too!
 

wingdnosring

New Member
Reaction score
16
All good points. I know grenades need a major tweaking.

The enemy AI is pinpoint more for testing purposes than anything else. I'll be making them less accurate soon, but I wanted to make sure they couldn't hit through cover and whatnot.

It's difficult to set up cover effectively without proper animations, but basically here's the way it works:

When you're in cover, your unit's collision height is halfed. If you aim within cover, it is amplified again, making your head a viable target. Ideally, I'd like the marine to be crouched down when he's not aiming, so that people can actually see that difference, but for the time being he has to be standing.

So basically, while you're shooting at them from behind cover, they CAN hit you, but the chances of them getting the perfect angle to hit your head when you're above them and largely covered is very slim. If you got onto cover on the same cliff level as them it would be different. If you're on the same cliff level as them they tear a chunk out of your health every time you start to aim.

I realize I don't comment enough. I've been working on that...in Warcraft I never commented at all. :p

So I have to hide every status bar individually, eh? That's a shame...good thing I only need to hide the health of cover and the player's unit, I don't mind enemy health showing up.

You may have noticed the marines were incredibly difficult to hit. When I uploaded the map, I was in the middle of testing hitting an enemy behidn cover from above, so I halfed the marine's collision height. Obviously I will be rectifying this.

The current cover system is a little overpowered if you have the high ground, but it really makes height count, as it should. If the enemies were above you, they could hit you over cover, when they're on the same level, they decapitate you if you try to aim. I really just need to work on their accuracy aiming upwards.

[Edit 2]: Solved the cover issue. There was actually a bug in that early version you tried, which made cover considerably larger than intended. Basically, cover was blocking shots regardless of height. It's been fixed now, so the cover blocks exactly the way it should.

Now I'm wondering how to work in MUI cover. It's probably best if computer controlled units don't move side to side on the cover and simlpy latch on and stay there to shoot, but how to go about that? I guess cover will have to be an ability they can use on destructibles. When they take significant damage a trigger will order them to use the ability on the nearest cover and then I can latch them on. The hard part will be aiming/not aiming, since they have no rigt mouse click events.
 

onisagi

New Member
Reaction score
6
enemy can just have different states on a random interval change. When its in cover state it'll hide and "not aim", when its in attack state they'll "aim". you should convert the way you detect aiming into a custom value, so it'll be unit dependent, and you wont have to create a new variable for every unit to flag their states. If it's already a custom value, then you're practically done already... xD

You can have a region limited event that randomly changes CPU units' states within a vicinity of your player. If you wanna be more comprehensive about it, you'll have states like "idle wandering", "seeking player", "hiding in cover", "shooting behind cover", "shooting in open ground"

After you have these action phases set, you can do things like make the AI throw grenades in the direction of the player when the player is "hiding in cover" state, or change to seek mode and get closer to you before attempting to fire again.

Depending on how far you want to develop the AI, it can be even more complex if you start converting custom values into binary, then you can flag multiple states. If you're familiar with binary at all 255 = 11111111, or 139 = 10001011, which allows you to change multiple flags. Feel free to ignore my ideas when i seem to go off into outerspace... i have a tendency to get overboard before i can even finish implementing the basics. Hence why i never really finish anything... xD

For now, i think an Aiming and not Aiming state that dynamically changes the enemies behavior on the field, will do what you wanna do. This shouldn't take too much time to get the ball rolling.


On a side note, i'd like to know the way your firing method works. I haven't looked into that specifically, but is there anyway to configure how accurate your shots shoot at a specific point? The bullets look like they are flying in randomized trajectories. Does that actually mean that each bullet has its own trajectory and collision or is that just the animation? It's pretty kool if those are randomized individual projectiles. I plan to do something like that for a zombie shooter i'm making soon.
 
General chit-chat
Help Users
  • No one is chatting at the moment.

      The Helper Discord

      Members online

      No members online now.

      Affiliates

      Hive Workshop NUON Dome World Editor Tutorials

      Network Sponsors

      Apex Steel Pipe - Buys and sells Steel Pipe.
      Top