Exploring the FPS side of Spring in constructive ways. - Page 3

Exploring the FPS side of Spring in constructive ways.

Various things about Spring that do not fit in any of the other forums listed below, including forum rules.

Moderator: Moderators

ZellSF
Posts: 1187
Joined: 08 Jul 2006, 19:07

Re: Exploring the FPS side of Spring in constructive ways.

Post by ZellSF »

BlackLiger wrote:I'm sorry, can both sides of this argument please provide evidence?
That he has no evidence that it is fact is my evidence that it isn't. Your request makes no sense.
User avatar
REVENGE
Posts: 2382
Joined: 24 Aug 2006, 06:13

Re: Exploring the FPS side of Spring in constructive ways.

Post by REVENGE »

ZellSF wrote:
BlackLiger wrote:I'm sorry, can both sides of this argument please provide evidence?
That he has no evidence that it is fact is my evidence that it isn't. Your request makes no sense.
lol the evidence being the lack thereof?
LBF_Vachequirit
Posts: 8
Joined: 26 Dec 2007, 09:59

Re: Exploring the FPS side of Spring in constructive ways.

Post by LBF_Vachequirit »

to come back to the original discussion, i also strongly believe that fps mode should be used more.

i'm no fan of FPSs btw, but it's just a fun way to interact with the game.

I'm like teutooni , i liked how you could fps the moho exploiters in BA, also, considering is cheating is a little silly imo. A game need tricks, because if not , it's not a game.

+ someone taking the time to FPS an unit in BA is already strongly disadvantaged by the fact he isn't handling his shit as a whole, so if they were some advantages to do it , it could bring FPS mode from "useless gimmick" to "fun bonus"

to sum it up :

- modders should find a way (if they want to naturally) for players to interact nicely with FPS mode. Giving bonuses and tricks is the key imo, but you need to balance them then.

- A widget that would make control of units easier would be nice, so that when you press "S" the units go backward to you, and in the game this translates by your unit making a 180° turnaround, while the head stays in the same direction. Same for left and right.
ZellSF
Posts: 1187
Joined: 08 Jul 2006, 19:07

Re: Exploring the FPS side of Spring in constructive ways.

Post by ZellSF »

REVENGE wrote:
ZellSF wrote:
BlackLiger wrote:I'm sorry, can both sides of this argument please provide evidence?
That he has no evidence that it is fact is my evidence that it isn't. Your request makes no sense.
lol the evidence being the lack thereof?
He's the one who was claiming it was fact, if it is fact it can be proven, to prove something you need evidence, that he fails to provide said evidence means that it isn't fact. How is this confusing?
Regret
Posts: 2086
Joined: 18 Aug 2007, 19:04

Re: Exploring the FPS side of Spring in constructive ways.

Post by Regret »

smoth wrote:Orly regret? I strongly disagrea, the maps alone will make it look like something from 96/95. The level of detail, collision detection and response to the controls will not be good enough for a FPS.
In my game, controls have perfect response in singleplayer, slight delay (+-500ms) in multiplayer. Collision detection is made fully by Lua. Since it is now possible to make both sphere and box hit detection, it's fully possible and quite simple to add primitive walls and even buildings using features. Level of detail depends on the artist.

As I said, none of what you said is a real obstacle.
User avatar
IllvilJa
Posts: 90
Joined: 08 Sep 2008, 00:01

Re: Exploring the FPS side of Spring in constructive ways.

Post by IllvilJa »

Just thinking about how to encourage players to "go FPS" ingame. Of course these mechanics should be configurable/optional by the one hosting the game, as some ppl prefer Spring to be "purely RTS" with little emphasis on the FPS side of it.

One way to get more FPS players is to let the unit's controlled in FPS mode be more effective relative to units only relying on the default autonomous micro-AI controlling them. This might sound unfair, but as the option of going FPS is available for everyone, it is actually ok IMHO. The nice touch to this is that the FPS controlled unit's get's that "Hero-role" which is nice to have when playing a combat game: that one manages to beat up quite a lot of enemy units while fighting in FPS mode, just like Indiana Jones, James Bond and Luke Skywalker does with the bad guys in the movies :wink: . If this get's too much of a problem for your opponent? Well, he's free to enter one of HIS units in FPS mode, and presto, we have a "hero vs hero" showdown on the battlefield, which could add even MORE to the epic movie feel :-) !

