My buddy Vic (creator of FlatRedBall) and I were discussing issues with tilemap performance recently. Namely that large tilemaps suffer in performance because of the volume of Update calls on Sprite objects, even if the sprites are small. One of the ideas we discussed to deal with this is that of compositing multiple small tile textures into a single large texture at runtime. This texture could be roughly the size of the screen and you lazy load these textures to be ready just before you need them and unload them as they leave the screen. Vic mentioned that FlatRedBall has an ImageData class that helps process images.

I’m really interested in procedural content generation. I’ve read a lot about how games like Minecraft create content but I haven’t really tried doing anything similar. I decided to play around with the ImageData class and see how to create textures on the fly. I love space and so the first thing I did was create a random starfield generator. It looks like this:

public static Texture2D CreateStarfield(int width, int height)
{
	int numStars = FlatRedBallServices.Random.Next(width / 2, width * 2);
	ImageData imgData = new ImageData(width, height);
	imgData.Fill(new Color(0f, 0f, 0.05f));
	for (int i = 0; i < numStars; i++)
	{
		int starSize = FlatRedBallServices.Random.Next(1, 3);
		int x = FlatRedBallServices.Random.Next(0, width - starSize);
		int y = FlatRedBallServices.Random.Next(0, height - starSize);
		float brightness = FlatRedBallServices.Random.Next(25, 100) / 100f;
		Color starColor = new Color(
		    FlatRedBallServices.Random.Next(85, 100) / 100f * brightness,
		    FlatRedBallServices.Random.Next(85, 100) / 100f * brightness,
		    FlatRedBallServices.Random.Next(75, 90) / 100f * brightness);
		for (int ix = 0; ix < starSize; ix++)
		{
		    for (int iy = 0; iy < starSize; iy++)
		    {
			imgData.SetPixel(x + ix, y + iy, starColor);
		    }
		}
	}
	return imgData.ToTexture2D();
}

So that’s very simple. It creates an ImageData object at the specified size, comes up with a number of stars based on the texture size, and then draws stars into the image before returning it as a texture.

Next, I wanted to create planets. Stars are easy because they are just light-colored pixels on a dark background. Planets are much harder if you want them to be varied in color, texture, atmosphere, etc. Ideally, I would create the planet textures on the fly. However, I’m not quite ready to do anything that sophisticated because I’m pretty new to image manipulation algorithms. So I cheated and created some planet elements in photoshop. If you came here looking for purely procedural content, I’m sorry. I’m still working on that!

Here’s how my planet-creation works in concept:

1. Create Basic Planet Shape
1. Load a texture describing planet shape. This is easier than manually drawing a circle and can use photoshop’s nice anti-aliasing.
2. Choose a random color to be the base color of the planet.
3. Create an ImageData object the same size as the planet shape
4. Loop through the planet shape. Everywhere a pixel with alpha greater than zero exists, create a corresponding pixel in the new image using the random color.
2. Apply a texture
1. Load a surface texture at random from a selection of textures created in photoshop and pre-warped to look spherical
2. Choose a random color to be the texture color
3. Loop through the surface texture and composite the texture color and alpha onto the base pixel
3. Apply clouds
1. Load a random cloud texture
2. Composite cloud color and alpha onto the pixel
4. Apply shadow
1. Load the shadow texture, created in photoshop using a simple radial gradient from transparent to black
2. Composite the shadow onto the pixel
5. Apply atmosphere
1. Load an atmosphere texture, created in photoshop by adding inner and outer glow effects to a sphere and then just exporting the glow
2. Composite the atmosphere onto the pixel

For a few years now, my primary monitor at home has been a 28″ HannsG with a native resolution of 1920×1200. I bought it used from a buddy for around $200 which was a steal at the time. The monitor was big and had a variety of inputs but that’s about all it had going for it. There was terrible light bleed when the screen was dark, the color would vary drastically based on viewing angle, the response time was low enough that pixel smearing was pretty bad and the refresh rate of the fluorescent backlight gave me wicked headaches. The monitor has been on its way out for awhile. Parts of the screen would seem to vibrate randomly and occasionally it wouldn’t turn on or off. It finally died completely this weekend, refusing to respond to a battery of basic diagnostics.

Anticipating my monitor’s demise, I have been monitor shopping but I haven’t been that happy with what I’ve found. I like having lots of monitor real estate. Two or more monitors is great but it means dealing with bezel between your displays and four connection and power cords. I’d rather have a single, large screen but buying a bigger screen doesn’t actually get me anything. Every single screen I looked at was 1080i or lower. Additionally, the larger the screen the more your viewing angle changes across the surface, which makes colors appear different depending on where you’re looking. I do some color-sensitive work and this is important. So, big monitors have the same resolution, making everything more pixelated at close ranges and displaying color poorly across the surface. Keep in mind that I was shopping for a monitor and not a television. TVs are viewed from a much greater distance than a monitor and these factors are less important.

Apple has realized the importance of density over size. The new iPad/iPad3 (whatever you want to call it) has a pixel density of around 250dpi. That means that every square inch of the display has 62,500 pixels. My HannsG monitor’s density was around 72dpi or 5,184 pixels per square inch. That’s an enormous difference, which is exactly why Apple created the Retina display… the difference is amazing.

