XNA Creators Club Online
Page 1 of 1 (15 items)
Sort Posts: Previous Next

Best Practice for a string table?

Last post 5/24/2009 5:14 AM by Zero Serenity. 14 replies.
  • 5/23/2009 3:57 AM

    Best Practice for a string table?

    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?
  • 5/23/2009 4:04 AM In reply to

    Re: Best Practice for a string table?

    Shazam.

    Edit: Oops, just read about your "not editable" comment. Not sure what you can do with resource files in that regard.
    Previously known as "Rainault".
    Twitter - me, Jade Vault Games
    Announcing ASCII Quest, a Roguelike under development for Xbox LIVE Indie Games
  • 5/23/2009 11:32 AM In reply to

    Re: Best Practice for a string table?

    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).
  • 5/23/2009 12:04 PM In reply to

    Re: Best Practice for a string table?

    XML is easy to edit manually and it gets compiled into the XNB binary format for deployment.
    Game hobbyist hell-bent on coding a diabolical Matrix
  • 5/23/2009 12:17 PM In reply to

    Re: Best Practice for a string table?

    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?
  • 5/23/2009 12:59 PM In reply to

    Re: Best Practice for a string table?

    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.
  • 5/23/2009 9:48 PM In reply to

    Re: Best Practice for a string table?

    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.
  • 5/23/2009 10:19 PM In reply to

    Re: Best Practice for a string table?

    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.
    Previously known as "Rainault".
    Twitter - me, Jade Vault Games
    Announcing ASCII Quest, a Roguelike under development for Xbox LIVE Indie Games
  • 5/24/2009 12:32 AM In reply to

    Re: Best Practice for a string table?

    This sounds good, got a primer? An MSDN doc? Anything?
  • 5/24/2009 12:50 AM In reply to

    Re: Best Practice for a string table?

    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!
    Kyle Zimmerman
    Anti-Force
    Follow me on Twitter! : Twitter
    Working on: ElectroStatic | AntiForce Editor
  • 5/24/2009 1:52 AM In reply to

    Re: Best Practice for a string table?

    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.
  • 5/24/2009 1:56 AM In reply to

    Re: Best Practice for a string table?

    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.
  • 5/24/2009 3:08 AM In reply to

    Re: Best Practice for a string table?

    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.
  • 5/24/2009 5:00 AM In reply to

    Re: Best Practice for a string table?

    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.
    Previously known as "Rainault".
    Twitter - me, Jade Vault Games
    Announcing ASCII Quest, a Roguelike under development for Xbox LIVE Indie Games
  • 5/24/2009 5:14 AM In reply to

    Re: Best Practice for a string table?

    I think I've got the idea now. I'll give it a shot and come back with how well it works.
Page 1 of 1 (15 items) Previous Next