Ok, one way to make the FPS units more powerful (relatively speaking) is to have some option of HOW bad units in RTS mode should be at aiming. The player hosting the game may leave this setting alone, which means that all units fire with their normal accuracy (which increases as they get more combat experience) or it may be adjusted to make the RTS units better or perhaps WORSE than normal. Imagine that setting being adjusted so the aim precision of the RTS units is pretty lousy. In that environment, a FPS unit has a clear, movie-hero-like, advantage. A single infantryman in FPS mode may actually stand a chance against a tank in RTS mode. Of course, a tank in FPS mode may go totally Batman/Rambo/NeoAnderson and leave a beautiful trail of destruction behind him... until the enemy throw a big enough army at him to take him out. Sure, a crappy enough player may actually fail against these lousy RTS units but you may never make a system that is guaranteed to work in such circumstances anyway :wink: .

Another advantage one may consider is to let FPS units have much longer viewing distance at which they get enemy units rendered on the screen. Note that the enemy stuff visible at this long bonus distance by the FPS player is not automatically propagated to the rest of the team (for that to happen, he has to get as close to the enemy as he would had to if the unit had been in RTS mode, or perhaps, one may consider implementing explicit spotting of units like in Battlefield 2) but is useful to be alerted of dangers to avoid or easy targets to hunt down, perhaps by using long range weaponry.

Another way to encourage FPS mode is to allow players to choose to go RTS without any combat penalty but using a score system: all teams have a score which they try to maximize. The nasty thing here is that the ONLY way to contribute to that score is to inflict damage whilst playing in FPS mode. So players hopefully balance the RTS ecoromy building and strategic troop moves with some FPS raids where they try to beat up some enemy hardware and harvest some score for the team. A good RTS player means more teammates may go FPS which means more score for the team in the long run (hopefully).

Ok, enough for today, time to sleep!

Edit: Oh, of course. The obvious advantage to give to human controlled FPS units... allow them to move BACKWARDS! Key feature for ground units, to be able to retreat whilst firing, or to quickly take cover while reloading etc...
Posts
Posts: 63
Joined: 02 Oct 2007, 04:00

Re: Exploring the FPS side of Spring in constructive ways.

Post by Posts »

an example of doing hacky FPS in a RTS game: warcraft 3 custom map, something like "bomber command", camera was mounted behind plane, you would always go forward, keys to move, keys to change elevation, key to drop bombs, key to fire rockets straight ahead, two teams bombing each others bases for victory, polished map.

Sort of a compromise that could be successful:

instead of doing FPS use the normal RTS view to micro a single unit (think fallout or any RPG), this may give you what you find attractive in FPS, without the huge negatives of springs FPS mode.

The trick to making this work/attractive is a item system and mod specific maps.

I plan on making an attempt at this in December.
User avatar
SwiftSpear
Classic Community Lead
Posts: 7287
Joined: 12 Aug 2005, 09:29

Re: Exploring the FPS side of Spring in constructive ways.

Post by SwiftSpear »

Posts wrote:an example of doing hacky FPS in a RTS game: warcraft 3 custom map, something like "bomber command", camera was mounted behind plane, you would always go forward, keys to move, keys to change elevation, key to drop bombs, key to fire rockets straight ahead, two teams bombing each others bases for victory, polished map.

Sort of a compromise that could be successful:

instead of doing FPS use the normal RTS view to micro a single unit (think fallout or any RPG), this may give you what you find attractive in FPS, without the huge negatives of springs FPS mode.

The trick to making this work/attractive is a item system and mod specific maps.

I plan on making an attempt at this in December.
There are many issues with making a real spring FPS, the hitboxes and latency are set up for an RTS engine. We don't have prediction code, we don't have real hitboxes pretty much at all, you can't do area specific damage (headshots) because it's just not possible. Most types of traditional FPS maps won't work for many various reasons (only 1 floor, no ceilings), ground units aren't currently able to backpedal or strafe (no animations for it, and no game logic). They will look bad because spring isn't set up for the camera being that close to terrain, or even capable of doing proper walls for that matter.

The reality is, there's a HUGE ammount of engine development to be done before most of those can even be reasonably addressed.
User avatar
Blah64
Posts: 31
Joined: 09 Jul 2006, 04:02

Re: Exploring the FPS side of Spring in constructive ways.

Post by Blah64 »

does anyone remember the mod "Gun_Wings_Test"?
It was fairly popular back around 1.5 years ago. It was a mod where you were given a plane that you used in FPS mode, and you had to shoot everyone else down. It was good fun.

What happened to it?
User avatar
IllvilJa
Posts: 90
Joined: 08 Sep 2008, 00:01

Re: Exploring the FPS side of Spring in constructive ways.

Post by IllvilJa »

