16 Apr, 2012, plamzi wrote in the 41st comment:
Votes: 0
Rarva.Riendf said:
Fact is when you go towards realism, you open a can of worms. Why is this realism, but not this etc etc etc.
It is a game, not a simulation of life. Life is not fun, especially since you can lose it very very easily.
And if you have a magical worlds…if you do not put any limitations (that are in themselves, not very coherent either) all hell break lose.


That's true, but it's important to note that degrees of realism are the key here. Every non-abstract game (even Angry Birds) has some degree of realism and is open to the question 'Why this, but not that.' The answer is usually that if you're asking this question, you're not suspending your disbelief, so the game is failing to engage you on another level.
16 Apr, 2012, Rarva.Riendf wrote in the 42nd comment:
Votes: 0
Exactly having a perfectly valid physical engine working will cause you problems, Angry Bird and all of the other game using one seems VERY limited in everything else.
Easy to limitate the thing a player can do with a physical engine when you limits its control and environment. Not so easy with an open world as a mud, and even more difficult with a multiplayer one.
I really dont think the problem mud have come from a lack of liberty and world interaction.
As a player I could not care less about it anyway, I only look for pvp action I cannot really have in a graphical game where all you do is click click click the faster way possible. What I like in mud is they are not a reflex game, but one slow enough to build a strategy, fast enough to not make it as boring a turn base one is.
16 Apr, 2012, Runter wrote in the 43rd comment:
Votes: 0
Well, I think you don't need complicated physics engines to calculate a collapsing house. Whether or not you think a collapsing house is a good thing is a separate issue, but we can model a collapsing house without needing to know, for example, the angular velocity of every debris. Let's imagine wanting to hit users with debris that are near the collapsing house. Since the users are dealing basically with action->reaction rather than visuals the gameplay would go like this: "The house collapses." So now you either have "You get hit with some debris." or not. It's not believable to see it, or be hit by it, if you're very far away in game. Likewise, it's not believable to not see it collapse or be missed by the debris if you're very close. You can interpolate between the two once you figure out the right formula. So there's ways to calculate this in a believable way for users without needing a full physics engine implementation. You can make a simple calculation for a "blast radius" based on the size of the object being destroyed, as well as a hit/miss modifier based on distance away and material type. It's not accurate physics based gameplay, but most or all won't be able to tell in a text based environment. It's been said on these forums many times and I'll repeat it once more. Simplifying models pays dividends when it comes to the complexity of the code and resources you need. In many cases, the simple models are actually what you want. Like Scandum, you may just not realize it. I'd argue in most cases your users won't even appreciate the difference even if you tell them. Or care that they're playing on the most (lol?) advanced mud in the world.
17 Apr, 2012, plamzi wrote in the 44th comment:
Votes: 0
I second Runter. Generally, I feel that when people bring up physics engines (or AI) in a conversation about MUD game design, it's because it's something they're excited about, not because it's practical or necessary. MUDs paint with words. There's a lot of power in that.
17 Apr, 2012, Rarva.Riendf wrote in the 45th comment:
Votes: 0
Runter: For all you described you actually have absolutely no need for a physics engine. I could even describe this easily as a mob, (that does not fight back) that fall in xxx material pieces when he dies, and that has a bomb like effect. (if you have a ROM like engine,and it would be even easier with an object oriented engine).
17 Apr, 2012, Runter wrote in the 46th comment:
Votes: 0
Rarva.Riendf said:
Runter: For all you described you actually have absolutely no need for a physics engine.


I think that's the point I was making. ;)
28 Nov, 2012, Kline wrote in the 47th comment:
Votes: 0
With the power of necromancy I resurrect this thread … :ghostface:.

If anybody was interested, I've picked this back up after a long hiatus. Settled in a new job and stuff and found some time for it again. Over the last day or two I've done a lot of work. There is now a working command interpreter and all commands are compiled and loaded as external objects via a plugin interface. Below is a sample of how a plugin written act as a command is structured. I haven't quite extended plugins beyond commands yet, but I do intend to with things like combat systems, NPCs, etc. I just need to finish up writing some of the "must have" commands like reboot, shutdown, etc first.

#include "includes.h"
#include "class.h"
#include "plugin.h"

class Help : public Plugin {
public:
virtual const void Run( SocketClient* client = NULL, const string& cmd = "", const string& arg = "" ) const;

Help( const string& name, const uint_t& type );
~Help();
};

