Gum integration in Glue is here!

So what is this Gum thing anyway? Gum is an open-source visual layout tool for game UI. It’s been in development off and on for a number of years, but it’s finally gotten to a state where I think it’s ready to be used with Glue.

Over the past few weeks I’ve been writing a new Glue plugin that lets you add Gum projects with no code. Today I’m very excited to announce the first release of this plugin along with a set of tutorials to walk you through the integration process.

You can find the tutorials here:

Keep an eye on this technology – I think it’s going to become one of the staple technologies of using FlatRedBall and Glue in the future.


FlatRedBall iOS tutorial available

Last year I started adding support for FlatRedBall iOS. It’s been functional and available in the new project creator for quite a while, but no articles specifically focused on this platform – at least until now.

I’ve just uploaded a new article for creating FlatRedBall iOS projects. Check it out here:

Keep in mind that creating FlatRedBall iOS projects requires using Xamarin.iOS which is not a free product. You can use their 30 day trial to create FlatRedBall iOS projects, but after the trial you must upgrade your license.

New 11-part Platformer Tutorial Available

Many of you have probably read through the Beefball and Rock Blaster tutorials. I’ve just put the finishing touches on a third game in the Glue tutorial series – a platformer made with Tiled and using various products from GlueVault.

Given that Beefball and Rock Blaster are perhaps the most successful tutorials on the site, I expect that the Platformer series will help advance the community’s understanding of FlatRedBall, Glue, and related technologies considerably.

As with all larger tutorial series, this platformer series resulted in many bug fixes, productivity enhancements, and many improvements to the platformer Entity which has been available on GlueVault for some time.

Please check it out, and let me know what you think of the series in the chat room. Here’s a direct link:


Did you know GlueView parses code?

One of the most powerful, yet not-so-well-known feature of GlueView is that it understands and can interpret C# code on the fly. Specifically, if you create an event for a variable, then set that variable in Glue, GlueView will interpret the code in that event and apply it….in real time! Not only can you simply set variables and see them apply in real time, but it even works if the variable is part of a state! It even works if you’re performing interpolation in GlueView between states. In fact, you can even write event code and GlueView will parse it in real time as you write it.

Excited about this feature yet? I hope so! That’s why I’ve updated an article about this very topic. Check it out here:


Eliminating the confusion of ScaleX/ScaleY

I mentioned a few weeks ago that I’ve added Sprite.Width and Sprite.Height to FlatRedBall to help simplify interfacing with the Sprite class. I’ve just added these properties to AxisAlignedRectangle and SpriteFrame. I’ve also added the properties Left, Right, Top, and Bottom.

This means you can now use these properties if you want to position an object according to their edges. For example, to place one of these objects (Sprite, SpriteFrame, AxisAlignedRectangle) side-by-side, you would do:

oneInstance.Right = anotherInstance.Left;

I’m adding support to Glue for these properties as well. I hope this will help everyone position and size these common FRB object. If you notice any tutorials that use Scale values which could be simplified by using these new properties please let me know.


Why code generation

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.


New article: Cross-referencing CSVs

I’ve recently completed an article on how to create CSVs which can cross-reference each other. Here’s the link:

Cross-referencing CSVs

This is a fairly common scenario in game development. The example used in the article above is one where a store in an RPG references weapons which are defined in another CSV. This allows the weapons to be modified and added in their own CSV without requiring making changes to a store info.

This approach is especially useful because the “DataTypes” classes generated by Glue are intended to be a “common language” between different Entities.

To extend the weapon example, an RPG that uses WeaponInfo may need information from WeaponInfo in a number of places:

* The Weapon itself may be an Entity like a Sprite.
* The player Entity will need to know which WeaponInfo is being used to calculate damage
* The CharacterJob CSV may need to define which weapons are allowed by a given class
* A store may need to define a list of weapons which can be purchased (this is covered in the example above)
* Planned encounters may provide specific weapons when the player wins
* Treasure chests may include weapons
* UI objects will need WeaponInfos to properly display stats and images – and these may be needed in a number of places like a player status screen, store UI, and battle wrap-up screen

Clearly there’s lots of places where this may be needed. Rather than needing to pass specific stats around (such as telling the UI how much damage a weapon does in the Screen that creates the UI), it’s much cleaner to simply pass around references to WeaponInfo’s and have each Entity internally modify itself to display the relevant information.

I hope this article is helpful for those of you using CSVs in your games.