SwiftSpear wrote: There are many issues with making a real spring FPS, the hitboxes and latency are set up for an RTS engine. We don't have prediction code, we don't have real hitboxes pretty much at all, you can't do area specific damage (headshots) because it's just not possible. Most types of traditional FPS maps won't work for many various reasons (only 1 floor, no ceilings), ground units aren't currently able to backpedal or strafe (no animations for it, and no game logic). They will look bad because spring isn't set up for the camera being that close to terrain, or even capable of doing proper walls for that matter.

The reality is, there's a HUGE ammount of engine development to be done before most of those can even be reasonably addressed.
"Reasonably" in this context is purely subjective, to be frank. Whether or not several of the things you list really are show-stoppers for using Spring as the basis for an FPS game is also purely subjective. Basically it is just a simple matter of personal preferences whether or not Spring can be used for an FPS and so far, I have not seen any compelling reason for why Spring cannot be used for a great FPS according to _MY_ preferences. Heck, I just spent quite some time today flying around in an attack airplane in the mod Operation Polaris earlier tonight and I had a great time and did not really perceive any problems of such a nature that they were impossible to code away. The FPS UI is not always intuitive and the "built in aimbot" present in the game have some quirks, but none of those are really anything that tells me that FPS in Spring is a dead end.

I can definitely do without headshots. Area shots would be nice (like blowing up a turret on a battleship or taking out the machine gunner in the open hatch of a tank using weaker weapons without actually taking out the entire tank as the latter require anti-tank gear) but again, not required for a great gaming experience.

I have no problem with the hitboxes being a bit sketchy (it's actually spheres and/or ellipsoids IIRC). Also, hitboxes may be enhanched, not necessarely to the point where they exactly matches the visible geometry, but it is worth exploring what improvements can be done which provide much value to the game without costing too much development or game performance.

Regarding "traditional FPS maps" we have games like the Battlefield series where they have maps pretty much EXACTLY like those in Spring, that is, you have a heightmap with the terrain topography which is overlaid by a (huge) texture with the look of the terrain, so no problem with "floor only, no ceiling". Sure, the ability to wander around inside, under and upon objects (like bridges for example) would be great (and can be added in the future in various ways) but it is by no means a requirement for the game to be fun.

Regarding looking bad with a camera close to the ground I can again refer to my gaming experience earlier tonight and I had no problem with how the ground looked on the "Sail away" map while I were driving tanks, patrol boats and airplanes. So again, it works great according to my preferences.

Regarding the vehicles being unable to backpedal, I have to admit that even if that requires change to the engine to implement as well as additional animations for those mods wanting to support the feature (and I consider it very likely such mods will exist) it must be one of the relatively easier issues to address (and in my opinion maybe the only current "show stopper" in the list of issues you have presented as having the option to retreat with a vehicle while reloading weapons or in order to repair while still facing opposition is tactically quite critical). Lack of strafing is also annoying (infantry moves more or less like "turreted walkers") but it can be added to the game and with the right trade offs in effect (like only providing strafing as a movement option for units under FPS control) that addition can be made easier. Note, I'm not claiming adding backpedal or strafing is trivial.

Regarding latency:what network latencies are the resulting FPS game expected to operate in? That also has to be taken into account. The latency of ca 200 ms between US West Coast and Sweden is no problem for some applications (web browsing or SSH terminal access to an application) but I would never consider playing an FPS under those conditions. If I play together with my clan-mates and their buddies, we end up being a bunch of Swedes fighting it out, which makes the network latency between participants relatively low and the impact of the Spring engine's "RTS adapted latency handling" less problematic.

At the end of the day, it is really only a matter of preferences. And for every person, preferences matters, at least when judging what is good or bad. Your preferences are perfectly valid for determining if YOU will find a solution or game design viable or not. My preferences are perfectly valid for determining if I will find it viable or not. What should NOT be done is to use YOU preferences as the basis for determining if Spning can be used to create an FPS that is a good game according to MY preferences.

So, I'm still very optimistic regarding using Spring as an FPS engine for games I like to play.

Biggest show stopper for FPS play, IMHO, is the lack of regaining lost sync or more important, to syncing up with an ongoing game which one has not participated in before. THAT is needed to enable the ad-hoc joining/leaving of games that I find critical to most FPS games.
Regret
Posts: 2086
Joined: 18 Aug 2007, 19:04

Re: Exploring the FPS side of Spring in constructive ways.

Post by Regret »

SwiftSpear wrote:you can't do area specific damage (headshots) because it's just not possible.
Lua can do it.

1) create an 'invisible' unit with whatever hitsphere/box size
2) move said unit each gameframe to the position of your normal unit's modelpiece, for example head, set it's hitpoints to your liking
3) set your normal unit's hitsphere/box to near 0 size, set the unit's hitpoints and idletime and regen rate to some ridiculously high values so it can't be killed
4) do this for every piece of the model where you want your hitsphere/box

