Tag Info

Hot answers tagged

10

Databases have a quite different use case than file formats like XML. File-Formats like XML: Are saved once and loaded once per application start-up. Since they are loaded once the access time after the loading is extremely fast. Used for serialization and deserialization as well as configuration files. Databases: Are for the most part constantly in ...


8

When it comes to making a multiplayer FPS, this is a pretty amazing resource: https://github.com/id-Software That is the full source code to every one of id's games up through Doom 3. There is no reason to go with a different implementation of how it works over a LAN vs over the internet. UDP is definitely the way to go, I don't know of any FPS that didn't ...


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

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


5

If this is just simple, local information, then storing it in any kind of "database" is massive overkill, let alone something like MySQL. SQLite might be appropriate. These data seem to be for game concepts. So don't forget: you need to author this data. It's a lot easier to hand-edit XML/JSON/etc than it is for some kind of database. You can even develop ...


5

Read up on standard database design. Specifically normalized forms. An approach would be to have 3 tables: character having a character_id and other data items having an item_id and other data (names, weight etc...) inventory having character_id, item_id, quantity. A player's inventory could be expressed as "SELECT items.name FROM items, inventory ...


5

Typically, simulation state is kept in memory and the server will send it out to the clients while longer term info like active games and who is connected would be kept in a database that all the services like the lobby can pull info from. Raw access, direct from the client with SQL commands? Bad idea. Have the server receive requests, which you then ...


5

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


4

Your question made me think that you're starting your game with the DB design, and this seems to be the case. Now you basically have some tables and you want to add more "stuff". Let me say that starting with the DB is a very bad idea. Firstly it doesn't represent a game-world properly and is not suited for lots of changes. Let's assume that you have a ...


4

What do you mean by "Raw access"? If it means what I think it means you have got a gaping security hole. As for the performance question, it would be stupid to try using a database for such a job, for a ballpark figure I'd say an average database is 1000 times slower than memory. Just keep everything in application memory, I don't think you'll run out of ...


4

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


4

Two pieces. 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: Player: Sprite: image: character/players.png Physics: size: [2,2] center: [1,1] PlayerController AudioListener Health: ...


3

Let your central server (CS) do only 'lightweight' things: Manage the authentication, Store the achievements. Store some basic stats of the available player-owned servers. Let player-owned servers (POS) store the tiles and manage the game states. The game client (GC) should only communicate with the CS when logging in, and when the player is looking at ...


3

I am just doing one which simply creates xml files. For example an entire level is saved as an xml file and then reloaded when needed, unless the user has finished the level, then a new random one is created. Every object is one tag with its attributes like <Object name="car" color="blue" maxspeed="300" /> I think this is more simple way to do it ...


3

I don't have the exact answers you're looking for, but I'll just lay some options out there. I'm biased, but I would say that you definitely want an ORM instead of dealing with SQL directly. If you're into the whole OOP thing, then an ORM gives you an object-oriented view of your data, which is usually more helpful than manually pulling data out of rows ...


3

MySQL is free, is fast, can handle really big tables, is easy to use and you can find documentation and help extremely easy. I also know MySQL better than say PostgreSQL and that is why I chose that one for my persistent multiplayer game. Go with what you know best and if the worst case scenario happens (everyone wants to play your game and the DB ...


3

I'd have to say it really depends on your game/simulation and how well you can model it in SQL. Nowadays SQL Servers can keep lots of data 'live' in memory, and optimize access and processing of the data extremely well. And SQL should scale, in many ways, number of users, servers, processors, memory etc. - Some of this really difficult stuff to do from ...


3

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


2

Seeing the discussion in comments, I guess I'd better put my recommendations as an answer. See, I've used relational databases for all kinds of static data in the past. And it always lead to shenanigans like these. This question or this one have to deal with this too. Relational databases are really quite inflexible in terms of data representation. ...


2

In postgreSQL or MS SQL Server, you'd use a recursive CTE for this. Since MySQL doesn't support recursive CTEs, you'll have to change the structure of your table to use nested sets, or you could use as many self-joins as the depth of your tech tree. See this article http://explainextended.com/2009/09/29/adjacency-list-vs-nested-sets-mysql/ for how to do it. ...


2

UDP is okay, you have exactly the same problems as you would have on a LAN but with the bonus that you can do NAT Hole punching TCP/IP is easier to use (no packet losses and everything comes in the expected order) so go with that if you think it is easier for you. For the "how does it work", it is a correct start but you seems to have forgotten the ...


2

Your question is extremely cryptic (we can only vaguely guess, for example, that $this->listKey in some way refers to the building type you're trying to create, and some of your sentences are unintelligible), but I suspect you mean something like: for($i = 0; $i < 4; $i++) { $balance = $this->listResources[$i]['balance']; ...


2

In my experience using a relational database for these situations is fairly clumsy. It can be fast, in very simple cases, but translating object oriented entities into relational tables is itself a burden. You might look into some of the newer object database solutions like VelocityDB. But don't take my word for it - do some testing to see what works best ...


2

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


2

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


1

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.


1

In most cases the objects/entities in a game change over time, sometimes very quickly for purposes of animation, sometimes less often. I think it is obvious that any object that is changed several timer per second is probably not a good candidate to be managed by a database. So anything that requires 1 or more SQL queries for each frame is right out. This ...


1

Well, you should start by checking the error code returned by sqlite3_open. Different codes are there for a reason to suggest what the error might be. I for one guess that the file was not found. Very often the current directory is not what you expect, and is oftent different on different platforms.


1

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



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