arthurprs, czar

Welcome

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.