const void Help::Run( SocketClient* client, const string& cmd, const string& arg ) const
{
if ( client )
client->Send( "Help!" CRLF );
else
cout << "Help!" << endl;

return;
}

Help::Help( const string& name = "help", const uint_t& type = PLG_TYPE_COMMAND ) : Plugin( name, type )
{
Plugin::sBool( PLG_TYPE_COMMAND_BOOL_PREEMPT, true );
Plugin::sUint( PLG_TYPE_COMMAND_UINT_SECURITY, SOC_SECURITY_NONE );

return;
}

Help::~Help()
{
}

extern "C" {
Plugin* New() { return new Help(); }
void Delete( Plugin* p ) { delete p; }
}
28 Nov, 2012, quixadhal wrote in the 48th comment:
Votes: 0
Sorry, can't resist:

k5bmQ4bUc..."> k5bmQ4bUc..." type="application/x-shockwave-flash" width="425" height="350">
28 Nov, 2012, Scandum wrote in the 49th comment:
Votes: 0
Rarva.Riendf said:
Runter: For all you described you actually have absolutely no need for a physics engine. I could even describe this easily as a mob, (that does not fight back) that fall in xxx material pieces when he dies, and that has a bomb like effect. (if you have a ROM like engine,and it would be even easier with an object oriented engine).

The whole point of a physics engine is code re-use, consistent action-reaction across the game. Once this mush person was explaining how each door was separately coded with a billion option for customization, and it's just a waste of time for everyone involved as the first thing a player thinks when getting to a complex custom build door is "whose cock do I need to suck to be told how to open this bitch." It's immersion breaking, though perfectly suited for the needs of the average mush as it does encourage social interaction, in one way or another.
30 Nov, 2012, Rarva.Riendf wrote in the 50th comment:
Votes: 0
Quote
The whole point of a physics engine is code re-use, consistent action-reaction across the game.

Code re-use with a physic engine is no different than code reusing without it. 'Consistent action-reaction across the game'. No you cannot have that, as it will not be a 'game' anymore but starts becoming a simulation. Sometimes you may want to be able to tear down a castle on their occupant, sometimes it is best to prevent it. So a physic engine is in no way something that will add a 'consistant action reaction' across the game.

Unless you want to make a real life simulation a physic engine is only needed to add fancy (mostly realistic visual effect) and add some gameplay features, but adding consistent action across a whole game ? nope.
Do you need on in a pure text game, I doubt it, as you don't need the realistic visual effect at all to begin with.
30 Nov, 2012, Davion wrote in the 51st comment:
Votes: 0
Rarva.Riendf said:
No you cannot have that, as it will not be a 'game' anymore but starts becoming a simulation.


Not to nitpick or anything, but are you saying that anything that uses a physics engine (IE. Havok) is not a game, but a simulation? Please elaborate, because I have a hard time accepting this.
30 Nov, 2012, Rarva.Riendf wrote in the 52nd comment:
Votes: 0
No, I am saying that if you have the physic engine runs everything you will. Most of the game using one will put bondaries on it and not only for computing power reason. Pushing realistic effect everywhere would only show how blantlantly unrealistic other parts are.

As an example, look how they push photorealism in game even for human face model. Problem is that the very second they have it moving it looks ridiculous because we are totally ingrained with recognizing people movement (part of our survival instinct). We dont have the problem if it looks like alien because well…we have no reference point.

Physics engine are mostly there to make some stuff bounce a little more realisticly, nothing more.
01 Dec, 2012, Ssolvarain wrote in the 53rd comment:
Votes: 0
Love them ragdoll physics.
02 Dec, 2012, quixadhal wrote in the 54th comment:
Votes: 0
Rarva, I don't know where to begin, so I'll just ask a few simple questions.

If you're computing falling damage, would you rather (a) cobble up some half-arsed formula of your own, or (b) ask the physics engine what speed you'll hit the ground at from a given height?

If you're writing a space-based game, and you want to travel by acceleration/deceleration, and would like to know how much fuel you'll use, would you rather (a) cobble up some half-arsed forumula yourself, or (b) ask the physics engine to handle the mass velocity and thrust vectors for you?

