Introduction
Today we’re going to tackle the same material as in this posting: Using Configuration Files (PHP)
Configuration In Rails
Fortunately, this is going to be an easy one. In Rails you use the config/database.yml file from the very beginning of your project to setup your connection to the three databases you normally use in your Rails projects. One database each for development, automated tests, and production. As long as you’ve put your connection information into the database.yml file and are able to successfully make a connection, you’re good. ActiveRecord will take care of making all database connections for you so you never have to deal with it in any of your models.
But there are other aspects to configuration that we can consider and Rails has setup a nice framework for those as well. If you have constant values that need setting or other setup work that needs to be done every time you startup your application then the config/environment.rb is the perfect place for that. Like most things in Rails, it is written in Ruby and if you need to perform setup which requires Rails (e.g. access to the database via ActiveRecord) you can add that to the end of the file and know that Rails will already be initialized before you reach that point.
Beyond that there are additional setup files in the config/enviroments directory (development.rb, test.rb, and production.rb). Whenever Rails is run under any specific configuration the appropriate environment file is used so you can have different settings for development from production. For example, you might use one email server when you are developing but a completely different one in your production deployment and put the settings for each one into the different environment files.
Extra Credit
Since Rails did all the hard work for you this time, why not take a few minutes to learn about version control and get a simple solution working? If you can backup your source code on a regular basis to another server with a version control system like Subversion, it will be easier for you to make changes without having to keep old code around, it will be easier to collaborate with others working on the same game, and a catastrophe like a hard drive failure won’t lose you weeks or months of hard work. If your game is open source then Google Code offers free project hosting but if you’re planning to keep your code to yourself you can run your own Subversion server or use commercial providers like unfuddle and wush.net. Both offer useful services for free or a few dollars a month.