When looking at a monitor, the numbers they pack into the specs are overwhelming, misleading and generally not that useful. For instance, the dot pitch can tell you how large the pixels are (which determines density) but it can be measured several different ways, which makes it impossible to compare. Additionally, most monitors really focus on the diagonal measurement and not the actual dimensions of the screen. So, the first thing I did was create a spreadsheet of common sizes for the two major aspect ratios (16:9 and 16:10). If you know the aspect ratio and diagonal measurement you can calculate the dimensions. If you know the horizontal resolution you can calculate the average pixel density across the screen and I created excel functions to do this. For years 72dpi was a standard, then it moved to 96dpi. I was looking for something significantly higher.

But that doesn’t address the color issues. I want to sit directly in front of a 28-30″ display and have a solid color look the same across the screen. Most modern televisions are actually not very good at this. This is because they use an LCD technology called Twisted Nematic (TN) display. TN displays have the advantage of being fast and cheap and are the most common LCD type on the market but they have relatively poor color production. In-Plane Switching (IPS) LCDs have much, much better color range and viewing angle but traditionally have slower response times than TN. This makes them popular for graphic applications but more likely to have ghosting and smearing when displaying quickly-changing content.

Finding a monitor that offered consistent lighting, large display, high pixel density and IPS technology that was fast enough for gaming too is a challenge. This type of monitor is rare and thus, expensive. The most obvious choice are Apple’s new Thunderbolt displays. But, as usual, Apple doesn’t want their tech to be compatible with anything else. I couldn’t find any reasonable way to hook up a PC to a Thunderbolt display and Apple monitors are not VESA mount capable without an adapter (surprise, only available from Apple).

After looking at a variety of different displays, I finally settled on a 30″ Dell Ultrasharp monitor at 16:10 (more vertical real estate) with a native display of 2560×1600. On paper, everything about the display was perfect except that it uses CCFL for lighting instead of LED. I ordered mine from Amazon.com for the points and the $4 overnight shipping. It is an expensive monitor but I believe in good tools. I tested it pretty thoroughly last night after unboxing it and setting it up. The only complaint I have is that the awkwardness of the VESA mounting system is going to make adapting it to my existing wall mount a little difficult.

Here are some pictures of the unboxing including a screenshot of common applications I use to get an idea of what to do with all those pixels:

This game is only 8k and has no pre-created assets. Bugs are drawn in code.

How To Play:

The bugs start as very fast little whippersnappers. As they age they grow bigger and slower. Once they are old enough they will breed and the females (antennas) will have babies. Some bugs are more fertile than others and some are not fertile at all. Baby bugs will generally be a combination of their parents’ color but there is a chance for anomalies to be born. Bugs will die of old age after awhile.

If you’re quick, you can squish bugs by clicking on them. If you want to squish them all press “S” (meanie).

If the bugs get too crowded they will stop having babies until some of the population dies off.

I haven’t blogged in a while for two reasons:

1. Work is insanely busy
2. I’ve been either working hard or playing hard in my spare time

A strange but important thing to realize is: game instances never match across a network! Realizing this was integral to getting the network to work. I had to evaluate what actually matters to the gameplay and send that. Entities that cannot affect a client do not matter and shouldn’t be updated until the server decides they do matter.

So, this is not “the way” to implement networking with FlatRedBall but it is “a way” that seems to be working pretty well. It is a work in progress but it is off to a pretty good start. Read on and comment with questions or concerns.

Step 0: The pattern used

I’m using a Client-Server pattern: one server, multiple clients connected. The server is the master record, both sides simulate the environment and exchange minimal data that describes changes to object states on each end without having to send updates for the entire world every frame. If you haven’t read the Unreal article above, do so. It’s a really good overview of how this works. I will be going into some detail about my specific implementation but that article was written by the pros!

Here’s the overview of how my implementation works:

• Keyboard input state is compressed into a bitmask each update and only sent to the server if the state changes using UnreliableSequenced send mode
• Every T seconds, the client sends a reckoning input update using ReliableSequenced
• Every T seconds, the server forces a “dead reckoning” of all interactive game objects (eventually limited to those affecting a specific client)
• The value of T is set in Glue so it can be tweaked and tested easily, currently I’m using 0.5 seconds for dead reckoning but that may be too frequent
• When an entity gets a new state via “dead reckoning” it interpolates to the new position instead of jumping straight there. This makes a big difference in perceived smoothness

Step 1: Abstracting the Lidgrin Library for FlatRedBall

I don’t want my entire project to depend on Lidgrin. First, I’d like others to be able to use my abstraction. Second, I might update to a newer version of Lidgren, discover another networking library in the future, or otherwise change dependencies. If that happens, I only need to make changes in one place: my adapter between Lidgren and the FlatRedBall engine. My abstraction is (as of this post) three files: a NetworkAgent, an incoming message class, an outgoing message class (links go to actual codez).

The NetworkAgent is the only object instantiated by a Game Screen. It can be instantiated as a Server or a Client. It provides the Game with a unique ID (which actually comes from Lidgren), latency measurement, and ways to send and receive messages. The NetworkAgent’s GetMessages method returns processes the queue of messages, writes any non-data messages to a provided logger, and pushes all data messages into a List of incoming messages and returns the list. The Game Screen calls this method every Update and processes the List returned.

