I'm working with C#, as noted by the prefix.

I've got a game server project with some scripting class interfaces in one project and some 'scripts' which inherit from this, over-riding some hooks that the game engine invokes on the base class when required.

My issue comes into parsing these scripts. Since the script project references the game server, the server cannot reference the script project (circular reference.) Since I can't load the assembly in with reflection (easily?) that I can think of, how else can I parse this scripts project and get them inside my game? I guess I could load the assembly somehow but that's got to be bad considering the circular reference window.

I'm doing the scripts as a project with a reference to get IntelliSense while developing them.

I'm open to changing the way they're created and imported. How is this usually done?

The circular reference is only bad at build time. You can just make it so the game server project doesn't directly reference the script project, but can still load it using reflection. There's no problem once it's loaded.

Here's what I've done in the past:

- In your game server project, define an interface or base class which something in your script project derives from. The interface should at least contain a "Initialize" method of some kind. The function can be static or an instance, whichever you want. You can add other methods as necessary. Think of this as the "Main" function for your script. You can use attributes as well, if you want.

- Set your script project to reference your game server project.

- Make sure your project configuration settings are set so that the script project is always built and copied to the game server project's output folder.

- When your game server runs, it can find all script projects by looking in its working folder for .DLLs. It can then load those using Assembly.LoadFile. LoadFile returns an Assembly object; you can search this assembly for type(s) which inherit from your interface/base class, instantiate them (if necessary) and then call the Initialize method using reflection.

- When your script's Initialize function is called, it can start calling methods in the game server project like normal, which will let you do anything you need to from that point on.

The circular reference is only bad at build time. You can just make it so the game server project doesn't directly reference the script project, but can still load it using reflection. There's no problem once it's loaded.

Here's what I've done in the past:

- In your game server project, define an interface or base class which something in your script project derives from. The interface should at least contain a "Initialize" method of some kind. The function can be static or an instance, whichever you want. You can add other methods as necessary. Think of this as the "Main" function for your script. You can use attributes as well, if you want.

- Set your script project to reference your game server project.

- Make sure your project configuration settings are set so that the script project is always built and copied to the game server project's output folder.

- When your game server runs, it can find all script projects by looking in its working folder for .DLLs. It can then load those using Assembly.LoadFile. LoadFile returns an Assembly object; you can search this assembly for type(s) which inherit from your interface/base class, instantiate them (if necessary) and then call the Initialize method using reflection.

- When your script's Initialize function is called, it can start calling methods in the game server project like normal, which will let you do anything you need to from that point on.

Thanks! If the circular reference thing is indeed true, that puts me at ease. I'll make sure it copies to a \Scrips\ folder and have it search there for assemblies to load. That sounds optimal. Right now, I'm thinking of passing stuff in via the constructor (for a skill script, the skill object it will be working with).

What is the rationale for a dediciated init function and what might it contain?

Thanks!

What is the rationale for a dediciated init function and what might it contain?

My rationale is that it's a hassle (and inefficient) to call functions via reflection, but you have to use reflection at least once to run code in the script project, since the main project can't reference it directly. So I make a single function that I call with reflection, and have that function do the bulk of the work of "connecting" the script project to the main project. From that point on, the code can call functions "normally" to call functions in the script project.

The ways that I "connect" the script project to the main project at runtime are:

- The script project can register itself with public events in the main project. When those events get raised, the script project can handle them.
- The script project can instantiate classes and then register those classes with the main project. This might mean creating some derived factory classes, "manager" objects, "game objects", or whatever else you might think of.
- The script project can add itself to a list of objects that get called during the main update loop (this is implied in the previous line).

What is the rationale for a dediciated init function and what might it contain?

My rationale is that it's a hassle (and inefficient) to call functions via reflection, but you have to use reflection at least once to run code in the script project, since the main project can't reference it directly. So I make a single function that I call with reflection, and have that function do the bulk of the work of "connecting" the script project to the main project. From that point on, the code can call functions "normally" to call functions in the script project.

The ways that I "connect" the script project to the main project at runtime are:

- The script project can register itself with public events in the main project. When those events get raised, the script project can handle them.
- The script project can instantiate classes and then register those classes with the main project. This might mean creating some derived factory classes, "manager" objects, "game objects", or whatever else you might think of.
- The script project can add itself to a list of objects that get called during the main update loop (this is implied in the previous line).

Thanks. I'll give it a whirl tonight, sounds like it should be fairly smooth. My architecture only needs a few hooks for now -- but this will come in handy as required!

What is the rationale for a dediciated init function and what might it contain?

My rationale is that it's a hassle (and inefficient) to call functions via reflection, but you have to use reflection at least once to run code in the script project, since the main project can't reference it directly. So I make a single function that I call with reflection, and have that function do the bulk of the work of "connecting" the script project to the main project. From that point on, the code can call functions "normally" to call functions in the script project.

The ways that I "connect" the script project to the main project at runtime are:

- The script project can register itself with public events in the main project. When those events get raised, the script project can handle them.
- The script project can instantiate classes and then register those classes with the main project. This might mean creating some derived factory classes, "manager" objects, "game objects", or whatever else you might think of.
- The script project can add itself to a list of objects that get called during the main update loop (this is implied in the previous line).

Just checking in to let you know everything worked out, thanks a lot!

You're welcome! Glad it worked out for you!