<!--quoteo(post=1678713:date=May 16 2008, 07:11 AM:name=Jackson3113)--><div class='quotetop'>QUOTE(Jackson3113 @ May 16 2008, 07:11 AM) <a href="index.php?act=findpost&pid=1678713"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->source engine sucks far too much for this to ever be added in.<!--QuoteEnd--></div><!--QuoteEEnd-->
stfu plx.
<!--quoteo--><div class='quotetop'>QUOTE</div><div class='quotemain'><!--quotec-->euphoria is physics-engine independent and works with all commercially available engines (as well as proprietary ones).<!--QuoteEnd--></div><!--QuoteEEnd-->
douchebagatronCustom member titleJoin Date: 2003-12-20Member: 24581Members, Constellation, Reinforced - Shadow
i like the hendrickson is going with this, and i agree that in an fps this might be a bad idea since it is quite disorienting to the players, but i think there would be a great way of doing it where the player's view and the 3rd person body are not necessarily connected. meaning that the player would see the game from the typicall fps view, but from other perspectives the player would be showing the euphoria animations.
the only problem between this comes in when a player is completely knocked down, and that can be done through the fps view.
the trick to making euphoria work in an fps game is to not tie the camera to the model, but to tie the model to the camera instead. if that makes sense.
I may have been coming off stronger sounding than I meant to in my first post on this topic. You have to understand where I'm coming from AcidicX. I've seen so many instances in software development (not talking just games here) where things were done with too much haste and cut & paste feature from different platforms. Granted it common sense that you shouldn't "reinvent the wheel" every time you publish a new professional (i.e. non-freeware) title, but I'm sick to death of developers trying to add chunks of incompatible code. Most of this angst is directed at Microsoft actually, but other developers like Grin, Bioware, <a href="http://www.gamersfirst.com/game_details.php?g=1" target="_blank">Mgame</a> have also made initial releases that were quite irritatingly buggy.
OOP is a fantastic concept and useful because it can allow for modularity of features / functions, but I guess there's a downside to it to.
I'm going to strikethrough my current no vote for the time being to nullify it and give this idea a second chance, but I've yet to see anybody make an argument that persuades me to support this idea. I'm stepping outside of the box to listen without bias. Why is this idea worth it? Is there something we could learn from this idea and just code it in the format that Source uses instead of cut&paste with an inherent risk of incompatibility? AcidicX? 6john?
douchebagatronCustom member titleJoin Date: 2003-12-20Member: 24581Members, Constellation, Reinforced - Shadow
well the big thing i want to see is the model's reaction to the objects and other players around it my previous example being that a marine actually gets knocked back some and stumbles when a skulk leaps into it. if that could be done in the source engine effectively without looking ridiculous or completely scripted, then im all for it.
<!--quoteo(post=1678788:date=May 17 2008, 11:07 AM:name=6john)--><div class='quotetop'>QUOTE(6john @ May 17 2008, 11:07 AM) <a href="index.php?act=findpost&pid=1678788"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->well the big thing i want to see is the model's reaction to the objects and other players around it my previous example being that a marine actually gets knocked back some and stumbles when a skulk leaps into it. if that could be done in the source engine effectively without looking ridiculous or completely scripted, then im all for it.<!--QuoteEnd--></div><!--QuoteEEnd--> So collisions generate flinching based on the force magnitude, direction, and skeletal variance limits (how the joints move against muscle tension resistance in real time? Of course it's possible to code in the Source engine just as much as it was for Gary's Mod to make build-able brush entities. But also like Gary's mod, couldn't it prove to be highly CPU intensive for the client? Perhaps if it isn't a fully accurate system that runs animations off of improved, or a supercomputer performance (i.e. luxury) toggle feature for those top tier systems, then it would benefit. (running force systems in static is commonly used in civil engineering simulation software, a dynamic system might be even trickier since you have to account for linear and angular momentum as well; regardless, it's not a lightweight calculation for the computers in NS2's general market even if we assume 4 years to release, is it?)
Understand that do want to see more realistic features in NS2, but aren't there simpler, great ideas that need to be taken care of first? i.e.: bullets have curved instead of linear paths that take gravity into consideration... improved collisions that correctly simulate the mix of elasticity and inelasticity improved collisions that are not just for phys objects but all players and even walls (jetpacks flying into a wall at 200KPH for zero damage anyone?) air friction, drag taken into account air density (will have a significant effect on air friction) facial response effects (one of HL2 signature creations, easy to implement and <i>does</i> have an effect on player behavior towards one another)
Rag doll deaths are already present, accurate flinching from collisions would be nice but it needs to be shown to not be too intensive for internet multiplayer combat for your typical gaming computer projected a few years into the future. (i.e.: quadruple current CPU processing average)
Convince me with logical evidence that you can make this a stable, smoothly running, integrate part of the Source engine for NS2 and you will have my support on this idea. Whatever is done, I hope UWE stays away from the cut-&-paste-for-haste syndrome so many other game developers are seeming to trend to. (just because it's the latest bell or whistle doesn't mean it's right for your software product)
douchebagatronCustom member titleJoin Date: 2003-12-20Member: 24581Members, Constellation, Reinforced - Shadow
there is no way for me to say that this would be possible to be done in ns2 given the hardware restrictions and other possible problems, my argument is that if it is possible, which is for the devs to decide, that it would be a really awesome feature. this comes from me playing gta4 and seeing euforia in action. it is honestly one of the most incredible things ive ever seen in video games. if its a bad decision to implement euforia for technical reasons then i am leaving it up to the devs to make that decision or not.
great idea!! <a href="http://www.naturalmotion.com/euphoria.htm" target="_blank">Example:An Skulk jump into marines, you see (other skulk mate) the marines will pushed back.I like the euphoria engine, its new its revolutionary like havoc physik was.</a>
Well, they (http://www.naturalmotion.com/euphoria.htm) say that (as quoted before) "euphoria is physics-engine independent and works with all commercially available engines (as well as proprietary ones)."
So if they advertising it that way, I think they will have to know how to implement it correctly - you could also say they have to because source is a commercially available engine - so not all the work has to be done by UWE. If they say it works with all engines, they must have done some testcases, and source is a big player. Anyway, if not, they must have written a pretty good interface, which brings us back to implementing - there is no copy&paste haze if you just have to pass through things to an interface. IF they really code that way, they will have really bigger problems on other parts.
As for the HW restrictions, that might be a problem. But: Source isn't a real CPU-basher. Most of the real load is graphics and therefore done by the GPU. There *should* be enough resources left on an intermediate system for running euphoria, but I can't give a guarantee there whatsoever. And if NS2 comes out in a year (yeah..lol, I know) the source engine will be pretty old... which means the average PC is getting more powerful while the engine and therefore requirements stay the same..
Comments
stfu plx.
<!--quoteo--><div class='quotetop'>QUOTE</div><div class='quotemain'><!--quotec-->euphoria is physics-engine independent and works with all commercially available engines (as well as proprietary ones).<!--QuoteEnd--></div><!--QuoteEEnd-->
the only problem between this comes in when a player is completely knocked down, and that can be done through the fps view.
the trick to making euphoria work in an fps game is to not tie the camera to the model, but to tie the model to the camera instead. if that makes sense.
I may have been coming off stronger sounding than I meant to in my first post on this topic. You have to understand where I'm coming from AcidicX. I've seen so many instances in software development (not talking just games here) where things were done with too much haste and cut & paste feature from different platforms. Granted it common sense that you shouldn't "reinvent the wheel" every time you publish a new professional (i.e. non-freeware) title, but I'm sick to death of developers trying to add chunks of incompatible code. Most of this angst is directed at Microsoft actually, but other developers like Grin, Bioware, <a href="http://www.gamersfirst.com/game_details.php?g=1" target="_blank">Mgame</a> have also made initial releases that were quite irritatingly buggy.
OOP is a fantastic concept and useful because it can allow for modularity of features / functions, but I guess there's a downside to it to.
I'm going to strikethrough my current no vote for the time being to nullify it and give this idea a second chance, but I've yet to see anybody make an argument that persuades me to support this idea. I'm stepping outside of the box to listen without bias. Why is this idea worth it? Is there something we could learn from this idea and just code it in the format that Source uses instead of cut&paste with an inherent risk of incompatibility? AcidicX? 6john?
So collisions generate flinching based on the force magnitude, direction, and skeletal variance limits (how the joints move against muscle tension resistance in real time? Of course it's possible to code in the Source engine just as much as it was for Gary's Mod to make build-able brush entities. But also like Gary's mod, couldn't it prove to be highly CPU intensive for the client? Perhaps if it isn't a fully accurate system that runs animations off of improved, or a supercomputer performance (i.e. luxury) toggle feature for those top tier systems, then it would benefit. (running force systems in static is commonly used in civil engineering simulation software, a dynamic system might be even trickier since you have to account for linear and angular momentum as well; regardless, it's not a lightweight calculation for the computers in NS2's general market even if we assume 4 years to release, is it?)
Understand that do want to see more realistic features in NS2, but aren't there simpler, great ideas that need to be taken care of first?
i.e.:
bullets have curved instead of linear paths that take gravity into consideration...
improved collisions that correctly simulate the mix of elasticity and inelasticity
improved collisions that are not just for phys objects but all players and even walls (jetpacks flying into a wall at 200KPH for zero damage anyone?)
air friction, drag taken into account
air density (will have a significant effect on air friction)
facial response effects (one of HL2 signature creations, easy to implement and <i>does</i> have an effect on player behavior towards one another)
Rag doll deaths are already present, accurate flinching from collisions would be nice but it needs to be shown to not be too intensive for internet multiplayer combat for your typical gaming computer projected a few years into the future. (i.e.: quadruple current CPU processing average)
Convince me with logical evidence that you can make this a stable, smoothly running, integrate part of the Source engine for NS2 and you will have my support on this idea. Whatever is done, I hope UWE stays away from the cut-&-paste-for-haste syndrome so many other game developers are seeming to trend to. (just because it's the latest bell or whistle doesn't mean it's right for your software product)
<a href="http://www.naturalmotion.com/euphoria.htm" target="_blank">Example:An Skulk jump into marines, you see (other skulk mate) the marines will pushed back.I like the euphoria engine, its new its revolutionary like havoc physik was.</a>
So if they advertising it that way, I think they will have to know how to implement it correctly - you could also say they have to because source is a commercially available engine - so not all the work has to be done by UWE. If they say it works with all engines, they must have done some testcases, and source is a big player. Anyway, if not, they must have written a pretty good interface, which brings us back to implementing - there is no copy&paste haze if you just have to pass through things to an interface. IF they really code that way, they will have really bigger problems on other parts.
As for the HW restrictions, that might be a problem. But: Source isn't a real CPU-basher. Most of the real load is graphics and therefore done by the GPU. There *should* be enough resources left on an intermediate system for running euphoria, but I can't give a guarantee there whatsoever. And if NS2 comes out in a year (yeah..lol, I know) the source engine will be pretty old... which means the average PC is getting more powerful while the engine and therefore requirements stay the same..