C&C in 2.5d?

Of course the new style means that I can’t reuse any of the existing level / sprite images. The assets you see in the screenshot are all placeholders that I threw together in Illustrator this weekend. My app supports sprite tinting, as well as some other simple effect (like flip and rotate).

Replacing the art will take precious time away from coding, but it’s not as bad as it sounds. I’ll be able to put my XNA-inspired Android game lib through some heavier testing, and I’ll be able to add cutesy extras like avatar customization.

One example is in-app purchases. When Andrew originally wrote Creatures and Castles, there was only one set of levels. Shortly after his port to Chrome, he added a new level pack, which the player can purchase from within the game. The iOS version has no screen to select the level pack, since there’s only one. The Chrome version has a single screen with only two options (the currently-available level packs: Medieval and Egyptian).

The Android version of C&C has the benefit of hindsight. I know that new level packs will be made available via in-app purchases. While there will only be two level packs when C&C hits the Android Market, I’m redesigning the menu system to support many more options.

Similarly, there are only two characters that the player can select when they start the game. Both the iOS and Chrome versions present the player with a single screen with those two options. My plan for the Android version is to have the original artist create a few more variations on the characters. As with the level packs, the character select screen will support many more options.

So, I’ve been spending a good chunk of my time programming a new, generic model for player options, but there’s another hurdle to leap in the Android port — the unpredictable variety in devices. I’ve started down the path of creating vector-based assets for the menu system and fonts.

Menu assets will ultimately be pixel based (after all, OpenGL textures are pixel-based), but those assets will be generated for the host device from vector sources at runtime. That means that tablets and phones, big and small, should have images that appear to be tailor-made for whatever device you happen to be playing the game on.