The incoming/outgoing message classes mostly wrap Lidgren message types. However, they can be tidily extended to send more complex objects than Lidgren allows. For instance, I added methods that can send/receive Vector3 objects, which are actually broken into their three discreet float values and packetized.

The NetworkAgent doesn’t care what type of game you make. It doesn’t care what type of messages can be sent (other than Lidgren’s generic “data” type). All of this game-specific stuff should be implemented in your Game Screen. The Network Agent just makes it easy to send/receive messages without having Lidgren dependencies sprinkled all over your project.

Step 2: Input Management

Since my game uses keyboard for movement and mouse for aiming, all movement-related input states are boolean: either a key is down or it’s not. Sending this as a bunch of Boolean values or something even heavier would slow down the network. I pack up to eight different key states into a single byte using bit operations. I can also send the mouse position as two floats. Since the mouse only controls the turret rotation, and that’s not really important unless the player is actively firing a weapon, I’m planning to test sending the mouse state only during the input reckoning or when firing and interpolating the tank rotation between these updates.

The important thing here is to understand the chain of events. If a player is holding down a single key, input state does not change until they release it. This type of update is only sent on state change and is sent UnreliableSequenced. This state update is received by the server and forwarded to other clients. However, since it is Unreliable it may not be delivered at all, which would result in the server not realizing the player had released the forward key and keep moving the tank forever. This is why I also need an input reckoning. This forces a reliable update to the server of the current state.

Note that the server also broadcasts its own input updates. And, when it forwards an input update, it forwards it to all clients (including the one that sent it). This means that a client must check the ID of the entity the update is affecting and discard it if it applies to the entity the client owns.

This is the Input State object:

// An enum who's values are ready for bitwise ops
[Flags]
public enum InputTypes
{
	None = 0,
	UpPress = 1,
	DownPress = 2,
	LeftPress = 4,
	RightPress = 8,
	FirePress = 16,
	SpecialPress = 32
}

// extension method to make input testing easy!
public static class InputTypeExtensions
{
	public static bool ContainsFlag(this InputTypes flagSource, InputTypes testFlag)
	{
		return ((flagSource & testFlag) == testFlag);
	}
}

The Game Screen does this each update cycle to create a new state:

private void HandleInput()
{
	// for readability
	Keyboard kb = InputManager.Keyboard;
	Mouse ms = InputManager.Mouse;
	mCurrentMousePosition = new Vector3(ms.WorldXAt(0), ms.WorldYAt(0), 0);

	// Use bitwise and a ternary to "OR" input states into the object
	mPreviousInputState = mCurrentInputState;
	mCurrentInputState = InputTypes.None;
	mCurrentInputState |= (kb.KeyDown(Keys.W) ? InputTypes.UpPress : InputTypes.None);
	mCurrentInputState |= (kb.KeyDown(Keys.S) ? InputTypes.DownPress : InputTypes.None);
	mCurrentInputState |= (kb.KeyDown(Keys.A) ? InputTypes.LeftPress : InputTypes.None);
	mCurrentInputState |= (kb.KeyDown(Keys.D) ? InputTypes.RightPress : InputTypes.None);
	mCurrentInputState |= (ms.ButtonDown(Mouse.MouseButtons.LeftButton) ? InputTypes.FirePress : InputTypes.None);
	mCurrentInputState |= (ms.ButtonDown(Mouse.MouseButtons.RightButton) ? InputTypes.SpecialPress : InputTypes.None);

	// only send input state if we own an entity
	if (mOwnedTank != null)
	{
		// apply the input state to our owned entity
		mOwnedTank.ChangeInputState(mCurrentInputState, mCurrentMousePosition);

		// send the server an update
		if (mCurrentInputState != mPreviousInputState)
		{
			// false means don't send reliably
			SendInputUpdateMessage(false);
		}
	}
}

How the Game Screen sends an input state:

// mInputMessage is an Outgoing Message instance
// mNetwork is a NetworkAgent instance
// note that we also send the entity owner id
private void SendInputUpdateMessage(bool isReliableMessage)
{
	mInputMessage = mNetwork.CreateMessge();
	mInputMessage.Write((byte)NetworkMessageType.InputState);
	mInputMessage.Write(mNetwork.GetId());
	mInputMessage.Write((byte)mCurrentInputState);
	mInputMessage.Write(mCurrentMousePosition);
	mInputMessage.SendToAll(isReliableMessage);
}

Whether it comes directly from the Game Screen or via a network message, an input state is handled by an Entity like this (just a snippit):

public void ApplyInputState()
{
	// uses extension method to check input state
	if (CurrentInputState.ContainsFlag(InputTypes.UpPress))
	{
		CurrentSpeed += AccelRate;
		TankTracks.Animate = true;
	}
	// handle other key states here...not shown

	// apply turret rotation
	TankTurret.RelativeRotationZ = (float)Math.Atan2(mTarget.Y - Position.Y, mTarget.X - Position.X) - RotationZ;

	// affect velocity with speed and rotation
	Velocity.X = (float)(Math.Cos(RotationZ) * CurrentSpeed);
	Velocity.Y = (float)(Math.Sin(RotationZ) * CurrentSpeed);

	// interpolate from reckoning (see next section)
	InterpolateReckoningDelta();
}

