Scripting is a natural part of working with Unity. With FFWD our philosophy is that you should be able to take the scripts you have in Unity and use them with as little modification as possible in XNA. What we do is that when you export scripts from FFWD, we transform the code you have written slightly so it will work in the XNA project. Mostly this means altering the namespaces at the top, but some translations of the code will occur as well.

In essence this means that you will work by altering your scripts in Unity and then translating them to FFWD. With the tools we have now, translation is a one way street. From Unity to XNA. So if you make modifications to your code in XNA, you will have to put that code back in the Unity script, otherwise it will be overwritten the next time you export from Unity.

We do this so you can work on porting to XNA while you are working on your game in Unity. You do not need to have a finished game in order to use FFWD.

The FFWD framework is using the same API as Unity. At least as close as we can get to it. There are some things that just work differently in XNA, and have no natural mapping to Unity. Since we can't do anything about that, you sometimes need to have XNA specific code in your Unity scripts.

Fortunately this is easy, by using conditional compilation. The following symbols are defined in XNA so you can use them in your code. All code that is contained in these directives will be ignored by Unity:

• WINDOWS_PHONE - You are running XNA on the Windows Phone.
• XBOX and XBOX360 - You are running XNA on the XBox 360.
• WINDOWS - You are running XNA on Windows.

One of the places where you will most likely run in to code that needs conditional compilation is when working with XML. On the Windows Phone you only have the System.Xml.Linq namespace available. Unity does not support that, so you need to write your XML code with conditional compilation to make it work.

Sometimes you have a script in Unity that you for some reason do not want in XNA when you export scripts. This can be code that you need to do differently in XNA, code that is not done yet or editor scripts that does not work in FFWD. You can exclude them by adding them to either Excluded Scripts or Excluded Paths from the FFWD configuration.

When we read the data from your scenes into XNA, we do it by using the built-in XML serializer. This system is quite flexible, and allow you to use attributes to define what is read from the XML file. Unity has a similar system in for the editor that controls what is being shown in the inspector. When we export a scene we only export what is shown in the Inspector and what is marked with SerializeField attribute in Unity.

There is one big difference in how Unity handles things compeared to what XNA does. Public properties are ignored in Unity, but are being considered in XNA. We cannot automatically determine where your public properties are in your script, so you have to mark them with the ContentSerialierAttribute so they will not be considered in XNA. This attribute is also seen by Unity, but has no effect there.

Example: [ContentSerializerIgnore] public void MyProperty { get; set; }

There are also a couple of other attrributes that you can use to control what FFWD does.

This attribute tells FFWD that you do not want to export this script from your scenes. When the exporter encounters this script in one of your scenes, it will skip it and not write it to XML. It will still copy the script to the XNA project, unless you exclude it as described above.

This attribute is used for advanced scenarios, where you want the exporter to use a specific class for writing your script to XML. This is only needed in very rare cases as the default exporter class and the use of attributes in the code is usually enough.