Re: [Realityfactory2-devel] Level Format

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Right now, I think I would vote for the main loop to be in C++.  It will
execute faster.  I really don't think we need to expose anything in
Python that is not related to customization of built-in entities or the
creation of custom entities.  This will just confuse non-programmer
users.

=20

Here is a suggestion of one way to handle entities:

=20

Built-in:  C++ creates this entity when the level is loaded.  A C++
manager for this entity type takes care of its behavior, driven to an
extent by data entered by the designer in the level editor (much like
RF1 works now).  The entity's data includes the capability to designate
a Python script.  This Python script, if specified, would be called each
update by the manager first, before any standard behavior is performed.
The script can then call any of the object's methods to create
additional functions.  The script should even be able to prevent the
manager from performing the 'normal' built-in behavior if it so desires.
This way a user can completely customize a particular entity OR use the
default one and then he is not required to do anything except supply the
entity's data at level edit time (as easy as RF1).  This way the
standard behavior executes faster since it is running C++ compiled code.

=20

Custom Entity:  C++ creates a generic entity and its behavior is
COMPLETELY defined by the Python script.  A custom entity manager
basically just calls the Python script and has no built-in behavior
programmed except things that are needed by all entities.  This way
users can develop their own entities and if they come up with a great
one we can create a built-in version later which could do the same thing
in C++ code that executes faster.

=20

What do you think of that idea?

=20

Best regards,
=20
David=20

  _____ =20

From: rea...@li...
[mailto:rea...@li...] On Behalf
Of Andy Riordan
Sent: Thursday, May 03, 2007 2:10 PM
To: Rea...@li...
Subject: Re: [Realityfactory2-devel] Level Format

=20

The main loop is undecided. I am leaning towards Python, however. There
are pros and cons to both approaches. On the C++ side, we would probably
make a root object which resides in the C++ code. Python objects which
wish to live any length of time attach themselves to that root object.
Each object has a method which it assigns as the "frame function". Every
frame, the main loop asks the root object to call all frame functions on
all objects attached to it, which it does. It would look something like:

class testobject:

def __init__(self):

rf.registerframefunction(self.frame)

def frame():

print 'This is a test that will print every frame.'=20

def main():

t =3D testobject()

root.attach(testobject())

The other approach would be to have the main loop in Python. In this
case, it is Python which is executing for the full length of the
program. There would have to be a function which it would call inside
RF2 (C++) which would signal RF2 to do what it needs to do every frame.
So an example would look something like:=20

def main():

while !rfwindow.closed():

print 'This is a test that will print every frame.'
rfwindow.frame()

I personally lean towards the main loop in Python approach if it is
technologically possible with stock Ogre, since it seems easier for the
user to both use and grasp concepts wise, especially for beginners, but
I might be very wrong. What do you think?=20

I don't quite understand what you mean when you say "Will the C++
interface simply be 'called' by Python, or vice-versa?"

The entities would be created by C++. C++ loads the level, and sees that
it contains an entity x in file y.py. It creates an instance of that
object, assigning it the properties assigned to it in the level editor.
The object lives until the level changes, the program closes, or it is
killed explicitly.

The way RF2 would work in relation to RF is: C++ created the entities.
These entities have some predefined behavior set by entity data, and the
rest is in the scripting. So the user may have a level change entity
which can have a property set called "delay", and the level entity may
look at that property, set in the level editor, and when triggered run
"sleep( self.delay)" before executing its scripted action of changing
the level.

Again, sorry, and if I need to clarify anything about it don't hesitate
to ask!

Best Regards,
- Andy Riordan

On 5/3/07, Swope, David C. <Dav...@ci... > wrote:

Thanks for the explanation!

I'm still having a problem understanding a few of the low level details
of how this will work.

Where does the main loop reside, C++ or Python? =20

Will the C++ interface simply be 'called' by Python, or vice-versa? =20

Will the individual entities be created by C++ or Python?

The way RF currently works is:  C++ creates the entities. These entities
have some predefined behavior set by the entity data and the C++
manager.  Some entities can specify a 'script' that is basically
executed by the C++ code during the manager's updating of the entity.
This script has predefined functions that can be called that allow the
behavior of the entity to be altered and to get feedback from the world.
Please explain how this will work in RF2.