Step 3: Reckoning

If you didn’t read the articles linked at the top and you haven’t figured it out by now: reckoning is the process of forcing clients and server back into sync with each other. A complete override of all client states by the server is called a “dead reckoning.” Input reckoning is not a full-on dead reckoning because it doesn’t reposition or change the entire state of an entity, merely updates it’s input. The entity could still be way out of position. Thus the server needs to force a reckoning on all entities in the game to make sure they are where they should be. This is simple in concept: every N seconds, the server loops through it’s entities and broadcasts a state message for each entity to all clients. The problem is, this state _never_ exactly matches the entity state on the client. Plus, the message will take a bit of time to transfer and be applied. So, even if the entity states exactly match when the server broadcasts a message, they probably won’t by the time the message is received. This means that even with latency close to zero and no packet loss you get jerky performance. There are two ways of mitigating this and neither works perfectly by itself:

Prediction: use the average latency, rotation and velocity to broadcast where the entity should be by the time the message arrives. This helps a little but if the player is actively turning or changing direction it can compound the difference between states.

Interpolation: Instead of immediately forcing the entity to a new position, interpolate the current position into the destination position smoothly. This is more (and less) complicated than it sounds because the entity’s current position and the received reckoning position are a snapshot of a moment in time. These values are actively changing. So you have to interpolate where the entity is going to be given the Client’s state with where the entity is going to be given the Server’s state, while also accounting for new input even as the interpolation happens!

The solution I found (after about 5 tries) was actually really simple in retrospect. I simply take the delta of the current position and the destination position and apply a percentage of the delta each update until there is no more discrepancy. This means that the client and server instances of an Entity do not match but are frequently, smoothly, shifted closer together. Making these shifts smoother makes them much harder to perceive, improving gameplay. If the discrepancy is big enough to cause collision problems with world geometry or enemy fire, the server position ultimately rules. This sucks but it is present in all games, how often have you died in a FPS because the enemy wasn’t actually where you were shooting?

// reckoning difference
Vector3 mPositionDelta;

// called by the client's Game Screen when it receives a reckoning message
public void ForceNewState(Vector3 position, float rotation, float speed, int health, InputTypes input)
{
	// the important line: set the delta
	mPositionDelta = Vector3.Subtract(position, Position);

	RotationZ = rotation;
	CurrentInputState = input;
	CurrentSpeed = speed;
	CurrentHealth = health;
}

// each frame the entity applies its current input state
// after the normal movement is applied this interpolation is called
// Interpolation rate is a global var that all entities can reference
private void InterpolateReckoningDelta()
{
	if (mPositionDelta.X != 0)
	{
		Position.X += mPositionDelta.X * GlobalData.GameData.InterpolationRate;
		mPositionDelta.X -= mPositionDelta.X * GlobalData.GameData.InterpolationRate;
	}

	if (mPositionDelta.Y != 0)
	{
		Position.Y += mPositionDelta.Y * GlobalData.GameData.InterpolationRate;
		mPositionDelta.Y -= mPositionDelta.Y * GlobalData.GameData.InterpolationRate;
	}
	// some clamping could happen here for really small deltas
	// but I have tuned interpolation rate so that it finishes up
	// just in time for the next reckoning!
}

Hopefully this has made some level of sense. Currently the game doesn’t implement shooting, collision, etc so there is still much to be done that will likely affect my pattern.

Love or hate? Drop it in a comment!

Update: Forgot to mention one little thing. Entity creation. When the client receives a reckoning update it checks the ID and then searches its list of entities for a matching ID and applies the reckoning to the matching ID. If it doesn’t find an ID it creates a new entity with that ID and applies the reckoning. This results in a slight delay in new entity appearance if you connect to an existing game between reckonings. Lots of ways to improve this with more explicit entity creation requests but I haven’t gotten there yet

I am rebuilding Grimwar in .NET MVC3 and it’s going really well. Unfortunately, Windows servers are more expensive than the LAMP servers I’m used to rolling on. I created and submitted a Kickstarter proposal to help raise money for some marketing expenses, printing expenses and server costs. Unfortunately my request was denied. Here’s what they had to say:

Hi Justin,

Thank you for taking the time to share your idea. Unfortunately, this isn’t the right fit for Kickstarter. We receive many project proposals daily and review them all with great care and appreciation. We see a wide variety of inspiring ideas, and while we value each one’s uniqueness and creativity, Kickstarter is not the right platform for all of them. We wish you the best of luck as you continue to pursue your endeavor.

Best,
Kickstarter

So…denied! I think Kickstarter is more interested in projects that further the arts, or technology. Grimwar is unique in that no other site serves the same function. However, it’s not particularly ground-breaking. So, I’m disappointed that I don’t even get the chance to try to get funding but I like that Kickstarter has a good gatekeeping system.

Anyway, I thought the processes of submitting a proposal, getting reviewed by real people and the gatekeeping thing was interesting. I still love you Kickstarter, maybe we can work together another time.

Note: I can make Grimwar work regardless of securing funding. I’ll dump an existing server and pick up some shared Windows hosting. So, if you’re reading this and concerned about the future of Grimwar…the show will go on!

