Thread: Re: [Algorithms] Kinematic Collision (Page 2)
Brought to you by:
vexxed72
Menu
▾
▴
gdalgorithms-list
|
From: James D. <jd...@gm...> - 2009-09-09 16:51:54
|
Agree with Christer here that ultimately fixing the mesh is the answer, such defects will cause artifacts in any algorithm to some degree... but one thing that is pretty useful is having code that validates input from the artist and smacks them around a bit if they decide to put in a bunch of T-junctions or gaps. -james On Sep 9, 2009, at 9:33 AM, chr...@pl... wrote: > James Robertson wrote: >>> Simple. You tell your art/design team not to design >>> geometry like that! (No, really.) >> >> That's only a solution for the most simplistic >> single player games these days. > > Perhaps God of War is simplistic to you, but it > works just fine for us. > > Programmers overengineer way too much. > > > Christer Ericson, Director of Tools and Technology > Sony Computer Entertainment, Santa Monica > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and > focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list |
|
From: Mark W. <Mwa...@to...> - 2009-09-09 23:55:13
|
Fixing the meshes isn't the difficult problem - its finding it before it goes to QA. We all know good tools are the solution, but it can be challenging to find cracks in all the geometry. The biggest problem case isn't a static mesh with cracks in, but a level designer placed item that effectively makes a "crack". This is quite difficult to find, especially if the item is dynamic in nature. So, to a certain extent, you have to make sure your runtime code is pretty robust with its case handling. I do agree on the whole overengineering thing though! Cheers, Mark > -----Original Message----- > From: James Dolan [mailto:jd...@gm...] > Sent: Thursday, 10 September 2009 2:52 AM > To: Game Development Algorithms > Subject: Re: [Algorithms] Kinematic Collision > > Agree with Christer here that ultimately fixing the mesh is > the answer, such defects will cause artifacts in any > algorithm to some degree... but one thing that is pretty > useful is having code that validates input from the artist > and smacks them around a bit if they decide to put in a bunch > of T-junctions or gaps. > > -james > > On Sep 9, 2009, at 9:33 AM, > chr...@pl... wrote: > > > James Robertson wrote: > >>> Simple. You tell your art/design team not to design geometry like > >>> that! (No, really.) > >> > >> That's only a solution for the most simplistic single player games > >> these days. > > > > Perhaps God of War is simplistic to you, but it works just fine for > > us. > > > > Programmers overengineer way too much. > > > > > > Christer Ericson, Director of Tools and Technology Sony Computer > > Entertainment, Santa Monica > > > > > > > ---------------------------------------------------------------------- > > -------- Let Crystal Reports handle the reporting - Free Crystal > > Reports 2008 30-Day trial. Simplify your report design, integration > > and deployment - and focus on what you do best, core application > > coding. Discover what's new with Crystal Reports now. > > http://p.sf.net/sfu/bobj-july > > _______________________________________________ > > GDAlgorithms-list mailing list > > GDA...@li... > > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > > Archives: > > > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-l > > ist > > > -------------------------------------------------------------- > ---------------- > Let Crystal Reports handle the reporting - Free Crystal > Reports 2008 30-Day trial. Simplify your report design, > integration and deployment - and focus on what you do best, > core application coding. Discover what's new with Crystal > Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgo > rithms-list > > |
|
From: James D. <jd...@gm...> - 2009-09-10 00:07:54
|
In my hobby project I just have a mode that detects all cracks and draws red lines along them. You can then quickly run around the world or level editor and visually any sort of collection defect is quickly noticed. -james On Sep 9, 2009, at 4:54 PM, Mark Wayland wrote: > Fixing the meshes isn't the difficult problem - its finding it > before it > goes to QA. We all know good tools are the solution, but it can be > challenging to find cracks in all the geometry. The biggest problem > case > isn't a static mesh with cracks in, but a level designer placed item > that effectively makes a "crack". This is quite difficult to find, > especially if the item is dynamic in nature. So, to a certain extent, > you have to make sure your runtime code is pretty robust with its case > handling. I do agree on the whole overengineering thing though! > > Cheers, > Mark > >> -----Original Message----- >> From: James Dolan [mailto:jd...@gm...] >> Sent: Thursday, 10 September 2009 2:52 AM >> To: Game Development Algorithms >> Subject: Re: [Algorithms] Kinematic Collision >> >> Agree with Christer here that ultimately fixing the mesh is >> the answer, such defects will cause artifacts in any >> algorithm to some degree... but one thing that is pretty >> useful is having code that validates input from the artist >> and smacks them around a bit if they decide to put in a bunch >> of T-junctions or gaps. >> >> -james >> >> On Sep 9, 2009, at 9:33 AM, >> chr...@pl... wrote: >> >>> James Robertson wrote: >>>>> Simple. You tell your art/design team not to design geometry like >>>>> that! (No, really.) >>>> >>>> That's only a solution for the most simplistic single player games >>>> these days. >>> >>> Perhaps God of War is simplistic to you, but it works just fine for >>> us. >>> >>> Programmers overengineer way too much. >>> >>> >>> Christer Ericson, Director of Tools and Technology Sony Computer >>> Entertainment, Santa Monica >>> >>> >>> >> ---------------------------------------------------------------------- >>> -------- Let Crystal Reports handle the reporting - Free Crystal >>> Reports 2008 30-Day trial. Simplify your report design, integration >>> and deployment - and focus on what you do best, core application >>> coding. Discover what's new with Crystal Reports now. >>> http://p.sf.net/sfu/bobj-july >>> _______________________________________________ >>> GDAlgorithms-list mailing list >>> GDA...@li... >>> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >>> Archives: >>> >> http://sourceforge.net/mailarchive/forum.php? >> forum_name=gdalgorithms-l >>> ist >> >> >> -------------------------------------------------------------- >> ---------------- >> Let Crystal Reports handle the reporting - Free Crystal >> Reports 2008 30-Day trial. Simplify your report design, >> integration and deployment - and focus on what you do best, >> core application coding. Discover what's new with Crystal >> Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> GDAlgorithms-list mailing list >> GDA...@li... >> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >> Archives: >> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgo >> rithms-list >> >> > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and > focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list |
|
From: Mark W. <Mwa...@to...> - 2009-09-10 03:07:47
|
This is what I was referring to as "QA" - its fine for small projects, but doesn't scale well for larger or tight timeframed projects (being a "reactive" rather than "proactive" approach). We have the same sort of debug display right now, but it doesn't show the dynamic object case unless it happens to the player which makes it of limited usefulness. Cheers, Mark > -----Original Message----- > From: James Dolan [mailto:jd...@gm...] > Sent: Thursday, 10 September 2009 10:08 AM > To: Game Development Algorithms > Subject: Re: [Algorithms] Kinematic Collision > > In my hobby project I just have a mode that detects all > cracks and draws red lines along them. You can then quickly > run around the world or level editor and visually any sort of > collection defect is quickly noticed. > > -james > > On Sep 9, 2009, at 4:54 PM, Mark Wayland wrote: > > > Fixing the meshes isn't the difficult problem - its finding > it before > > it goes to QA. We all know good tools are the solution, but > it can be > > challenging to find cracks in all the geometry. The biggest problem > > case isn't a static mesh with cracks in, but a level > designer placed > > item that effectively makes a "crack". This is quite difficult to > > find, especially if the item is dynamic in nature. So, to a certain > > extent, you have to make sure your runtime code is pretty > robust with > > its case handling. I do agree on the whole overengineering thing > > though! > > > > Cheers, > > Mark > > > >> -----Original Message----- > >> From: James Dolan [mailto:jd...@gm...] > >> Sent: Thursday, 10 September 2009 2:52 AM > >> To: Game Development Algorithms > >> Subject: Re: [Algorithms] Kinematic Collision > >> > >> Agree with Christer here that ultimately fixing the mesh is the > >> answer, such defects will cause artifacts in any algorithm to some > >> degree... but one thing that is pretty useful is having code that > >> validates input from the artist and smacks them around a > bit if they > >> decide to put in a bunch of T-junctions or gaps. > >> > >> -james > >> > >> On Sep 9, 2009, at 9:33 AM, > >> chr...@pl... wrote: > >> > >>> James Robertson wrote: > >>>>> Simple. You tell your art/design team not to design > geometry like > >>>>> that! (No, really.) > >>>> > >>>> That's only a solution for the most simplistic single > player games > >>>> these days. > >>> > >>> Perhaps God of War is simplistic to you, but it works > just fine for > >>> us. > >>> > >>> Programmers overengineer way too much. > >>> > >>> > >>> Christer Ericson, Director of Tools and Technology Sony Computer > >>> Entertainment, Santa Monica > >>> > >>> > >>> > >> > --------------------------------------------------------------------- > >> - > >>> -------- Let Crystal Reports handle the reporting - Free Crystal > >>> Reports 2008 30-Day trial. Simplify your report design, > integration > >>> and deployment - and focus on what you do best, core application > >>> coding. Discover what's new with Crystal Reports now. > >>> http://p.sf.net/sfu/bobj-july > >>> _______________________________________________ > >>> GDAlgorithms-list mailing list > >>> GDA...@li... > >>> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > >>> Archives: > >>> > >> http://sourceforge.net/mailarchive/forum.php? > >> forum_name=gdalgorithms-l > >>> ist > >> > >> > >> -------------------------------------------------------------- > >> ---------------- > >> Let Crystal Reports handle the reporting - Free Crystal > Reports 2008 > >> 30-Day trial. Simplify your report design, integration and > deployment > >> - and focus on what you do best, core application coding. Discover > >> what's new with Crystal Reports now. > http://p.sf.net/sfu/bobj-july > >> _______________________________________________ > >> GDAlgorithms-list mailing list > >> GDA...@li... > >> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > >> Archives: > >> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgo > >> rithms-list > >> > >> > > > > > ---------------------------------------------------------------------- > > -------- Let Crystal Reports handle the reporting - Free Crystal > > Reports 2008 30-Day trial. Simplify your report design, integration > > and deployment - and focus on what you do best, core application > > coding. Discover what's new with Crystal Reports now. > > http://p.sf.net/sfu/bobj-july > > _______________________________________________ > > GDAlgorithms-list mailing list > > GDA...@li... > > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > > Archives: > > > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-l > > ist > > > -------------------------------------------------------------- > ---------------- > Let Crystal Reports handle the reporting - Free Crystal > Reports 2008 30-Day trial. Simplify your report design, > integration and deployment - and focus on what you do best, > core application coding. Discover what's new with Crystal > Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgo > rithms-list > > |
|
From: Mat N. <mat...@bu...> - 2009-09-09 16:59:12
|
Simple level geometry does not mean simple appearance. MSN -----Original Message----- From: chr...@pl... [mailto:chr...@pl...] Sent: Wednesday, September 09, 2009 9:34 AM To: Game Development Algorithms Subject: Re: [Algorithms] Kinematic Collision James Robertson wrote: >> Simple. You tell your art/design team not to design >> geometry like that! (No, really.) > > That's only a solution for the most simplistic > single player games these days. Perhaps God of War is simplistic to you, but it works just fine for us. Programmers overengineer way too much. Christer Ericson, Director of Tools and Technology Sony Computer Entertainment, Santa Monica ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list |
|
From: <chr...@pl...> - 2009-09-09 18:22:19
|
Mat Noguchi wrote: > Simple level geometry does not mean simple appearance. Indeed. Simon's ant taught us that: http://realtimecollisiondetection.net/blog/?p=26 Christer Ericson, Director of Tools and Technology Sony Computer Entertainment, Santa Monica |
|
From: David B. <db...@fa...> - 2009-09-09 17:06:27
|
Changing topic slightly in the other direction(ie making character controllers more sophisticated). I am interested to know how others are handling interaction with physics objects, eg jointed rigid bodies such as a box connected to a hinge joint with limits for a door. The system I have right now just uses a kinematic rigid body connected to the character controller. The problem with this is that it tends to be too strong an interaction and will for example push the door off its hinges. So my current plan is to instead use a rigid body connected to the controller with a joint or spring. That way when the controller pushes against the door the rigid body exerts a force on the door, but when it reaches its limit it will push the controllers rigid body back far enough that the controllers collision detection takes over and stops movement. Is this the approach others are using, or is there a better method? David -- http://www.fastmail.fm - Access all of your messages and folders wherever you are |
|
From: <Pau...@sc...> - 2009-09-09 17:50:21
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > So my current plan is to instead use a rigid body connected to the > controller with a joint or spring. That way when the controller pushes > against the door the rigid body exerts a force on the door, but when it > reaches its limit it will push the controllers rigid body back far > enough that the controllers collision detection takes over and stops > movement. > > Is this the approach others are using, or is there a better method? We're working on LBP PSP, and so our world is very very physics based. The character is a full rigid body with inverse inertia tensor of 0 so he can't rotate. He is controlled using a custom written 'actor' constraint which has parameters like acceleration, strength and so on. He interacts with the world just like any other rigid body. Having the actor constraint was an important step forward for us in terms of solidity; we started out just applying 'external' forces to sackboy to move him around, but when he interacted with his environment (particularly with other constraints) it didn't go so well. Now his actor constraint is an integral part of the constraint solver it works much better in terms of feel. Cheers, Paul. ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify pos...@sc... This footnote also confirms that this email message has been checked for all known viruses. Sony Computer Entertainment Europe Limited Registered Office: 10 Great Marlborough Street, London W1F 7LP, United Kingdom Registered in England: 3277793 ********************************************************************** P Please consider the environment before printing this e-mail -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.9.1 (Build 287) Charset: US-ASCII wsBVAwUBSqfkj3ajGqjtoMHxAQirMQf9F7kysMvkz0jEuou7oX1uzsIXwuRuppqZ 8sXjAVsPb8gdOdSRS7vAMv5GFzzXSJGUGiJfWm9bpDo4lb7Erb2u0I6G1VGkqT/n pEyJp+7cJZqoTEqt/0weWEf4JELayGKxNCZ+acgg1EngZfin98RpTWvMhUf0aWbJ /M78xNX/ucUQDMcFmFu9gfaNM7A3lNy/E5z/B6bvKyfBLfMubUVvFaNaKXKbBnsU MFx3sk8RdESXj7jiUR3XTD5qqzZkK0OJq8lse1U3DhXbzbbjaLe0IXB1ioAsFgm9 k+vEd2QBtWhS/Jdxd0DbPrh1Q4+Z6KZ8BjN8M7S+xi3qSrUSWsaP2g== =DV73 -----END PGP SIGNATURE----- |
|
From: David B. <db...@fa...> - 2009-09-09 18:17:21
|
I am not familiar with LBP? If I understand correctly, you have effectively a fixed joint constraining the character controller, and solve the other joints after that one. ie ensuring that the action of the other joints takes precedence. So how do you handle cases where it is correct for the player to be influenced by other objects. eg a physically simulated motorized revolving door pushing the player? The whole topic of two way interaction between user controlled objects and physically driven objects is interesting and I have never seen much discussion on the topic... David On Wed, 09 Sep 2009 18:26 +0100, Pau...@sc... wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > > So my current plan is to instead use a rigid body connected to the > > controller with a joint or spring. That way when the controller pushes > > against the door the rigid body exerts a force on the door, but when it > > reaches its limit it will push the controllers rigid body back far > > enough that the controllers collision detection takes over and stops > > movement. > > > > Is this the approach others are using, or is there a better method? > > We're working on LBP PSP, and so our world is very very physics based. > The > character is a full rigid body with inverse inertia tensor of 0 so he > can't rotate. He is controlled using a custom written 'actor' constraint > which has parameters like acceleration, strength and so on. He interacts > with the world just like any other rigid body. > > Having the actor constraint was an important step forward for us in terms > of solidity; we started out just applying 'external' forces to sackboy to > move him around, but when he interacted with his environment > (particularly > with other constraints) it didn't go so well. Now his actor constraint is > an integral part of the constraint solver it works much better in terms > of > feel. > > Cheers, Paul. > ********************************************************************** > This email and any files transmitted with it are confidential and > intended > solely for the use of the individual or entity to whom they are > addressed. > If you have received this email in error please notify > pos...@sc... > This footnote also confirms that this email message has been checked for > all known viruses. > Sony Computer Entertainment Europe Limited > Registered Office: 10 Great Marlborough Street, London W1F 7LP, United > Kingdom > Registered in England: 3277793 > ********************************************************************** > P Please consider the environment before printing this e-mail > > -----BEGIN PGP SIGNATURE----- > Version: PGP Universal 2.9.1 (Build 287) > Charset: US-ASCII > > wsBVAwUBSqfkj3ajGqjtoMHxAQirMQf9F7kysMvkz0jEuou7oX1uzsIXwuRuppqZ > 8sXjAVsPb8gdOdSRS7vAMv5GFzzXSJGUGiJfWm9bpDo4lb7Erb2u0I6G1VGkqT/n > pEyJp+7cJZqoTEqt/0weWEf4JELayGKxNCZ+acgg1EngZfin98RpTWvMhUf0aWbJ > /M78xNX/ucUQDMcFmFu9gfaNM7A3lNy/E5z/B6bvKyfBLfMubUVvFaNaKXKbBnsU > MFx3sk8RdESXj7jiUR3XTD5qqzZkK0OJq8lse1U3DhXbzbbjaLe0IXB1ioAsFgm9 > k+vEd2QBtWhS/Jdxd0DbPrh1Q4+Z6KZ8BjN8M7S+xi3qSrUSWsaP2g== > =DV73 > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and > focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list -- http://www.fastmail.fm - The professional email service |
|
From: <Pau...@sc...> - 2009-09-09 18:40:28
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > I am not familiar with LBP? Little Big Planet.... Its a physics based platformer on the PS3, we're re-authoring it for PSP... > If I understand correctly, you have effectively a fixed joint > constraining the character controller, and solve the other joints after Not quite - we don't have a character controller at all; its just a rigid body like any other, except that its not allowed to rotate. > that one. ie ensuring that the action of the other joints takes > precedence. So how do you handle cases where it is correct for the Actually, this is quite the opposite of what we do :) The actor constraint is 'just' another constraint in the system, solved at the same time as all the other constraints in the solver - this is important otherwise the forces experienced by and exerted by sackboy are not correctly transmitted and things feel sloppy and incorrect. > player to be influenced by other objects. eg a physically simulated > motorized revolving door pushing the player? It just works(tm) because the character is no different than any other rigid body, so the revolving door pushes him around just like it would a box, or sphere etc etc... > The whole topic of two way interaction between user controlled objects > and physically driven objects is interesting and I have never seen much > discussion on the topic... I guess its a fairly new thing; most games have a 'barrier' interface between the player and the world, because the player usually reacts with animations, which aren't usually driven by the physics engine (although this is changing)... Cheers, Paul. ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify pos...@sc... This footnote also confirms that this email message has been checked for all known viruses. Sony Computer Entertainment Europe Limited Registered Office: 10 Great Marlborough Street, London W1F 7LP, United Kingdom Registered in England: 3277793 ********************************************************************** P Please consider the environment before printing this e-mail -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.9.1 (Build 287) Charset: US-ASCII wsBVAwUBSqf2kXajGqjtoMHxAQjfygf/Zp9b12E9TIszbfH24BHkHYD2fEkqq/eB sB6n+4BjLaHGwwoulanIM6+Ud9G42FZc3CGl+15s0Tw4MnuGAo7ds/7HElNwIpcX raCPz311YTldT3dspl196GRlOi92YriE/lRwTN+7SwXj65GMA4DOHsOtigjxNLpX lI7J1iecCcDMLAv2LngOy1PXgepWzAD0ovUiA35DasMYyTen7Jho9o6LzD037sOR 4Gfx6QmQ7JC81fARXCO50p7cdo/B8zssE3c5lAe7Tbjl4CipudZ+fh9J5LV86ABt ULpaGJbmJnA0wKzrplZr8fASzwvVpPMjHcfLoBS09uQF6ya1F4KjFQ== =BMtp -----END PGP SIGNATURE----- |
|
From: Alen L. <ale...@cr...> - 2009-09-09 20:18:59
|
Wednesday, September 9, 2009, 7:26:07 PM, Paul_Firth wrote: > The character is a full rigid body with inverse inertia tensor of 0 > so he can't rotate. He is controlled using a custom written 'actor' > constraint which has parameters like acceleration, strength and so > on. He interacts with the world just like any other rigid body. That sounds exactly like the approach we used in SS2, and in SS:HD soon. From our experience so far, I'd say that though it was attractive in the beginning think it has gathered more cons than pros over time. The idea of using an "old-school" character controller, and connecting it to the rigid body solver using something like a hybrid dynamics approach sounds more and more attractive. Note that this may apply more to us due to the specifics of the FPS movement. I guess it looks different for LBP. JM2C, Alen |
|
From: Jon W. <jw...@gm...> - 2009-09-09 18:09:49
|
David Black wrote: > Is this the approach others are using, or is there a better method? > I go one step further, and make the character controller interact with the rigid body physically (not kinematically). Sincerely, jw -- Revenge is the most pointless and damaging of human desires. |
|
From: David B. <db...@fa...> - 2009-09-09 18:20:14
|
Can you describe your approach in more detail? eg how the user input is translated into movement of the rigid body? Because approaches involving applying forces etc to a rigid body in order to move it have never felt correct for player movement etc (ie the result is too disconnected/soft). David On Wed, 09 Sep 2009 11:09 -0700, "Jon Watte" <jw...@gm...> wrote: > David Black wrote: > > Is this the approach others are using, or is there a better method? > > > > I go one step further, and make the character controller interact with > the rigid body physically (not kinematically). > > Sincerely, > > jw > > > > > -- > > Revenge is the most pointless and damaging of human desires. > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and > focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list -- http://www.fastmail.fm - Email service worth paying for. Try it for free |
|
From: Jon W. <jw...@gm...> - 2009-09-09 21:00:49
|
David Black wrote: > Can you describe your approach in more detail? eg how the user input is > translated into movement of the rigid body? Because approaches involving > applying forces etc to a rigid body in order to move it have never felt > correct for player movement etc (ie the result is too > disconnected/soft). > Well, I'm not making FPS games, so I don't need that wrist-snapping single-frame 180-degree turn. In fact, what we make is "down-tuned" from what we could make, because requirements are that it should be human-like (no running at 90 mph and turning at 20 g). FPS gamers constantly complain when they first have to use our software :-) However, when I've done it more action-adventure style, I make the available propellant force inversely proportional to velocity (clearly avoiding divide-by-zero by adding some tuning constant to the divisor :-). This means that "getting started" is a lot quicker, which is generally the main problem. The draw-back is that you can be able to move really heavy things, so to work around that, I down-scaled the available propellant force if there was a sideways contact onto the player capsule. Also, no propellant force unless you have some upwards-facing contact (from the ray legs or from the capsule), meaning you have a floor contact. In my opinion, for an action-adventure style character, that controller actually turned out pretty well. It also had the nice (for this case) side effect that you couldn't turn as quickly when running fast as you can when standing still, because propelling force (which turns into delta-vee) is less. I did allow a large amount of braking force in all cases, though. And in the end, it still uses a ray plus a capsule as all the testing needed, by being smart about re-using all the information you get. (I did not add two rays for legs -- that'd be an interesting experiment) Sincerely, jw -- Revenge is the most pointless and damaging of human desires. |
|
From: metanet s. <met...@ya...> - 2009-09-09 18:02:20
|
> > That's only a solution for the most simplistic > > single player games these days. > > Perhaps God of War is simplistic to you, but it > works just fine for us. I think what was meant by "simplistic single player" is "Quake-like: static world where the only dynamic objects are characters"; GoW *does* fall under this category -- the player can't create arbitrary arrangements of objects, deform the scenery, etc. which means that if no problematic terrain is created by artists, none will ever exist. Obviously it's trivial to ensure that the scene plays nice with the character movement code in such a game -- you just make the scene that way and that's the end of the story. In a more dynamic world, where there are lots of physics-based objects and/or destructible shapes, it's not so trivial (maybe impossible) to guarantee that the scene is nicely behaved with no tiny channels or other problematic geometry. Especially if you're trying to allow characters to move on/across such dynamic shapes, rather than simply treating them as untraversable obstacles. Raigan --- On Wed, 9/9/09, chr...@pl... <chr...@pl...> wrote: > From: chr...@pl... <chr...@pl...> > Subject: Re: [Algorithms] Kinematic Collision > To: "Game Development Algorithms" <gda...@li...> > Received: Wednesday, September 9, 2009, 12:33 PM > James Robertson wrote: > >> Simple. You tell your art/design team not to > design > >> geometry like that! (No, really.) > > > > That's only a solution for the most simplistic > > single player games these days. > > Perhaps God of War is simplistic to you, but it > works just fine for us. > > Programmers overengineer way too much. > > > Christer Ericson, Director of Tools and Technology > Sony Computer Entertainment, Santa Monica > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal > Reports 2008 30-Day > trial. Simplify your report design, integration and > deployment - and focus on > what you do best, core application coding. Discover what's > new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list > __________________________________________________________________ Make your browsing faster, safer, and easier with the new Internet Explorer® 8. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/ |
|
From: <chr...@pl...> - 2009-09-09 19:03:00
|
Raigan wrote: > In a more dynamic world, where there are lots of physics-based > objects and/or destructible shapes, it's not so trivial (maybe > impossible) to guarantee that the scene is nicely behaved with no > tiny channels or other problematic geometry. Especially if you're > trying to allow characters to move on/across such dynamic shapes, > rather than simply treating them as untraversable obstacles. Game development isn't about solving the general case; it's about ensuring the special (failure) cases don't happen. It is about the smoke and mirrors, the bang for buck. Christer Ericson, Director of Tools and Technology Sony Computer Entertainment, Santa Monica |
|
From: James R. <ja...@fu...> - 2009-09-10 07:08:55
|
Game development like almost every other form of software development is about using the right tool for the job. I think you'll find you *do* always solve the general case - it just so happens that in simplistic games (from the perspective of collision detection) the general case is more simply defined, but as Raigan clarified, any game with dynamic content, deformable worlds, destructable scenery, player generated content, etc have a more complex general case. chr...@pl... wrote: > Raigan wrote: > >> In a more dynamic world, where there are lots of physics-based >> objects and/or destructible shapes, it's not so trivial (maybe >> impossible) to guarantee that the scene is nicely behaved with no >> tiny channels or other problematic geometry. Especially if you're >> trying to allow characters to move on/across such dynamic shapes, >> rather than simply treating them as untraversable obstacles. >> > > Game development isn't about solving the general case; it's > about ensuring the special (failure) cases don't happen. It > is about the smoke and mirrors, the bang for buck. > > > Christer Ericson, Director of Tools and Technology > Sony Computer Entertainment, Santa Monica > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list > > |
|
From: Jamie F. <ja...@qu...> - 2009-09-10 09:13:47
|
chr...@pl... wrote: > Raigan wrote: >> In a more dynamic world, where there are lots of physics-based >> objects and/or destructible shapes, it's not so trivial (maybe >> impossible) to guarantee that the scene is nicely behaved with no >> tiny channels or other problematic geometry. Especially if you're >> trying to allow characters to move on/across such dynamic shapes, >> rather than simply treating them as untraversable obstacles. > > Game development isn't about solving the general case; it's > about ensuring the special (failure) cases don't happen. It > is about the smoke and mirrors, the bang for buck. Absolutely. I recently came across a car game where they'd spent some time optimizing the AI, so they could handle the AI for up to 30 cars on a 360 core. 10 years ago, on PS1, we used to have 30 cars running physics, AI and everything else on the only core (which ran at a heady 30MHz...). Jamie > Christer Ericson, Director of Tools and Technology > Sony Computer Entertainment, Santa Monica |
|
From: Alen L. <ale...@cr...> - 2009-09-10 10:12:04
|
Jamie wrote at 9/10/2009: > 10 years ago, on PS1, we used to have 30 cars running physics, AI > and everything else on the only core (which ran at a heady > 30MHz...). And they looked so good and played so well... for that time's standards, but today... When I revisit some of the games from my youth, then yes... some aspects are so good, even better than some games today. But other aspects, even in the playability and the satisfaction with the controls seem to suddenly appear much worse than I remember. Isn't the human memory so deceptive? Alen |
|
From: Jamie F. <ja...@qu...> - 2009-09-10 11:42:40
|
Alen Ladavac wrote: > Jamie wrote at 9/10/2009: >> 10 years ago, on PS1, we used to have 30 cars running physics, AI >> and everything else on the only core (which ran at a heady >> 30MHz...). > > And they looked so good and played so well... for that time's > standards, but today... > > When I revisit some of the games from my youth, then yes... some > aspects are so good, even better than some games today. But other > aspects, even in the playability and the satisfaction with the > controls seem to suddenly appear much worse than I remember. Isn't the > human memory so deceptive? Absolutely; I can't see myself playing Manic Miner any more, or learning to dock with space stations in Elite again. But it does look like a lot of the massive processing power that's now available seems to go into producing a similar experience to what we had ten years ago, more expensively. This seems to be particularly true in AI; graphics have moved on quite a lot, and physics a fair bit. I would like to see more of that processing power and development time going into crafting the player experience. Jamie > Alen |
|
From: Danny K. <dr...@we...> - 2009-09-10 14:50:38
|
> Absolutely; I can't see myself playing Manic Miner any more Actually, I recently played a port of MM for the first time in 20 years, and it was as addictive as ever. Sometimes simple gameplay is as good as it ever was. Danny <relurks> |
|
From: Jamie F. <ja...@qu...> - 2009-09-10 15:11:17
|
Danny Kodicek wrote: >> Absolutely; I can't see myself playing Manic Miner any more > > Actually, I recently played a port of MM for the first time in 20 years, and > it was as addictive as ever. Sometimes simple gameplay is as good as it ever > was. OK, you tempted me :) I went here: http://www.darnkitty.com/manic/ ... But after a few minutes of repeated dying on the first level, I gave up! Maybe I'm just getting old.... Jamie > Danny > <relurks> |
|
From: Danny K. <dr...@we...> - 2009-09-10 15:32:43
|
> Danny Kodicek wrote: > >> Absolutely; I can't see myself playing Manic Miner any more > > > > Actually, I recently played a port of MM for the first time > in 20 years, and > > it was as addictive as ever. Sometimes simple gameplay is > as good as it ever > > was. > > OK, you tempted me :) I went here: > > http://www.darnkitty.com/manic/ > > ... But after a few minutes of repeated dying on the first > level, I gave up! I wonder if that's the biggest change in gaming since those days: we're much less willing to spend ages getting pixel-perfect on a game. I was looking at a review of Arkham Asylum, talking about how great the combat was because it did all the work for you and you just pressed two buttons, and it occurred to me that lots of games have gone down this route recently, making combat much more about movement and button-mashing than about mastering complicated systems of combos. I'm not particularly saying one is better than the other, but it's interesting how much these things have changed. The selling point of most games is now about big worlds and exploration, rather than the kind of micro-world pinpoint accuracy of those days. Obviously, there's still plenty of that going on in the casual game market, though. Danny |
|
From: Jon W. <jw...@gm...> - 2009-09-11 04:00:40
|
On Thu, Sep 10, 2009 at 8:32 AM, Danny Kodicek <dr...@we...> wrote: > I wonder if that's the biggest change in gaming since those days: we're much > less willing to spend ages getting pixel-perfect on a game. I was looking at I think the difference is you and me. My 11-year-old is perfectly happy spending hours getting the exact right angle on some "casual" cannon firing Flash game. I'd try it twice and then give up, because frustration is no longer something I consider entertaining :-) (I actually tried general Raam about 50 times at the end of Gears 1, read all the walk-throughs, and *still* couldn't get him. I even tried it in co-op with said 11-year-old. Shame on Epic for balancing it so poorly!) Sincerely, jw -- Americans might object: there is no way we would sacrifice our living standards for the benefit of people in the rest of the world. Nevertheless, whether we get there willingly or not, we shall soon have lower consumption rates, because our present rates are unsustainable. |
|
From: James R. <ja...@fu...> - 2009-09-11 07:14:18
|
TV and movies have been progressively dumbed down over the years to the point now where 90% of programs are formulaic garbage that even the simplest of morons can understand. I don't see that the majority of games are much different to be honest. Back in the days of way back the people who played games were people who enjoyed learning all those damn combos and skills and wanted something challenging that they could spend hours and hours playing, mastering, and ultimately perfecting. Now that the market has broadened, more and more games have to appeal to newer types of gamer who consider games something to do when there's nothing on TV for half an hour. They want their quick fix of fun that their brains have been trained into demanding but really don't want to have to think about what they're doing. Danny Kodicek wrote: > > Danny Kodicek wrote: > >>>> Absolutely; I can't see myself playing Manic Miner any more >>>> >>> Actually, I recently played a port of MM for the first time >>> >> in 20 years, and >> >>> it was as addictive as ever. Sometimes simple gameplay is >>> >> as good as it ever >> >>> was. >>> >> OK, you tempted me :) I went here: >> >> http://www.darnkitty.com/manic/ >> >> ... But after a few minutes of repeated dying on the first >> level, I gave up! >> > > I wonder if that's the biggest change in gaming since those days: we're much > less willing to spend ages getting pixel-perfect on a game. I was looking at > a review of Arkham Asylum, talking about how great the combat was because it > did all the work for you and you just pressed two buttons, and it occurred > to me that lots of games have gone down this route recently, making combat > much more about movement and button-mashing than about mastering complicated > systems of combos. I'm not particularly saying one is better than the other, > but it's interesting how much these things have changed. The selling point > of most games is now about big worlds and exploration, rather than the kind > of micro-world pinpoint accuracy of those days. > > Obviously, there's still plenty of that going on in the casual game market, > though. > > Danny > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list > > |
Thanks for helping keep SourceForge clean.
X