View Full Version : PyroGine Script Editor

23-06-2008, 10:23 PM
I'm currently working on a light-weight script editor that will be in the next release of PGSDK. It's currently in early beta at the moment and I would like to see if/how it works on different configurations. You can download it here (http://pyroginegames.com/downloads/pgse_beta.zip).

* Syntax compatible with Delphi 7
* Project configuration in the source code. See Scroll.pas and PolyPoint.pas
* You can set the ExeName, ExeType (GUI, CONSOLE), SearchPath, ExeIcon and version information.
* You can generate stand-alone EXEs
* The editor will launch the command-line compiler to compile the source code and capture the output back to the editor.
* Edit multiple source files (limited only by memory)
* Build source files for syntax check only or build and run the generated EXE.
* Clicking on a line in the error tab takes you to that line in the source file
* The scripting engine, PyroScript is based on a modified version of paxCompiler.
* PyroScript is on average about 3-4 times slower than Delphi generated code
* PyroScript allows you to easily bind to your own native routine and classes (requires PGSDK)
* In script you can dynamically bind external routines in DLLs for extension
* You have access to nearly all the features of PGSDK
* Much more

* Download and unzip
* Start the editor by clicking on PGSE.exe
* There are some test scripts in the [scripts] folder
* Scripts in [scripts/delphi] shows how it handles the Delphi syntax
* Scripts in [scripts/pgsdk] shows how it handles accessing the PGSDK

* The edit menu options do not work yet
* The Save As menu option does not work yet
* There is lots of work yet to do feature wise as it's still in beta


23-06-2008, 11:02 PM
No disrespect intended but...

What would you use this for? What solution does it provide?

Are there any examples/projects where a scripting engine is used, I don't think I fully understand what scripting engines are for and what they achieve that can't be done in compiled delphi.

Once again this is not a knock against your project it is just I would like to know how I can use this in my own projects.

24-06-2008, 01:44 AM

No worries, this is a good and valid question:

* Let say you want to provide MOD'ing support for your project or even make it easy for you to update it yourself. You can expose enough to the scripting engine to make this process easy. If you have good interop between native and script, which PyroScript does, this becomes very easy to do.

* Unreal uses Unreal Script, the first versions of Quake used QuakeC and Quake3 used an updated scripting solution (I think). There are many commercial game projects that use Lua for scripting. Duke Nukem 3D (http://en.wikipedia.org/wiki/Duke_Nukem_3D) had a scripting system. The Cipher (http://www.cipherengine.com/articles/ciphervm.php) game engine.

* Since most scripting system runs in a sandbox environment there is a layer of security that you now have. This can work to your advantage such as helping to minimize cheating in a networked type game.

* You game logic and configuration can be in script, which then can be updated easily without recompiling.

* If you do not have access to Delphi or you wish to use a light weight development system for proof-of-concept or prototyping.

* PyroScript is really not scripting in the normal sense because it's actually compiled code (not byte code but native machine code). But because you easily interop just like a good scripting system I still refer to it as such. It's powerful enough to interop with your native project or stand alone.

* Lua is great, it's light weight, fast and popular, but my preference is to use the same language that I use every day. What's nice is that in the future more language will be added (java script, basic and C) and they will work together.

* Back in the day, a company called Rebel Boat Rocker (http://en.wikipedia.org/wiki/Rebel_Boat_Rocker) was using Java Script as there scripting solution.

* Lets say you have your engine ready in native code and your working on a game project. You want to be able to easily update things yourself in addition to making modifications. A Delphi or FPC (sure it's free, but still) installation and configuration can be a chore. With the scripting system in place, you can hand this off to other members of your team to code the logic or maybe the GUI front end without having to touch the native stuff. You can simply hook into your complex native code with the sandbox scripting system. Someone looking to MOD your game can just fire up the script editor or your game editor tool and make great MODs.

* We plan to use all that I've mentioned (and more) in our game projects moving forward.

* It's all about flexibility and expanding possibilities. If you Google (http://www.google.com/search?num=100&hl=en&newwindow=1&safe=off&client=firefox-a&rls=org.mozilla%3Aen-US%3Aofficial&q=who+uses+a+scripting+system+in+games&btnG=Search) you can see scripting is being used a lot and the different ways it can benefit your project.

24-06-2008, 02:28 AM
Thanks for the good explanation.

I will have a think how I may be able to apply it o my own projects in teh future.

24-06-2008, 02:32 AM
Thanks for the good explanation.

I will have a think how I may be able to apply it o my own projects in teh future.

same here,

on the past i tried to make a game using python + delphi,

delphi exports my engine to python, and the game itself is all written in python,

its nice to know other ways to use these scripting languages

24-06-2008, 03:33 AM
arthurprs, czar


Yes do consider how it can benefit your project. Having a good scripting system just opens up a great deal for you IF you plan things properly. You can think of it the same way as using an editor tool to make levels (UnrealED, QRadient for example). Ideally the goal is to eventually have a editor tool that will allow you to make different types of games with PGSDK, such as platformers and scrollers, adventure and more. The one development environment will give you the tools needed to assist in making these and other types of games.

I plan to take the same route as arthurprs and code the bulk of the game in PyroScript. The game engine is a native ECOM DLL. This made is very easy to expose 99% of PGSDK to the scripting system. Understand too that you can extend the native classes on the script side just as you would do in Delphi for example. The PolyPoint demo is an example of this. I'm extending a TPyroEntity class and dropping this on a native TPyroActorList that is exposed in script. What's happening here is that a script class, extended from a native class is being managed by a native class that is exposed to the scripting system. See what I mean by very great interop? Sweet man, sweet.

Let say you wanted to compile your script code to a stand alone EXE, but needed to expose your own native routines. You would just need create a console app, create an instance of your extended TPyroScript class, register your native routines and classes and then call TPyroScript.RunOrCompile, free the script instance and exit. What will happen when you run this exe is that it will register, load and compile your script and generate an new EXE that will simply run without the sources.

Or maybe you wish to keep it on the native side and expose logic in script. In this case, you would register your game routines and classes with the scripting system. At startup you you can create an instance of the script object and get the address of say the OnUpdate and OnRender methods. Now when your native code needs to update or render items, then simply call into script OnUpdate and OnRender. If you need to make a change to the logic in OnUpdate, just do it and on the next run, the change will be reflected without having to recompile your whole project. Do you see how this can be used to make modifications and expansion packs for your games. Since PyroScript is compiled machine code, speed will not be an issue like it may be for other scripting solutions.

The possibilities become boundless.