Menu
▾
▴
realityfactory2-devel — General discussion about design and implementation topics in RF2
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
(9) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: Andy R. <and...@gm...> - 2007-08-14 16:28:33
|
I think it's time to discuss the design of the level editor, as I will be starting development of it in about a month. The libraries are, unless there is a very good reason otherwise, pretty much obvious and set in stone - wxWidgets for GUI, Ogre for graphics, Boost::Python for some helper functions and Python integration. The UI is completely up for grabs. I have created a few sketches, but nothing definitive. I would recommend we keep a similar interface to that of RFEditPro - for those who have not seen it: http://www.cs.nccu.edu.tw/~g9436/ca/q.jpg One thing we definitely need to discuss is whether the 3D view should be usable as an RF2 instance. Personally, I see little benefit to this - it's pretty much a "Oh, that's cooool!" feature that doesn't really increase productivity - UNLESS you can play, pause, edit, then play with your changes applied, which could also be done with the RF2 instance receiving the changes (a sockets poke saying "Hey, reload the level"? Something else entirely?) - Andy Riordan |
|
From: Andy R. <and...@gm...> - 2007-05-29 02:14:31
|
For the input, what do you think of this idea?
rfinput.keys.x, r, q, etc are booleans, set to whether the respective key is
pressed. In addition, there is rfinput.notifydownevent('keyhere', 'function
to execute on notify', param1, param2, etc). That would execute the function
specified when the given key was pressed down. There would also be
notifyupevent, etc for when the key is released etc.
Best Regards,
- Andy Riordan
On 5/28/07, Andy Riordan <and...@gm...> wrote:
>
> I have been working on the camera manager and have modified it to allow
> > looking and zooming and attaching the camera to an actor (defined in my
> > actor manager port). I currently have the python connection to the camera
> > manager operational. Python can call all the functions of the cam mgr. In
> > order to support having the cam mgr do anything I have installed the
> > standard RF1 key mapping into my version of the input manager. I can now
> > look and zoom with the keyboard or the mouse from the C++ built-in manager.
> > I am now going to write a similar functionality in Python. I have added a
> > two level Python override possibility to the camera manager. I made the cam
> > man able to handle multiple cameras; the users may want to create a two
> > player split screen game or simulation. A Python script can be run before
> > the cam mgr manage function that runs every update. This script can turn
> > off any further built-in functionality if so desired. The built-in cam mgr
> > manage function also performs logic for each camera that is defined. I
> > allow for a Python script that runs before each camera's built-in manage
> > logic is run and another that can run after the built-in logic. The one
> > that runs before can turn off the individual camera's built-in logic if
> > desired. Before I write the Python version of the logic I need to provide
> > user input for the Python program. I can't decide the best way to do this.
> > I currently have the key or mouse listener set a camera boolean variable
> > when the user requests look mode. The camera mgr uses these (look,
> > lookright, lookleft, lookup, and lookdown, etc.) booleans to animate the
> > active camera. I don't know whether the user input should set data items in
> > the cam mgr, like this, and Python can get the relevant user input from the
> > camera mgr or if Python should have a generic way of getting user input, or
> > both? What do you think?
>
> Great progress, thanks so much! I think it should be more or less generic,
> and then the user can create a camera object and map his own keys to it by
> getting the key states himself and adjusting the camera manually, and also
> providing a few subclasses of rfobjects.camera which have predefined,
> common layouts like the wsad fps camera, etc.
>
> > Or have you already decided this or actually implemented something? I
> > keep thinking about how the user input should be provided to the individual
> > subsystems, but I can't seem to come up with anything I like. I hope you
> > have some ideas.
>
>
> I'll have to think about how I would do it.
>
>
>
> > I have used Boost v1.34 and Python 2.5 along with the latest version of
> > Ogre (v1.4). Boost v1.34 has the exec, import and exec_func macros
> > (very nice).
>
>
> Yeah, in my working copy of RF2 I'm using Boost 1.34's import to
> easily get backtraces during python exceptions and provide a message box
> showing the script error when it occurs.
>
>
> > You never did answer my earlier question about why you weren't using the
> > latest version of Ogre.
>
>
> Sorry, I didn't see the question. They changed the api slightly in 1.4breaking the build, so I just haven't taken the time to port it yet. It's
> definitly on my todo list.
>
>
>
> > Let me know what you think. I'm moving pretty fast and don't want to go
> > the wrong way.
>
>
> I think it sounds good. I'm not sure about how the API is designed; I
> imagined it being the managers aren't really visible, and objects are
> handled. IE rather than rfmanagers.camera.create(), rfobjects.camera(). I'm sorry to not have a concrete document laying out everything in RF2
> and how it should work; I am working on a complete spec which will detail
> everything in RF2, as well as the tools, right now. It won't be set in
> stone; changes are certainly welcome of course as always, but it lays out
> generally what RF2 should be and will be updated to match the current state
> of things. It might take a little bit, but afterwards it should solve any
> problems of wasted work or not knowing what to do next, and I again
> apologize for being so disorganized!
>
> Best Regards,
> - Andy Riordan
>
|
|
From: Andy R. <and...@gm...> - 2007-05-29 02:05:31
|
> > I have been working on the camera manager and have modified it to allow > looking and zooming and attaching the camera to an actor (defined in my > actor manager port). I currently have the python connection to the camera > manager operational. Python can call all the functions of the cam mgr. In > order to support having the cam mgr do anything I have installed the > standard RF1 key mapping into my version of the input manager. I can now > look and zoom with the keyboard or the mouse from the C++ built-in manager. > I am now going to write a similar functionality in Python. I have added a > two level Python override possibility to the camera manager. I made the cam > man able to handle multiple cameras; the users may want to create a two > player split screen game or simulation. A Python script can be run before > the cam mgr manage function that runs every update. This script can turn > off any further built-in functionality if so desired. The built-in cam mgr > manage function also performs logic for each camera that is defined. I > allow for a Python script that runs before each camera's built-in manage > logic is run and another that can run after the built-in logic. The one > that runs before can turn off the individual camera's built-in logic if > desired. Before I write the Python version of the logic I need to provide > user input for the Python program. I can't decide the best way to do this. > I currently have the key or mouse listener set a camera boolean variable > when the user requests look mode. The camera mgr uses these (look, > lookright, lookleft, lookup, and lookdown, etc.) booleans to animate the > active camera. I don't know whether the user input should set data items in > the cam mgr, like this, and Python can get the relevant user input from the > camera mgr or if Python should have a generic way of getting user input, or > both? What do you think? Great progress, thanks so much! I think it should be more or less generic, and then the user can create a camera object and map his own keys to it by getting the key states himself and adjusting the camera manually, and also providing a few subclasses of rfobjects.camera which have predefined, common layouts like the wsad fps camera, etc. > Or have you already decided this or actually implemented something? I > keep thinking about how the user input should be provided to the individual > subsystems, but I can't seem to come up with anything I like. I hope you > have some ideas. I'll have to think about how I would do it. > I have used Boost v1.34 and Python 2.5 along with the latest version of > Ogre (v1.4). Boost v1.34 has the exec, import and exec_func macros (very > nice). Yeah, in my working copy of RF2 I'm using Boost 1.34's import to easily get backtraces during python exceptions and provide a message box showing the script error when it occurs. > You never did answer my earlier question about why you weren't using the > latest version of Ogre. Sorry, I didn't see the question. They changed the api slightly in 1.4breaking the build, so I just haven't taken the time to port it yet. It's definitly on my todo list. > Let me know what you think. I'm moving pretty fast and don't want to go > the wrong way. I think it sounds good. I'm not sure about how the API is designed; I imagined it being the managers aren't really visible, and objects are handled. IE rather than rfmanagers.camera.create(), rfobjects.camera(). I'm sorry to not have a concrete document laying out everything in RF2 and how it should work; I am working on a complete spec which will detail everything in RF2, as well as the tools, right now. It won't be set in stone; changes are certainly welcome of course as always, but it lays out generally what RF2 should be and will be updated to match the current state of things. It might take a little bit, but afterwards it should solve any problems of wasted work or not knowing what to do next, and I again apologize for being so disorganized! Best Regards, - Andy Riordan |
|
From: Andy R. <and...@gm...> - 2007-05-11 23:58:41
|
> > How about if I take a simple entity from RF1 and modify it to show you > what I mean? I was thinking maybe the 3dAudio one or Trigger. > Sure, sounds great, please get an account on SourceForge and I'll make a branch of RF2 in Subversion for you to test it out in. If it's a built-in entity and you change it's behavior you would have to > rebuild. However, the optional, overriding Python script can be > autoreloaded. > Sorry, I didn't explain fully. I meant I don't know whether you can unload then reload the DLL itself in real-time. If he doesn't need the flexibility all we've done is slowed down the > execution of the entity. What I proposed does not take away any > flexibility, all it does is provide a base functionality in C++ that can be > extended or replaced by a script only if the user needs to. > That is true, but a big part of learning would be copying and pasting the code from one entity to his own personal Python entity. If it is C++ he wouldn't be able to do so. However, if we went to the effort of writing all entities both in Python and C++ (which wouldn't be terribly difficult), and had RF2 prefer the C++ one but choose the Python one if that were all that was available, we will have conquered that too. I'm not talking about the execution of the compiled Python code (which I > assume will be slightly slower than C++), but more so the fact that every > time Python needs to call an Ogre method or function it will have to go > through another level of indirection (through the wrapper). This will take > additional time and you can multiply that tiny bit of time times hundreds or > thousands making it very significant. What I'm proposing allows us to > eliminate this penalty for built in things that work ok the way we > programmed them in C++ for the user. But, if he needs additional or > completely different functionality he can have it by writing the script. I > love the way you can script almost anything in your vision of RF2, all I > want to do is add a base functionality you can use also. If the base > functionality works for the user's needs then he doesn't have to use a > script, but the possibility is still there. Here is an example: Let's say > we have an entity that simulates a model in RF1. If this model is currently > animating then we must call the Ogre animation object every frame supplying > the elapsedtime. Why not have that call performed by the base entity > functionality instead of making the script do that every frame? The script > could then just execute the logic to decide when to start or stop animating. > However, if the user had a reason to, he could decide to tell the base C++ > code not to call the animation object with the elapsedtime every frame and > perform that function himself in the script. Most users will never need to > modify this aspect of the model entity. Why not have theirs execute the > fastest which will save them time for scripting another entity where they > need different behavior than the base? But, again, if they need to, they > can. > Sounds good to me. Whether we design these base entities as plugins or built-ins I haven't > really thought about much, but we can discuss it more. I think that the base entities being plugins is the best choice. That way users can make plugins and post them on the forums for download rather than having to splice together various versions of RF2, all with different entities, and recompile it if you want the functionality of more than one extender's work. Best Regards, - Andy Riordan |
|
From: Swope, D. C. <Dav...@ci...> - 2007-05-10 13:34:07
|
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 |
|
From: Andy R. <and...@gm...> - 2007-05-06 23:39:55
|
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?
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.
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.
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.
What do you think?
On 5/3/07, Swope, David C. <Dav...@ci... > wrote:
>
> 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.
>
>
>
> Here is a suggestion of one way to handle entities:
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> What do you think of that idea?
>
>
>
> Best regards,
>
> David
> ------------------------------
>
> *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
>
>
>
> 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
>
>
>
> -------------------------------------------------------------------------
> 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
>
>
|
|
From: Swope, D. C. <Dav...@ci...> - 2007-05-03 19:24:32
|
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
|
|
From: Andy R. <and...@gm...> - 2007-05-03 18:10:01
|
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
>
>
|
|
From: Swope, D. C. <Dav...@ci...> - 2007-05-03 15:38:33
|
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...> 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
|
|
From: Swope, D. C. <Dav...@ci...> - 2007-05-03 12:49:18
|
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... 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 |
|
From: Andy R. <and...@gm...> - 2007-04-30 18:37:35
|
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 > > |
|
From: Swope, D. C. <Dav...@ci...> - 2007-04-30 13:46:25
|
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 |
