General

Re: Best Practice for a string table?

Zero Serenity — Sun, 24 May 2009 05:14:15 GMT

I think I've got the idea now. I'll give it a shot and come back with how well it works.

Re: Best Practice for a string table?

Daniel Hanson — Sun, 24 May 2009 05:00:05 GMT

If you're only releasing your game on Xbox, then don't worry about it. None of your consumers will ever be able to crack open your game and sift through the files. So that shouldn't be a concern.

Even if they could, they wouldn't see XML files; they would see XNB files, which are the serialized binaries of your XML files. The Content Pipeline exists as a part of your build process. Just like how the C# compiler takes your .cs files and compiles them into binary executables, the Content Pipeline will take your assets (including .xml files) and compile them into .xnb binaries that are loaded by your game. You should not be concerned about people reading your XML files any more than you should be concerned about them reading your source code.

Re: Best Practice for a string table?

Zero Serenity — Sun, 24 May 2009 03:08:21 GMT

I read this, but I'm still confused. It basicly tries to explain serialization and what it does when cached, but implementing this in a useful state doesn't seem to be the objective.

Re: Best Practice for a string table?

Kris Steele — Sun, 24 May 2009 01:56:40 GMT

Zero Serenity:
Great, but I'm a tad confused a bit. The articles I'm reading seem to be just stuff that says to make XML files, but they can obviously just be opened with something as small as notepad and give away tons of information or can be edited. So I'm not sure how this is a help. It also mentions "Serialize" a lot, which is a concept I don't understand. I read the articles but couldn't follow the concept. I would like to release this game as a XNA Xbox game when it's done (and aproved) but if I cannot I'd like to just throw it out there as a PC version, which is a lot easier to just browse through the files.

Serialize is the process of converting something into XML (for instance a class or, on the web, your most recent news).

If you include the XML in the content pipeline, it will get compiled and won't be so easily editable.

Re: Best Practice for a string table?

Zero Serenity — Sun, 24 May 2009 01:52:31 GMT

Great, but I'm a tad confused a bit. The articles I'm reading seem to be just stuff that says to make XML files, but they can obviously just be opened with something as small as notepad and give away tons of information or can be edited. So I'm not sure how this is a help. It also mentions "Serialize" a lot, which is a concept I don't understand. I read the articles but couldn't follow the concept. I would like to release this game as a XNA Xbox game when it's done (and aproved) but if I cannot I'd like to just throw it out there as a PC version, which is a lot easier to just browse through the files.

Re: Best Practice for a string table?

khalos44 — Sun, 24 May 2009 00:50:19 GMT

Shawn Hargreaves Blog has a lot of stuff. Look under the Content Pipeline and intermediate serializer headings
Nick wrote a good article on Ziggyware.
There is a Localization sample on this site that uses this method. (Check it out even if you don't plan on supporting more than just English)
And of course, Google.

Good luck!

Re: Best Practice for a string table?

Zero Serenity — Sun, 24 May 2009 00:32:20 GMT

This sounds good, got a primer? An MSDN doc? Anything?

Re: Best Practice for a string table?

Daniel Hanson — Sat, 23 May 2009 22:19:09 GMT

XML files will do that nicely, since they are built into a separate XNB file. I think (don't take my word for it) resource files are embedded into the binary, so they may not be the best solution for your needs.

Re: Best Practice for a string table?

Zero Serenity — Sat, 23 May 2009 21:48:32 GMT

Craig Martin:
XML is easy to edit manually and it gets compiled into the XNB binary format for deployment.

This, I think. Let me try this a little more in depth. What I want are basicly language files. Stuff that I can hotfix out of the main executable for whatever reason, then deploy it whenever it's done, updated or whatever.

Re: Best Practice for a string table?

Danny Tuppeny — Sat, 23 May 2009 12:59:40 GMT

GregA:
Nowdays I wouldn't store anything in a database unless you have some specific database need. Look at the complexity of model files, and those are essentially just flat files. I like the idea of either XML or making const classes with all of your text in them. Then you are an easy step (and a translator or three ) away from multi language support.

But my question fits in here nicely. I'd like to store text attributes, like bold, italic, and color. Is there some cheap easy way to parse out escape codes in XNA?

I think you'd need to use different fonts. I can't think of an easy/nice way to do it. You'd need to come up with a method for storing which font/index in the string and parse through it. If you did it in XML you could use the possibly content pipeline to convert a nice format to a quicker format at compile time, eg:

<String Name="GameOver">Game <B>Over!</B></String>

Could compile into a class like this:

public class GameString
{
    public GameStringPart[] Parts;
}

public class GameStringPart
{
    public SpriteFont font;
    public string Text;
}

Then you could create an extension method on SpriteBatch so you have:

spriteBatch.DrawFormattedString(gameOverGameString, location, etc.);

Then loop through the GameStringParts "DrawString"ing them, keeping track of the width (with MeasureString) to do the next one.

Re: Best Practice for a string table?

GregA — Sat, 23 May 2009 12:17:44 GMT

Nowdays I wouldn't store anything in a database unless you have some specific database need. Look at the complexity of model files, and those are essentially just flat files. I like the idea of either XML or making const classes with all of your text in them. Then you are an easy step (and a translator or three ) away from multi language support.

But my question fits in here nicely. I'd like to store text attributes, like bold, italic, and color. Is there some cheap easy way to parse out escape codes in XNA?

Re: Best Practice for a string table?

Craig Martin — Sat, 23 May 2009 12:04:47 GMT

XML is easy to edit manually and it gets compiled into the XNB binary format for deployment.

Re: Best Practice for a string table?

Danny Tuppeny — Sat, 23 May 2009 11:32:47 GMT

Zero Serenity:
second is somehow not be editable by anything else

Can you explain what you mean by this? I was also going to suggest Resources. They can't be modified by the player on the Xbox, but I wonder if you mean on the PC. Is this to stop people replacing the resource file in the game folder on the PC?

You could potentially store a checksum of the resource file and check that, but it might be a PITA to keep changing.

You could also try a static class in the game with a load of public constants:

public static class Strings

{

public string const GameOver = "Game Over.";

public string const PressAToStart = "Press A To Start";

}

This is easily editable in one place (not sure if it meets your "editable in VS" requirement) but not editable easily on the PC (Note: with Reflector, this might not be as hard as you think, depends who you're trying to protect it from).

Re: Best Practice for a string table?

Daniel Hanson — Sat, 23 May 2009 04:04:37 GMT

Shazam.

Edit: Oops, just read about your "not editable" comment. Not sure what you can do with resource files in that regard.

Best Practice for a string table?

Zero Serenity — Sat, 23 May 2009 03:57:28 GMT

Let me qualify what I want to do here first. I'm making a game with lots of dialog. Stuffing it all into hardcode in the game is probably a bad idea, so I'd like to use an external file to hold all the dialog. Two requirements are really needed, first one is it can be easily editable from within VS and the second is somehow not be editable by anything else either by encoding or passwords. Sofar the only thing I can come up with is Compact .NET Database which seems to be suiting the purpose quite well, but there's a bit of lag to it. Is there any better ways?