[casual_games] Middleware and Physics, features, troubles and failures..

[Branislav Siles]

Hello fellow game developers, publishers and others.

I am interested in your opinions regarding physics in [your] games, third party physics middleware and middleware for games in general. I find this mailing list a perfect media for sharing thoughts and feelings about products of this exponentially growing part of the game business.
I am especially interested in the troubles and failures related to middleware and your struggles to use middleware (or your own physics) for the first time. I would appreciate your thoughts on this topic and answers to any of the questions below. If you wish to remain anonymous and want to share your experiences freely about a particular product, please feel free to reply directly to my e-mail address.
Thank you and have a nice day!

Branislav Siles
siles at atomontage.com
atomontage game physics

My questions:

1. MIDDLEWARE
1.1 What are your worst experiences with middleware in general (licensing issues, documentation, support, features, quality/stability, impossible or difficult addition of new features)?


2. PHYSICS
2.1 How important was physics for your recent project(s)? How important will it be (or you think it might be) for your projects in the next couple of years?
2.2 If your project does not truly require any kind of physics (or just a few trivial algorithms), what could be the reason for you to implement or integrate a physics engine regardless of that fact?
2.3 If you do not want to use a 3rd party physics engine or you do not use physics at all, but you would like to, what are the main barriers for you to start to implement or integrate one?
2.4 How much time (%, man-weeks) did your team (programmers) spend implementing an in-house physics engine for your recent project and how much time do you expect to spend that way in your next project(s)? 
2.5 How much time (%, man-weeks) did you spend integrating an existing 3rd party physics library into your project and how much time do you expect to spend that way in your next projects(s)?
2.6 If you're a publisher (or producer, ...), are you satisfied with the state of physics in games you publish or produce? Why or why not?


3. FEATURES
3.1 What features are you missing the most in your in-house physics and/or in the existing 3rd party engines (engines you may consider to use, no matter whether you use them now or not)?
3.2 What was the main reason(s) for you, related to features, to refuse a 3rd party physics engine you were about to integrate?
3.3 Why did you choose for a licensed (paid) physics solution instead of a free one?
3.3.1 What (features, support, ..) are you missing the most now?
3.3.2 Why would you decide for a different, licensed engine now? 
3.4 Are you satisfied with the physics-model of the physics you are using now? (e.g. it is not intuitive enough, not real-world-like physics, hard to initialize correctly -> you are probably not satisfied) 
3.5 Does the physics you use allow you to tweak it so that you can easily simulate a fantasy or sci-fi world with physics very different to the one in the real world?
3.6 How hard it is for you to build the physical representations of objects in your game? (fully automatic -> very easy; all done by hand -> very hard)


4. STATISTICS
4.1 What is the typical memory-usage of the physics you use (e.g. in MB or % of the memory allocated by your game)? Is it OK with you and your gamers? 
4.2 Is the size of the distributed physics (dll(s) or statically linked + sources if required) OK for your game (usually critical for a downloadable game)? How many KB is it?



Feel free to add a short description of your game(s), features or yourself if relevant.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://seven.pairlist.net/pipermail/casual_games/attachments/20060615/13342076/attachment.html