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.

–Vic–

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.

–Vic–

I just made a small change to the engine to add Width and Height properties to the Sprite class. I’ve you’ve been using FRB then you may already be familiar with the ScaleX and ScaleY properties.

Given how many questions I’ve had about ScaleX and ScaleY over the years, it’s clear to me that Sprite really should have Width and Height properties. Of course, ScaleX and ScaleY are still going to be around for backwards compatibility, and for the IScalable interface.

I’m sure we’ll be seeing more changes as Glue standardizes the way we work with FRB types, but exactly when or what those changes will be is hard to say at this time.

–Vic–

Despite using 16-bit lower-resolution graphics, Baron actually pushes phone hardware quite a bit. There are two main reasons for this:

1. Complex UI – we have a lot of UI in the game, and since it’s all built using Entities and States, there are often lots of invisible objects floating around a Screen, eating up update cycles.
2. Render state changes – lots and lots of them! A render state change (also known as a RenderBreak in FlatRedBall) occurs when the engine must change the texture, color operation, blend operation, or the type of object it is rendering (sprite vs. text). For a more in-depth discussion on this topic, see:

Render state changes

I’ve done some work to improve #1, and have more tricks up my sleeve for that one, but #2 is a tricky one. On one hand, the general view on profiling is to postpone it later until performance problems actually appear, and until you can identify what they are and address them specifically. On the other hand, the longer you wait, the more difficult it can be to profile your code because of project complexity. In the case of Baron I first started measuring and found that in a large battle we had over 100 render state changes! This is definitely a no-no on phone hardware – at least Windows Phone 7.

If we accept that performance fixes mustn’t be done early in the development of a game, then we require good measurement tools to cut through the complexity of a fully-functional game.

The profiling offerings from FlatRedBall have been inadequate (at best), and this has become clear to me as I’ve worked on Baron. In the past I’ve sprinkled in timing calls in the engine to help identify performance problems. This of course presents a lot of problems – the most obvious being that most users do not have access to the source, so this isn’t even an option. The second most obvious being that this requires engine modifications every game, and which are not easy to perform or interface with. Something had to be done!

We can group most performance problems into one of the following categories:

* Memory allocation – this one is a common one, especially on the compact framework (Xbox360 is the worst). Fortunately the CLR profiler does a great job of providing visibility into your memory allocations, so there’s not too much that FlatRedBall needs to provide here.

* Loading times – Long load times can be a problem for games. Glue offers a number of solutions here with content being loaded only when referenced, being loaded asynchronously, and being part of global content. I haven’t documented it yet, but we have also added new support for being able to measure and output loading times for different Entities and files so that you can get a very clear idea of exactly what is taking a long time to load. More on this in the future.

* Long frame times – This is a problem occurring when your game has long load times either due to a lot of rendering overhead, the engine having to update a large number of objects, or your custom code performing time-intensive calculations. Similar to the load time profiling, I have been working on some new code that can give you visibility into exactly what is taking a long time for the engine to do – both in the frame update as well as rendering.

What’s interesting to note is that I’m actually doing very little to improve the underlying performance of the engine in response to Baron’s slow frame rate. The reason is simply because we’d have to start eliminating some of FlatRedBall’s flexibility so that the engine could make more assumptions in updates and rendering. Since many games utilize the flexibility of the engine, the next best option is to provide as much visibility into what’s going on under the hood so that each game can identify where their slowdown is occurring and make modifications to engine settings and how they structure their objects appropriately.

If your game is running slowly, let me know in the chat room and I can help you get set up with some of the latest profiling tools that we’ve added to the engine.

–Vic–

The other day someone asked me on instant messenger “Is FlatRedBall still alive?” Of course, I replied…then realized that I haven’t blogged in many months.

Lately I’ve been spending a lot of time in the FRB chat room, and anyone who spends time there knows FRB is just as active as it ever was. Of course, not everyone has time for that. So what has been keeping me busy lately? Let me list a few things:

