FlatRedBall

I just finished a set of new tutorials for the AnimationEditor. These tutorials assume a new version of the AnimationEditor because I found some areas to improve in the tool as I wrote them up.

Here’s a direct link to the tutorials:

http://www.flatredball.com/frb/docs/index.php?title=AnimationEditor:Tutorials

I feel really good about the tutorials – they’re similar in style to what was established earlier this year with the Glue tutorials.  Please check em out if you are planning on doing any type of animation in your game – I’m sure these will help.

–Vic–

Wow!!!! The X10 team has just won 2nd place in Dream Build Play with their game A.R.E.S. Amazing job guys! I’m so excited for you! Keep up the fantastic work.

For those of you interested in the game, check our their site:

http://trashman.x10studio.com/

–Vic–

I’ve just finished uploading the May release. As always, it’s got lots of minor improvements to the engine. Big things that may interest you are:

* Lots of usability improvements in the AnimationEditor
* New project creator works from any install location
* Fix on .bmp loading on the 360
* 360 template works!
* And much more…

For those of you using Glue and upgrading, you will likely need to update your Screen and ScreenManager code. You can get the latest here:

http://www.flatredball.com/FlatRedBallAddOns/FlatRedBallAddOns/Screens/

Just copy the contents of the Screen and ScreenManager files. Be sure to not mess up your namespaces.

Until next month, good luck to all and thanks to everyone for feedback.

–Vic–

The third Littlest Pet Shop set of games was just announced. I’ve been the lead designer on this franchise for all three versions, for those of you wondering how this is in any way relevant to FRB

Not sure if I’d give it a strong recommendation for older guys, but if you know any girls 6 – 10 years who have a DS, this is usually a pretty safe bet.

Here’s the official announcement:

http://www.ea.com/news/ea-announces-littlest-pet-shop-biggest-stars

–Vic–

I mentioned a few days ago that we’d be releasing a new application which would be used to make projects.  The April 2010 version is out and it includes this new program.

As always, there are new improvements and bug fixes in the engine, as well as Glue improvements.  Thanks to everyone who has given feedback, and as always, good luck!

–Vic–

A some of you may know, when I’m not working on FlatRedBall, I’m doing contract work for game studios in the northern Utah area – usually I’m at EA (Electronic Arts) as a lead designer.

Because of that role, I often have to think about the games I play in abstract terms so that I can identify what it is about certain games that make them great, and how these great principles can be applied to other games.

Obviously there’s so much to analyze and discuss, so for the sake of brevity let’s look at the high-level stuff.  In the last few years there are three considerations for me that decide whether I’ll play a game:

1. Is the game cooperative in its campaign mode?  This doesn’t mean the game includes a coop side-mode, but the main mode is multiplayer cooperative.
2. Does the game have amazing or nostalgic content?
3. Does the game have some form of progression?  Level-ups, growing your town, accumulating wealth?  This should be tied to time spent not progress in the game.

I’ve listed them in the order of importance, and I’d say that percentage wise, a game being coop makes up 60% of whether I’ll enjoy it.  Amazing/nostalgic content is 25%, leaving progression at 15%.  How did I come up with these numbers?  Well, the cooperative element is rated as high as it is because that’s often sufficient for me to play a game.  I often do “game nights” at my house where friends come over to play games.  Also, I play online multiplayer (cooperative) games on Sunday nights with a group of friends.  This makes up the majority of the amount of time I spend playing games.

Nostalgic content is great, but it’s rare.  I’m still hoping that Nintendo will do a proper sequel to Zelda: Link to the Past or Super Metroid.  Something that isn’t pushed to a wimpy hand-held.  Something with a $20M budget in high def (or even 480p on the Wii).

Finally, progression matters because I want to feel like my time spent in the game is building up to something.  So this means I tend to enjoy RPGs and games with RPG-like elements (Dynasty Warriors, Castle Crashers).

Of course, if you can combine a few of those elements mentioned above, then you have an amazing game.  As mentioned above, Dynasty Warriors and Castle Crashers are coop but also have a level-up element.  That’s amazing!  Fortunately there seems to be a trend lately where games should be multiplayer.  Hopefully this trend continues, and that games don’t abandon the same-screen coop in favor of networked coop.

–Vic–

I remember the good ol’ days (2006) when FlatRedBall was just FlatRedBall MDX, and creating a template was easy.  It was a simple wizard in Visual Studio which created a ZIP file and that was that.  It was easy for us to do our monthly releases then.  But boy have things changed since then!

First we saw XNA, which was awesome, but completely broke the template exporting in Visual Studio.  The reason is because XNA had this weird embedded content project that Visual Studio’s template exporter didn’t really understand.  To “make up” for it, Microsoft posted information on how to modify an exported template to support the Content project.  Well, that worked for us, even though it was a pain to update.

Then came Silverlight and FSB.  Again, awesome that MS expanded the available platforms for C# and ultimately FRB, but things got even trickier.  FSB requires two projects – a web and a regular project.  We did figure out how to create a template for FSB, keeping things consistent across all versions of FRB, but again, it was a pain.  But the bad thing is that there were some things we just couldn’t figure out:

