This project is read-only.

Patch 806 - scripting

Feb 6, 2008 at 2:01 AM
Just because I didn't have anything else to do I went ahead and created a simple scripting system. The script files are placed in mods/sample in the sample game. There are amny issues, but lets start a discussion on how this should look and feel like. This also give a starting point for the editor.

Script files contains 2 files a .cs and a .designer.cs, we will autogenerate the latter and the user is only supposed to edit the .cs file. currently only update is supported, but more will come, tell me what you think.
Feb 6, 2008 at 2:49 AM
Very interesting. Few notes:

  • What's the purpose of the designer.cs file, just hiding the "behind-the-scenes" code?
  • Run-time compilation is all well and good, but we can't do it on Xbox. :) We will need to have the option of building a script assembly upon deployment. (MSBuild task?)
  • Some sort of update timer may be nice. Let each script specify an update time: every-frame, every 100 ms, every 3 minutes, etc.

We also need to decide how to handle assets. If a script is bound to an entity, where is the model/material information stored? In the script (.designer.cs maybe) or a separate XML data file?
Feb 6, 2008 at 6:30 AM
Edited Feb 6, 2008 at 6:31 AM

shawmishrak wrote:
  • What's the purpose of the designer.cs file, just hiding the "behind-the-scenes" code?


Exactly, currently it hides the constructor from the user so he doesn't have to think about QSGame being passed. I envision it something like the designer.cs used by visual studio.


shawmishrak wrote:
  • Run-time compilation is all well and good, but we can't do it on Xbox. :) We will need to have the option of building a script assembly upon deployment. (MSBuild task?)


Yes, we need a complie task which simply takes all the scripts and turn them into one assembly which can be deployed along with the game. This assembly can also be used on the windows platform so that customers can do obfuscation on the script in order to protect the game.


shawmishrak wrote:
  • Some sort of update timer may be nice. Let each script specify an update time: every-frame, every 100 ms, every 3 minutes, etc.


Yes from a perf perskective this would be good. But I don't think that we should solve it like that. If you need a timer thingy, you should just attach a timer entity on the entity and do the code there. Similar to how you would do it using WinForms development.


shawmishrak wrote:
We also need to decide how to handle assets. If a script is bound to an entity, where is the model/material information stored? In the script (.designer.cs maybe) or a separate XML data file?


That is the main question, the way I envision the developer experience is: (I'm going to assume that the editor has an layout similar to VS)
  • The Game Developer adds a explosive barrel on the screen
  • The Game Developer sets the properties on the barrel using the propery sheet on the right (Giving it the name: ExplosiveBarrel)
  • The Game Developer selects the "Events" tab in the property sheet
  • The Game Developer scrolls through the list of events and finds the "Collide" event
  • The Game Developer dblclicks on the field to the right of name
    • The editor now autumatically creates the script files needed
    • The editor adds an eventhandler to the designer.cs file
    • The editor adds a method prototype to the .cs file called ExplosiveBarrel_Collide
    • The editor opens the file and places the cursor on the first line inside the method
  • The Game Developer now adds the code needed for the barrel explosion.

That's a scenario I would like to see use being able to cover. Though that does imply a few things. Somehow the script and the entities are bound together. Somehow the editor knows which properties are available for all entities, also custom entities will be displayed properly. There should properly be different collide events, as you would want to have to constantly filter collision events with the terrain.

I'm leaning much towards the design experience in VS. This is because most will be familiar with VS and WinForms development, and there are many resources on that topic for new entry level developers.
Feb 15, 2008 at 6:13 AM
I've downloaded the newest source and applied the script patch, whenever I try and compile the project I get an error:
Error 7 The name 'QSActivator' does not exist in the current context ..\framework\code\Common\Configutation\ConfigurationManager.cs 157

Are we missing a file? Or did I somehow screw something up?
Feb 15, 2008 at 6:24 AM
The scripting system doesn't work on the newest source, it requires 9387 (As stated)