I don't think Ruby is the best for audiogames. I've found that interpreted languages (or languages that are compiled into some kind of bytecode to be executed on a VM of sorts) run far slower than a native application that doesn't have such a complexity. I'd recommenc C++ -- it's not as difficult as people make it out to be. I'm certainly starting to enjoy it at least. Here's how you might read/write a configuration file in C++ with Boost.PropertyTree:
#include <boost/property_tree/ptree.hpp>
#include <iostream>
#include <string>
// We include the different parsers to demonstrate the
// different formats.
// You don't need to include all of these unless
// your writing a multi-language configuration
// database
#include <boost/property_tree/info_parser.hpp>
#include <boost/property_tree/ini_parser.hpp>
#include <boost/property_tree/xml_parser.hpp>
#include <boost/property_tree/json_parser.hpp>
using namespace std;
using namespace boost::property_tree;
int main () {
try {
// Initialize the property tree to hold our configuration
// data
ptree pt;
// Then we use pt.put to add our entries:
pt.put ("version", 1.0);
// Or we can add an indefinite number of sections and
// sub-sections and so on:
pt.put ("libloader.loader.libs", "libgl");
// Or even:
pt.put ("this.is.a.very.long.section.that.descends.to.the.key.1.which.is.defined.as", 1);
// Now, write it in the different formats.
// All writers follow the syntax: write_lang (filename, property_tree_object).
info_parser::write_info ("test.info", pt);
xml_parser::write_xml ("test.xml", pt);
json_parser::write_json ("test.json", pt);
// We leave this for last since it throws an exception.
ini_parser::write_ini ("test.ini", pt);
} catch (exception &ex) {
cerr << "Error: " << ex.what() << endl;
return 1;
}
return 0;
}
The resulting output is as follows:
test.info:
version 1
libloader
{
loader
{
libs libgl
}
}
this
{
is
{
a
{
very
{
long
{
section
{
that
{
descends
{
to
{
the
{
key
{
1
{
which
{
is
{
defined
{
as 1
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
Ini:
JSON:
{
"version": "1",
"libloader": {
"loader": {
"libs": "libgl"
}
},
"this": {
"is": {
"a": {
"very": {
"long": {
"section": {
"that": {
"descends": {
"to": {
"the": {
"key": {
"1": {
"which": {
"is": {
"defined": {
"as": "1"
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
XML:
<?xml version="1.0" encoding="utf-8"?>
<version>1</version><libloader><loader><libs>libgl</libs></loader></libloader><this><is><a><very><long><section><that><descends><to><the><key><1><which><is><defined><as>1</as></defined></is></which></1></key></the></to></descends></that></section></long></very></a></is></this>
As for gaming libraries in C++, I'd highly recommend SFML and SDL. SFML is written in C++ and SDL is written in C. Both can be used together and work very well. (I know I posted something that was irrelevant to the question at hand; I wanted to dispel the notion that interpreted languages are good with games, as it seems like some people have that. In truth, their not really suited to such a task: every line is compiled as the program is executed (in the context of Python or Ruby), so this drastically slows down gameplay for the users, and (in the case of Java) it's very really to reverse engineer -- far easier than C++ code is, at any rate. And unless you like your code being option to the world, Python and Ruby are not the best languages for writing games or shareware products.)
"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question." — Charles Babbage.
My Github