• How to have the name of the solution propagate down to the names of the individual solutions.
• How to have the name of the solution become the namespace of the project.
• How to have the .Web project reference the regular project in the Silverlight Applications properties tab.

We worked around the first two by doing what MS did for VS’s template shortcomings – we created a tutorial explaining how to change namespaces and project names.  But let us say openly that we’re NOT happy about this solution.  It sucks.

The third problem listed above is preventing some users from running FSB altogether – unless they make some changes to properties in their projects which are rather hidden.  Well, we could just write another tutorial and direct people to that in the regular tutorial flow, but really how many extra steps will we tolerate before it’s too much?  Or more importantly, how many more steps will our users tolerate?

This isn’t a question we’re wanting to find the answer to.  Instead, we’re going to simply things again.  We’ve decided to completely eliminate the Visual Studio templates from our releases.  What does this mean for you as a FRB user?

The downside is you’ll no longer have access to templates through Visual Studio.  If you want to create a new FRB project, you’ll have to do it outside of Visual Studio.  Instead, we’ll be creating a simple application that you can start though the Start Menu under the FlatRedBall folder which will be a New Project tool.  Once you launch it you will be able to select which type of project you’d like to create, give it a name, then press OK.  All projects will work out-of-the-box with no modifications necessary.

This also gives us a lot of extra flexibility in project creation.  Ideas that we’d like to implement in our new project creator is:

• Have the creator pull from the server so you are always using the latest version of FRB.
• Have the creator allow you to create multiple projects simultaneously (like FRB, FRB 360, and FSB)
• Have the creator integrate with Glue so you will be able to create new projects from Glue and have them automatically open in Glue once you’ve created them.

So, the good news is that we think this will improve the overall user experience even more.  The downside is that this all requires work on our (the FRB developers) part, so please be patient with us as we’re working to get you the new April release as soon as possible!

–Vic–

That’s right. We just couldn’t wait three more days to make this release in April. Consider it a late Christmas gift to the community.

Aside from the usual multitude of tweaks, features and fixes that come with a new release, anyone interested in using FlatSilverBall should take note that the FSB template has been fixed to properly reference the new SilverArcade.SilverSprite and SilverArcade.SilverSprite.Core dlls.

Also, we’ve added a new feature to Glue that allows you to

1. Create a .csv file within Glue
2. Populate the spreadsheet with data that represents a collection of objects(using different columns for different fields)
3. Then have Glue AUTOMATICALLY create a class based on the columns of data that you specified, and then populate a list of that class using the individual rows of the spreadsheet.

If your mind seems to be blown by this, don’t worry. A tutorial on this feature is likely to make it into the FRB documentation fairly soon. Until then, have fun with the new build, and let us know of any problems that you encounter (You always do!)

Happy FRBing!

Get it while it’s hot!

In addition to the megaton of generated code that Vic added for ShapeCollection collision, this month’s release is full of bug fixes in Glue and reduced memory allocations in some of the core FlatRedBall classes. Also, the installer has been updated to allow you to add file associations for FlatRedBall file types. Now you can just double-click your .scnx files and have windows (magically) open the SpriteEditor for you!

Last, but not least, a big FlatRedThanks goes out to APSStaff. Their XLoader class can now be found in the FlatRedBall.Graphics.Model namespace, and it will allow you to load .x models straight from the file with the greatest of ease!

Happy FRBing!

The latest version of Glue (which should be part of the FRBDK today) introduces the ability to select “Entire File” when you create a named object that references a file.

This means that you’re no longer limited to a Circle or Polygon collision – your collision object can be an entire ShapeCollection. This is great for ease of use…but not so great for us writing FRB. Why?

If you’ve used Shapes before (like Circle and Polygon) then you probably know that “Shapes” is a word we use to categorically talk about these classes, but there isn’t actually a Shapes interface or base class that defines collision methods. We do this to avoid having virtual collision functions. This slows call speed and collision functions are usually functions which are called a lot of times every frame.

The downside to it is that we have to explicitly write collision functions for every type vs. every other type. Now that the ShapeCollection file is here, and it contains 7 types of objects, that means we need to explicitly code every type of collision. That’s 7 X 7 = 49.

But each loop has spacial partitioning optionally built in to it, meaning that each loop is over 20 lines of code. That means 7 X 7 X 20 = 980 lines.

But wait, there’s more! There’s CollideAgainst, CollideAgainstBounce, and CollideAgainstMove. So that means:

7*7*20*3 = 2940

And of course, there’s all the rest of the overhead of defining extra variables return values, method headers, brackets… you get the picture. In all, the new code is becoming around 3500 lines!!!

I’d be crazy to want to write and maintain all of that by hand. So, instead I’m writing a code generator to create this code for us. The code generator is well under 200 lines of code – far more maintainable.

In the end, we hope to make the different shapes essentially abstract for the user, so you can simply just call one function to partition the ShapeCollection, and then another function to perform collision. This will mean ultimate convenience and performance. Go code generation!

–Vic–