Tag Info

Hot answers tagged

31

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


26

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


17

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


16

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


14

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

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


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

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

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

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


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

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

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

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


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

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



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