Tag Info

Hot answers tagged

33

We did, hopefully Ben Z will give a better explanation of the reasons than I can since he was actually the original author of our database. The short version is that relational DBs are not very useful for games because they cannot efficiently store heavily structured hierarchical data, which makes up the vast majority of data an MMO needs for normal ...


28

Okay this answer is more of an observation. Full disclosure I haven't worked on MMORPG. I have worked at what was one of the top 10 most visited sites back in 2009, and I have worked at game engine company that thought they were making MMORPG tech (I don't know if shipped). If you look at companies that have achieved massive scale (Google, Facebook, ...


22

How can files be used to keep track of players positions? You write the player position to the file. For example, if you identify every player with a unique number (or a GUID), you could use that as the file name. In the file, simply write the position data out in a format you can parse later. For example, 467239.txt might contain 20, 3, 19 if player ...


18

Would a noSQL database be suitable for a web-based game? Absolutely! Generally speaking, non-relational databases (such as MongoDB) are much better for games, as they are more flexible in how they model data, while being more performant than relational databases (such as SQL) - making them a "win-win" choice. What are the issues that might arise using a ...


17

Couple of words do defend SQL databases. 1 - If you have SQL database you can work with your data not only by primary key. Most of queries in MMO goes by PK but when you need to find all users with level > 30 what will you do in NoSQL world? 2 - If you have SQL language you may create "hotfixes" to repair broken data. For example: "update player_items ...


16

Basically, there's a whole range of approaches, and I think they're chosen based more on the experiences of their developers as much as the properties of the database. At one end, many MMOs are using standard relational databases - eg. Dark Ages of Camelot used/uses (are they still going?) MySQL, FreeRealms use a modified Postgresql, etc. Moving along the ...


15

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

It might not come up so much for a small personal game, but one hard problem when it comes to game data is multi-user editing/versioning. We use a lot of small text files that get baked down to a small number of binary blobs by a build process. This makes life easier for designers since they have a lot of flexibility in their workflow. CCP, as a counter ...


13

Your question is really broad because of the sheer number of genres out there, but here's the perspective of a professional software developer. You provided a list of criteria that you want to use to determine which data persistence mechanism you use. Those were: The size of the project. The platform targeted by the game. The complexity of the data ...


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

Minecraft saves the world data and the player data. Saving the world data is done in multiplayer and singleplayer with the same method. It saves everything in a single .mcr file. Previous versions of minecraft saved the data in a file structure with many files, which was slower, I think. I don´t know this exactly, but I guess that a database for world saving ...


10

I'm going to mildly disagree with everyone and say that the relational approach is reasonable here. What's interesting here is that items can have multiple roles. The main issue will be that the mapping between this relational layout and an OO layout in the code won't feel “natural”, but I think on the database side multiple roles can be expressed cleanly ...


10

While this proposed implementation is workable, it's not very scalable -- and scalability should be one reason you consider using something MySQL. You don't need a "database" to store items and shop/vendor data for a game, especially not a simple single player game. Simply storing the data in flat files (text, or XML, or some binary format you invent) would ...


9

I'm working on a TCG myself, so I have a little bit of experience with it. I would have a base "Card" table which would have the columns common to all cards, such as Name, Description, CastingCost or whatever. Then for each type you'd have the type specific columns which would foreign key to the Card table. The CardId can be both PK and FK in the ...


9

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


8

I like what Noel proposed on his blog. A telnet based variable tweaker. By using telnet he was able to use any telnet client to edit the variables. Later they built a gui around the protocol. It seems sufficiently simple, that it probably isn't worth a middleware library but looking at his code might be useful. I disagree with his anti-Lua sentiment ...


8

First of all, don't skimp so much on space. Even on shared hosting you'll get several GB of space and if you're not storing large binaries or entire books or something, CPU and memory are going to be bottlenecks before disk space is (usually). I thinking keeping int columns as small as possible is pretty old advice when disk space was more expensive than ...


8

My suggestion is to have your game communicate to a web service that you created that itself deals with querying the database. At that point, it's very simple to try different kinds of databases by "switching" web service implementations (your web service interface always stays the same so your game doesn't break) and decide which one is right for you. ...


8

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


7

On Pirates of the Burning Sea, we stared off with MySQL (though honestly I would've preferred Postgres) and when it started falling down under load, we switched to Microsoft SQL Server. Honestly, though, I probably won't go that route again in the future. Most of the PotBS data is pre-serialized before it's persisted anyway, so a large portion of what's in ...


7

The MMO terminology for "remain within a single game world" is single shard. EVE online is the only major MMO to attempt stuffing every player into a single shard. Lucky for you they published a very informative article on how they do it. The bad news. You cannot apply EVE online's techniques generally. Their solutions are absolutely tailored to their ...


7

SQLight does work with XNA, just don't expect any store procedures or functions. Any flat file will work to store data (XML, JSON etc). I prefer XML, though if I was using lots of data I would switch to SQLite


7

However, the amount of content could be potentially very high, and it may be too hard on the server's resources once the game grows bigger - userbase included. The other way to do it to simply hardcode everything in: What makes you think that a system can cope with it in hardcoded form, but not when it's stored in a database? Databases are designed to ...


7

I'm not familiar with TGC. I assume you trade cards and each card can be categorized into one of four types: tblCreatures, tblSpells, tblTraps, tblQuests If the four types are very unrelated, then I would split them into four tables, so you can manage each type independently, much like you outlined your tblCreatues. You would need to add a cardID to each ...


7

From a DB programmer passing by... It depends how different are your items. I think for your case, that you should have a main table, for all main shared fields, and additional specific tables for each specific field. The main table, must have a special field that indicates what kind of specific table relates that item. When you read info from the ...


7

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

It seems to me that you could just store the production rates, the base resource level, and a last-updated timestamp. Then, whenever you need to know the actual resource level, you could just multiply the production rate by the elapsed time. Whenever the actual resource level changes - simply update the base level. Whenever the production rate changes, ...


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



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