If you want to make chain mail out of various metals, and you'd like to also make daggers from various metals, and you want to have a different amount of wear-and-tear on each, as well as have a differing amount of protection… you get the idea.

A physics engine is in NO WAY limited to just graphical eye-candy. It's up to you to use it to make your computations simpler, and then use the results in a way that makes sense for YOUR game. Dismissing it as only useful for graphics processing is just silly.

Having said that, will most MUDs benefit from having one? No. And that's only because most MUDs put zero effort into using real-world values for things. If you throw made-up numbers into the physics engine, you're likely to get gibberish output.
02 Dec, 2012, Rarva.Riendf wrote in the 55th comment:
Votes: 0
In a mud:write the formula myself, it is not like I care about any realistic output (even in a visual game you dont really look for that) , and the only I need to control is how it scale (linear exponential etc…not rocket science maths)

In a visual game I would use a physic engine not for the accuracy of formulas anyway, but for having coherent visual effects within the game. Yes they are only used for that:calculate boucing stuff so it does not look 1:ridiculous 2:give possibility to put more bouncing stuff around without having to recode stuff for every shape or weight of bouncing stuff…(that is code factorisation, nothing to do with calculating accurate result in the first place)

Will they apply the physic engine to all objects though ? Not at all, only the one they want to be affected for the gameplay.

Quote
And that's only because most MUDs put zero effort into using real-world values for things.

Replace mud by game, and they do it for a reason: real world values are not fun at all….

Look at that and tell me how a physic engine would have helped..

http://www.piratehearts.com/blog/

So newsflash for you:yes in a game you will write your own equationq, as the real life equation with real values would be the shittiest result you could have.

Nothing prevents you to make a framework of all of them once you are done and call it a physic engine..but there are no universal physic engine.
There is a reason why the "revolutionar" physX hardware acceleration card thing went down the drain…


Quote
If you want to make chain mail out of various metals, and you'd like to also make daggers from various metals, and you want to have a different amount of wear-and-tear on each, as well as have a differing amount of protection… you get the idea.


And then you have the mage cast armor and stone skin….why the hell you would want to bother with realistic metal work in the first place ?
02 Dec, 2012, Rarva.Riendf wrote in the 56th comment:
Votes: 0
And the precise post where he explains that physics and game dont always mix:

http://www.piratehearts.com/blog/2012/03...
02 Dec, 2012, donky wrote in the 57th comment:
Votes: 0
quixadhal said:
Having said that, will most MUDs benefit from having one? No. And that's only because most MUDs put zero effort into using real-world values for things. If you throw made-up numbers into the physics engine, you're likely to get gibberish output.

Haven't we had this discussion before? I could swear there's a thread somewhere detailing geology and materials and talk towards making a shared database.

I think that most muds could benefit from having one, if a sufficiently usable resource was made available. Is anyone likely to put in the work to do so? Or to finish the work if they started? Or to end up with something that was sufficiently usable? Unlikely. But I think that it should be possible. I'd be interested in discussing what the scope of such a project should be, if anyone else were interested.
03 Dec, 2012, Rarva.Riendf wrote in the 58th comment:
Votes: 0
Quote
Haven't we had this discussion before? I could swear there's a thread somewhere detailing geology and materials and talk towards making a shared database.


Yep, I recall that as well. But again I doubt there is any value in…real value, for a game. (the game industies would have created one by now it it had purpose, if only just to save cash)
03 Dec, 2012, Runter wrote in the 59th comment:
Votes: 0
Axiom reads if your game uses physics then there's real value in using a well-tested and developed physics engine rather than coming up with formulations on your own. With the corollary that if you happen to like writing your own formulations, and you don't have any particular deadline you are trying to reach then it may be just fine.
04 Dec, 2012, donky wrote in the 60th comment:
Votes: 0
Rarva.Riendf said:
Quote
Haven't we had this discussion before? I could swear there's a thread somewhere detailing geology and materials and talk towards making a shared database.


Yep, I recall that as well. But again I doubt there is any value in…real value, for a game. (the game industies would have created one by now it it had purpose, if only just to save cash)
I generally wish they had, when I play most computer games. I would speculate one reason why it hasn't, is that making games is just so hard and time consuming as it is, it's hard to look past the status quo.

On the bright side for this sort of activity, in the Dwarf Fortress forums there are threads where people research more a wider range of more accurate values for that game's simulation.
40.0/65