Sorry about the confusion, but I'm trying to map what I know about RF1
to RF2.

=20

Best regards,
=20
Dave

  _____ =20

From: Andy Riordan [mailto:and...@gm...]=20
Sent: Thursday, May 03, 2007 10:43 AM
To: Swope, David C.

Subject: Re: [Realityfactory2-devel] Level Format

=20

I'm sorry, I have done a terrible job of clarifying what I wish RF2 to
even be. This is completely my fault. I plan to write a detailed design
document later, but for now I will just clarify the Python/C++
integration question.

RF2 embeds Ogre in it, along with the Python interpreter. The Python
interpreter is used to call scripts, which define the program's
behavior. Inside the program, many of Ogre's functions and data members
are exposed to Python, but in a way which is simpler than how Ogre
behaves by default. For instance, where in Ogre you would have to define
a camera manually, there should be a default camera created in RF2 for
in-game use, which can be deleted if unneeded with "delete defaultcam"
or something similar. Another example would be the creation of
materials; in Ogre this is a multi-line process for even a simple
material, where in RF2 scripting this should be one line. The texture
class should have a constructor which can take a string, and parse it as
meaning that you wish to load a bitmap from a file rather than load a
material script, which is the default in Ogre.

There are two reasons for this. For one thing, RF2's target audience is
mainly original RF users, and they are used to extremely little, simple
scripting for very specific things. For another, the simpler it is the
more productive the game developer will be, and that is a major focus
for RF2.

The reasons I did not use an existing Ogre Python binding is that I
could not find one written in Boost (perhaps I missed it, though of
course if it were a drop-in situation that wouldn't matter quite as
much), and because of my desire to simplify Ogre to such an extent.

One of the worst things that could happen is that RF2 would be harder to
use than RF. With RF, you have hard, strict behavior that can be
customized to an extent, but beyond that point you must rewrite it with
the (easy) pawn scripting system. With RF2, nothing is set in stone, so
the player is just a .py file which you can edit all you want. If you
need a new feature, like going prone, you can simply script it in rather
than rewrite the player entirely and then implementing the feature you
wanted. However, if the scripting in RF2 is more complicated than it was
in RF, it would have the opposite effect, reducing the ability to
customize the game objects due to the fact that the scripting is so hard
that for most users, who are predominately non-programmers, the
scripting would be too obscure for them to try changing.

As such, an existing binding might work, but we would have to customize
it a lot to get it to the point we need.

Often, there would be something like:

class camera
{
public:
camera(); // Needed to initialize the cam, register with scenemgr, etc
~camera();

void setname(string name) { _camera.setName(name); }
void getname() { return _camera.getName(); }

(etc)

private:
Ogre::Camera _camera;
};