Of course I'm assuming here the use of lua movectrl and a whole custom collision system for units etc., but all that is already made in Mech Combat.

A less hackish method would be getting the point of weapon impact/explosion upon colliding with a unit, then calculating the amount of damage dealt by taking into account the position and radius of chosen modelpieces. And blablabla possibilities are numerous.
User avatar
hawk900
Posts: 4
Joined: 29 Oct 2008, 22:06

Re: Exploring the FPS side of Spring in constructive ways.

Post by hawk900 »

I was actually considering this myself. The interaction with terrain would be a problem, I mean as in height variances.
User avatar
BattleMonk
Posts: 44
Joined: 15 Oct 2008, 19:32

Re: Exploring the FPS side of Spring in constructive ways.

Post by BattleMonk »

i often crash when trying to fps units in BA
Regret
Posts: 2086
Joined: 18 Aug 2007, 19:04

Re: Exploring the FPS side of Spring in constructive ways.

Post by Regret »

hawk900 wrote:I was actually considering this myself. The interaction with terrain would be a problem, I mean as in height variances.
If you mean slope recognition for unit movement, already done that, units can jump off a cliff just as well as climb on it.
User avatar
KaiserJ
Community Representative
Posts: 3113
Joined: 08 Sep 2008, 22:59

Re: Exploring the FPS side of Spring in constructive ways.

Post by KaiserJ »

just a thought, i remember playing one of the old command and conquer games (possibly the very first) and using a commando unit who was equipped with a sniper rifle / stealth / some sort of plastic explosive charge / the ability to capture buildings. you could only build one of these units at a time if i remember correctly.

seems to me this could apply well to some of the mods and games i've played on spring, i know there are sniper units and stealth units as well as commanders who can fill the same sort of use in terms of capturing and blowing things up, as well as the fact that a commander is essentially a unique unit in your army (unless you are fortunate enough to /take another one.)

my suggestion would be, make a commander unit that is upgradeable so that it can shoot sniper style attack (dont have to get rid of dgun, replace the laser perhaps or make it a different attack altogether) only while in FPS mode with a generous range of fire, a faster movement speed, as well as a less expensive cloaking field and the ability to plant heavy mines / explosive charges in any view.

this would make the commander more self-sufficient, and tempting for players to use in fps mode for various purposes (sneaking into enemy territory and blowing things up, sniping other commanders, stealing babies, breaking porc defense by sniping etc. this would also make attacking the enemy base with your commander less of a suicide mission.

fps mode is cool, i can understand the arguments that spring cannot and will never become able to support a standard fast-paced fps game, but at the same time, the fps mode is an interesting and unique aspect of the engine, and i'm confident that with some care and effort it could be incorporated into the existing gameplay to provide a richer experience.
User avatar
SwiftSpear
Classic Community Lead
Posts: 7287
Joined: 12 Aug 2005, 09:29

Re: Exploring the FPS side of Spring in constructive ways.

Post by SwiftSpear »

IllvilJa wrote:
SwiftSpear wrote: Regarding latency:what network latencies are the resulting FPS game expected to operate in? That also has to be taken into account. The latency of ca 200 ms between US West Coast and Sweden is no problem for some applications (web browsing or SSH terminal access to an application) but I would never consider playing an FPS under those conditions. If I play together with my clan-mates and their buddies, we end up being a bunch of Swedes fighting it out, which makes the network latency between participants relatively low and the impact of the Spring engine's "RTS adapted latency handling" less problematic.
Spring doesn't handle latancy like an FPS game. All units are controlled server side, and every projectile and movement is calculated in parallel on every machine in play. It's ok for slow moving/lumbering particles and characters, and it's further amplified by the fact that targeting code handles the majority of hit calculation in spring, but in a true FPS environment with units and projectiles moving at any reasonable speed it would fall apart horrendously.

Ok, just speaking candidly, as a game developer, spring is not a good choice for an FPS. You could use a baseball bat as a hockey stick if you really wanted, and ya, it will techincally work, but for a number of reasons it's a bad idea. Spring doesn't have alot going for it in regards to the creation of an FPS, and there are many open FPS engines that do. I'm just saying, if you seriously want to create an FPS, spring is not a good choice. If you're more just trying to teach yourself advanced spring modding techniques, because some of the stuff you'd use making a spring FPS could be used for more appropriate spring projects later, then fine. It's not going to be an amazing FPS, but why not?

The goal of this engine was never to have a universal game engine that can be used for all things with equal potency. It's an RTS engine. I'm not going to tell anyone not to make FPS games for it... but I will say that those FPS games will not hold a candle to comparible FPS titles available, simply because of engine constraints.
Post Reply

Return to “General Discussion”