RE: embedding scripting into a program: a few questions
- From: "Ken Perry" <whistler@xxxxxxxxxxxxx>
- To: <programmingblind@xxxxxxxxxxxxx>
- Date: Mon, 8 Mar 2010 00:18:06 -0500
There are a few ways to do it here is one:
https://www.vmware.com/
If you want to use boost though this is how I would do it:
http://members.gamedev.net/sicrane/articles/EmbeddingPythonPart1.html
Ken
-----Original Message-----
From: programmingblind-bounce@xxxxxxxxxxxxx
[mailto:programmingblind-bounce@xxxxxxxxxxxxx] On Behalf Of Tyler
Littlefield
Sent: Sunday, March 07, 2010 11:07 PM
To: programmingblind@xxxxxxxxxxxxx
Subject: Re: embedding scripting into a program: a few questions
Hello ken,
From what I've seen of the boost docs, the python setup is used for creating
add-ons to python. Can I reverse that, or does it have more functionality
beyond creating c++ libraries for python's use. I would love to use that, as
I know python the best out of most languages, I just moved away because of
the API for python; it seemed to have quite a few qwerks.
Thanks,
Tyler Littlefield
http://tds-solutions.net
Twitter: sorressean
On Mar 7, 2010, at 8:39 PM, Ken Perry wrote:
>
> Tylor as you know on our mud we wrote our own compiled language using
bison
> and flex. I do not recommend that to anyone who has half a brain any
more.
> It's hard to up keep and even though our language resembles a combination
of
> c++, basic and Pascal it is none of the above. We have to write all the
> docs which makes the job twice as hard to up keep and we have to debug
each
> little problem.
>
> Now with all that said I would use one of two languages either Python or
> Java script which can both be embedded quite easy. I like LUA but there
are
> not a lot of documents so you would still have to write specialized
> documents to fit your environment. Python on the other hand is a great
> language to embed because there are so many coders who already know it and
> the documents are amazing. Java script is the same way but it is a bit
> harder to embed. You can have python in your game in seconds just buy
> adding the right libraries from boost and then building on them.
>
> So I guess in short the most important things you have to think of when
> adding scripting are as follows.
>
> 1) how easy is it to bridge the gap from c++ to scripting language
> 2) How easy will it be for your builders to use and learn which means
> documentation you will have to support
> 3) What happens when the scripting language out there changes like python
> going from 2.6 to 3.1 do they have upgrade scripts like Python does.
> 4) What is the memory over head and speed of interpretation. We have over
> 28,000 scripts on our current game and while that don't sound like much
many
> of those are scripts that hang around waiting on events so you need to
know
> that you have a way to deal with that like an event que of some kind. We
> dealt with it by pretty much making our game server an OS and the scripts
a
> compiled binary but in the days of jvm's there are better ways to deal
with
> it.
>
> Ken
>
>
>
> -----Original Message-----
> From: programmingblind-bounce@xxxxxxxxxxxxx
> [mailto:programmingblind-bounce@xxxxxxxxxxxxx] On Behalf Of Tyler
> Littlefield
> Sent: Sunday, March 07, 2010 9:38 PM
> To: programmingblind@xxxxxxxxxxxxx
> Subject: Re: embedding scripting into a program:a few questions
>
> Hello,
> Bevire I switched to angelscript, I was bouncing around the idea of Lua.
>> From what I read, it doesn't support inheritance or classes, so I'm not
> quite sure how I'd embed an OO setup like I want into a functional setup
and
> get the same sort of layout or design I'm working toward.
>
> Thanks,
> Tyler Littlefield
> http://tds-solutions.net
> Twitter: sorressean
>
> On Mar 7, 2010, at 7:32 PM, Andreas Stefik wrote:
>
>> Tyler,
>>
>> This is just a thought, and you can discount it if you wish, but are you
> familiar with the programming language LUA? LUA is a scripting language
used
> all the time in commercial video games (e.g., world of warcraft). The
reason
> it is used is because they have a fancy way of binding between C++ and the
> LUA scripts, which makes doing this kind of interface relatively
> straightforward.
>>
>> I'm hardly an expert on the details, but if it were me digging around in
> this area, I might consider using LUA scripts and basically using its
> internal system of binding between C++ and the scripts.
>>
>> Stefik
>>
>> On Sun, Mar 7, 2010 at 8:29 PM, Tyler Littlefield <tyler@xxxxxxxxxxxxx>
> wrote:
>> Hello Laura,
>> The idea is that the world class be able to be exposed to the language--I
> don't need to add methods to the world class. What I do need to do, and
what
> seems to be causing the issue is the component setup; All components will
be
> loaded at startup and as they're added, but I need to be able to inherit
the
> c++ component class and add to it in order to create scripted components,
> then I can just register them with the world class.
>> The issue is making the scripted components be usable. Obviously I can't
> access a scripted component from c++, or I could through it's basic
> functionality, but the idea is for the components to be able to be added
to
> any object whether scripted or not.
>>
>> Thanks,
>> Tyler Littlefield
>> http://tds-solutions.net
>> Twitter: sorressean
>>
>> On Mar 7, 2010, at 7:23 PM, qubit wrote:
>>
>>> Hi Ty --
>>> Did I read once that your base is implemented in C++?
>>> Let me clarify what you are saying you want to do:
>>> 1. class A in your scripting language needs to interface with class
> World in
>>> your base, and use its methods, and also to add methods of its own, and
> to
>>> do this dynamically. Right?
>>> 2. These new methods need to access class World in some way. Do they
> need
>>> to go so far as to touch private or protected data? Since you want
> dynamic
>>> insertion/removal of methods in class A, these methods will need to be
> able
>>> to work with World without being members of World.
>>> 3. As an aside, you could of course dynamically create a new inherited
> class
>>> C for each method m(), which is derived from World and therefore can use
>>> World's protected and public data. m() can be a virtual or nonvirtual
>>> method. But this all has to be done in the interface to your scripting
>>> language. This is an interesting problem, as it almost requires that
> the
>>> scripting language have the same inheritance structure as C++ to make
> the
>>> implementation fall out cleanly. But who ever heard of a clean
>>> implementation in the "real world"...*smile*
>>> Now, if your implementation goes so far as to create derived classes
> with
>>> their own virtual table for each function added to A, you will need some
>>> dynamic linking to pull it off.
>>> I'll have to think on this one for a while.
>>>
>>> Hey Ty, great job picking an interesting project. That should go really
>>> well on a resumé.
>>> Happy hacking.
>>> --le
>>>
>>> ----- Original Message -----
>>> From: "Tyler Littlefield" <tyler@xxxxxxxxxxxxx>
>>> To: <programmingblind@xxxxxxxxxxxxx>
>>> Sent: Sunday, March 07, 2010 6:12 PM
>>> Subject: embedding scripting into a program:a few questions
>>>
>>>
>>> Hello all,
>>> As some of you may know, I'm working on a custom mud base that I will be
>>> releasing to the public and probably using for my own mud in the near
>>> future.
>>> I've got most of the stuff I want handled, except scripting; I was told
> to
>>> use Angelscript and was taking a look at it, but it seems to not be to
> well
>>> documented, so maybe someone has another idea.
>>>
>>> What I want, is to be able to make the world class (which stores a list
> of
>>> players, rooms, mobs, etc) accessible to the scripting language I use.
>>> Secondly, I want to expose events so that the language can attach it's
> own
>>> functions to them.
>>> Third and possibly more dificult, I want to expose my component system,
>>> which I will explain.
>>>
>>> Rather than using a is-a setup (through inheritance), I decided to go
> with a
>>> has-a setup. This provides some really cool ideas for design, such as
> being
>>> able to let clothing use containers if you decide that your shorts need
>>> pockets, without either moving container functionality up the
> inheritance,
>>> or using a multiple-inheritance setup, which can become messy. So, the
>>> components get loaded with the object from a list. I can easily use an
>>> AddComponent function to add the component to the list, but I'd like to
>>> allow builders and coders that I don't want using shell or that have an
> idea
>>> for a component to be able to build one in the language of choice, then
>>> register it with the dictionary that is used for holding components and
>>> allowing other objects to use this setup. So, in short I need a sort of
>>> transparent way to communicate back and forth, and not for the scripting
>>> language of choice to just control the driver, etc.
>>>
>>> Thanks,
>>> Tyler Littlefield
>>> http://tds-solutions.net
>>> Twitter: sorressean
>>>
>>> __________
>>> View the list's information and change your settings at
>>> //www.freelists.org/list/programmingblind
>>>
>>> __________
>>> View the list's information and change your settings at
>>> //www.freelists.org/list/programmingblind
>>
>> __________
>> View the list's information and change your settings at
>> //www.freelists.org/list/programmingblind
>>
>>
>
> __________
> View the list's information and change your settings at
> //www.freelists.org/list/programmingblind
>
>
> __________
> View the list's information and change your settings at
> //www.freelists.org/list/programmingblind
__________
View the list's information and change your settings at
//www.freelists.org/list/programmingblind
__________
View the list's information and change your settings at
//www.freelists.org/list/programmingblind
Other related posts:
