85

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


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


13

The Position must be in RAM while in use. (ex: player's character is in the world) You cannot use the DB as operating memory. Well you can, but this will be terrible. You should save the positions regularly, but not every time they change. I would also avoid saving all positions at the same time. If you want to maintain persistence in case of a server ...


11

If you think a 2D RPG is so complicated that you not only need a database, but also a ORM to simplify the interfacing to that database, then I'd suggest you probably haven't yet studied the game mechanics yet. Do bear in mind that we had Zelda in the cartridge era where you might have had 256 bytes of battery-backed RAM to save the current state of the game ...


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

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

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


7

Database Updating You should really use a message queue - chances are your SQL DB will fall over when you hit it with this level of concurrency (deadlocks etc.). I have heard that RabbitMQ is quite good. Remember that once your data is in the MQ it's as good as it being in a database - MQs are just designed to process a lot of messages and allow other ...


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

You don't need a database for a turn-based RPG, just store your save game data in an object and serialize it to disk. You can serialize binary or serialize to something readable like XML which you can then later import easily via the content pipeline importer. Requiring users to have Access, or any other non-integrated database, installed next to your game ...


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

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

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

The database is the backend, your game is the client. Since you can't (well, technically you can but you really shouldn't) connect to the DB directly, you'll have to write some kind of middleware for that. The middleware usually runs as a web-service or deamon on a server and exposes an interface for you to access/store game data. This stuff can be ...


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


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