Hot answers tagged

17

Dialogue could be provided in any form/structure you wish it depends on how you parse the information that makes the difference. I will provide you with a basic XML syntax to get you started without understanding your games structure or language I afraid i cant provide an implementation. <?xml version="1.0" encoding="UTF-8"?> <npcs> &...


11

The XML describes one instance of a mob, i.e. the traits of one specific mob (it's personal personality and intelligence). The Java class describes the general structure of all mobs (their traits: personality and intelligence). Typically, a game engine would serialize the XML data at runtime to create actual Java Mob objects (= instances of the Mob class).


10

Databases have a quite different use case than file formats like XML. File-Formats like XML: Are saved once and loaded once per application start-up. Since they are loaded once the access time after the loading is extremely fast. Used for serialization and deserialization as well as configuration files. Databases: Are for the most part constantly in ...


9

When you put all languages in one file, no two translators can work with the same map at the same time, because there will be edit conflicts. You also have to train your translators how to edit your level files. XML might seem intuitive to a programmer, but to a non-technical person it isn't. But when you use a string file for each language, all translators ...


8

Im late to the party here but I spent A-LOT of time researching this. First why I don't use the following: XML: Excessively verbose. Tons of redundancy. Repeating field names? GROSS JSON: I think JSON is great for a UI layout but for a database, hell no. It will have the same problems as XML, redundancy, and deep nesting. GROSS. SQL: This is a great ...


6

Maybe I didn't explain fully, You implement the loading of the XML to the Class instance ensuring meaning in theory it could just as easily be any data format, json, flat file, Database its how you use the data that decides what it means. The example i provided was instantiating a new instance of IPersonality based on the String within the tags public ...


6

Take a look at Tiled. It has support for Isometric maps and stores them as XML.


6

Good guess, XML is not by default the simplest method of storing plain text data. It depends on a lot of things, mostly what existing tools you are planning to use. Some questions to ask yourself before choosing XML: Do you feel XML editors make you (or your team) more productive? (If you are a programmer, used to a text editor, the answer is probably no.) ...


6

My preferred elegant solution is this: The English text in any file (or whatever your base language might be) must be passed through a translation function before display. The gist is that your string table(s) consist of the English version of the string followed by the localised version(s) of the string, and your translation function takes the english ...


5

There's no single "best" way to do this, it depends on the needs of your game. Here are some options: Hard Coded Both the easiest and probably least flexible approach. No reason you can't just make a static class with static fields for each of the levels. Actually, this isn't a bad way to prototype, so you can move it into some other approach later. If ...


5

There may be a way to do this with the content pipeline, but I have done it without and instead used standard XML Serialization. The approach I am about to show is just one way you can structure your data and may or may not be relevent to what you are trying to accomplish. My goal with this answer is to provide you enough direction so that you will be able ...


5

If this is just simple, local information, then storing it in any kind of "database" is massive overkill, let alone something like MySQL. SQLite might be appropriate. These data seem to be for game concepts. So don't forget: you need to author this data. It's a lot easier to hand-edit XML/JSON/etc than it is for some kind of database. You can even develop ...


5

Although XML is more predictable, kinda have a defined structure and all that. I would go with scripts. Rolling your own language(if you have the time, but usually this is not the best choice), or even implementing one. There are LOTS of script languages out there, they're all nice, some examples: Squirrel, Lua, Angel Script, Python, and many many many ...


5

You'll want to use a List. Probably a List<InventoryItem> or similar. The documentation for List<T> is here. Here is a set of answers on how to serialize a list to XML (you didn't say how you were saving your XML - this link gives you some options). An XML file can store the list of items "inline", so it might end up something like: <...


4

In case of the zeroes and ones, you have to split with "", but in case of the tile-numbers this doesn't work as it would create an array entry for - and 1 when the value should be -1. But luckily you have a delimiter , which you can use. So instead of levelTiles = levelTiles.split("\n").join(""); levelTiles = levelTiles.split(",").join(""); tileArray = ...


4

You should generally prefer structured data (XML) over scripts at every opportunity. The biggest reason for this is tool support. You can make a dialog editor for a structured format, which supports internationalization, dialog branching, testing a debugging of dialog trees, deadend and infinite loop detection in trees, etc. For a script, the only thing ...


4

The content project supports XML files, and it uses a special type of serializer called IntermediateSerializer, which is better suited for game data than XmlSerializer. No need to read your PlanetData and figure out how to convert it to a Planet, you can directly serialize a Planet and have it seamlessly loaded at runtime. In your editor, you can create a ...


3

There's definitely ways to make this a lot less tedious. Your level file should describe the entities and their relationships in the world, so that when you deserialize the XML through ContentManager.Load, you get a Level instance that is ready to use. No additional processing needed. The reason you find it tedious is because you are MANUALLY adding all the ...


3

You don't. Content is for loading objects compiled by the content processor. However, you can add the xml files to the content project and have the project copy them to the deploy location without compiling them. If you do this you can use relative paths to access the content. To do so put the XML file in your project as you normally would, change Content ...


3

Instead of going for the manual copy solution, you can opt to go for the StreamingAssets route. Create a folder within your Unity project named "StreamingAssets" and place your XML files in there. Upon build, Unity will then create a verbatim copy of this directory. Your XML files will be accessible at string path = Application.dataPath + "/StreamingAssets"...


3

XML files do not get merged into a single XNB, unless you have a custom content processor that you've specifically configured to do so (you'd know if you had, it's a non trivial process). I recommend going with whatever file structure helps you develop most quickly, and in the end if you have a tremendous number of files you may want to consolidate them ...


3

Resources like shaders, textures, fonts, etc. Each live individual XNB files after being processed by the content pipeline. XML files may be used as an index of resources and configuration data, but I'm having a hard time imagining a situation where it would be beneficial to include the XNB contents within the XML. Given that, XML files are typically ...


3

I would look heavily into state machines and deserializing the XML data into state instances. You can create class definition for a condition, be that an integer on an item for it's int brightness = 4; value or a string name = "torch"; in the inventory. Something along these lines: public enum ConditionType{ default, itemLevelReq, itemEquip, ...


2

Maybe take a look at tIDE? It's a XNA 3.1/4.0 solution for using tiles. It also has support for Tiled and Mappy (suggested in the other answers). And to answer your basic question, XML is the way to go.


2

Not exactly what you were asking but might be of interest to you. Do you know Mappy Tile Editor ? it's very popular in the subject You could get some inspiration from it or there is the extension for XNA you could use : XNA Content Pipeline Extension to Mappy Maps(.FMP). This way would save you some time : you won't have to write a ContentImporter and a ...


2

It really depends on the engine or tools used internally by the developer. The simplest method of storing data is, in fact, XML, or XML-like syntax. The format for models will probably be something different; for example, Unity uses the FBX format for it's models (and it can also import MAs and MBs, Maya's format). The format for textures would be any ...


2

You most definitely want to use something like XML or JSON if a plist if what you're familiar with. Take a look at some of the available libraries you can use to parse either and store your data like that. A simple XML file might look like this: <Data> <NumberOfEnemies>20</NumberOfEnemies> <SpawnSpeed>60</SpawnSpeed> &...


Only top voted, non community-wiki answers of a minimum length are eligible