How do I make on object hard?

[Archimonde]

First of all, this is my very first time ever using ALice, and I like it so far. However, I cannot seem to figure out how to make on object hard, so that when another object touches it, it cannot go through.

[madden]

look up the word Collision

or do this

loop infinity
if object1 is within 5 meters of object2
(then object1 move backwards 1 meter, 0 seconds) just an example, mess around with it:D

p.s this is you'r fortune........hmmmmmm........AAAAAA! you guessed it, the cookie monster loves cookies:eek: I am a genius aren't I

[DrJim]

look up the word Colision

.......I am a genius aren't I

No comment on that - but you can't spell. :p

Archimonde - Try searching on "collision" or doing something like Madden's code.

Unfortunately, I don't know of any way do do what I think you want, which is to allow nothing at all to go through an object. Most of the collision methods just keep specific objects from colliding with each other.

[DickBaldwin]

Archimonde,

Although I'm not an expert in this area and may be wrong, I believe that you will find that few if any programming environments that support the movement of objects in either 2D space or 3D space also support "hard objects."

I believe that it is normally up to the programmer to detect the fact that two objects are about to collide and to take the appropriate action as a result of that circumstance.

Why is this the case? Because the authors of the programming environment have no way of knowing what the appropriate action should be. For example, if a bullet collides with something, it should probably penetrate the object becoming invisible at the same time, or possibly go all the way through being visible when it exits.

On the other hand, if a ball collides with a bat, it should probably bounce off the bat, but in what direction at what speed?

If two cars collide, they usually don't bounce. Instead they usually crumple into a heap of twisted metal. However, if they collide in a glancing blow they may crumple and bounce.

The decision as to the appropriate action to take when two objects collide is left to the ingenuity of the programmer.

Therefore, it is usually the responsibility of the programmer to know where two moving objects are at all times, to detect an impending collision, and to take the appropriate action when they do collide.

Dick Baldwin

[DrJim]

....few if any programming environments that support the movement of objects in either 2D space or 3D space also support "hard objects."

While this is certainly true, there are some "game engines" that do partially provide this feature automatically - specified objects (usually the shooter in first person games) cannot penetrate any other "hard" object. Note the programmer (or game engine designer) still has to decide what classes of objects are "hard" to what other classes of objects.

Alice actually does this in the case of camera movement controlled by the arrow keys - see the attached and do a search for Gabe's posting describing this in a bit more detail. No matter how you move the camera or what the object is (try one for yourself) the camera, controlled by the arrow keys, will not go through a "hard" surface. With mouse control, on the other hand, the camera goes right through any surface. There are some "maze" programs in the forum that demonstrate how to approximate this behavior for other objects in your own programs.

I mention this partially because it is an interesting demonstration of an advantage of OOP over older programming styles. Early games required a master control routine to oversee all of the objects in a game - and had to be updated for each time slot, even though usually 90%+ of the game objects were inactive. By distributing this control, much more activity can be supported - as demonstrated by modern games (or guidance systems, for that matter). If anyone is interested further, the discussion forums on the Blender game engine would be a good place to start.

[DickBaldwin]

DrJim,

Any clues as to how to find Gabe's posting that you reference.

Thanks,
Dick Baldwin

Never mind. I think I found it at the following URL:

http://www.alice.org/community/showthread.php?t=69&highlight=camera

Dick Baldwin

[DrJim]

Any clues as to how to find Gabe's posting that you reference.


I could only find the same one you found - suspect the one I was thinking of got combined with some others into that one.

The thing I remembered - which may have been from one of the maze designers, not Gabe, was the difference in behavior between mouse control and arrow key control of the camera. Doesn't make much sense for a teaching tool - except to demostrate the flexibility of interface options, which is good - but does make sense for a "first person shooter" game engine.

[DickBaldwin]

Doesn't make much sense for a teaching tool - except to demostrate the flexibility of interface options, which is good - but does make sense for a "first person shooter" game engine.

It also illustrates the dangers of the designers trying to anticipate appropriate behavior in advance and building that behavior into the object (with no opportunity for the programmer to modify that behavior).

When the camera slides to the right until it reaches the corner, it penetrates the wall and comes out the other side even though the wall appears to be solid at the corner.

I assume this is because the wall is actually two walls set at right angles and the apparent behavior of the camera is to go around the object that it has encountered. It is unable to recognize that the path around the end of the first wall is blocked by another wall and slides through the crack.

