Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I have a multiplayer game written in C# and we've recently been creating a lot of content but have been looking for a way to give our entities customization logic that the designers can hook into. I took a look at this post. With something like this in mind (using C# as a scripting language); I have a few questions.

1) Would one embed the script itself in the entity object before persisting to it to the disk? Is this okay?

2) Would I compile once per scripting then - this seems like a lot of overhead to store all these compiled Assemblies to execute.

Any general advice on how to do thigns is welcome, too. These entities are generated on the fly inside the editor and could be composed of a lot of different things.

share|improve this question
add comment

1 Answer

up vote 6 down vote accepted
+25

1) Would one embed the script itself in the entity object before persisting to it to the disk? Is this okay?

You'll get cleaner diffs in your version control and encourage reusable scripts by providing the actual script out-of-line and having the entity merely store, say, a filename and script parameters. Storing the script in the entity itself is viable however.

2) Would I compile once per scripting then - this seems like a lot of overhead to store all these compiled Assemblies to execute.

You're looking at a handful of kilobytes on disk per assembly if they're small, and I'd imagine a similarly small runtime overhead. While there are possible scaling concerns (loading 1000s of scripts may have some inefficiencies) you can always start to batch up assemblies at a later date if (not when) you encounter problems. An assembly per script is a simple enough starting point, and as long as you avoid tying large swaths of your codebase to an assumption that will always be the case, you should be fine (just centralize the actual loading of assemblies and extraction of types in one place instead of doing it ad-hoc.)

A bigger concern is if you want to let scripts interact with each other directly 1000 scripts all referencing each other is a PITA to untangle even without circular references: in that case you might prefer to compile, say, on a per-level basis (or just have a single global scripting assembly.) Of course, that might be trending towards putting too much logic in scripts that belongs at a more core engine level.

share|improve this answer
1  
If I understand right, you want to compile those addins/script ect. you can use the .Net enviroment to make a script language out of it. You can take a look at this: csscript.net or use .Net to create your own. –  Techie Dec 15 '12 at 8:13
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.