Here’s a shortened example of a type of object I get from JSON and want to save persistently:

[Serializeable()]
public class Department {
   public int Id {get; set;}
   public string Name {get; set;}
   public Drawable Thumbnail {get; set;} // Drawable is an android type that holds image data
}

The above example will not serialize because the Android Drawable class is not serializable. We probably don’t want to be serializing image data into our cache anyway so…let’s mark that as [NonSerialized]. Now we get a new exception because you can’t mark a property as non-serialized…because Properties aren’t serialized! Yet, if you comment out the Thumbnail property the rest of the class can be serialized and deserialized with no problems. Why?

Traditionally, auto-properties didn’t exist. You had to have an explicit class member defined and manually create the accessors. When we create an auto-property (which are awesome, IMHO) the compiler creates a class member behind the scenes that the auto-property references. But this is given an arbitrary name and is not accessible. So, when you serialize a property, the property is not being serialized, the hidden member behind it is being serialized. This has some very important consequences.

Let’s say you create the class above and the data is serialized and stored on disk. As time moves on you have some updates to make that require name to perform some logic. Perhaps it simply needs to upper case the name before returning it. So, you create an explicit member variable and your code looks like this:

[Serializeable()]
public class Department {
   public int Id {get; set;}
   public Drawable Thumbnail {get; set;} // Drawable is an android type that holds image data
   public string Name {
      get {
         return mName.ToUpper();
      }
      private set {
         mName = value;
      }
   }
   private string mName;
}

Unfortunately for you, when your program deserializes the data from the old version, Name and mName are going to be null. This is because the actual serialized member behind Name was called something else and that’s what was serialized. If you serialize again and save before you realize this, your binary data will now have a bunch of empty names. The worst part is: it won’t even warn you! It simply doesn’t inflate the old member because it no longer exists as part of the class and the new member is left as its default (null for strings).

The above would still fail because it doesn’t solve the problem of Drawables being unserializeable (is that even a word?). To fix this, you have to give Thumbnail an explicit class member and mark the member as [NonSerialized]. Remember, if you mark a class as [Serializeable()] it will try to serialize the whole thing, even private members.

So, the ultimate thing to be aware of is: be really careful using auto-properties with binary serialization. If you have auto-properties that have ANY CHANCE of changing and data integrity is important…explicitly define the backing members.

One of the most-frequently-used components in Android applications are ListViews. Android ListViews are good and bad. They are good in that, if you do it properly, they handle view recycling and can be pretty efficient. They are bad in that the abstraction is so leaky that 90% of the so-called tutorials and examples I’ve seen do it poorly. Many of the tutorials don’t even take advantage of the view recycling and the ones that do still miss out on some important optimizations.

This is a quick example of how to optimize a list view, starting with bad implementation and moving to better implementation. Note that I’m mocking up this code so please point out any mistypes in the comments.

Here’s an example of the most basic implementation of a ListAdapter’s GetView method. Please do not create your list like this. This would be fine for viewing just a few items but it doesn’t take advantage of any recycling. This is inflating a new view every, single time – which is extremely wasteful and will definitely slow your lists down. Notice that we’re not using the “convertView” parameter at all! We will implement that in the next example.

public override View GetView(int position, View convertView, ViewGroup parent)
{
   // get our data object from the list
   MyObject dataObject = mObjectList[position];

   // inflate our custom line item
   LinearLayout view = mContext.LayoutInflater.Inflate(Resource.Layout.my_line_item, parent, false) as LinearLayout;

   // get references to our views
   TextView title = view.FindViewById(Resource.Id.myLineItemTitle) as TextView;
   TextView subText = view.FindViewById(Resource.Id.myLineItemSubtext) as TextView;
   ImageView thumbnail = view.FindViewById(Resource.Id.myLineItemThumb) as ImageView;

   // bind data to our line item
   title.Text = dataObject.Title;
   subText.Text = dataObject.Description;
   thumbnail.SetImageDrawable(dataObject.Thumb);

   return view;
}

This version improves slightly. Here we are using the recycled convertView, if it exists, instead of inflating a new view. This will help a lot but we still have to instantiate references to our sub views before we can bind data. FindViewById is expensive enough that this still adds overhead. If your line item is simple enough that it doesn’t have subviews or only has a single subview this method might be okay but use it with caution.

public override View GetView(int position, View convertView, ViewGroup parent)
{
   // get our data object from the list
   MyObject dataObject = mObjectList[position];

   // check if we have a recycled view, if not then inflate
   var view = convertView;
   if(convertView == null)
   {
      view = mContext.LayoutInflater.Inflate(Resource.Layout.my_line_item, parent, false) as LinearLayout;
   }

   // get references to our views
   TextView title = view.FindViewById(Resource.Id.myLineItemTitle) as TextView;
   TextView subText = view.FindViewById(Resource.Id.myLineItemSubtext) as TextView;
   ImageView thumbnail = view.FindViewById(Resource.Id.myLineItemThumb) as ImageView;

   // bind data to our line item
   title.Text = dataObject.Title;
   subText.Text = dataObject.Description;
   thumbnail.SetImageDrawable(dataObject.Thumb);

   return view;
}

