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

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


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


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

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

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

Don’t. You cannot secure your password indefinitely. What you can do is restrict access remotely. I don’t know anything about trello, but if it allows multiple logins with multiple permissions, you could create a user with more restrictive permissions and include those credentials in the game. Another alternative, if this is not supported, is to make a ...


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

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

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

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

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


4

What you are trying to do here unfortunately can not work. The MongoDB protocol is based directly on TCP/IP. But a web application running in a web browser can not create raw TCP/IP connections. There is no API in JavaScript for doing that. The closest it gets are HTTP requests ("AJAX") and WebSockets (which are intentionally incompatible with ...


4

Multi-user concurrent transaction support will be required if you have multiple designers who are not actively deciding who will work on the data at such-and-such a time. Without this, data can be corrupted. Implementing such an advanced feature yourself, would consist of far more effort than it would be worth, when you are only trying to write a game. Large ...


3

For the sake of making changes faster, it speeds up development on larger productions by tons. You don't need to teach everyone to learn how to go in and edit source to make simple changes. By dragging it out of the actual code, more people get the chance to fool around with, it's easier to find out what options you can play around with and the whole ...


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