Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 13 Dec 2002
Offline Last Active Jul 20 2014 06:09 PM

Posts I've Made

In Topic: Many to one relation in an SQLite database

14 December 2013 - 06:03 PM

SQLite is a great tool to use as you migrate data from flat files. In fact I have been using SQLite for years for everything from config files to storing large data maps. There are so many tools for it and it is so light weight it is nearly as accessible as a human readable file but with a bit more kick.


That being said, and this is from my own experience - others may vary, just get your flat file data into SQLite however you find most intuitive to you (or your team) at first. In most cases the size of the data will be very small (relatively speaking in terms of DB performance) and the overhead of trying to learn SQL, Entity Relationships and all of the nuances of how to improve your DB performance are useless until you identify your database as being a performance issue. In many ways this is premature optimization. What you are doing is fine as long as you get the results you are looking for or at the very least get the same information you got out of the flat files.


Normalization of your database with foreign keys and foreign key constraints is tedious and time consuming to do correctly (once available the tendency is to lean on them which causes issues on it's own). Learning how to design, manage and run a database can ultimately lead you down a path to not completing your game. That is not to say time spent on learning the intricacies of database design, management and optimization would ever be a waste of time (I spend a lot of time doing this for work) however it will be a distraction from getting your game completed. Also in my experience, rarely has a database design been a bottle neck for any projects I work on until down the road when there are 1-3k+ users all adding and reading data at the same time. Granted the DB is almost always a bottle neck when we reach certain user thresholds or data sizes however at this point the applications are usually working well and the time spent on the database has more focus since the application has had time to mature and we know what kind of performance we are looking for.


I will repeat myself and say that overall I would do what is most intuitive for you and your game - especially if you are the sole developer. Database management has many religions and like any religion there are zealots who believe their word is Dogma and we all know how that turned out for Cardinal Glick. Once it is working for you the worst that can happen is you improve it.

In Topic: Benchmarking servers

06 September 2013 - 03:23 PM

It may help to use something like collectd to throw various metrics you think are important at while your game is running at specific intervals while doing load tests. This results in some nice trends that let you make SWAGs about how your server should operate given a certain amount of hardware resources under certain amounts of load. Once you have some theories, establish ways to validate or invalidate them.


Every game server will have different requirements and different metrics it finds important but in most cases, being able to trend what is happening is required for any kind of trouble shooting or bench marking.

In Topic: Why companies still use C++ and what should I learn then

25 July 2013 - 12:56 PM

Programming is a task. The language is a tool you use to accomplish that task.


Just like any task, there are many ways and many tools you could use to accomplish that task both correctly and in a timely manner.


For example - Should you learn to use a hammer or a nail gun first? It really depends on what the job calls for but you are probably encouraged to continue to learn about any tools that can get the desired result.


In our company we generally hire people who have demonstrated the ability to learn multiple disciplines even if the one we are looking for isn't their strongest one (so long as they are proficient in it). Learning something is never a waste of time. You know what you can do and what is comfortable for you. Some people can pick up complex languages with relative ease, others need to wade in. The thread has given many opinions from people who work in your targeted industry (or claim to at least). The choice remains yours in the end however and your success will ultimately depend on how much you are willing to change and adapt to the employment environment you are seeking out.




It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change.

~ Charles Darwin

In Topic: VOIP - How often should I be sending packets when streaming music?

24 May 2013 - 01:32 AM

Media streaming in general is a relationship between sample size and playback rate so sending fixed sized packets at timed intervals is indeed the way to go but you have many more options when streaming music vs. streaming real time communications since music files are known in their entirety before transmitting.


Is streaming really what you want to do? There are plenty of streaming media servers out there to take examples from but for gaming I can't imagine why you would do this versus having the media pre-loaded or downloaded on demand unless you were mixing audio in real time.

In Topic: SQL login security?

13 May 2013 - 08:50 AM

Even disregarding issues like password theft, letting anyone directly connect to your database server is a terrible idea.




Even a thin API wrapper between your internal applications and your database can be a positive thing. For the most part the main issues here are shielding yourself from malformed, incomplete and/or intentional malicious things - most notably the unintentional especially where quotes and special character escaping like $@!* are concerned. It is relatively simple to do since in most cases queries only require on a very small portion of information from the actual client side such as a function name and a date range or other criteria found in the 'WHERE' clause.


In most cases the only information a client should send is (authentication to your app server should be separate from the database login credentials and already complete at this point!) a few variables set to determine what function to call and the parameters it needs to reliably build the query server side. It is important to note that this forces you to an extent to validate the client requests and validity of their request before sending anything to your database and not rely solely on the somewhat lacking security features on various database engines.


This is not only ideal for security reasons but for maintainability. You can usually update/improve your query server side without having to update the clients in any way.