next »

[SouldomainTM]

I'm making a custom game engine with F# for my game. I have some experience with UE4/Unity and even Xenko. I played around with the Windows Presentation Foundation, and found the idea of type providers interesting.

So, I was wondering. Whether I could, or should use type providers, too?! I figure, that with type providers I could remove the need of referencing objects within the editor. And keep this "programming" more to the actual programmers. Entities in the scene, that are given a name, would get automatically type provided.

It would be good if there was an engine that does this. So, I could see for myself whether that is even a good idea.

[JWki]

I tried looking up type providers and I can't make sense of it, can you try and explain what they are and what use you see for them in a game engine?

[oahda]

I don't understand what you mean either, sorry. :c

[SouldomainTM]

To my understanding. Type providers generate code. And because there is code, you can access new data, or types that the provider provided, from your source. But while you edit that source in the IDE. So this is dev-time not run-time. The providers runs along the IDE, and the compiler's IntelliSense.

I think these types can also be viewed as bindings, like those of an API. That provide bindings for a managed language from a native API. These bindings don't program any new features, they just give you access.

If I recall, I have seen Xenko using type providers, too, for its shaders. I can access the public variables of a shader program from C#, without having to write first, any extra code to retrieve the variable via the graphics sub engine. But don't quote me on this.

I think eventually, Xenko also will provide types for its GUI, just like WPF. Currently you have manually to retrieve the GUI elements in Xenko. Because unlike Unity, Xenko doesn't store the individual GUI elements inside game objects. So, you can't just access some public reference inside a MonoBehaviour. Neither does UE4, by the way. You can only access the entire GUI hierarchy in Xenko.

I haven't studied UE4's architecture closer yet. But I'm intending to follow more the UE4 model of handling scene objects, so Actors from source code. Instead of Unity/Xenko's way that seem to be too much one the editor side for code related stuff. I suspect that there are plenty of type providers inside UE4, for its BluePrint system. Otherwise BP couldn't access many aspects of the engine and assets. At least not without a ton of extra nodes, which would defeat the purpose of BPs.

[BorisTheBrave]

It sounds like a promising idea to me. Lots of engines have represent different types of game objects with different run-time types, and lots of engines encourage as much stuff to be data driven as possible. But no engines marry the two, as without type providers, it's not possible to have run time types that are configured by data, not code.

[JWki]

UE4 uses reflection to drive blueprints - tbh I still don't really understand what type providers are supposed to be, it sounds like it could be some sort of reflection as well...?

[SouldomainTM]

UE4 uses reflection to drive blueprints - tbh I still don't really understand what type providers are supposed to be, it sounds like it could be some sort of reflection as well...?

Reflection works only during run-time. Type providers work during dev-time, generating source code. I think it may work via the compiler itself. At least in C#/F#.

Here is an example from WPF. I created a window and added a TextBlock element:


The editor created a XAML file:


Now, I can access that GUI element with its name texBlock:


But how is this possible? Because I never defined any textBlock class inside my C# code. It's because of this code that was generated by the type provider:


Note that this file, this partial class, is not visible inside my project files. But you will fined the definition of textbox in there. And any other element, like the button class for the Button element, that I also added to the editor earlier.

This is how I consider doing things inside my engine. But with the scene files, and assets. And with Yaml instead of XAML.

[JWki]

Ohhhh okay - it's a fancy term for code generation then. I actually thought about doing that for some things before. I know that some in house engines use it to generate shader constant buffer structs.

[SouldomainTM]

Maybe a reason why it's called type provider, and not code generator, is because it never makes the source files visible inside an IDE. And seems with F#, it more of an actual language feature. While in C#, it's more of I tool, I read.

[InfiniteStateMachine]

Type providers are not a feature I've used a lot in F#.

The main type provider I typically see is the SQL type provider and from what I can tell, the difference is there is no code generation unlike an ORM for C#. It seems that at the top of the file you simply attach to the database and request the context then you can see the types. So it might be that visual studio simply scans the database and then shows you what's available through intellisense.

That's kind of cool that it doesnt do code generation because one of the annoying things about entity framework for c# is keeping your code model in sync with your database model. If it's fully dynamic like the type provider in f# you remove a huge layer of complexity and maintenance.

https://docs.microsoft.com/en-us/dotnet/fsharp/tutorials/type-providers/accessing-a-sql-database

[oahda]

Now that I understand, this is actually quite interesting!