Re: [Realityfactory2-devel] Level Format

[Swope, D. C. <Dav...@ci...>]

Andy,

=20

You wrote:

The "concrete yet extensible" idea is very good, and had actually
crossed my mind before, but there are a couple problems with it. For
one, what happens if you want to remove functionality rather than add
it? For two, what if you want to modify existing functionality?

=20

My thought was that we would expose all the data & functions to Python
that are available to the C++ implementation.  One of the built-in data
items of the entity would allow specifying a Python script.  If a script
is requested then during the entity's time update or during the entity's
response to an event the first thing C++ would do is to run the script.
The script could then do anything that the C++ built-in code could do.
If the user wanted to completely change the entity's behavior then the
script can tell C++, with a call we provide, not to do its normal
processing.  This way the user could completely modify the existing
functionality if so desired. =20

=20

I can't seem to get comfortable with putting everything into Python
because: =20

=20

1. 90% or more of RF2's users are non-programmers.  We are now forcing
them to understand a possibly complicated program written in Python in
order to modify the behavior of an entity.  Providing specific hooks for
the Python script to call to modify the underlying behavior would allow
the script to be a much simpler and easier to understand program.  I
understand this type of architecture will not be as flexible for the
non-programmers, but I am afraid that we will be putting too much power
in the hands of users who have no programming experience.  The old
saying is: Giving them enough rope to hang themselves.

2. The users who are programmers can just as easily modify the C++ code
as they can the Python script to get additional functionality.

3. I really like the way RF1 hides the underlying mundane details of how
an entity does what it does.  The entity data allows the user to modify
its behavior without worrying about these details.  If everything is
done in Python, we are making the non-programmer user see and possibly
have to understand all those details.  I know those users can ignore the
script and just use the already scripted functionality, but in this case
what value have we added?  The only thing we have really done is require
all the Python calls to C++ to be slower having to go through the
wrapper.  This same functionality can be accomplished in C++ which will
be faster and even better we can leverage the RF1 code that handles
these entities already.

4. I know you are not worried about speed, but in my opinion speed will
always be an issue.  Yes the processors will get faster, but in order to
compete in the marketplace the applications will have to have more
content, more details and more effects.  Even if the Python interface
adds only a tiny amount of overhead, having hundreds or even thousands
of entities in the application will add up to a significant hit on
framerate.

=20

Please take this as my opinion after 30 years of writing real-time
software for machine controls.  I just want us to have thought out these
details before getting in too deep to easily change direction.

 =20

Best regards,
=20
David

  _____ =20

From: rea...@li...
[mailto:rea...@li...] On Behalf
Of Andy Riordan
Sent: Sunday, May 06, 2007 7:40 PM
To: Rea...@li...
Subject: Re: [Realityfactory2-devel] Level Format

=20

>From what I understand, the only additional overhead would be one
function call per frame, which isn't anything to worry about. However, I
could be wrong.

I think overall it would be a good idea, but in my opinion it would take
RF2 too far from it's original intent without providing that much
benefit (just speed). The speed difference isn't terribly much, and will
continue to diminish with better processors. The "concrete yet
extensible" idea is very good, and had actually crossed my mind before,
but there are a couple problems with it. For one, what happens if you
want to remove functionality rather than add it? For two, what if you
want to modify existing functionality?=20

Also, RF2 is being designed so that it can be used for any type of game,
and also for things other than just games. Having extra code in the core
of RF2 to do things they would not need would confuse those wishing to
extend RF2 through C++ programming whose applications do not match the
predefined entities, unless they were well-separated from the core of
RF2.=20


The confusing new users part I am not sure on. The "script everything"
approach would, as you said, most likely confuse new users wanting to
modify existing functionality due to the sheer volume of scripts and
code. However, I'm not sure that looking through the C++ code (or
reading documentation we would have to write or generate somehow) to
find out what hooks are available for extensibility would be easier.
Perhaps this problem could be solved with guides, most likely on a wiki
so others could add them. You would have "how to extend your player
script to add prone", "how to extend your weapons script to support
dual-wielding", and so on. This would help to not confuse new users
wanting to extend the scripts, and teach them skills they would need to
know how to extend things not covered in the wiki. Most of the articles
could also be written by the users that way.=20

This would also take longer to build, since C++ is slower to code
functionality in than Python. In addition, we could always implement
this later on if we discovered that doing everything in Python was
indeed too slow without sacrificing too much work.=20

What do you think?
=20