Hot answers tagged sql
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
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 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 ...
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
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 ...
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 ...
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
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 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 ...
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 ...
1
I've done something similar to this using an abstract concept of Area. An Area is just basically collection of Tiles, calculated at run time, but will allow you to work with that collection much easier. An Area made up of a collection of individual Tiles will also allow you to have irregular (not just square) areas of forests and deserts.
Using this ...
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
Since this is PHP, you can pass your buildingId and townId as GET data in the URL, i.e.:
build.php?building=39&town=204832
You can then access this with $_GET["building"] and $_GET["town"], which would equal 39 and 204832 respectively in this case.
Your other option is submitting this as POST data (form data) and accessing it using ...
1
This portion of your code
key_playlistname +"="+name
probably needs the name part in quotes
i.e.
key_playlistname + "= '" + name + "'"
Otherwise CoolPlayList probably be treated as an SQL command and would come back with an error such as invalid SQL statement.
1
Performance wise: Yes. If you have a column for the various balances in one row, you will improve performance when looking up this information. Looking up and returning 1 row is faster than returning X rows and generating the totals from the compiled results.
Example:
CREATE TABLE town_totals (
town_id int(10),
iron decimal(8,2),
gold ...
1
Because of the problem you mentioned I would recommend you to simply keep track of the current day and phase of the user separately, instead of trying to compute it from the Logs table everytime.
The simplest solution is just adding these fields to the Users table:
user_id = 1, current_day = 30, current_phase = 3, other_stats...
That makes things easier ...
1
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 ...
Only top voted, non community-wiki answers of a minimum length are eligible
