Another example is handling firing bullets from a gun or ship. One way of doing this would be to have a List<Bullet> where we add new bullets as we need them, and remove them as they go offscreen or out of the playing area. When you add items to a list that cause the list to expand its capacity, you are creating new instances of Bullet each time. A more efficient system would be to have a cache of Bullet instances that we can use to populate an "active" list of bullets that are in use. As bullets go out of play, we can just put them back in the cache.

Of course, you probably don't need an infinite amount of bullets; most games tend to limit the number of bullets or missiles you can fire. In that case, you can keep your cache small so as not to use up too much memory, and you can set a capacity on the active bullets list in advance so that the list is not expanding during game play.

If you are having to create lots of temporary variables while loading levels or doing some other sort of major processing, you can try to call GC.Collect(0) as often as you can. This will ensure that the Garbage Collector collects those temporary items as soon as possible, rather than waiting for the next automatic collection. Also, you will want to try to avoid calling any kind of collection during game play; if the GC does have to do a major collection during an update loop you will no doubt see a definite pause in your game. It might only be for a few milliseconds, but it will be noticeable. Note that unlike GC.Collect(0), GC.Collect() does a full garbage collection across your application's heap. It can take up to 100-200 milliseconds (several frames) so you will want to avoid making calls to GC.Collect during actual gameplay, otherwise it will introduce a definite pause or lag to your game.

Lastly, don't use too many instances of SpriteBatch. Generally speaking, in XNA games you will want to keep the number of SpriteBatch instances to a minimum; this is true for MonoGame as well. MonoGame's implementation has an internal cache of SpriteBatchItems that we recycle to keep the number of object allocations to a minimum. By default, we create 1000 items in the cache, so the more instances you have the less system memory you will have to play with.

Android and iOS Linker

When targeting Android and iOS using the Xamarin tool chain, you will need to be aware of the linker that is run against your code during the build process. This linker reduces the code size of your packages by removing unused code in both your code and the framework depending on the linker settings. The result is your final package will contain an optimized mono framework, rather than the entire framework, and any unused code in your game will have been removed as well.

If you are dynamically loading objects through the content pipeline, you'll sometimes get into the situation where the linker doesn't know you need the types you are using, and it removes that code. This will usually result in a MissingMethodException when trying to construct or call methods on these linked away types. The good news is that there are ways in which you can inform the linker that you wish to preserve certain objects as they are and not remove them. One method is to use PreserveAttribute, which is provided in both iOS and Android:

#if ANDROID

  [Android.Runtime.Preserve(AllMembers=true)]

#elif IOS

  [MonoTouch.Foundation.Preserve(AllMembers=true)]

#endif

public class Example {

  public Example ()
  {
  }
}

This will make sure that on both Android and iOS this entire class is not linked away.

There are other ways to control the linker behavior; if you are interested in learning more the documentation for both iOS and Android is available on Xamarin's docs site.

http://docs.xamarin.com/guides/ios/advanced_topics/linker
http://docs.xamarin.com/guides/android/advanced_topics/linking 

Help Us Out!

This article has only touched on the surface of MonoGame, but hopefully it will motivate you to try it out -- and perhaps even make it better! We've got a few things on the horizon that we want people to help out with, like building a fully cross-platform content pipeline, adding new platforms like Windows Phone 8 and Raspberry Pi, making use of DirectX 11, and extending the XNA API even further. So if you want to help out, head over to www.monogame.net and join in.