Skip to main content
Game Development

Return to Answer

replaced http://gamedev.stackexchange.com/ with https://gamedev.stackexchange.com/
Source Link

A corollary of FxIII's answer FxIII's answer is that you should design everything (that would be moddable) in the scripting language first (or at least a very decent portion of it) to ensure that your integration logic actually provisions for modding. When you are certain that your scripting integration is versatile enough rewrite the required bits in C#.

A corollary of FxIII's answer is that you should design everything (that would be moddable) in the scripting language first (or at least a very decent portion of it) to ensure that your integration logic actually provisions for modding. When you are certain that your scripting integration is versatile enough rewrite the required bits in C#.

A corollary of FxIII's answer is that you should design everything (that would be moddable) in the scripting language first (or at least a very decent portion of it) to ensure that your integration logic actually provisions for modding. When you are certain that your scripting integration is versatile enough rewrite the required bits in C#.

Source Link

A corollary of FxIII's answer is that you should design everything (that would be moddable) in the scripting language first (or at least a very decent portion of it) to ensure that your integration logic actually provisions for modding. When you are certain that your scripting integration is versatile enough rewrite the required bits in C#.

I personally hate the dynamic feature in C# 4.0 (I am a static language junkie) - but this is without doubt a scenario where it should be used and is where it really shines. Your C# components would be simply be strong/expando behaviorial objects.

public class Villian : ExpandoComponent
{
 public void Sound() { Console.WriteLine("Cackle!"); }
}
//...
dynamic villian = new Villian();
villian.Position = new Vector2(10, 10); // Add a property.
villian.Sound(); // Use a method that was defined in a strong context.

Your Lua components would be completely dynamic (the very same article above should give you an idea of how to implement this). For example:

// LuaSharp is my weapon of choice.
public class LuaObject : DynamicObject
{
 private LuaTable _table;
 public LuaObject(LuaTable table)
 {
 _table = table;
 }
 public override bool TryInvokeMember(InvokeMemberBinder binder, object[] args, out object result)
 {
 var methodName = binder.Name;
 var function = (LuaFunction)_table[methodName];
 if (function == null)
 {
 return base.TryInvokeMember(binder, args, out result);
 }
 else
 {
 var resultArray = function.Call(args);
 if (resultArray == null)
 result = null;
 else if (resultArray.Length == 1)
 result = resultArray[0];
 else
 result = resultArray;
 return true;
 }
 }
 // Other methods for properties etc.
}

Now because you are using dynamic you can use Lua objects as though they were real classes in C#.

dynamic cSharpVillian = new Villian();
dynamic luaVillian = new LuaObject(_script["teh", "villian"]);
cSharpVillian.Sound();
luaVillian.Sound(); // This will call into the Lua function.
default

AltStyle によって変換されたページ (->オリジナル) /