So, that was an easy way to make sure we’re using our recycled views. But we still are finding sub views every time. To fix this we implement something called the ViewHolder Pattern. Views in Android have something called a Tag. A Tag can be any type of Java.Lang.Object that is stored in the View.Tag for future use. The idea here is to create a ViewHolder class that will store references to our subviews so that we only have to find them once. Then we store that reference in the View.Tag and retrieve it when we need it. I take this even further and create a “Bind” method so that my GetView method is really clean!

// our GetView method is now very clean!
public override View GetView(int position, View convertView, ViewGroup parent)
{
   ViewHolder vh;

   // attempt to recycle existing view
   var view = convertView;
   if(view == null)
   {
      view = mContext.LayoutInflater.Inflate(Resource.Layout.my_line_item, parent, false) as LinearLayout;
      vh = new ViewHolder();

      // here's where we get our subview references
      vh.Initialize(view);

      // push the viewholder reference into the view tag
      view.Tag = vh;
   }

   // get our data object
   MyObject dataObject = mObjectList[position];

   // get our viewholder from the tag
   vh = (ViewHolder)view.Tag;

   // bind our data!
   vh.Bind(dataObject);
   return view;
}

// extend Java.Lang.Object or you will run into all kinds of type/cast issues when trying to push/pull on the View.Tag
private class ViewHolder : Java.Lang.Object
{
   TextView mTitle;
   TextView mSubText;
   ImageView mThumb;

   // this method now handles getting references to our subviews
   public void Initialize(View view)
   {
      mTitle = view.FindViewById(Resource.Id.myLineItemTitle) as TextView;
      mSubText = view.FindViewById(Resource.Id.myLineItemSubtext) as TextView;
      mThumb = view.FindViewById(Resource.Id.myLineItemThumb) as ImageView;
   }

   // this method now handles binding data
   public void Bind(MyObject data)
   {
      mTitle.Text = data.Title;
      mSubText.Text = data.Description;

      // we've also improved the thumbnail to use a default image if missing
      if(data.Thumb == null)
      {
         mThumb.SetImageResource(Resource.Drawable.missing_thumb);
      }
      else
      {
         mThumb.SetImageDrawable(data.Thumb);
      }
   }
}

Now we only instantiate a view if we don’t already have one. We only find subviews if we haven’t already. The only step that is done every time is getting the ViewHolder from the tag and binding data to it. There is a tiny inefficiency left here: when I instantiate the ViewHolder the first time, I push it into the tag and then pull it back out instead of using it directly. I do this intentionally because the overhead required is very tiny and it proves that the system is working immediately. If you have any casting issues with your ViewHolder and View.Tag it’ll happen the first time a view is created, instead of just when a view is recycled.

Note: There are lots of ViewHolder pattern descriptions out there but few (none?) of them use the Initialize/Bind system that I show here. I like this style a lot but I can’t claim credit for it: Joel Martinez gave me a lot of ideas here and may be the first to use ViewHolders like this. I just adapted it from Java to Mono.

I love playing with GameDev tools such as engines, frameworks/libraries, game creators and new languages. I’ve been a big advocate, fan and user of FlatRedBall for some time as you may know.

Today, while reading up on something totally unrelated, I saw a reference to an HTML5 game maker called Creator2. Curious, I read a little about it and decided to play with it this weekend.

I’ve been pleasantly surprised by how awesome this tool actually is. While I don’t think it’s suitable for a super-feature-rich and complex game, it is a pretty solid tool for prototyping or creating casual 2D games. I also was pretty impressed by how smoothly it ran.

I built a tiny but mostly-complete space game in just a few hours. The game features Box2D physics integration, health and scoring. Being able to download the editor, follow a single, short tutorial and immediately create a working prototype is pretty incredible.

I avoid using strong language. I also try to avoid words that cause offense or harm to specific groups in a professional or public forum. That being said, I generally find jokes that poke fun at racial, religious and other stereotypes funny when they are joking and in the right company or context.

As you may know, my beautiful, wonderful, four-year-old daughter Nora has a horrible neuro disorder called Rett Syndrome. Dealing with Rett Syndrome is a major part of the lives of my family, extended family and friends. When we first found out we were simultaneously crushed by the news and uplifted by the amazing support of our family and friends, that continues to be touching.

My wife and I went to a few meetings that were intended to be a sort of group therapy. We were positive and hopeful but found many of the group members to be bitter, depressed and angry at the world. In one session a parent went off about the use of the word “retard” by a large cross-section of people. While I understood the point, my wife and I did not like the anger and bitterness at the world that was a common attitude in the group and quit going.

Words like “fag” and “nigger” garner a ton of attention because they have an enormous and vocal advocacy group. Professionals that would never use those words on their blogs, twitter or in a public setting are often quick to use the word “retard,” which is admittedly surprising to me. The sad thing is, most people that do suffer from some form of mental retardation can’t defend themselves and thus the word “retard” rarely has the backlash that it’s racial and sexual-orientation counterparts do.

