If you’ve used Glue much then you know it makes heavy use of code generation. Many programmers have asked me, “Why use code generation? Why not create a higher-level .dll that can load the GLUX xml file and do the same thing that the generated code does?”
The reason this question is hard to answer is because the generated code doesn’t have one single big benefit, but rather lots and lots of smaller benefits which add up and result in a huge boost in developer productivity. But, I suppose we should at least start from the beginning.
Perhaps the first thought which drove me to code generation is the idea that as more functionality is added to an API, usually the number of things that you need to learn to take advantage of the API increases. That is, if you double the number of classes or functions or properties, then (all things equal) the user must learn more about the API to use it.
This means that even though an expanding API has the potential to make its user more efficient, it often requires more up-front learning to get there. So of course, the question is – can an API expand, improving the productivity of its user, while *reducing* how much the user has to learn?
To use Glue as an example, I could have added a .glux loading API to allow for .glux files to be loaded alongside custom code. Details aside, this would work, and would expand the options available to FRB users, but it would also expand the necessary API and would require FRB users to learn yet one more thing to effectively use FRB. Even in its simplest case you’d have to learn:
1. The line of code (if it is only one line of code) necessary to load the .glux. Such as GluxManager.Load(“MyProjectName.glux”);
2. Where to put this code. Does it go in Game1.Initialize? Before or after FRB initialization?
3. Maintaining this call. It may get lost or shifted around. there would be nothing at compile time forcing this call to be in its proper location, and if some junior programmer, designer, or a bad version control merge screwed this line up, you may not realize it – your code may just crash or not render anything!
4. You may have to learn to program in the first place. Sure, 1 line of code in the right place may seem trivial if you’re a seasoned programmer experience with an API. Not so easy if you barely know how to do a little C#, or if you’re an artist who is trying to make a game and you don’t know how (and don’t want to learn how) to program.
That last point is a big one that I’d like to emphasize – the presence of one single line of code can eliminate a huge potential audience. We’re still not in a possible code-free environment yet, and it bothers me because the requirement of C# in FlatRedBall means a large group of developers will instead steer towards GameMaker, Construct 2, or Multimedia Fusion 2.
Of course you may be thinking to yourself “But you still have to learn how to navigate and use the UI of Glue!” While that’s true, I see the potential of reaching a low-code or 0-code setup for some simpler games, and in that case, the knowledge of using Glue isn’t an extra thing you must learn, it’s a replacement of needing to learn how to interface with the FRB API in code…and a replacement of needing to learn C# in the first place.
I’m definitely skipping over a lot of details in this article, and what I’ve written about isn’t the end of the code generation discussion – there’s a lot of details, benefits, and costs associated with it. For those interested, I hope to continue this discussion in future blog posts, and of course we can talk about it more in the chat room too.