* FlatRedBall iOS is now publicly available. It’s available as an option in the New Project Creator, and works with Glue. Of course, you will need a Mac to run FRB iOS games. Tutorials and iOS-specific articles will be coming in the future.
* Lots of improvements to the AnimationEditor plugin. In fact, it has completely replaced the old AnimationEditor. Especially after this last week of work it is superior to the old AnimationEditor in every way.
* Improvements in performance diagnostics and z-buffered rendering (also for the end goal of improving performance). This includes being able to record and view render breaks, have ZBuffered SpriteFrames (including on layers), and sort ZBuffered Sprites by texture.
* Behind-the-scenes work on a 3rd Glue tutorial (to continue Beefball and Rock Blaster). This one will be a platformer using Tiled.
* Significant improvement in GlueView’s ability to parse and apply C# code in realtime.
* Continued various improvements to Glue for performance, stability, and ease-of-use features.

I’ll be doing my best to blog more frequently to help keep everyone in the loop on what we’re working on.

–Vic–

I’ve uploaded a new plugin to GlueVault. It’s a plugin that allows you to edit .emix (EmitterList) files right Glue. This plugin does not display the actual particle graphics – it relies on GlueView to do so. I think that as we move forward and continue to rely on GlueView for game display we’ll both see more plugins take this approach, as well as improvements in general to GlueView to help support its extra responsibilities.

Just like the plugin for the Animation Editor, this plugin does not prevent editing particles through the older ParticleEditor FRBDK app, so you can use both if you prefer the old tool for some tasks. Give it a try, it can be found at:

http://www.gluevault.com/plug/62-particle-editor-plugin-glue

–Vic–

Big thanks to KallDrexx for a new plugin which is available on GlueVault. This new plugin is called Glue Compile, and as it suggests it allows you to compile your project from Glue as opposed to going into Visual Studio. Not only that, but you can run your project from Glue.

If you or someone on your team is working purely in Glue as a designer, artist, or scripter then this plugin makes it so you can edit, run, then return to editing all without requiring Visual Studio to be open and without having to leave Glue.

I personally see this plugin as a key part of making Glue a full game editing environment, so I’m very happy to see it available.

You can grab the plugin here:

http://www.gluevault.com/plug/61-glue-compiler

–Vic–

For a long time Screen and ScreenManager have been two classes which existed in a strange place between the FlatRedBall Engines and Glue. They were neither part of the engine, nor were they by default generated by Glue. This was mostly a holdover of how Screens were used in the days before Glue.

Now the Screen and ScreenManager class are required classes if you are working with Glue, and given that Glue has become the standard way to develop FlatRedBall games, we finally recognized that moving the two classes into a more formal location was overdue.

Tonight’s nightly build moves Screen and ScreenManager into the FlatRedBall Engines. What does this mean?

The good news is that you will no longer have to worry about your Glue build, Engine build, and Screen/ScreenManagers being out of sync. Now if you update your engine, you will automatically pick up the latest Screen and ScreenManager.

This also removes the option of editing these two files, which although was encouraged years ago, is now strongly discouraged given the dependencies between Screens and glue.

Also, another small benefit is that the Screen and ScreenManager files will no longer occupy your project’s Screens folder.

Of course, this does mean that these base classes have a namespace change, and for most developers this is the only thing you’ll need to worry about. This means that the Screen class has moved from

YourProjectNamespace.Screens

to

FlatRedBall.Screens

You may need to modify your using statements or fully-qualify the Screen, ScreenManager, and AsyncLoadingState types in your code.

It is possible that your project will also have ambiguous references between the Screen in your project and the Screen in FlatRedball. To solve this, simply delete the Screen and ScreenManager classes from your project after you have updated to the latest Glue and engines.

We apologize for the trouble this change is causing, but we think it will make things easier in the long run. Thanks for sticking with us through this change.

–Vic–

Congratulations to the team at FlowersFX. They just released a new game on Xbox Indie Games using FlatRedBall. Way to go! Here’s the game page for more info:

Eat my Shuriken and Die!