Despite all that, the word rarely bothers me. The internet at large uses it ALL the time. My friends use it frequently. Sometimes my wife and I even slip and use it (we try not to after seeing how offensive it is to some). The word seems to be pretty thoroughly decoupled from its association with disabled individuals. To put it another way, the two offensive words mentioned above still refer to specific groups whereas “retard” rarely actually refers to disabled people. Similarly, the words “stupid” and “dumb” at one time referred to the mentally or physically disabled but now seem to be generally accepted in informal speech. The only time “retard” does bother me is when it is used to refer to disabled people, which is highly offensive.

What bothers me more than the R word is the stigma around disabilities – but who’s fault is that? It is hard not to look (read: stare) at someone that obviously has a disability. And there’s nothing wrong with curiosity. I think the stigma is often negatively perpetuated by the caretakers of disabled people when they are rude to people who are curious. In our short-lived support group experience one of the parents ranted about people staring at her child at the park playground and talked about how “she showed them.” Of course people are going to stare! They’re curious and probably afraid to ask if you act like a total jerk because they’re interested! I’ve had some really positive experiences with strangers that asked about Nora with genuine concern and a desire to learn about her disability. I also think it’s awesome when people treat disabled people like anyone else.

The thing that is absolutely unacceptable is mockery of people with disabilities. I watched a marketing professional, probably in his 30s, make a drunken spectacle of himself at a conference – impersonating someone with special needs in a public setting. It goes on record as one of the most insulting and pathetic things I’ve ever seen. So while I may not flinch at the R word, I might get violent at outright mockery or disrespect that’s actively directed at a disabled person.

Ultimately, if you’re unfamiliar with the world of disabled people and their caretakers try to treat them like anybody else. Be considerate with your language because it does offend some. If you are a disabled person, caretaker or otherwise related…focus on the positives: people are fascinated, interested and occasionally legitimately concerned about disabilities. While some of them may be rude, punishing everyone for it only hurts us all.

Note: In case you missed the point, this post is NOT giving you license to say the R word any more than having an African American friend gives you the right to say the N word.

I’m not an economist but, as far as I know, the main law of economics is the relationship between supply, demand and value. If supply goes down, demand and value go up, etc. Digital content causes problems with this equation because it’s theoretically infinite. Since the content can be replicated perfectly over and over there is no scarcity of supply and demand can be instantly fulfilled, meaning value is zero. So: infinite supply equals zero value.

I’ve seen this point argued both ways with people in the middle saying that the supply is not actually infinite and so on. The truth is when you can replicate something as easily and perfectly as you can with anything binary, the supply is practically infinite. I also believe that the law of economics is true, meaning that digital content’s value goes to near-zero. The preachers-of-doom are right, content has lost its value. Does this mean that good content will die in favor of mass-produced, regurgitated garbage?

In the late 90s the infamous mp3 caught the music industry by surprise. The way I see it, there were two big catalysts. First, the development of the mp3 compression algorithm (I’m not sure exactly when this happened and I’m too lazy to look it up because I’m a blogger, not a journalist). Second, the steady increase in bandwidth at reasonable prices. Suddenly you could create a 10:1 compressed file of a song, at similar quality, and download it in less than 20 minutes on dialup. When DSL and Cable dropped in price it added fuel to the fire. I’ll skip the history lesson because you know what happened: Media piracy exploded via P2P networks.

Music, video game, film and other content industries freaked out and are still freaked out because the content they offer is increasingly under valued.

I felt this burn personally when I created Whirlygig for WP7. I’ll readily admit that Whirlygig is not a great game. It’s not bad, but it’s not great. And I couldn’t sell it for a dollar. After working for months on a game, pouring my sweat and soul into something, it was hard to accept that it was worth less than 1/3 of a Starbucks latte. I realized that my hard work had very little perceived value and, at the time, got pretty depressed about the future of indie game dev (which I now find ironic because I consider 2011 to be a pretty stellar year for indies).

I spoke at a mobile marketing conference in Houston in October, 2011 and, as part of my research, I looked at total volume of apps on the market. At the time iTunes had almost 500k apps, Android was nearing 250k and WP7 was working towards 50k for a nice round 800k number. I’m sure it’ll hit 1 million total apps soon. So, even without the digital music revolution, the sheer volume of choice makes the perceived value of individual apps very low because supply outweighs demand.

Industry pundits lament the demise of quality content, blah, blah, blah and indies like me either get burned out and quit or continue to do it for the love of it, without hope for financial success. The digital revolution has happened and there is no money to be made in content creation.

Or is there?

Every equation has inverse equations. If the value of digital content has dropped to zero it is a hard product to sell. But if you think of digital content as a resource and not a product it suddenly has enormous potential because it’s a FREE RAW MATERIAL.

In 1901 a blacksmith would have to put a moderate amount of labor into creating a tiny metal ring. Now there are factories in China that do nothing but churn thousands of them out a minute. The value of that tiny metal ring has dropped so much that it may as well be valueless. But Victoria Secret combines a few of those metal rings with some lace to create a $35 fancy bra [1]. There are two important things happening here. First, Victoria Secret is creating a high-value product from low-value materials. Second, there is artificial scarcity. While all of the materials exist in abundance, the combination is unique, hard to reproduce and thus valuable.

In 2003, some smart company created a way to deliver a product that was dropping in value and create a business around delivering that content. They called their product the iTunes Store and sold individual songs digitally instead of full, physical CDs. Apple took a material that was dropping in value and wrapped it in a unique service that created value. The industrialization of music was becoming complete.