Next, Boost::Python should be used to combine the setname and getname
into a single data member, name, using setname and getname as setter and
getter functions (see
http://www.boost-consulting.com/writing/bpl.html#id12).

Sometimes, I think we could do something like:

class camera
{
public:
camera(); // Needed to initialize the cam, register with scenemgr, etc
~camera();

Ogre::Camera _camera;
};

And then simply expose _camera.getName and setName themselves as the
getter and setter functions. Sometimes this will not work as translation
between the simpler RF2 scripting API and the Ogre API would need to be
done, but often this will work and be a lot simpler.

So RF2 itself is more or less a giant wrapper for the API's it uses,
plus some things like level loading code. Speaking of which...

Basically, RF2 will have built into the shell level file loading code.
This code would be exposed to script, giving the script the ability to
load levels, and possibly individual components of them as well. The
level editor would parse the scripts folder for classes with a comment
saying entity above them, and add the ability to set them as entities,
with properties being defined somewhere, like in the constructor, and
descriptions set in comments. Example:

#entity
#param color, rfobjects.color, Color this entity should be
#param position, rfobjects.position, Position this entity should be at
class something:
(...)

The level format would likely be something like:

rflevel
(level settings, such as ambient light, etc)
brushes:

(brushes defined here)

entities:

something (name):

color (255, 255, 0) (NOTE: Type is worked out by looking at script)
position (20 -32 200)

staticmesh (name):

actor ("media/actors/knight.obj")
(other attributes...)

And so on.

If you have ANY other questions whatsoever, feel more than free to ask,
or clarifications etc. Again, I'm extremely sorry I did not explain this
sooner! Also, the design is something I'm more than willing to have
change, so if there is a way anyone thinks it can be improved feel free
to speak up!

Best Regards,
- Andy Riordan

On 5/3/07, Swope, David C. < Dav...@ci...
<mailto:Dav...@ci...> > wrote:

Andy,

=20

I like the idea of a .zip file also.

So, you are thinking of just building the level from individual .mesh
files that we load into the octree scene manager?  Or are you planning
to have an external scene/level compiler of some sort to create the
necessary octree data?  This, I guess, will be part of the level editor.

=20

I would also like to discuss the involvement of Python in loading the
level file.  Are you planning to have Python scripts create all the
entities/static geometry/cameras/etc. or have the C++ portion load these
things and just provide an interface to Python so you can manipulate
them with scripts.  I would like to flesh out the details of this point.
Much of the code I've written for the sound/camera/actor/timer
interfaces will depend on where we draw the Python/C++ line.  If we
could get these details worked out I could start making the
modifications to these subsystems.  I think you have already thought
about this, but I still don't understand where you want the line drawn.
Please try to enlighten me again. =20

=20

Best regards,
=20
Dave

  _____ =20

From: rea...@li...
[mailto:rea...@li...] On Behalf
Of Andy Riordan
Sent: Monday, April 30, 2007 2:38 PM
To: Rea...@li...=20
Subject: Re: [Realityfactory2-devel] Level Format

=20

I have given some thought to this, and a few things jumped out at me. I
personally like the way the Unreal engines handle this. They have levels
consist of one file, which is both the compiled and source map rolled
into one. The benefits of this are that you would never lose your source
files, as sometimes happens, and when working on a game project, when
you send a level you are working on to a colleague, they don't have to
bother you again if they also want the source file. The downsides would
be the file size (and source material really doesn't take up much
compared to compiled material, which would need to be distributed either
way with the finished game), and easier access to non-game development
team members to source access for teams so inclined (which would be an
issue with most types of resources, unless we provide for a way to
encrypt game resources, which I am debating).=20

Another option is levels being zip files. This would be nice because you
could embed level-specific resources into the zip file, and it
integrates with Ogre nicely - Ogre can read directly from zip files. The
level itself would be more or less a list of entities, a list of
brushes, and some level properties. The models can be imported into the
level, where you can keep them separate from the folder or if you want
embed them into the level, which simply places them into the zip file.
Compilation data could either be embedded in the level file like above,
or as a separate file inside the zip file. Data like the brushes after
optimization and triangulation, lightmaps, and so on could either be
integrated into that compiled file, into the unified level file as
above, or be split up into a folder inside the zip level file. Do you
think that would be a decent option?=20

BSP might be an option, but I am hoping to be able to just use Octree
for scene optimization. If that were not fast enough, I would most
likely try various other things, and if I could not find a fast enough
solution I would likely use a BSP-type system. I am not very educated or
good at scene optimization code, and someone other than me can do some
of it (at least the parts which I am unfamiliar with).=20

- Andy Riordan

On 4/30/07, Swope, David C. < Dav...@ci...
<mailto:Dav...@ci...> > wrote:

Andy,

=20

I was wondering if we could start discussing the level format for RF2.

=20

Are you thinking about using bsp files?  It sounds like the bsp support
in Ogre is being dropped.

=20

Best regards,
=20
David=20

=20

------------------------------------------------------------------------
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.=20
http://sourceforge.net/powerbar/db2/
_______________________________________________
Realityfactory2-devel mailing list=20
Rea...@li...
https://lists.sourceforge.net/lists/listinfo/realityfactory2-devel=20

=20

------------------------------------------------------------------------
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.=20
http://sourceforge.net/powerbar/db2/
_______________________________________________
Realityfactory2-devel mailing list=20
Rea...@li...
https://lists.sourceforge.net/lists/listinfo/realityfactory2-devel=20

=20

------------------------------------------------------------------------
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.=20
http://sourceforge.net/powerbar/db2/
_______________________________________________
Realityfactory2-devel mailing list=20
Rea...@li...
https://lists.sourceforge.net/lists/listinfo/realityfactory2-devel

=20