Re: [Realityfactory2-devel] Level Format

[Andy R. <and...@gm...>]

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.'

def main():
t = 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:
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?

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?
>
> Will the C++ interface simply be 'called' by Python, or vice-versa?
>
> 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.
>
>
>
> Best regards,
>
> Dave
>  ------------------------------
>
> *From:* Andy Riordan [mailto:and...@gm...]
> *Sent:* Thursday, May 03, 2007 10:43 AM
> *To:* Swope, David C.
> *Subject:* Re: [Realityfactory2-devel] Level Format
>
>
>
> 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...> wrote:
>
> Andy,
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> Best regards,
>
> Dave
>  ------------------------------
>
> *From:* rea...@li... [mailto:
> rea...@li...] * On Behalf Of *Andy
> Riordan
> *Sent:* Monday, April 30, 2007 2:38 PM
> *To:* Rea...@li...
> *Subject:* Re: [Realityfactory2-devel] Level Format
>
>
>
> 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).
>
>
> 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?
>
> 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).
>
> - Andy Riordan
>
> On 4/30/07, *Swope, David C.* < Dav...@ci...> wrote:
>
> Andy,
>
>
>
> I was wondering if we could start discussing the level format for RF2.
>
>
>
> Are you thinking about using bsp files?  It sounds like the bsp support in
> Ogre is being dropped.
>
>
>
> Best regards,
>
> David
>
>
>
>
> -------------------------------------------------------------------------
> 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.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Realityfactory2-devel mailing list
> Rea...@li...
> https://lists.sourceforge.net/lists/listinfo/realityfactory2-devel
>
>
>
>
> -------------------------------------------------------------------------
> 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.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Realityfactory2-devel mailing list
> Rea...@li...
> https://lists.sourceforge.net/lists/listinfo/realityfactory2-devel
>
>
>
> -------------------------------------------------------------------------
> 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.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Realityfactory2-devel mailing list
> Rea...@li...
> https://lists.sourceforge.net/lists/listinfo/realityfactory2-devel
>
>