Hi, I just learnt about C# expression trees, never used them before. This week I implemented a trigger system based on reading file data and compiling them into runtime delegates and actions.
I think I am just using basic functionality:
var contextParameter = Expression.Parameter(typeof(TContext), "context");
var castedContext = Expression.Convert(contextParameter, contextType);
var parameterExpressions = new Expression[parameters.Length];
for (int i = 0; i < parameters.Length; i++)
{
var delegateInstance = Expression.Constant(parameters[i]);
var delegateEvaluateMethod = parameters[i].GetType().GetMethod("Evaluate");
var evaluateCall = Expression.Call(delegateInstance, delegateEvaluateMethod, castedContext);
parameterExpressions[i] = evaluateCall;
}
var methodCall = Expression.Call(castedContext, methodInfo, parameterExpressions);
var lambda = Expression.Lambda<Func<TContext, TResult>>(methodCall, contextParameter);
return lambda.Compile();
After fully implementing the system, it suddenly occurred to me that I should check for platform support, but the earliest discussions I found are from 2017/2018.
From what I understand, I am doing a JIT compile and this is only supported on Mono scripting backend. For mobile platforms, only IL2CPP scripting backend is supported so that means what I am doing here wonât work on mobile.
Is my understanding correct, and is there anyway I can workaround the limitation without tearing down everything I have done?
Or maybe Iâve come across this for a split second in context of Roslyn and runtime compilation.
Most likely correct, since iOS definitely and Android possibly maybe doesnât allow runtime code modification or compilation UNLESS the app absolutely requires it (ie a âlearn to codeâ app).
Yes, and look at that code: not at all basic.
If you want runtime reload or script execution, by all means use a scripting language. Lua-CSharp I can recommend. Especially if it comes to serialization - Lua tables are easy to write, and reading is simply âdostring(fileContents)â and you get a usable collection back.
The last thing you want to do is read data that compiles into code in order to represent data.
If you strictly separate code from data, what you get is trivial serialization and runtime data reload, while your code will be cleaner and easier to debug, too.
So basically what you did is to build a rocket that can fly into space, except you really only want to go to the mall. In other words: it smells like the wrong tool for the job, and the overengineering potential is immense.
afaik nothing from the Reflection.Emit namespace is usable in IL2CPP. Dont know about any workarounds other than re-designing what you are trying to achieve
Thanks for the confirmation on the issues with expression trees.
Sigh⌠luckily the rocket can be reduced to only a single method, albeit a bit bulky, that creates a Func<> delegate. I have replaced the internals with Delegate.CreateDelegate()
I am not familiar with Lua, it will be yet another thing to learn. For now, my trigger system is a matter of assembling events, conditions, actions and delegates â scripts maybe next time.
While this doesnât answer your question directly, you can always test it by building your project with IL2CPP scripting backend on Windows or macOS and running it. You donât need to deploy to a device to do that. If it works there, chances are the same scripting features will work on other platforms too (one exception being WebGL which is a bit more restrictive than most).
I get the feeling you may be trying to solve a problem the hard way because youâre not seeing (or not aware of) the obvious solution.
It kinda looks like you want to serialize callbacks (delegates). Which you could simply provide in your system, ie data says âraise event XYZâ and the code processing things simply invokes a preset event.
As to generic and multiple params that makes me suspicious. You can typically wrap multiple parameters into a single DTO (data transfer object), which you could make generic as needed.
What on earth are you doing that needs this kinda whackiness?!!!
All I see above is some kind of dialog system that perhaps sets some values at the end of it to trigger other things to happen in game. Dialog systems are never going to require wild whacky stuff like the above code, although I suppose they could be done that way.
Dialog system fundamentals and structure:
There are also some free packages you could start from:
Even if you donât end up using either of those, you could review them for structure because it is almost certain that they have already solved all the same problems you are trying to solve.
I currently have a context object which is like an event arg that is raised when some game event happens. And the context object defines the methods what are available to the event trigger system. I am serializing these methods and deserializing them.
[GameContext]
public class CEncounterStartedContext : CGameContext
{
public CEncounterStartedContext(ISceneControl control) { ... }
[TriggerCondition("Compare whether hero {0} {2} {1}")
public bool HeroComparison(Hero hero1, Hero hero2, ComparisionType compareType){ ... }
[TriggerAction("Move camera to {0}, with zoom {1} and rotation {2}")
public void MoveCamera(Vector3 position, float zoom, float rotation) { ... }
[TriggerDelegate("Get player heroes that are {0}")
public Hero[] GetPlayerHeroes(HeroStatusType statusType) { ... }
[TriggerDelegate("Get position of hero {0}")]
public Vector3 GetPositionOfHero(Hero hero) { ... }
}
Originally, Expression Trees provide type safety up front without funky generics. The deserialization of triggers happens once at start up, and then it runs fast in a tight update loop. But Delegate.CreateDelegate() canât do that at runtime, so this is what I end up.
I could make all methods take a single parameter DTO object and I will not need to deal with generics with unknown number of params. But that just means I complicate other parts of the system. e.g. I lose readability at compile time and the ability to apply the method description directly on method parameters which comes for free in this setup. You gain some, you lose some.
Just based on the trigger conditions and delegates, I see the âConditions and Actionsâ of a Statemachine transition. Hereâs a version I made.
It would likely look like the code in my blog post, and it would be serializable because the references arenât hardcoded but runtime lookup. Eg Hero becomes either a string heroName or int heroID. The other types are primitives that serialize easily. The methods themselves would be either conditions or actions in the statemachine.
Such an ID administration system or âregistryâ is highly recommended for many games, it simplifies working with references because there arenât any floating around - they are obtained and discarded, ideally never âheld on toâ by subsystems because they donât own that reference. And with IDs or names you also have clearly identifiable âsoft referencesâ that ease debugging because rather than ânullâ you can still report âHero âDumbledudeâ reference unexpectedly missingâ. This is invaluable and one of the strengths of data-driven designs.
In case you need an action to âquery somethingâ so that follow-up actions act upon it (ie all heroes which are in range) you can use nested actions, or a transition context object which gets filled by a preceding query action - basically the context object only needs a List and successive actions that perform something like âDamageâ would use that list, get any components as necessary (IDamageable) and do their thing where applicable.
I might be wrong but that system definitely has all the bells and whistles I associate with Statemachines, or as an extension of that: Behavior Trees.
Event system - triggers once when condition is met, a sequence of actions run once.
State machine - state is updated when event changes.
Behavior tree - while in a state, entity keeps polling the tree for the current behavior.
Sometimes state machine and behavior trees are intertwined, like a node in a state machine is the root of the tree, and a node in the tree is a state in the machine. But the event system is like an interrupt into that system.
The part I am focusing on right now is deserialization of actions/conditions/delegates in the trigger system. Itâs actually not that complicated. Once the reflection was set up, adding new serializable delegate is literally just writing a new class method with attributes. I get automatic context filtering, names and description for âfreeâ.
Agree with using primitives for references too. Thatâs what I am doing in the data layer, however, during bootstrapping, I convert them to runtime object reference once, hence the context method I showed all use object references.
On hindsight, definitely there are areas I could have done better. Itâs always horrible code when we look back 1 year later.
The problem with this forum is people post a question with a few line of codes and some other people start to assume things and want to improve things they donât even know the full context about.
It looks like you found a working solution, so there is no point to rewrite your whole system, just because some random commenters would have designed it different. You can try a different approach for your next project (if you want to), but if you change your working system now, then you will maybe get burnt out and not finish the project at all, so itâs better to continue with the âhorrible codeâ that is working.
These days code emittance is a bit of an outdated tool. It still has some great uses but the most common on Iâve ever found for games is to generate code at runtime that would otherwise require reflection. With generators being a thing now though, like I said, emittance is a bit outdated.
Itâs also not necessarily supported on all platforms. Likely youâll find anything that enforces AoT to not allow it since, by definition, it canât be compiled ahead of time. IOS and likely Android in the near future (if not already, I dunno. I donât keep up with mobile anymore) donât like anything that isnât AoT. On desktop, Windows is likely to work fine for the near future. I canât speak for MacOS or Linux but I imagine Linux would work fine and probably allows users to configure to their preference of support for JIT vs AoT. As for MacOS, canât say there either but Iâd be slightly surprised if it did work.
Overall, itâs a really cool tool thatâs been partially superseded with newer technology and it seems much of the industry is shying away from JIT these days due to security concerns. Code emittance is one step beyond JIT so is even more precarious.
