First Person Shooter Ideas

Doesn't quite fit anywhere else? Post here!
21 posts Page 2 of 2 First unread post
Chameleon
Modder
Modder
Posts: 601
Joined: Thu Nov 22, 2012 6:41 pm


LeCom wrote:
The only thing on this page that sounds 100% like a good idea to me is grenades wasting players that are near them but not near enough to get killed.
"Wasting" as in "making them bleed", right? For example, M67 is fragmentation grenade, it relies on shrapnel(or fragments) to do most of the damage, explosion being only a secondary thing. And then, by my logic, if you get hit by shrapnel (not in Kevlar vest/Helmet), you bleed.
LeCom wrote:
HP balancing is a bit difficult. AoS has the problem that the only "source" of damage are guns, nades are negligible due to their nature of either doing <10 damage or instakilling. So, when setting weapon damage, you just would count how many hits that weapon would need for a kill. What I want to say is, the most common HP values aside from 100 are 51, 2 and whatever is left after getting hit by an SMG. Random gun damage is shit - so if you always get the same HP values, damage penalties would be pretty shitty.
Well... yes, 100/51/25/2 numbers are seen too frequently.
There are some fixes to this - and they can all be used at the same time:
a)Nothing that'd indicate your exact HP
Spoiler:
Image1.Area you are bleeding from 2.Health (and stamina) you have lost 3.If this area is flashing in bright red, it means you are bleeding out.
The only thing I want to point out here is absence of HP number.
b)bleeding would randomize it by 1-5 points (etc. you fight back before bandaging)
c)Damage falloff. It is quite nonsensical that @ 132-135 blocks damage suddenly goes from 100% to 0%. So damage falloff would start from half the fog to twice(or more?) the fog range. Mind that an SMG/pistol would have more/faster damage falloff than a rifle. Bleeding speed should not be affected. Kevlar/Helmet would make damage falloff a bit more obvious.
But be aware that if you make damage falloff too fast, it won't feel anyhow realistic and will break the mood (in cod it's there only to make sniper rifles useful, whereas in OS it would be to make killing harder/more random at bigger distances).
d)The less stamina out of max stamina you have (the faster your heart is beating), the faster you bleed out. So if you manage to hit someone who's sprinting, they'll be in deeper trouble.

Btw, I want this conversation to be open to all 15 people still on bns.com.
Chameleon
Modder
Modder
Posts: 601
Joined: Thu Nov 22, 2012 6:41 pm


Spoiler:
Chameleon wrote:
I looked up two videos. HE grenades seem to be fast - they have quite flat trajectory - easy to aim. Probably low fire delay too.
bad--- very arcade-ish; if grenade has flat trajectory they seem to be light and kinda made out of plastic.
Chameleon wrote:
What I did in 01.03 is good example of balancing - freeaim + not very accurate crosshair. In Hallway, when some random dude, 10 blocks high at your spawn, makes 1x3 hole in the wall and starts harassing you, it's hard to nade him. You can try cooking, but if grenade bounces, you're fucked ==> grenade is balanced.
kinda good, it is hard to lob grenade into window from 10 metres.
MAT nades are designed to be reliable and easy to use. It's much easier to nade kill in a game that doesn't use time fuses. It's also easier to land that perfect explosion because you know exactly how to bounce it
Well then it's up to you how arcade-ish you want it to be.
Insert the best magazine; if you are throwing ammunition away, throw out worst magazine.
Idea: a system that reloads to a magazine with the most rounds in it.
That's what I meant. Basically, for the most stuff you just apply IRL logic.
Also I have to point out that clips and raw ammunition rounds weight less than magazines ==> Shotguns, some rifles and revolvers can carry more rounds, but sometimes are loaded slower.
I'm unsure what to be specific about. I just don't like the idea of them [M203] in use up close.
They have arming distance, typically 40 metres. If lower than 40 metres, round is a dead round.
Also I forgot there is a buckshot 40mm shell. But some guys on forums counted that it is a bit less powerful than Benelli M3.
So... let's make this documented.
Each issue should start in new page.
You don't mind if my perspective is "ideas for OS"? I understand your perspective is about "ideas for a brand new game".
Chameleon
Modder
Modder
Posts: 601
Joined: Thu Nov 22, 2012 6:41 pm


Ok....
I am trying to figure out how to do mouse inertia.
I know there are methods that average mouse input over time, I don't want that (this is more like mouse smoothing actually).
I am not talking about this kind either:
Image
I am talking about this:
Image

Now what you see in those two images is the speed of resulting movement. 0 is starting point, 1 on X axis is the goal.
Imagine: you have a car, which can only accelerate at 1m/s/s or brake at 1m/s/s. So if you want to get from 0 to 1 on X axis, your speed graph over the distance will look like the second picture.

Implementing this is so damn hard for my mind, because I don't want mouse movement to be inaccurate.

EDIT:
I am thinking about something like this (integral stuff)(link I provide is too hard for forums to understand correctly, so "code"):
Code: Select all
http://www.wolframalpha.com/input/?i=-1%2F2x^2+%2B+2x+-+1+%3D+1%2F2+*+x^2
You can see in the graph how fast mouse movement should be changing. Start from 0;0 and go to 2;1, it's a very nice curve, no spikes.
Of course speed would depend on weapon weight and health left.

You can also remember old stuff:
distance'x = speed
speed'x = acceleration
distance'x'x = acceleration

Which means, in this case, that:
acceleration = a*x + b
speed = a*(1/2)*x^2 + b*x + c
distance = a*(1/6)*x^3 + b*(1/2)*x^2 + c*x + d

I think I'm right, at least I hope so.
Last edited by Chameleon on Thu Jan 28, 2016 8:27 pm, edited 1 time in total.
LeCom


Oh shit, d/dx formulas in IT. So, what's your problem here? As I said, just change values until you're happy with them. For the formula, dir.x+=xrel*xrel*c should be enough, with xrel being the relative mouse coord and c being some constant.
Chameleon
Modder
Modder
Posts: 601
Joined: Thu Nov 22, 2012 6:41 pm


LeCom wrote:
For the formula, dir.x+=xrel*xrel*c should be enough, with xrel being the relative mouse coord and c being some constant.
What do you exactly mean with dir.x+=xrel*xrel*c, what would be the result?
Should I store the difference between xrel*xrel*c and xrel and adjust for it during the next step? What is purpose of "c", what does it control - overall sensitivity or mouse inertia?

I am imagining your code like the first image, where your mouse input has instant acceleration, but still has some deceleration over time.
And actually it would make more sense than the second image/variant, which has both acceleration/deceleration. Guess I'm overdoing some stuff hehe.

And to be exact on my side, I want to simulate some weapon inertia and to have some mouse velocity for spread/recoil purposes.
Chameleon
Modder
Modder
Posts: 601
Joined: Thu Nov 22, 2012 6:41 pm


https://docs.google.com/document/d/1Lpm ... sp=sharing

This link makes you able to view the document. Mind it's in early stages, just a draft.
If you want to be an editor, send me your email address (***@gmail.com) to PM. Only known people will be editors.
21 posts Page 2 of 2 First unread post
Return to “The Lounge”

Who is online

Users browsing this forum: No registered users and 17 guests