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

[Matt Benic]

It's been some time since I last worked on a product that utilized
middleware, but we had some relevant experiences so I'll take a shot at your
survey, I hope it helps :-)

The product under development at the time was never released, however the
technology developed is being used in an upcoming title by I-Imagine, called
Final Armada.

 

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)?

-It's a tie: bugs and features. We were amazed that previous customers had
not picked up some of the issues we hit, at the same time considering the
middleware we were using, and the products used to 'spearhead' it, we were
caught by surprised by some of the features it did not support, and the way
we had to mangle the system to implement these 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?

-Physics was integral to this title, it was a driving game.
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?

-The difficulty in integrating with existing middleware, and the processing
and memory resources wasted because of the two systems not being designed to
work together
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)? 

-about 15% of project time
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)?

-Easy development of vehicle physics models. Ie real tools that designers
and artists can use.
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?

-It would have taken just as long to integrate into our other middleware as
our in-house engine, and we simply would not have seen any benefits worth
the effort. Particularly we had no control over the data structures in a
third party engine (as opposed to within our own) and this resulted in huge
amounts of wasted resources as data was duplicated and/or needed to be
copied around excessively.
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?

-As above
3.3.2 Why would you decide for a different, licensed engine now? 

-As above
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?

-Yes
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)

-Intermediate


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?

--



Hope this helps :-)

Regards,

Matt

  _____  

From: casual_games-bounces at igda.org [mailto:casual_games-bounces at igda.org]
On Behalf Of Branislav Siles
Sent: 15 June 2006 02:00 PM
To: casual_games at igda.org
Subject: [casual_games] Middleware and Physics, features,troubles and
failures..

 

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

 <mailto:siles at atomontage.com> siles at atomontage.com
atomontage game physics <http://atomontage.com> 

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/6d6b97ed/attachment.html