So let's quickly summarize XMLImageLoader & XMLImage, by defining what they are, what they accomplish, how they do it, etc. etc.
I'll try to keep this short.
XMLImageLoader takes an XML file and reads through it. The format of this file is as follows (and currently resides as /texture/textures.xml):
<?xml version="1.0"?> <imageset> <image> <name>grey</name> <width>16</width> <height>16</height> <file>grey.png</file> </image> <image> <name>red</name> <width>16</width> <height>16</height> <file>red.png</file> </image> </imageset>
So, as you can see, there are multiple (and, technically, there could be infinite) elements called "image". Inside each is a name, width, height, and file location. XMLImageLoader will read through this XML and put each image element into a XMLImage object. This object will then attempt to load the texture. As a precautionary effort, I have made it so that if the XMLImage class cannot find the image file, or it fails to load for any reason, a boolean value is set to false (notifying the program that this file failed to load), and a default texture is loaded. This way, artists wishing to test new images who make a typo somewhere or otherwise mess something up, can easily identify the problematic texture and investigate what exactly went wrong.
Furthermore, once an artist is on-board with our team, I want to add support for texture packs, and easy reloading/swapping of the texture packs with a keypress in-game. With this, artists can easily see what looks good and what doesn't.
Texture packs would be accomplished by having a file in our main texture directory, perhaps called "texturepacks.xml". In addition to this file, there would be several directories, each containing appropriate imagery and a "pack.xml" (name subject to change) file. "pack.xml" would be essentially what texture.xml is right now, and texturepacks.xml would simply be an index of all the texturepacks installed, and, if any, their respective variables.
Moving on, I'd like to speak a bit more about the actual game. We will absolutely be including local multiplayer, likely only two-player, though. We'd like to add support for the 360 controller, as well, since this is a very simple thing to do.
"AwesomeSnake" (as we love abbreviating our games with the word "Awesome") will have a nice little configuration file that can be editted. For the sake of user simplicity, it will not use XML, and will instead be a simple text based configuration (ie, player1_color=#FF44DD). Due to time constraints and the hassle of adding in menus, we will likely not include an in-game config editor. Writing text input code is a pain in XNA, so we'll put that off until the next project.
Multiplayer will be an interesting addition to this. I'm thinking co-operative and versus modes will be included, so as to suit all playstyles (and really, it's just a difference between one score, and two scores).
I didn't keep this short. Oh well.
No comments:
Post a Comment