I took a break from the programming this evening to create some vector-based assets in Adobe Illustrator. Here’s a PNG of the SVG that I made. Andrew is a little miffed that I drew stars (“they’re supposed to be shields, %#$@!”), but I’m generally satisfied with the result — especially considering that this is really just a test to validate my vector-based plans.

Test of Vector-Based Sprites for C&C

Remember, these images are based on vectors. While this looks like a traditional sprite sheet, and it will ultimately be used as a sprite sheet, the pixels aren’t set in stone until the game starts up. Every device gets its own version.

I hope it works as well in code as it does in my head.

So far, everything has gone according to plan. When developing for iOS and Chrome, Andrew was able to easily manage platform variances. For example, all iPhone / iPod Touch devices fall into one of two general categories – Retina, and non-Retina. When it comes to Android, it’s not quite that simple. A lot of wiggle room is afforded the hardware manufacturers.

I think of iOS development as a close cousin of developing for game consoles, where hardware consistency is your best friend. Android, on the other hand, is akin to developing for PCs. You’ll never be able to test every hardware variant, so you try to write code that adapts.

As time (and master Rollings) permits, I’ll try to blog about the technical details of the project as it progresses, and (more interesting to me) how my assumptions about the Android platform are validated or contradicted.

This week was spent with the family in GA, but I was able to get a lot of the menu code written, and do limited testing on a few hardware devices. Tonight, I added support for SVG images using a 3rd-party lib. Using vector art for the menus and options should make life a lot easier. We’ll see.

The Files

The update projects are compressed into ZIP files. They’re separated based on the section of the book in which the example was developed, with one exception — chapter 10′s project is a monster beacuse of the WAV source files. That project has its own ZIP file.

• Part 1 – Introduction [without CH10 - Audio].zip [2.04 MB]
• Part 1 – Introduction [CH10 - Audio].zip [46.80 MB]
• Part 2 – Genre Studies.zip [1.77 MB]
• Part 3 – Components.zip [0.39 MB]
• Part 4 – Tasty Bits.zip [coming soon]

Intuitive File Names

I used longer, more descriptive filenames for the solution files, project files, and directory names. The new names make it much easier to locate the source code for a specific chapter. This may cause issues if you do your development in a deeply-nested subdirectory, like the default Visual Studio project folder of “C:\Documents and Settings\{username}\My Documents\Visual Studio 2005\Projects\”.

I suggest creating a folder off the root of the drive from which you wish to develop your XNA games. I use “C:\projects\” on my laptop, and “E:\projects\” on my desktop.

Reach versus HiDef

There are two “Game Profile” options for your projects — Reach and HiDef. If you get an error along the lines of “No suitable graphics card was found”, you probably need to change your projects Game Profile to Reach. You’ll find this setting in the project properties, under the XNA Game Studio tab.

When converting the book’s examples to XNA 4.0, I’ve been setting the projects to the Reach profile. I’m working on a virtual machine, and it doesn’t support HiDef. Read about the differences for yourself, and see which is right for your game. In my case, I’d prefer that my examples work on as many hardware types as possible (Reach).

SpriteBatch.Begin

There were some changes to the parameters of the SpriteBatch.Begin method. Nothing Earth-shattering, but the changes did break many of the examples. I edited the calls to correct the errors where needed.

Chapter 5

The ResolveBackBuffer API has been deprecated. I rewrote the CaptureGameScreen method to use RenderTarget2D instead. This required changes to the Draw method as well. The general flow is (within Draw):

• Create RenderTarget2D object.
• Set GraphicsDevice to new render target.
• Draw stuff. (results are drawn to a texture)
• Set GraphicsDevice render target to null.
• Draw stuff again. (results are drawn to the screen)

Chapter 6

(Ugh.) The FillMode.Point enum has been removed, along with the FILLMODE = Point statement in HLSL. Point rendering is no longer supported as of XNA 4.0, per Shawn Hargreaves.

The simple fix (and the one that I chose) is to remove the point.fx shader from the example. If you REALLY want to render points, Shawn recommends converting each point to a tiny (single-pixel) triangle.

The “GraphicsDevice.RenderState.FillMode = FillMode.Solid” statement that was used in the example has been deprecated. You now need to use a RasterizerState object, which has a FillMode property.

Chapter 10

The previous version of XACT is no longer supported by XNA 4′s content pipeline. To fix this, I just loaded the XACT project (example.xap) into the new version of XACT and saved it (without making any changes). This automatically converted the project file to the new version.

Chapter 11

There were some significant changes to the storage APIs. I added a static helper to emulate the old APIs, based on the code found at this website. The two biggest changes are: all storage APIs are now asynchronous, and the container.Path property is no longer supported.

Chapter 14

The way that you load files from the game’s directory has changed. References to StorageContainer.TitleLocation have been replaced with TitleContainer.OpenStream.

Significant changes have been made to the GameFont class. See the notes for Chapter 21. In short, I recommend that you replace any references to the GameFont class with XNA’s built-in SpriteFont. The GameFont class is obsolete.

Chapter 19

As with Chapter 14, references to StorageContainer.TitleLocation were changed to TitleContainer.OpenStream.

Chapter 21

The byte ordering on internal storage for the Color struct has changed in XNA 4. BGRA is now RGBA. I tweaked the logic in GameFont, but the result is less than ideal. I do not plan to spend any more time on this code since XNA has provided support for in-game fonts since version 2. Changes include:

• Set the Properties / Content Processor / Premultiply Alpha of the image in the content project to false. This preserves the row markers, column markers, and encoded character data in the source image — but it makes the letters more “jaggy”.
• Set the Properties / Texture Format of the image in the content project to NoChange.
• In the GameFont class, replace Texture2D.GetData<uint> calls with Texture2D.GetData<Color>, and correct logic that depends on specific byte ordering with new Color-based checks. For example, “data[0] & ROW_COLUMN_MASK == ROW_COLUMN_MASK” becomes “data[0].A == 0xFF”.

While the changes that I made allow the GameFont library to work as before, I recommend that you no longer use it. Replace references to the GameFont library with XNA’s built-in SpriteFont. Consider this library an interesting look into how sprite fonts could be implemented, rather than as an example of how to draw text within your games.

Where’s Part 4?

I’ll try to get the source for Part 4 converted soon, but I can’t commit to a specific deadline. As with previous source updates for the book, I don’t expect the Content Pipeline example (from chapter 26) to be included in the conversion. There are plenty of other resources out there that provide guidance on this topic (see Google).

Thanks!

Thanks for your patience, guys! Enjoy the code, and let me know if you find any issues or need any help.

Oh, and if you’re reading this blog post and you’re asking yourself, “Book? What book?” — click here to see what the fuss is all about. You can read Chapter 07 here, and Chapter 18 here. If you like what you see, please feel free to buy a copy of the book here.

– joe