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


39

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


32

The trick Elite likely uses is that they don't pre-generate the whole galaxy and store it in a database. They likely generate most of the galaxy at runtime when it is needed. I would do this using a pseudorandom but deterministic algorithm which can generate the properties of every object in the galaxy at runtime just from its position. So when a player ...


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


9

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


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


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

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

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

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

Databases usually only make sense for data "at rest". As in data which someone might or might not look at at a much later point in time and which you want to be searchable by different keys. If you aren't going to do that, using a database usually doesn't make any sense. When you have a real-time game, you should store all data you need for your ongoing ...


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


5

First of all, consider if it is actually necessary to break down the world into units of storage. 32x16x32x16x16x16 = 67,108,864 blocks. When each block is a 2 byte integer representing the type-ID, your world is just 128MB of data. All but the most low-end platforms should be able to handle that in-memory. But let's assume that you already tried that and ...


5

I would generally not use a SQL database (not even SQLite) for handling static data in a singleplayer game. The only exception would be if I had so much data that it won't all fit into RAM. But when the data is less than a couple hundred MB, I would look for a solution which loads all the data when the game starts and then allow the game to access it ...


4

If you're expecting to have 180+ different types of characters, even if they are constructed via different combinations of components, you definitely don't want to hardcode the choices and guides for them. You're going to want to write a generic solution. You can start by sorting out the different layers of base types and components that will be attached ...


4

The content creation perspective: RPGs tend to be quite text-heavy so you and your team will spend quite a lot of man-hours writing, proof-reading and maybe even translating the dialogs. It might pay off to make this process as comfortable as possible. Pure Javascript objects have the advantage that you can more easily integrate functions into your dialog ...


4

Database access is always an expensive operation. For that reason it should be minimized as much as possible. In an ideal case, you would read and write the player data once per session: When the client connects you read it, and when the client disconnects, you write the changed data back. In the meantime it should be kept in the memory of the gameserver. ...


4

It is suitable, though perhaps not ideal. First, do note that ProtoBufs are no longer state of the art in its class. Consider Cap'n Proto, Fast Buffers, or Flat Buffers. I'm personally a fan of Flat Buffers these days, but I'm sure there's already something even better out there; this is hardly a "solved" problem. For serializing game data, you ...


4

You will need three tables: Player, PlayerInventory and ItemType. ItemType stores the shared information by all instances of that item, like the name, maximum stack size, minimum exp, appearance and other properties. Primary key should be an integer-id. The advantage of storing these properties centralized is that if you decide to change the game balance ...


4

You probably do want to communicate to this information to the client so that they are able to view it. You can treat the client as a dummy terminal though with sparkly representation and have a "neutral" server as the authority. Lets consider League of Legends in this context. At the beginning of the game, each client connects to Riots servers. Every ...


4

Quick Answer: What your code actually currently does is compare references to check that they are the same, not the values of those references. Try changing print("is the following true or false" + i.type.ToString() == type); to print("is the following true or false" + string.Equals(i.type.ToString (), type)); When you use string.Equals, you're ...


4

Unity does not include a server side persistence solution out of the box. As far as I can tell the only storage solution Unity includes is PlayerPerfs, but that is client side. However that does not mean you have to create a SQL database. Some games use services that provide a nice interface for NoSQL databases (for example MongoDB via GameSparks or ...


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