1000 player may or may not be a problem. It depends on how often you need to update the database. However there is a simple solution: put the database on its own server.
I had a peek at how the database system works a game that people would call an MMO-Lite – which one I will not disclosure – yet I can tell it consistently has more than 1000 players, this ...
Both approaches are used with MMORPGs. Keeping everything in memory and periodically check pointing it to disk seems to be the most popular option, at least for older games. It has the advantage of being fairly simple to implement and scaling fairly well, but making it reliable is completely up the to the developer. SQL databases provide ACID properties ...
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 ...
Never, EVER, should you give the client the password to anything.
Never, EVER, should the client be executing queries themselves.
So a solution is put a service between it, let the user have a session from whatever your service is written in and store the user id in there, don't let the client pass along an arbitrary user id.
You'll want to use a List. Probably a List<InventoryItem> or similar.
The documentation for List<T> is here.
Here is a set of answers on how to serialize a list to XML (you didn't say how you were saving your XML - this link gives you some options).
An XML file can store the list of items "inline", so it might end up something like:
A window handler should not be an entity property. As you said it will be retrieved every startup. So no need to store it as property. Store the handler in a subsystem responsible for dealing with windows.
Your meshes: the entity properties should contain everything to recreate the meshes, but not the meshes themselves. Read the necessary data from the ...
First, it's handy to have an idea of "archetypes." This is some data that defines a type of game object and which components it has and what their data is. For instance, you might have data file like:
If you're really worried about the storage most of all, the maximum you'll have to store is half the map, plus one bit. The first half of the exploration, you keep track of where they've been. Once they reach halfway explored, you switch over to keeping track of where they haven't been and flip you bit. This will cost you a performance hit when you need to ...
Theres two basic ways to do this:
The Magic Bag
Containers themselves have fixed sizes, but there's no limit to your ability to put "bags" inside other "bags". Thus the only practical limit on your inventory is your ability to get more "Bags"
This has the advantage that containers have fixed capacity (which might be easier to implement), and that you can "...
For XNA you can use isolated storage to be able to store data in a cross-platform manner.
You can find the documentation here: http://msdn.microsoft.com/en-us/library/ff604992.aspx it includes an example that works on both Windows, Xbox 360 and PC.
If you're only developing for Windows you can also use the normal C# IO functions like File.Create, File.Open ...
Many problems can always be solved with a bit of decomposition.
First off, if your target is the MMO space, then I suspect you either elected to create your maps in continous connected zones much like World of Warcraft's world maps are designed or they're separated into zone-based maps much like GuildWars2.
In either implementation, a map includes area ...
Given your requirements I would recommend not using a RDBMS. I'd look at a JSON type document database for storing your data. It tends to be me more flexible and matches the data structures you'll design in a cleaner way.
If you do want to use an RDBMS though I'd look at PostgreSQL rather than MySQL. PostgreSQL 9.4+ has JSON binary support. You can ...
Databases are supposed to be used for persisting long-lived data, not for ephemeral data. Using a database for storing short-lived chat messages just to delete them seconds later is quite an anti-pattern. It was common in the early years of PHP where databases were pretty much the only way to exchange data between sessions. But more modern web application ...
It really doesn't matter which database you use for this. You can use pretty much any.
The sql-by-the-book solution for storing the current state of all games would be to create a table with these fields:
The game history would look like this:
The exact answer depend on your exact use case so I'll try to stay general.
Basicaly, memory is cheap and fast. If you can afford to keep X games states in memory at once, then go away with that. The only thing you have to take care of is to store only one version of each game so that the state stay in sync between players. Also don't forget to store that ...
I tried it all and the best way is the cursor/helper way. Its much simpler than using any framework.
Just create a helper class to manage all db interactions.
Persisting data is as easy as this:
ContentValues cv = new ContentValues();
cv.put("column1", "some value");
db.insert("mytable", null, cv);
And fetching from db is like this:
Cursor c = db....
Would it just be better to jam all card fields into one table, rather than keeping them in three separate tables?
That depends on 2 things: How many you have and how different they are. Basically if you don't aim to have more than several thousand items (that's just a random number order I throw, it's system and query dependent), you are probably better of ...
This is an excellant question, I am developing an app for Android using AS3, Flash Builder and Tiled for the maps. I am running into complications with the shear amount of data taken up by the tmx files. Ive cut down a bit of the memory usage by creting bitmaps of the ground tiles and any canopy tiles, instead of parsing those. However when I load the map ...
TMX Files are basically a XML file describing your map/level; You usually read it to initialize your world and forget about it.
Now, if the lib you use to manipulate/display them (or your own code if you did it by hand) is able to regenerate the TMX from your world after the player interactions modified it I'd say the way to go is to just serialize the new ...
Because you say you use MySQL to store user data, I'd imagine that you'll want to use it to store which questions are locked/unlocked, as the player interacts with the game.
In that case, you'd have some tables to represent the state of the player. Something simple like:
TABLE NAME: unlocked_options
ID: global ID of options unlocked
TABLE NAME: locked ...
Beside using the trick of flipping from saving the discovered tiles to saving the undiscovered ones once the player has reached 50% of exploration, this comes down to a data organization and compression problem.
As per your question, I assume that the player usually explores the area by moving between adjacent tiles. This will lead to a pattern of "explored ...
How about using binary(length) or varbinary(maxlength)?
With binary you could store the data for the entire map as bits. Imagine a grid or matrix where the first bit is the position (0,0) and the next is (0,1). Each bit's index N represents the position (N % Width, N / Width). This means 1024 * 1024 bits in total which is one megabyte per player. If you ...
Keep in mind that no MMO server is just a single process. In fact, they typically are composed a plethora of processes that each handle unique characteristics of the game world.
But specific to game object data, generally these are handled by zone servers that are often overseen by a master world server. These zone servers are separate processes with ...
You can split the ID integer space in Temporal IDs and Permanent IDs and treat it different. E.g: using a 16bits unsigned integer:
[0 - 32767] Permanent IDs
[32768 - 65535] Temporal IDs
This way a saved entity never will get a temporal ID and there will be no collision.
You can adjust the ranges knowing the amounts of entities of each type.
Non-distributed systems as you mention, rely on processing within a local environment. They are not designed to scale. Therefore, your approach is based heavily on the use of local processing, in that you aren't considering distributed approaches.
Distributed systems, rely on processing spread out both locally and remotely. In order to achieve a ...
You could combine SQL persistence with some ideas described here:
Best practices for periodically saving game state to disk
Essentially, you don't want to use SQL server to load/store your entities real-time on the fly. But if you load/update/insert the entities in a background thread through some memory buffer, it could work just fine. I myself am trying ...