Thanks, I am looking into SQLite as said.
---EDIT---
Well I got it working sofar as to create and insert data into a table from my C++ application but then program crashes with no errormsg or stdout.txt (SDL puts stdout in there)
----------
About something completely differant (should I made a new thread?)
Sofar I can only figure out how to send chat over SDL_Net.. more exactly an array oh chars (as in tutorial).
I have been reading others posts and it seems I should be able to send my own structs over network aswell? Can someone explain how that is done with SDL_Net?
Is it something fancy or relatively easy to learn?
Database vs. Files ?
it's very easy, when you send your data put the struct as the first argument to send and the size of the struct as the second argument
Author
if I have on client :
Is that right? And on server :
struct SChat{ string from; string line;}SChat somechat;somechat.line = "Hello world!";SDLNet_TCP_Send(host, &somechat, sizeof(SChat)+1);Is that right? And on server :
SChat chatincoming;SDLNet_TCP_Recv(client, &chatincoming, MAX_INC_DATA);
You can also try Postgresql. It is easy to set up, a very mature database server and it is quite easy to integrate to your project in both Linux and Windows.
After facing the same question, I decided that using files instead of databases is not a good choice.
After facing the same question, I decided that using files instead of databases is not a good choice.
Quote:Original post by TheTroll
Now with all that said, if you impliment a database for number 2, then you should use a database for the rest. Best to keep all your information in one format.
This statement is not true. Do not store default or static variables in the database. This will bloat your database and add additonal overhead.
You should store static data in files or in a local stored database structure (like SQLite).
I do not know much but keep in mind you should look carefully at the time of transfer between your app and the database(if any)
I am currently looking to port some of SQLite to java(if I have the will and the time)
C,C++ I recommmend SQLite(it's like it has been designed for this)
java you have at least 2 choices
port sqlite to java
or use hsqldb
do not use dbs.outside your application or you'll get yourself a bottleneck
I am currently looking to port some of SQLite to java(if I have the will and the time)
C,C++ I recommmend SQLite(it's like it has been designed for this)
java you have at least 2 choices
port sqlite to java
or use hsqldb
do not use dbs.outside your application or you'll get yourself a bottleneck
Actually, you can store all static and design data in a database, at least while developing.
IF your database is too slow to load a level (not necessarily true), you can dump the tables to flat files at the point of level compile, and load from flat file.
Again: the key is to abstract access to the data through an interface, such that you can replace the implementation when and if you need to.
IF your database is too slow to load a level (not necessarily true), you can dump the tables to flat files at the point of level compile, and load from flat file.
Again: the key is to abstract access to the data through an interface, such that you can replace the implementation when and if you need to.
I posted this same message on the Multi-Server thread......see below
An alternative is to use a database that does not require mapping. It makes persisting C++ applications especially easy .... since with C++, unlike Java, there are not a plethora of ORM tools. It is especially well suited to dealing with the complexities of multi-server implementations, but works equally well in a single server environment. This is the same database running the American Stock Exchange and a host of other extremely large scale, multi-user systems.
Cheers,
-Robert
You should check this out .....
ftp://ftp.versant.com/pub/outgoing/mmog/Versant_the_MMOG_advantage.doc
Just login anonymously.
This technology solves all your caching, concurrency, mapping and storage needs. It is used by several commercial multi-server MMOG games. If you want to play around with it, I can facilitate a license..... rgreene@versant.com
-Robert
An alternative is to use a database that does not require mapping. It makes persisting C++ applications especially easy .... since with C++, unlike Java, there are not a plethora of ORM tools. It is especially well suited to dealing with the complexities of multi-server implementations, but works equally well in a single server environment. This is the same database running the American Stock Exchange and a host of other extremely large scale, multi-user systems.
Cheers,
-Robert
You should check this out .....
ftp://ftp.versant.com/pub/outgoing/mmog/Versant_the_MMOG_advantage.doc
Just login anonymously.
This technology solves all your caching, concurrency, mapping and storage needs. It is used by several commercial multi-server MMOG games. If you want to play around with it, I can facilitate a license..... rgreene@versant.com
-Robert
Quote:Original post by hplus0603
Implement the data store as a separate class with a clear interface.
Define the operations you want to make on your data store.
Have the code call the data store, and implement the data store in the easiest way you can think of.
Then, when and if the data store becomes a bottleneck, start optimizing.
Right. Seems a great idea, and in all other situations bar DB's I agree (e.g. loading config files, interfacing to external data systems that are NOT DBs, etc), but after many years of doing this, I have to point out the one fundamental problem:
Searches.
Databases are great, but the biggest single thing about them is their ability to request arbitrary combinations of arbitrary data according to arbitrary relationshpis and comparisons with arbitrary sorts and filters, and ... well, you get the idea.
If you're ever going to make use of any of that, don't bother with writing an interfaec, because you'll end up re-creating most of SQL in order to get even a small percentage of the flexibility you need :).
IMHO, you're going to want to make use of that nearly every time. People usually hit it when they want to make a high scores feature for the game, and e.g. want sortable columns - if they used a DB, it's only one method call for each new sortable column. If they did it via a code interface, it's usually 10+ lines of code, and often as much as 100 or more (to re-create something that only takes one cunning SQL line).
I disagree. The interface is a perfect place to put your searches.
You want a search like "count and item ID of every item owned by player P". Call that "player_inventory_query". Put a member for player_inventory_query() into your interface, taking the parameters you need (say, player ID and item type).
Then, on the back-side, you can generate SQL from the function call, or go look in a hash-table, or call a stored procedure, or whatever.
In general, btw, it's very often the case that you end up using stored procedures for your different queries; the stored procedures become the "API" between the database and application, and changes can be made in the database without re-compiling the app.
An alternative is to build your SQL as prepared statements, which keeps application logic out of the DB schema, but then you have to re-compile your app if you change the query implementation (unless you in turn load the SQL text from some data file).
No matter which way you go, putting an interface between your user code ("I want to load the inventory") and your data access code is the right thing to do, in my opinion.
You want a search like "count and item ID of every item owned by player P". Call that "player_inventory_query". Put a member for player_inventory_query() into your interface, taking the parameters you need (say, player ID and item type).
Then, on the back-side, you can generate SQL from the function call, or go look in a hash-table, or call a stored procedure, or whatever.
In general, btw, it's very often the case that you end up using stored procedures for your different queries; the stored procedures become the "API" between the database and application, and changes can be made in the database without re-compiling the app.
An alternative is to build your SQL as prepared statements, which keeps application logic out of the DB schema, but then you have to re-compile your app if you change the query implementation (unless you in turn load the SQL text from some data file).
No matter which way you go, putting an interface between your user code ("I want to load the inventory") and your data access code is the right thing to do, in my opinion.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
