84

There are several reasons for that. I'm just gonna touch on a few: It makes your source code a mess. If you have a lot of dialog (trees), a huge part of your codebase is just text that has nothing to do with your actual game code. You'd need to recompile every time you change so much as a single character. The dialog itself is hard to navigate. I imagine ...


66

This is not for performance. This is a failsafe. If the world saves every few minutes, then if something happens to the server and it shuts down everyone will only lose a few minutes' progress. By saving on disconnect, if the server has an issue everyone will lose everything they have done since they logged on. For those on particularly long play sessions (...


38

When you are comming from non-game application development, then you need to be aware of a couple things. Relational databases have a niche role in game development. You really only need them when you have a massive multiplayer game where most of your players are offline most of the time. There are also some niche applications like online scoreboards or ...


26

Only use a database if you need a database. That is: If you need to perform complex queries often. If you have complex data relationships. If your data is huge and is not likely to fit in memory. If your game's data satisfies any of these conditions, you might benefit from using a database. Note that these are not very common, and you probably don't ...


17

Test case of 500 players all communicating, that's 250K streams of information flying around at 20Hz. The internal bandwidth for that would be, assuming 100 bytes each message, about 500MB/sec. Sounds ambitious. Especially between processes. If you segregate players to groups of 100, that lowers to 20MB/sec, and so on. Which is why MMOs have zones, and ...


11

An SQL database is not nearly fast enough to use for realtime reading and writing game information. Such data is almost always kept in memory, in traditional data structures. There may be some benefit to using an embedded database such as SQLite for certain types of data, eg. static data that doesn't change during gameplay but does change during ...


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 ...


8

Read in the data from a file. 648 lines of data, one line per unit type. Store that into an array of 648 unit prototypes. Either write the data by hand, or write a tool for it. You might consider writing the values in Excel and exporting a CSV file. (parsing suggestions here.) Once you have the data in memory as an array of unit prototypes, making units is ...


8

As implied by the name, PlayerPrefs is mostly intended for storing config options. But it can also be abused to store savegame data, if that data is rather small. If you target platforms without write-access to a filesystem (like WebGL) then it might in fact be your only option to persist data without relying on external online services. However, if your ...


7

As always, as always, it depends. But first, I would like to argue that hard coding is not bad by itself. I have hard coded content, specifically dialog text, in some simple games, and the world didn't end. We programmers love abstracting things, but remember that each layer of abstraction you make will make your program more complex and more difficult to ...


6

I first thought I would simply put it in the (MySQL) database Sounds good! but I think it will be too much. Then you don't know the limits yet. Seriously, just throw everything in a database. Don't care about performance too much at this stage, if it becomes an issue you can fix it later. Here's an abstract view of what your database could look like: ...


6

Regarding that link you posted: The creation of a SQLite Database has nothing to do with XML, nor is XML needed. What you see there is a MXML document, a special XML flavor introduced by Macromedia/Adobe. But the majority of this document is just plain Actionscript 3 (wrapped in <mx:Script> tags). So you're going to use Actionscript to create and ...


6

First, let's separate your data. A player table could look something like this: Player ------------------ id INTEGER PRIMARY KEY AUTOINCREMENT name VARCHAR(255) While an item table could look like this: Item ------------------ id INTEGER PRIMARY KEY AUTOINCREMENT name VARCHAR(255) Note that I haven't added anything fancy like effects or ...


6

The key phrase you're looking for is game state serialisation. Game state is what it says. Your game has some sort of structure to keep the current state of the game. In an RPG game, you want to store the list of quests the player is on, how far they are into those quests and what their characters' stats are. Serialisation is the reversible conversion of a ...


6

Database reads are usually via network and from hard-drive. That means database queries will always take a few ms, no matter how simple they are. Databases can get faster with in-memory techniques and smart database designs with good indexing concepts, but their speed is often still insufficient for real-time processing. Blocking your process while a ...


6

Your server would have some kind of background process (could also be implemented as a timer or a thread) which runs at regular intervals and updates all players. The process would run daily, hourly or every few minutes depending on how often you want the players farms to update and generate resources. Any online players would get notified immediately that ...


5

Raknet has an abstraction for a Lobby system (friends, rooms, emails, ranking) with different backends. You can choose between your own PC Lobby server backend (the "simple poor man's version" as you called it), or use their implementations for services like XBox Live, Steam, Games for Windows Live, in case you find out later you are allowed to publish on ...


5

A database isn't fast, using a database is a whole lot slower than traditional memory access. The reason is simple, a database is dynamic, there is a bunch of overhead attached to it, the queries need to be parsed, hashes need to be computed and other stuff. There are is only one advantage from using a database and that's persistence. You can run one or ...


5

I would also go for the ID solution. You should give every object in your whole world (not just on the current map) a unique ID. A 32 Bit int should be sufficient. Further every object can store a state value, also a 32 Bit int value. You can squeeze a lot of information into 32 Bit, e.g. you can make 32 flags out of it to store 32 bool values. Or you can ...


5

It depends on the developer. But I'd say ints are more common. It's generally far more efficient to use an int for both network communication and storage. You need to be careful to ensure int IDs are "stable" - that you don't insert or remove an enum value, except adding news ones at the end of the list. Otherwise your data breaks. For data source, ...


5

Use area of interest filtering. If a world is broken into 3 servers, and the area on server 1 is nowhere near the area of server 3, there's no reason for them to share information about entities at all. Likewise, on a single server, only send relevant information to clients. If player A is on the totally opposite end of the map from player B, there's zero ...


5

If you're willing to ease on the requirement that a client should be informed of other clients that are exactly 200 blocks away or closer, then here's an idea: split your map to squares of, say, 200 blocks each side. Then you can keep track of where the client is, and inform the client of all other clients in the adjacent squares. More detailed discussion ...


5

This is probably not the answer you were hoping for, but I think the best way to implement this is to use both inheritance AND interfaces. The inheritance tree you describe above seems pretty good, in that it's fairly complete (you may find you want to add some extra abstract classes for common functionality between some of those branches, but that's an ...


5

I would probably start with the following schema: Slot (ID, CharacterID, SlotID, ItemID) where Slot is the name of the table ID is the table's primary key CharacterID is a foreign key that points to the character SlotID is the slot's ID going from 1 to 64 (or 0 to 63, or whatever) ItemID is a foreign key that points to the item (ID of a specific weapon, ...


5

From a performance standpoint, having data in memory is orders of magnitudes faster than having it in a database. There are two reasons to put data into a database instead of storing it in memory: You have more data than fits into memory You want to make sure no data is lost in case of a (intentional or unintentional) server shutdown As you already said, ...


5

I really like MongoDB for game develpoment, it has a really good performance and it's really flexible, easy to use and json-based. You can just add any field you need in any collection due it's NoSQL Arch, so it fits really well in any "dynamic" enviroment like games. Give it a peek. If you are developing some kind of MMO Turn based strategy game, ...


5

I'm inclined to assign this task to the server for security and integrity reasons, but i'm not sure on the way i can accomplish that. Yes, definitely; never trust clients. Clients sometimes "predict" what is likely to happen to help isolate the user's graphical experience from their network conditions, but any actions that could affect the outcome of the ...


5

Early systems that saved only on disconnect tended to also save periodically while the player was active. In those systems, typically MUDs (Multi-User Dungeons), the character was maintained in memory until they were periodically dumped to a file. This meant that if a user disconnected without "camping", they usually found themselves several rooms away and ...


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