This transition has been further realized by Spotify, Pandora and other streaming services. These services do not sell you songs as a product. You don’t pay for individual songs at all…you either pay for a service or even get it for free thanks to advertising. The songs are a raw material that powers the service as opposed to a product themselves. These companies have realized that content is getting harder to sell due to the volume available. Additionally, the volume itself creates its own problems that are solved by streaming services. They create playlists and stations of like-music that combine the raw materials (songs) into unique experiences (playlists) just like clasps and fabric in a fancy bra.

Smart game developers have leveraged this. SpryFox‘ created Realm of the Mad God (RotMG) and Triple Town, that leverage the exploding Free-To-Play (F2P) business model. In Triple Town you have a limited amount of turns that slowly recharge over time. If you run out of turns you can wait or buy more turns with real money. In RotMG you are limited to a single character at a time unless you buy more slots. You can also pay for cosmetic and other upgrades. League of Legends, TeamFortress 2 and countless other well-known games have similar models. Note that this is very different than in-game ads. In game ads generate some revenue but the model overall is not sustainable long term for any but the highest-downloaded games[2]. Additionally, it doesn’t really view the game as a raw material for a higher-level experience, it’s just a billboard for a different product that someone else is selling.

So F2P has circumvented the infinite availability by creating a scarcity of supply. You can play TripleTown for free and it’s a good game (this is a key point, more on this in a bit) but then you run out of supply (turns) after the demand has been generated (when the gamer has been pulled into the game flow). Suddenly the product has value. Even better, it creates a reliable revenue stream for the developer that enables them to add even more content and charge for that too. The game becomes a self-sustaining platform by managing its own supply and demand. But Triple Town’s model works because it is a good game at its core. The turn threshold is just long enough to get gamers into the flow but short enough that it runs out before you’re satisfied and the game is good enough that you want to keep going. So, even as I make the point that the value of content is dropping and that content has become a raw material, you have to have GOOD raw material to build a product on top of it. Weak content has no value as a product or a resource.

But I don’t think these events define the future of the industry. I personally do not like the F2P model in most cases. While I enjoy TripleTown, RotMG, League of Legends and other F2P games, they have gotten a minimum of cash from me (maybe $1). I paid the game price for SWTOR and the monthly fee to play. I also bought Skyrim and often buy indie games on Steam. I like to pay up front or at least know the fixed cost of a media experience. New indie markets are springing up and some indies are making it really big. Some people are content to stream music, pay for a service, and never actually own songs. I prefer to own my collection. Everybody has their own preference: mainstream markets, niche markets, F2P and other evolving models will coexist.

The point is that content creators need to understand the economics of the market. I think we all see and understand the what of the business models that rise around us but do we understand the why of it? Do we know which pie will give us the best exposure and the biggest slice? I discovered this the hard way when I worked hard on Whirlygig and realized that only close friends and fellow devs were really willing to purchase the game[3] and mostly out of the goodness of their hearts. The thing I still believe is core to any of these models: you have to create good content. Triple Town’s model wouldn’t work if the game didn’t really suck you in, gamers would hit the barrier and simply walk away. I personally hope to make Whirlygig better and integrate things that will keep people playing and maybe even find a way to make it financially worth it.

We content creators wear a lot of hats as we produce, market and deliver our content. It’s time to put on your economist hat and find the business model that will earn your shining content the revenue it deserves.

[1] I didn’t use the example of bras to be juvenile, I read about a Chinese factory that does nothing but create the metal rings used in bras in this National Geo Article and have found it fascinating every since.

[2] Here’s why ad-supported games are not viable long term:

1. Advertisers (usually brands or retailers) have a product to sell.
2. Advertisers will never spend more on ads than they make in sales and prefer that cost to be a predictable ratio.
3. Thus Advertisers prefer to pay for revenue-share on sales (exactly predictable) or clicks (fairly predictable)
4. Since the Advertiser drives the market they only buy impressions at high volume, for low cost.
5. New ad markets usually subsidize the impression payouts to get Publishers (developers, website owners, etc) to integrate their ads and have big enough impression blocks to drive deals with Advertisers.
6. Once the market matures, the Ad Market and Advertisers can forecast sales driven by impressions and stable prices are negotiated
7. Now that the Ad Market has predictable income they relax the payout subsidies and ad payouts drop for Publishers
8. The Publisher payout starts as a percentage of the Net Sales price of the Advertiser’s product and gets further cut by the Ad Market’s take

So, armed with the above knowledge, think about how likely that in-game ad is to actually drive a sale of an Advertiser’s product. Not likely. Eventually Advertisers will pull out of in-game marketing unless it either drives sales hard or gets really, really cheap. I have purchased ads as an Advertiser long enough to see this happen in several new web markets and I don’t think mobile will be any different.

[3] Note that Whirlygig doesn’t have a trial mode, which probably would have greatly increased the number of purchases. That being said, my research for the Houston talk drove home the point that the conversion rate (conversion rate = purchases / trials) for games is much, much lower than the conversion rates that online retailers and other businesses enjoy. All of the research I have done indicates that it’s easier to get someone to pay a dollar for a cup of coffee than for an app.