Variable speed vs. invariable speed

Started by Spekkio, December 08, 2007, 06:15:29 PM

Previous topic - Next topic

Spekkio

#45
Quote from: element54 on December 10, 2007, 02:14:55 AM
has anyone mentioned 3 speeds yet? i saw that spekkio has something for 5 speeds but that just seems a bit overboard and too much to work with.

slowest: material won't make noise, mercs can't hear you and proxy mines won't blow.
medium: material still won't make noise and mercs won't have the sound reticule ping but you will set off proxy mines.
fast: you fail. mercs can hear you, sound reticule will ping and you set off mines.

this seems a pretty easy solution to me.

I just don't think 3 speeds is enough to create a real difference between all the different types of surfaces. Under your system, it's still all or nothing -- you make audible noise on a surface at speed 2, and you don't at speed 1. You might as well just have 2 speeds then.

At 4 speeds you can divide it up nicely by surface type:

-speed 1: used for very loud surfaces like gravel or metallic rafters, or when the merc is in very close proximity
-Speed 2: used for surfaces like ventillation shafts or shallow water, or when the merc is further away
-speed 3: used for surfaces that could be loud, but not really like sand or wooden flooring, or when the merc is far away
-speed 4: used for quiet surfaces like carpet or solid flooring.

Not that that has to be set in stone, I was just throwing stuff out there quickly. You could use the numbers system proposed in the previous post. That would also allow you to adjust the values later as needed for balance.

Gawain

well adding complexity to the sound system sounds good to me, because in ct (with eax) it's like hearing everything like walking in vents, using hbs etc (but not that much other loud surfaces besides the cans in orph or the water in sherm), and the sound reticule is pretty 1 or 0; slow walk in vents is way too slow but ok in mine areas.
but i also think that 5 different crouching speeds is a little over the top. adding more different surfaces without eax sounds already sufficient to me; 3 speeds could work out well, too.

goodkebab

as Frvge said,   when you own the game engine, you can code anything you want and have complete freedom.  Only limitations are time/resources/technical budget.

I am not underestimating you guys when I say you would get tired of tweaking a map.  I speak from experience when I say artists will want to move on to new things after a certain point(usually after a few hundred hours on 1 map).  Bug fixing and balancing are not fun things to do,  it is not creative and gets quite tedious and boring.  It is a necessary job to do,  but if something is complicated from the start,  it will be even more complicated during bug fixing.  Add the fact that it is all done in your spare time, and the turn around time for these fixes will be even longer.


If there is a clean and efficient way to assign each shader a particular attribute that will tell the engine what kind of sound attribute it has...then it would be possible to create.  The level artist could then assign the shader the appropriate attribute,  and the scriptor would then effect the sound based on this attribute.

But that has to be answered by the programmers. If it is a complicated process that involves hard coding then we cannot do it.

InvisibleMan999

Quote from: goodkebab on December 10, 2007, 03:36:59 PM


But that has to be answered by the programmers. If it is a complicated process that involves hard coding then we cannot do it.

CT already does all the stuff you need to do. When you roll in a vent, you make a special "Vent noise". So already CT accounts for materials, it just doesn't have the code that makes it ping the reticule. All you're doing is that in addition to playing the vent noise, you're also creating a reticule ping. So you're going to have material sounds coded regardless and reticule mechanics coded regardless, this is just combining the two.

The only thing that actually needs to be coded is the variable speed animations.

Cyntrox


Gawain


goodkebab

Invisible,  you fail to understand that we are making this from scratch.  Not only that, but we are modding,  which means modifying existing code from Unreal Tournament which has nothing to do with CT.

Gawain

no. you fail to understand that you have to add specific noises etc anyways if you want to clone ct so it's not that much harder.

frvge

#53
We WILL NOT clone SCCT.
Quote from: savior2006SCDA has more bugs than a rain forest.
Quote
Treat your customers with respect you make more customers. Treat your customers like pirates, you make more pirates.

goodkebab

more like we WILL NOT...

And Gawain,  features like this are decided by the programmers,  not you...so dont presume to tell us how easy it would be to do these things.

Gawain

well you're post didn't make much sense...

haha yeah i will try to avoid the evil word in the future XD

Farley4Fan

Quote from: Gawain on December 10, 2007, 05:51:51 PM
Quote from: Cyntrox on December 10, 2007, 04:31:29 PM
PS isn't based on the CT code...
very intelligent post... ::)

Yeah, your post was MUCH smarter.  ::)  Please...

InvisibleMan999

Quote from: goodkebab on December 10, 2007, 06:38:02 PM
Invisible,  you fail to understand that we are making this from scratch.  Not only that, but we are modding,  which means modifying existing code from Unreal Tournament which has nothing to do with CT.

Right, but you're likely going to be creating a sound for walking on various surfaces, like CT had, and you're definitely programming in reticule mechanics.

So yeah, I realize you've got to code all this stuff yourself, it's just that this sound system is just a minor tweak to what you probably were going to code anyway. Unless of course you were planning on having only a generic footstep sound independent of what material you're walking on.

So if you've got the capability to:
-Ping the reticule (whcih you'll definitely have)
-play different sound effects depending on what material you're walking on (which you'll probably have)

Then it's actually a fairly simple matter to combine them, once you have the functions coded to do the two above tasks.

The hardest part as I said earlier is going to be actually programming the slow walk animations for various speeds. 

Is it worth it? That's for the design team to decide. But it should certainly be programmable if you wanted to.

LennardF1989

#58
"How troublesome" - Shikamaru

As a programmer, I don't see any use in more than 2 speeds ATM.

Like I said on the very first page, with multiple speeds, you will take eather the fastest noisiest or the fastest not noisiest, so it's way easier we set those speeds for you in just one click (eg. Middlemouse. you can ALWAYS remap).

It's a game of quick action, not of thinking what kind of speed you should use on the current surface. This will make mapping even more of a pain than it already is and the learning process will take much more time, since you would have to adjust speed on EVERY piece of the map. It will make the game loose all of it's fun, since you will be more busy with not being heard on the current surface than you are with the objectives.

To help some misery out of the world, the WHOLE game is build out of code, the animations don't go and move on theirselves you know? A weapon doesn't fire on it's own as well. What about the gametypes and the moving of the character? Don't make such dumb statements will you, it makes you look so dumb.

InvisibleMan999

Quote from: LennardF1989 on December 10, 2007, 10:35:18 PMIt's a game of quick action, not of thinking what kind of speed you should use on the current surface. This will make mapping even more of a pain than it already is and the learning process will take much more time, since you would have to adjust speed on EVERY piece of the map. It will make the game loose all of it's fun, since you will be more busy with not being heard on the current surface than you are with the objectives.


Yeah this is a good point Lennard. We probably don't want to force people to micromanage their speed all the time.

I'm thinking the speeds may be better off not being "speeds" at all in the generic sense but modes.

So you've got sometihng like.

Aggro- Full speed all the time.
Basic stealth: Adjust speed to produce minimal sound. If the merc is close by he can hear, otherwise no.
Full stealth: Auto-adjust speed to produce no sound.
Creep: Used against proxy mines. Always going slow speed.

Though this would undoubtedly be a lot harder to code than basic speed functions. So maybe it isn't worth it.