I assume that it wouldn't work for a maze unless that behavior can somehow be modified to handle corners appropriately. Or maybe, the walls could be overlapped at the corner so as to prevent this behavior.

Dick Baldwin

[madden]

No comment on that - but you can't spell. :p



i'me soo serry

p.s seriesly

[madden]

it was joke drjim:D

p.s as a wise man once said "do not lick the spoon that pokes":confused:

[DrJim]

It also illustrates the dangers of the designers trying to anticipate appropriate behavior in advance and building that behavior into the object (with no opportunity for the programmer to modify that behavior).


A very good point! :)

Game engine design - including how to include "just enough" - isn't really a subject for this forum - but for those interested, look at the Blender site http://www.blender.org/ and their game engine stuff or at the Irrlicht Engine site http://irrlicht.sourceforge.net/ .

Madden: I'm afraid you have "the Knack" - see http://www.guzer.com/videos/dilbert_knack.php :D

[madden]

http://www.guzer.com/videos/dilbert_knack.php[/url] :D

um...ok

P.s drjim you need a poptart

[madden]

I made this... Try it out

P.s Keep away from me!:eek: http://www.lastpersonwins.com/pixel/uploaded_img/funny%20face.jpg

[JungleJim]

The lack of collision detection was excused earlier with the argument that the system designer would not know what particular action was appropriate for the collision. But that is the entire point of event processing (Java ActionListeners etc). There could be an Alice event:

When xxx collides with anything do yyy

in analogy with the

When the mouse is clicked on anything do yyy

event. That would leave the consequences up to the programmer.

[DickBaldwin]

I suppose I was the one who is guilty of excusing the lack of built-in collision detection with "the argument that the system designer would not know what particular action was appropriate for the collision"

The idea of a collision event does have merit. Unfortunately, it still leaves open a lot of interesting questions, that would require decisions on the part of the system designer that may not agree with decisions that would be made by the programmer.

A fundamental example is the question of exactly what constitutes a collision. Consider the case of two oddly shaped objects that happen to be in close proximity to one another as shown by the stick figures below (monospace font required for proper viewing). Try to envision this as two fighters (with very small heads). Pretend that a leg and foot of the fignter on the left is represented by ====& The fiighter on the left has attempted to kick the fighter on the right.

Also pretend that @==== represents an arm and a fist belonging to the fighter on the right, who has attempted to punch the fighter on the left. Pretend that the dots represent free air space. (Actually, I had to put them there to take up space in the final text presentation.)

Note that neither fighter has succeeded in striking the other fighter. However, the bounding boxes of the two fighters overlap significantly.

...........
..0.....0..
..X.@===Y..
..X.....Y..
..X===&.Y..
..X.....Y..
..X.....Y..
...........

Is this a collision? If the definition of a collision is based on the intersection of the bounding boxes of the two fighters, the answer would be yes even though the fighters haven't made contact. If the bounding box isn't used as the criteria for a collision, what could be used in its place?

Life's questions rarely have simple answers.

Dick Baldwin

[lanceA]

WELL PUT !

Only the person programming the scenerio actually knows all of the facts !

Isn't that what programming is all about - solving problems ? Granted the age group here wants to develope the latest NUKE 'EM game and live in the fantasy world where dragons fly and pigs walk on two legs, but . . .

HOW DO I SOLVE THIS SHORTCOMING IN ALICE TO SOLVE THIS PROBLEM ?

Hmmmmmm - This would be a GREAT teaching exercise for beginners!!

Might I suggest that we teach PROBLEM SOLVING, and not BASHING the teaching tool ?

M$ Windows has never had any problems, once released.
Quicken was NEVER sued
M$ Paint is NOT involved in several law suits

It's easy to complain folks, it's GREAT to find work-arounds or simply accept that this software does not do EVERYTHING we want it to do.

You know what? You didn't pay anything for it and if you do not like it - GO buy the perfect software. Java's NOT perfect -

I'll get out my soap-box now,
lanceA



Just my thoughts,

[DrJim]

If the bounding box isn't used as the criteria for a collision, what could be used in its place?

Scratch seems to be having a lot of success with "when xxx is touching color yy." This lets the designer pick what "hits" can cause damage for rather abstract shapes. Of course Scratch is 2D - not sure what the 3D equivalent would be.