So with that, I’m putting together this post to help clarify exactly how the various parts of Rice work together, how the entire process flows and more importantly helping anyone who’s wanting to learn and work on Rice with a solid starting point (or at least officially crooked). After reading this, anyone should be able to understand the various classes in Rice, and have an idea on where certain functionality lives when looking to add features, or address any bugs. So with that, we’ll start at the top.

What is Rice?

Rice is a wholly remarkable piece of software that takes complicated C++ classes, methods, types, etc and exposes them into Ruby using as simple an API as can be made. In short, you can take a C++ class such as:

class Generator {
  public:
    Generator(int seed) : mSeed(seed) { }
    ~Generator() { }
 
    int getRandomInt() { return 4; } // chosen by dice roll, guaranteed to be random
 
    void setSeed(int seed) { mSeed = seed; }
 
  private:
    int mSeed;
};

and use in in Ruby seemlessly:

g = Generator.new(5)
g.random_int          # => 4
g.seed = 10

through a very simple Rice wrapper Ruby extension:

void Init_generator() {
   define_class<Generator>("Generator").
      define_constructor(Constructor<Generator, int>()).
      define_method("random_int", &Generator::getRandomInt).
      define_method("seed=", &Generator::setSeed);
}

Were this class to be wrapped using Ruby’s C-API, every method on Generator, and even the constructor would have to be wrapped in a C method with calls into Ruby’s API (particularly Data_Make_Struct and Data_Get_Struct), very tedious and time consuming work, and at times quite error prone. So how does Rice make this tedious process as simple as four lines of code? C++ templates, and lots of them. We’ll go through each line here and dive into Rice itself to see what’s happening, but first, a quick word on Rice’s file naming convention.

ipp, hpp, cpp, _defn … what??

Because Rice is so template driven, most of the code cannot be pre compiled. That which can gets put into cpp files and ends up in librice.a, otherwise the core of Rice is template code generation which means only the code needed for the given extension is generated and compiled when building the extension itself. Given this, Rice still tries to strongly adhere to the separation of definition and implementation code. The definitions of classes are normally placed in [class_name]_defn.hpp, with the implementation placed in [class_name].ipp (to keep it separate from compilable code which gets placed in .cpp files). These two files are then combined in [class_name].hpp which is meant to be used in Rice extensions when including various pieces of functionality. When working inside of Rice and you need class definitions, you’ll want to use #include “[class_name]_defn.hpp” in most cases or risk running into circular dependencies and “already defined” compiler errors. Otherwise, when writing an extension using Rice, you’ll #include “[class_name].hpp” to ensure that all functionality is available for the extension.

As for the .mustache files, a lot of Rice’s template code is very repetitive and so instead of using complicated macros like Boost.Python does, Rice simply uses Ruby to generate the C++ code. Rice currently uses the Mustache library for this and the code for this process can be seen in rice/code_gen.

Defining a class: define_class

To expose a C++ class into Ruby you first need to define the class, give it a name, and tell Rice which C++ type this class is (as a side note, you can create a Ruby class not hooked to a C++ type, just don’t give define_class a type). The prototypes of define_class are found in Data_Type_defn.hpp. The one we are particularly interested in is:

//! Define a new data class in the default namespace.
/*! The class will have a base class of Object.
 *  \param T the C++ type of the wrapped class.
 *  \return the new class.
 */
template<typename T>
Rice::Data_Type<T> define_class(
    char const * name);

Following the code into Data_Type.ipp, we can see the implementation of this method:

template<typename T>
inline Rice::Data_Type<T> Rice::
define_class(
    char const * name)
{
  Class c(define_class(name, rb_cObject));
  c.undef_creation_funcs();
  return Data_Type<T>::template bind<void>(c);
}

This method starts out creating a new Rice::Class with the given name, making it a subclass of Object (aka a top-level Class, emulating what Ruby itself does). A quick jump into Class.cpp shows us that define_class(char*, VALUE) simply forwards off to the Ruby API call rb_define_class, then takes the resulting VALUE and wraps it into a Rice::Class.

Rice then undefines #alloc and #initialize to prepare the class for Rice’s own type management (to be discussed later). The third line of this method is what actually binds this new class to the C++ type, binding it as a top-level class (Data_Type::bind is templated to the superclass type, so void in this case).

Data_Type binding

Probably the most confusing, and at the same time most important, aspect of Rice is how it manages C++ types and their link into the Ruby world. Every C++ class that’s to be wrapped into Ruby must be bound to a Ruby class which is done in the static method Data_Type::bind (implemented in Data_Type.ipp). This logic forms the core of how Rice does automatic conversions from C++ types to Ruby types and vis-versa.

To start, every Data_Type<T> has a static pointer to a Ruby class (Data_Type<T>::klass_). After checking that this C++ class isn’t already bound to another Ruby class, bind() registers the Ruby class with the Ruby GC and sets up a Caster between this C++ type and the Ruby class (to be discussed later).

We’ve now got our C++ class Generator properly bound to the Ruby class Generator and can continue.

Adding methods to a class: define_method

We’re now at the point where we can start wrapping the methods on our Generator class. We’ll follow the code execution of wrapping the method Generator::getRandomInt(), starting with Module::define_method found in Module_impl.hpp.

Quick side note: Rice’s C++ API attempts to mimic Ruby’s top level Object structure, so the interplay between Data_Type, Module and Class can get confusing. Suffice it to say, class-based objects in Rice are all Rice::Module-s at the top, which then itself is a Rice::Object.

The specific define_method we’re interested in here is as follows:

  //! Define an instance method.
  /*! The method's implementation can be any function or member
   *  function.  A wrapper will be generated which will use from_ruby<>
   *  to convert the arguments from ruby types to C++ types before
   *  calling the function.  The return value will be converted back to
   *  ruby by using to_ruby().
   *  \param name the name of the method
   *  \param func the implementation of the function, either a function
   *  pointer or a member function pointer.
   *  \param arguments the list of arguments of this function, used for
   *  defining default parameters (optional)
   *  \return *this
   */
  template<typename Func_T>
  Derived_T & define_method(
      Identifier name,
      Func_T func,
      Arguments* arguments = 0);

The Rice::Arguments object has to do with the implementation of default argument definitions and I’ll get to that later.

This method is the beginning of where the true template craziness (genius? probably) happens. As a warning, if you are not comfortable with templates, the following is either going to confuse you, or it will open your eyes to a whole new level of possibilities in C++.

Rice works directly with Function Pointers and template definitions tailored to react to specific function pointer definitions to generate the appropriate code for properly wrapping C++ methods into Ruby. As a refresher, a C++ function pointer looks like this:

ReturnType (ClassName::*methodName)(ArgT1, ArgT2, ...);

so if we were to print out the function pointer of Generator::getRandomInt we would see:

int (Generator::*getRandomInt)();

This is what Func_T ends up being, a function pointer type. It can be a method with any return type, and any number and type of arguments, all handled by this one method. Looking at the implementation of this in Module_impl.ipp, we can see that execution is simply forwarded off to detail::define_method_and_auto_wrap given the Module/Class/Data_Type (*this), the name, the function pointer, any defined exception handler (this->handler) and the arguments object.

From this point, Rice needs to make a very important distinction on the method being wrapped: is it a class method, or a static method? The method Rice::detail::define_method_and_auto_wrap, defined in detail/define_method_and_auto_wrap.{hpp,ipp} uses Wrapped_Function classes, via wrap_function (detail/wrap_function.{hpp,ipp}) to make this distinction and to set up the final method object before finally jumping into Ruby’s C-API for finally exposing this method.

Auto_{,Member}_Function_Wrapper

Opening up detail/wrap_function.ipp you’ll see a very long file full of very repetitive method definitions. The key here is this method uses templates to match the passed in function pointer to one of Auto_Function_Wrapper (static functions) or Auto_Member_Function_Wrapper (a class instance method). Due to how Auto_{,Member}_Function_Wrapper works, wrap_function also has to have template specifications for functions with a return type and functions with void, as well as specifications to handle const and non-const function pointers.

To continue from here we need to understand how Rice actually hooks into Ruby. Glancing in detail/Auto_Function_Wrapper.hpp we’ll find template-overload classes similar to what’s in wrap_function. These classes are the core that handle argument and return type management as well as taking execution from Ruby and passing it into the related C++ function or method. What we’re going to focus on here is the ::call static method, though we’ll get to the details of this method’s implementations later.

Ruby’s API will only take C-style functions with the signature VALUE(*)(…). The Auto_…_Wrapper classes are the glue that gives us a function with this signature:

static VALUE Auto_Function_Wrapper::call(int argc, VALUE *argv, VALUE self);

If you’re familiar with Ruby’s C-API, then this signature should look familiar, it’s the -1 arity signature used when you want to support a variable number of arguments (in Rice’s case, default arguments). So how does a static function on a templated class work with an instance of this class to call the correct C++ method or function? It’s time to dive into detail/method_data.cpp, which defines define_method_with_data() as seen in the second part of define_method_and_auto_wrap() (Rice::protect is a wrapper around rb_protect to catch any exceptions and handle them gracefully).

detail/method_data.cpp

I’ll start this section with the comment block describing define_method_with_data():

// Define a method and attach data to it.
// The method looks to ruby like a normal aliased CFUNC, with a modified
// origin class.
//
// How this works:
//
// To store method data and have it registered with the GC, we need a
// "slot" to put it in.  This "slot" must be recognized and marked by
// the garbage collector.  There happens to be such a place we can put
// data, and it has to do with aliased methods.  When Ruby creates an
// alias for a method, it stores a reference to the original class in
// the method entry.  The form of the method entry differs from ruby
// version to ruby version, but the concept is the same across all of
// them.
// 
// In Rice, we make use of this by defining a method on a dummy class,
// then attaching that method to our real class.  The method is a real
// method in our class, but its origin class is our dummy class.
// 
// When Ruby makes a method call, it stores the origin class in the
// current stack frame.  When Ruby calls into Rice, we grab the origin
// class from the stack frame, then pull the data out of the origin
// class.  The data item is then used to determine how to convert
// arguments and return type, how to handle exceptions, etc.

Bear with me here as I still have a hard time keeping this straight in my mind. To help understand what exactly is going on here, I’ve made a graph showing all the relevant links between Rice, C++ and Ruby as made by this method.

The steps define_method_with_data takes:

1. Create a new class inside of the class we’re exposing (called the origin class).
2. Build a new two-element array that has [ 0xDA7A, VALUE pointer to Auto_..._Wrapper class]
3. Give the origin class an easily recognized name (which is also an invalid Ruby constant name, preventing it from every being accidentally used in Ruby code, but it prints out in object dumps on occasion).
4. Set this origin class to be FT_SINGLETON which hides it from the user¹.
5. Set a hidden ivar on the class that’s the array built in step 2
6. Define a method on the origin class that links to Auto_…_Wrapper::call with the requested name

At this point we’ve got everything ready except for actually being able to call the method from Ruby. These next steps were hard to show right on the graph because Rice actually modifies the symbol table of the base class in question.

7. Create an alias on the origin class that aliases the method to “dummy”
8. Find this new alias entry in the origin class’ symbol table
9. Modify the symbol table of the base class to call “dummy” on the origin class on any call to the method being wrapped.

We’ve now got everything hooked up: we have the c-style function hooked into Ruby and we have a way to access the actual Auto_…_Wrapper class once call() gets called. Now, you may be asking why this is such a complicated process when it could be done with a simple rb_define_method on Auto_…_Wrapper::call(). The answer to this question is show in the image above, there’s data and information saved in this Auto_…_Wrapper object that Rice needs to be able to properly convert argument and return types, and handle any exceptions that may get thrown.

With that, we’re done with the wrapping and exposing path through Rice. Now it’s time to head back up the chain and see how Rice handles calls from Ruby and passing execution back up into C++.

Auto_…_Wrapper::call()

It’s time to take a detailed look at this method. In short, once execution enters this method, it’s now Rice’s job to convert VALUE arguments into the appropriate C++ types, execute the wrapped method / function, then do any required conversion of return values back to VALUEs for Ruby, while also making sure that any exceptions that throw along the way are properly caught and handled (an uncaught exception in C++ will give you a SegmentationFault or a BusError. Always fun to debug).

So, first things first, we need to get back the Auto_…_Wrapper object we saved when we wrapped this function. This is done with the detail::method_data() function, details of which are easily seen and understood in detail/method_data.cpp. With this we run our arguments list through rb_scan_args then run through each argument and check if there’s was a default set in the wrapper and if we should use it (Side note: the sanitize<> template is a no-op right now and can be ignored. It’s there to attempt to clean out any references or const arguments that may come in to get the base type, but this was causing crashes on other wrappers. For now I assume there’s a possibility of a small memory leak here related to reference types). Once all the types are converted it’s time to actually call the C++ method or function, and handle the return type.

The noticeable difference between Auto_Member_Function_Wrapper and Auto_Function_Wrapper is that Auto_Function_Wrapper has some special handling for the “self” parameter. This functionality is here to support the ability to wrap C functions that are written in an OO way, such as:

Jukebox* newJukebox();
void play(Jukebox* jukebox, Song* song);
void stop(Jukebox* jukebox);
void addSong(Jukebox* jukebox, Song* song);
// etc.

Because of the special self handling of Auto_Function_Wrapper, these methods can be wrapped into a Jukebox class very simply:

define_class("Jukebox").
  define_method("initialize", &newJukebox).
  define_method("play", &play).
  define_method("stop", &stop).
  define_method("add_song", &addSong);

Other than this, the two classes are identical in functionality.

Constructor

Because constructors aren’t accessible via normal function pointers, Rice has to implement special handling of wrapping class constructors for proper instantiation. This is done through the Rice::Constructor class and the define_constructor method. The path here is mostly equivalent to define_method. Opening up Constructor.{hpp,ipp} you can see the same ::call() static method, with a much simpler body. Every Ruby object has a free slot accessible through DATA_PTR. It’s in this slot that C++ class instances are saved and used for type conversions as described next. Constructor::call creates this object and saves it in DATA_PTR for later use.

Default Arguments

The code for handling and managing Default Arguments is pretty easy to read, but how the syntax work is definitely cause for confusion. Pulled from Boost.Python’s implementation of this exact feature, this functionality uses the comma operator to string together Rice::Arg objects into a single Arguments object that’s then passed into the Wrapped_Function object for that method. Due to the fact the comma operator doesn’t even come into play if there’s a single argument to a method, I was forced to copy some functionality around to make this feature work in all situations. So where you see two methods, one which takes a Rice::Arguments* and one which takes a Rice::Arg*, that’s what’s going on. I hope to clean this up drastically in the near future.

to_ruby / from_ruby

The last piece of Rice’s functionality is the type conversion system, exposed to the user through two methods: to_ruby(), which takes a C/C++ type and converts it to a VALUE, and from_ruby() which does the opposite. The signatures of these methods are simple:

template<typename T>
T from_ruby(Rice::Object x);
 
template<typename T>
Rice::Object to_ruby(T const & x);

For most basic and fundamental types, the to_/from_ruby implementations are very simple and can be seen in to_from_ruby.ipp, but this is only half of the story.

Rice’s real strength comes in handling custom-defined C++ types and seamlessly converting them from Ruby to C++ and back again, making sure to handle inheritance (both C++ <=> C++ and C++ <=> Ruby) appropriately. The core of this functionality is found in Data_Type::from_ruby in Data_Type.ipp, and in the Rice::Caster class found in detail/Caster.hpp, but it begins at the end of Data_Type::bind, which creates a new Caster for the newly bound type:

  detail::Abstract_Caster * base_caster = Data_Type<Base_T>().caster();
  caster_.reset(new detail::Caster<T, Base_T>(base_caster, klass));
  Data_Type_Base::casters().insert(std::make_pair(klass, caster_.get()))

Caster is at the core very simple. It’s a class that enables Rice to build a tree of Casters that define how to cast from a Ruby type into a custom C++ type. The code above is simply building a new Caster linking the new type to the Ruby class, specifying any superclass type as needed, then registering this Caster with Rice’s Caster tree. From here it’s time to look at how Rice uses this Caster list in Data_Type::from_ruby() (which btw is called through ::convert() in detail/from_ruby.{hpp,ipp}).

In the case that the C++ type we want is exactly the Ruby type we’ve been given, casting is easy, make a new Data_Object for that type and get the pointer. If this doesn’t match, then we need to start heading up the inheritance heirarchy (rb_mod_ancestors) looking for the lowest class in the hierarchy bound in Rice, get it’s Caster and attempt to cast into C++. This functionality allows any depth of inheritance to work seamlessly in Rice.

The Future of Rice

Rice is currently a very capable library, and is being used successfully by a couple of projects, but it does have a long way to go to be the SWIG replacement (along with my rb++ suite) I want it to be. For the next release of Rice I’m current planning on the following work:

• Refactoring Auto_{,Member}_Function_Wrapper, Constructor, wrap_function, et.al. to be much simpler. Going to try to abstract out the actual method dispatch into a class like Auto_Functor_Wrapper which will handle all the to_/from_ruby and argument management magic.
• Default arguments on Constructor. To do this Constructor needs to act more like an Auto_Function_Wrapper, and thus would be much easier to implement once the refactoring above is done.
• Beginning into a def_helper (from Boost.Python) feature. Right now the implementation of default arguments is pretty messy. As I need to handle multiple arguments as well as a single argument, I’ve resorted to two define_method implementations to take these two cases. With some template magic, I can make it work with a single argument, as well as opening up a single place for call and return policy functionality, instead of multiple places that would be required today.

As always, I’m available over Github messages / Issues, Email, comments here, or on Rice’s mailing list (rice AT librelist DOT com). I’ve also got a public tracker up on Pivotal: http://www.pivotaltracker.com/projects/48783, but not sure how well that’s going to work for a free-time project such as this, though keeping a some-what strict time line is probably good for me, but I digress.

1. http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/336728

http://www.telegraph.co.uk/news/worldnews/northamerica/usa/6173399/Charles-Darwin-film-too-controversial-for-religious-America.html

The article does make some very good points. In America, religion rules. This can be seen especially today with the massive political upheaval of the recent elections, where we’ve got the “religious right” (mainly Christian, which I’m most familiar with) against the “secular left” fighting it out to the bitter end. What I have been trying to understand is why do less than half of all Americans believe in Evolution and how can we solve this? Is there a glaring and unrecoverable conflict between Evolution and Christianity? Is there any scientific evidence supporting either side? Is this an irrational, fearful reaction in the face of the unexpected and the new? And more importantly, why is it most Americans are so against Evolution while almost everyone else in the world has happily accepted the theory?

What is Evolution?

To make sure we’re on the same page, I want to specify the definition of ‘believe’ here. I’m going with Webster’s second definition:

b : to accept as true, genuine, or real .”¹,

When I talk about belief in Evolution, I’m simply talking about the acceptance of the scientific evidence in favor of Evolution, nothing religious.

Also, this post will be mostly on Biological Evolution, but will touch on the general idea of Young Earth and the Big Bang Theory.

Lets start with a quick primer on what Evolution actually is. First laid out in Charles Darwin’s Origin of Species in 1859, it’s the theory that states (paraphrased):

Biological evolution … is change in the properties of populations of organisms that transcend the lifetime of a single individual. The ontogeny of an individual is not considered evolution; individual organisms do not evolve. The changes in populations that are considered evolutionary are those that are inheritable via the genetic material from one generation to the next.²

The Theory of Evolution is the theory that species change over time. This change manifests itself in random mutations of the DNA defining an organism, which is passed down to offspring. If these mutations are harmful, the offspring don’t survive. If these mutations are neutral, or even beneficial to the organism, it survives to pass down these changes to it’s offspring, a process known as Survival of the Fittest. Following this process over thousands and even millions of years results in the diversity of life we see today.

Evolution today is used to explain a myriad of observations we’ve made in the biological world, from why there are hundreds of different species of pigeons, some slightly different, others completely different, yet definitely all pigeon, to why virii are impossible to vaccinate against and why cancer is such a brutal and difficult disease to fight.

So if Evolution is so successful in describing the biological we live in, why isn’t it more accepted here in the States, and in some cases attacked as a tool of Evil? Lets look at the Christian counter-argument known as Creationism.

Creationism

I used to be a Creationist. I was brought up in a rather conservative Christian home, and as the prevailing view of the Beginning of the Universe was Creationism, I naturally accepted and followed these beliefs. What follows is what I used to believe, and what I know about the movement.

Creationism has very simple roots: Genesis 1:1 (NIV).

In the beginning, God created the Heavens and the Earth.

What follows in verses two to the end of the chapter is a day-by-day account of what God created on each day, creating the entire Earth and everything on it, in six days. Creationists take this account literally, in that it took six days, as we define “day,” for God to create the Earth and all living things. They also believe that, as each day starts with “and God said…,” we all appeared here one day by the whim and will of God. Picture it as a blank sheet of paper, and start drawing animals, plants, and people. There was nothing, then there was everything.

Creationism’s biggest beef with Evolution is that Evolution seems to take God completely out of the picture. They commonly argue that Evolution says we’re “all here by accident” or “we’re a product of random chance.” They claim that because of this, Evolution goes directly against the Bible and thus (in the most extreme of cases) claim that Satan introduced Evolution into the scientists’ minds to drive people away from Christ. Past this, the next most popular argument Creationists have against Evolution is the idea of a biological part being unevolvable, such as the eyeball, saying Evolution cannot be true because the eyeball is so complex that it has to either exist, or not exist, there is no half-way-point because, according to Evolution, the part would have been deemed bad and been phased out many generations ago.

Where do I stand in this?

I’m still a Christian, but I can no longer accept the Creationist claims. I owe this change-of-mind to two books: Language of God by Francis S. Collins and Only a Theory by Kenneth R. Miller. These books showed me that one can believe in Evolution, and still be a Christian. For anyone on the fence, these are great books to start with, and what follows is a quick run down of the major arguments for Evolution, and how they fit into the Christian world-view.

Problems with Literal Bible Interpretations

Christianity has a very poor track record when it comes to literal translations of the Bible. The most poignant, and relevant, example would be the stories of Copernicus and Galileo. They had the audacity to suggest that the Earth actually revolves around the Sun, contradicting a long standing teaching of the Church that the Earth is obviously the center of the Universe, because the Bible says so. We all know how that one turned out.

So following this, are Creationists making another mistake in taking the Bible literally? It would appear so, as the first two chapters of Genesis give two (arguably three) different creation accounts.

Genesis 1:1 –

In the beginning, God created the Heavens and the Earth.

Gensis 1:2-31 –

• Day 1 – Light and Dark
• Day 2 – Land and Air
• Day 3 – Sea and Land, Vegitation
• Day 4 – Sun Moon and Stars
• Day 5 – Water Animals and Birds
• Day 6 – Land Animals and Man
• Day 7 – Rest

Genesis 2 –

• Earth and Water
• Man
• Vegitation
• Animals
• Woman

While the comparison isn’t one-to-one, it’s easy to see that the order of events do not match up. If one is to attempt to take the Bible completely literally, this is a difficult contradiction to overcome.

Other arguments against literal interpretations of the Bible include discussions of the Hebrew writing style, mainly that they wrote more in poems and stories, and that the writers were less concerned about factual accounts, but as I am not knowledgeable in this I’ll leave it at that.

Evolution’s “Random Chance”

A major misconception that is proving very difficult to dispel is this idea that Evolution is a completely random process. This idea couldn’t be farther from the truth. Most Evolution nay-sayers completely forget about, or do not completely understand, the concept of Survival of the Fittest. All mutations are put through the most strenuous of tests: surviving and reproducing. When mutations pass this test, they get fully integrated into that gene pool and thrive. When the mutations fail the test, the organism(s) die off and the mutation is lost. The key point here is that most mutations fail the test due to the random nature of the process mixed with the very complex nature of DNA.

Due to this, were our evolutionary process to be done over, we most assuredly wouldn’t be exactly the same, but fish would still be shaped like they are (for efficient movement through water) and birds would have wings and probably hollow bones (for light-weight and moving through the air). The limits imposed on organisms by the world they live in are what drive evolution failures and successes, we are not the direct result of a few thousand random mutations, we are the result of a select subset of mutations that survived among the millions that allowed us to survive and thrive in our environment.

Unevolvability

Another common argument against Evolution is this idea of “unevolvability.” Creationists say that there are biological components (the eye and bacteria flagellum, to name two) that simply cannot have evolved because if a single part is missing, the component is useless. Useless parts, of course, are not favored in Evolution and thus, these parts should not exist.

This is actually a very true statement, which lends towards it’s strength in the Creationism world. However, there is a very pivotal assumption being made in this argument that Evolutionists have found to be a false one. This is the assumption that the parts of these components are only useful in the component they’re found in today. I’ll paraphrase the argument made in Language of God on how a bacteria’s flagellum actually did evolve to show this point.

Flagellum³ is a collection of proteins used to propel bacteria through it’s environment in a rotating and/or whip-like manner. This is obviously a very complicated system, and if any of the many parts were to be missing, this locomotion would not be possible. This does not disprove Evolution though, because scientists have actually found parts of the flagellum being put to completely different uses⁴. For example, scientists have found a similar sub-construct being used as a secretion system.

I’ll admit this can be hard to understand for those of us who aren’t medically versed, but the point is this: the process of Evolution periodically takes a working and capable part, and mutates it to be something completely different. There is a lot we do not know about this process, but there is very strong evidence that biological constructs previously thought to be unevolvable are in fact a direct product of the evolution of various other constructs. For further information, here’s Wikipedia’s page on the evolution of the eye.

What Evolution Does Not Cover

Given all this, there are still a few points that Evolution and Science in general does not yet have answers for. Among these are:

1. How did life itself get started from a lifeless ball of rock orbiting a burning ball of gas?
2. The Big Bang. Something exploded, but where did that something come from?

If we can figure out how to answer question #1, that would be the biggest breakthrough in all of Science: the ability to create life. This of course has some very far reaching moral, religions, and philosophical issues to work through, for if Man can create life from lifelessness, does that new life have rights like the rest of us? And what does that mean for Man itself, the ownership of a life form, etc?

As for question #2, I’m not sure if that question can be answered scientifically. As our viewing technology gets more sophisticated, we can see closer and closer to Time Zero, but how do you see anything before the Big Bang and is there anything to really see?

What I Believe

So given all this, how exactly does my Christianity work with current scientific knowledge? I believe that God used and continues to use Evolution in our Universe (even outside of the Earth? we may never know, but there’s nothing stopping God from such a thing). I believe that there had to be something that God created out of the nothing that was the Void, and that this thing eventually exploded in the Big Bang.

I believe that at a certain point in our Evolutionary history, God had on his hands beings that were advanced enough intellectually to understand Him and to worship Him. He embodied these beings with souls and named them Adam and Eve, starting what we know call the Human Race.

I believe that God gave us Science and infinitely inquisitive minds and as such it’s impossible for Science to in any way disprove the existence of God. We are simply learning about the world that He put us in. Any scientific finding that seems to go against my personal beliefs should be a cause of reflection on the discovery and on the beliefs I hold, not of immediate rejection of the science in question.

Going Forward

So what can I do to help fix the state of affairs in this country? I can educate people. Talk with friends, discuss with family, and encourage people to branch out. I’ve found that the best way for me to strengthen my faith is to doubt what I believe. With doubt comes uncertainty, and the mind hates uncertainty, and will crave resolution, which requires more information. When I can take this one further and can get other people to doubt their fundamental ideals, the discussions and debates that follow can only help to strengthen my beliefs. If I can get a few people to change their thinking, they’ll do the same with others.

I realize that fanatics and extremist will always exist, but the key to defeating them is to ignore them, to defuse their movements. If they’re yelling at people, and no-ones listening, they’ll eventually go away. This won’t be easy, but it’s necessary if this country is going to stay the leader in scientific advancements.

Evolution is the process God put in place to bring about life on this Earth.

1. http://www.merriam-webster.com/dictionary/believe
2. http://www.talkorigins.org/faqs/evolution-definition.html
3. http://en.wikipedia.org/wiki/Flagellum
4. http://en.wikipedia.org/wiki/Evolution_of_flagella

I’m not going to write it because frankly, I’d never want to read it. So I’ve condensed my point into three simple words:

BALANCE

PVP

FIRST

You simply cannot have a PvE game and add PvP on top of it. PvP is player skill, PvE is just numbers. One could go to the extreme and say that they can’t co-exist, but I’m not quite convinced this is true. Close, but not quite.

Problem is, it’s very hard to find the simple How-Tos for common situations in all this text. I spent many days scouring and tinkering to figure out the security solution to my application: a flash-based video viewer that would connect into a server and display Motion-JPEG frames that get streamed in.

Hopefully I’ll help save someone else the same hours of research and playing with this problem. My solution is such:

You first need up a simple service on the server you want to connect into that serves the crossdomain.xml content that defines your security policies.

I use a modified version of the service found here: http://www.lightsphere.com/dev/articles/flash_socket_policy.html. It’s updated to be a full Daemon process, so you need Proc::Daemon and Proc::PID::File installed.

Please note:

<site-control permitted-cross-domain-policies=”all”/>

is the required addition to make this script work with Flash 10. Also, if you are worried about corporate firewalls blocking ports < 1000, simply change $port to something bigger, and add the following to your Flash client:

And you're good to go!

I have to say, I’m impressed. I was appalled at the atrocities perpetrated by the Bush administration, especially now as more information gets leaked out, but what’s going on now is mind-boggling at best, and at worst will decimate our country to where we’ll never recover.

I refer, of course, to the constant Republican QQ-ing and stonewalling about the choices the Obama administration is making.

Ever time I hear a prominent Republican talk on TV, on the radio, or read something on the Internet, I hear nothing but “waaah waaah I’m not getting my way anymore so I’m going to make life difficult for everyone who doesn’t see things my way, waaah waaah!” Ironic, this, as it’s the old-folks that are acting like 8 year olds who aren’t getting their way.

Aparently, some of these people need a refresher for what THEY had a hand in for the past EIGHT YEARS:

• DOUBLING our National Debt from ~$5 trillion to > $10 trillion
• TWO wars, one justified one not
• The justified war in Afghanistan has been under-manned and assumed to be a “quick romp” to clear out the Taliban. Guess who’s back in power and even stronger?
• The unjustified war in Iraq has destroyed the friendships we had with many countries around the world and has made even MORE people angry at America, leading to MORE terrorists. Iraq will fall into civil war between Sunni and Shiite as soon as we leave, just you watch.
• Decimation of personal liberties through acts like the Patriot Act and the Digital Millennium Copyright Act (What did Benjamin Franklin say about safety and liberty?)
• Secret prison camps. Torture guidelines, Guantanamo Bay, Detention without Trial
• … and who knows what else we’ll find out about in the coming years

You guys have done a TERRIBLE job at running the country. Why should we trust, or even listen to, anything you guys have to say? You complain about lack of bi-partisanship, but then you don’t ever budge on your stances on bills. You guys are going to fight the new Supreme Court nominee (well, you’re probably still pissed that the exiting justice, David Souter, made you guys look like idiots, but I digress), only because it’s Obama’s choice, not one from your party.

You guys might mostly disagree with Limbaugh, but come on, you are all working towards Limbaugh’s ultimate hope, the “failure” of Barack Obama.

Do you care about this country? Or do you only care about your personal “values” that get thrown out of the window anyway once you’re in power?

Congratulations on losing most of the young vote (like myself), that’s really going to help you get back into power in the future. Oh and grats on alienating the Hispanic vote, and most of the Black vote too. In fact, the women vote is going to the Democrats as well (thank you Limbaugh!)! If anything, the self-inflicted implosion of the GOP has been very entertaining to watch, but the delusion that the party is still as relevant now as it was 20 years ago is causing far more damage than good.

That said, there is a simple solution to this problem:

Grow Up.

Now of course I can’t list, or even think about, most of the design decisions that have helped towards making WoW the massive success that it is, but there are a few decisions, both good and bad, that have hit close to home for me, decisions that I have to work with or around every time I play. Were I to be on the WoW dev team, these are some of the things I’d be recommending.

Stat Equality

Wow is all about gear because character power advancement is built completely around the stats. The stats in WoW are Strength (STR), Agility (AGI), Intellect (INT), Spirit (SPI), and Stamina (STA), and they are directly related to how powerful your character is, or at least they should be.

In WoW, stat allocations over the various classes has always felt arbitrary, and frankly it’s a very complicated system that doesn’t need to be, which has lead to serious balancing issues between Melee and Caster classes that have yet to and probably will never be fixed.

For example, a Warrior gets two Attack Power (AP) (stat on which all abilities scale, thus directly related to damage output) per point of strength. Rogues and Hunters get their Attack Power from AGI (Hunter is considered a “Ranged Melee” class by the game). However, Mages get a 1% increase chance to crit every 60 INT along with 100 mana per one point of INT, while Spell Power comes purely from items themselves. SPI gives a DPS boost to Warlocks because of a skill that class has, but anyone else just gets mana regen (as of 3.1, SPI does give very small amounts of crit now too), making it a very important stat for some healing classes, but not all.

Confused yet?

When WoW first came out, progression for DPS caster classes, especially Mages, stopped hard at level 60. The game did not have the stat Spell Power, so the only benefits Mages got from gear was higher health in STA and more mana / crit with INT. The game did have Attack Power, so melee were outscaling Mages exponentially, who were simply able to cast spells longer. Since then, caster DPS scaling has been an issue.

A much, much simpler system of making INT behave like STR would have gone a long way towards simplifying scaling from the beginning. If your game is going to have stats, make them consistent. Arbitrary decisions will lead to big problems, and sooner than you’d expect.

All stats need to scale to appropriate levels and then some

Following the above, make sure those stat decisions actually do scale into the foreseeable future. It is surprising to see a Blizzard lead designer explicitly say that they check the scaling of all classes only through to the next patch or expansion (which ever is nearer) and fix problems as they crop up. I can’t begin to imagine the amount of work that would have been saved had more care been taking at the beginning to make stats less complicated and properly scale for longer than just the next tier of gear.

Character resource decisions can make or break balancing from the beginning

The Death Knight uses a Runes and Runic Power resource system. The DK expends Runes on certain attacks, those attacks build Runic Power, from which the DK then uses other abilities that deplete the Runic Power. Any rotation a DK choses can be kept going forever.

Rogue energy is always refilling and simply serves to put a “cast time” on rogue abilities. Rogues can fight forever.

Warriors have Rage. Warriors gain Rage when they hit with white attacks or get hit. They then use this Rage to use special attacks. This system, while dependent on Rage income, can be kept going forever.

Casters use Mana, and can run out. They cannot fight forever. This is a very poor decision that has caused numerous problems with fight balancing, character balancing, and makes PvPing with these classes especially difficult.

Healers are not included in this. Healers running out of mana is a very valid ’soft enrage’ system to put on a raid. If a healer could go forever, then any fight is easily trivialized.

Warhammer got it right: every class uses a refilling energy system like the WoW Rogue.

Incentives drive player inclusion

Converse to that, disinsentives do drive players to not participate. When you’re dealing with a group of people, it really is quite easy to predict what that group will do. For example, by adding Battlegrounds and gear rewards for doing those battlegrounds, Blizzard completely destroyed World PvP. Why spend hours ganking people in the world when at least you get rewards for doing it in a Battleground?

Achievements!

Nothing has refreshed WoW like Achievements. Giving people the ability to show off their exploits, to be rewarded for taking on hard content, or for committing acts of crazy mindlessness (see: The Loremaster) helps keep players busy with tasks they otherwise have not done, along with just straight keeping them in-game and paying. Nothing helps a game’s population than more ways for people to show off what they’ve done.

World Events

Special time-specific events are always a big hit for players, but they usually are very time consuming to implement and it’s rare that every player gets to participate in said events. WoW’s system of having set events that happen throughout the year, every year, help to make sure that as many players as possible can experience this specially crafted content. Hooking achievements to world events was of course a brilliant idea, and has made players actually look forward to the next event, preparing and planning.

Mistakes have been made, but it cannot be denied that Blizzard hit on the recipe for hugely successful MMO. It’s easy to get into, easy to play, difficult to master, and full of content for everyone, from the PvPer to the PvEer to the players that just hang out with friends. There’s a lot to be learned from this game, and I’m sure designers will be using WoW as a template for many years to come.

Part 3 will be my (hopefully not to angry) rant on the decision Blizzard made to try to turn a PvE game into a PvP game, and the constant balancing work that has and is going into both sides of this game.

Turns out, this is a lot harder to figure out than it would initially seem. The irb code is quite complex and nothing there is documented in any way shape or form. Also, searches around the Internet came back with results that were some six years old, and while helpful, did not pertain to my particular case.

Then I remembered that ruby-debug does exactly what I’m looking for. A quick glance in that code got me the code snippet I needed.

require 'irb'
 
module IRB # :nodoc:
  def self.start_session(binding)
    unless @__initialized
      args = ARGV
      ARGV.replace(ARGV.dup)
      IRB.setup(nil)
      ARGV.replace(args)
      @__initialized = true
    end
 
    workspace = WorkSpace.new(binding)
 
    irb = Irb.new(workspace)
 
    @CONF[:IRB_RC].call(irb.context) if @CONF[:IRB_RC]
    @CONF[:MAIN_CONTEXT] = irb.context
 
    catch(:IRB_EXIT) do
      irb.eval_input
    end
  end
end

And it’s use is quite simple. When you want to drop into an irb session, you simply do

IRB.start_session(binding)

and you will have a code prompt with all data available at your finger-tips.

See the related rb++ commit

You use this feature in rb++ as follows:


ruby your_extension_file.rb console


From there, start playing around with the parsed source tree using either @parser or self.namespace to get started.

I figured, now that I’ve got a blog, it’s time to start taking more permanent notes on the design decisions, both good and bad, of the various games I play. To start, I’m going to pick on the 800lb Gorilla in the room, World of Warcraft (known here on out as WoW). This is the first of what will be a multi-part series of articles, as I tend to delve in to rants and ramblings at time. However, I will try to keep it all coherent. So, without further ado…

I’ve been playing this game on and off for nigh three years now. I’ve seen plenty of ups and plenty of downs, been a part of quite a few guild breakups, and have developed an almost unhealthy love of criticizing and critiquing every little change Blizzard make to the game. I’ll admit, it’s not the best state of mind to be in, and many-a-time it has eaten away at me and caused me to loose all enjoyment of the game as I end up only able to focus on what’s wrong and not what’s fun.

What follows are the results of my brooding over the what and the why of the decisions made at Blizzard. Why does Blizzard make the decisions they do, what are the ramifications, and what can other game designers and developers learn from one of the best companies in the business. To start off, the most important rule about game design in general is quite simple:

You are building your game. Make the decisions you think are right.

I give Blizzard HUGE applause for what they have accomplished with WoW. It is by far the most complicated game ever created, and the fact that they have kept it running, continually added more, and still kept the same general WoW atmosphere and Blizzard Polish since release is a testament to the courage the development team has in shaping this massive game over time. Given all the flak they receive on a daily basis on their official forums and forums across the world, Blizzard rolls right along with the punches.

If you want your game to be successful, trust your instincts. It’s your game, not theirs. Make the game you want to play. That said…

Some players will know the game better than you

An interesting phenomenon I’ve been following with WoW is the statements of theorycrafters (those players that constantly calculate and run all the numbers they can get a hold of, to find the best, the worst, and everything in between) contrasted to the official statements of Blizzard, and what I’ve noticed is this: the theorycrafter community is almost always right.

As an example (and this will be difficult to really show without forum posts, but those are gone so please bear with me), with the most recent expansion to the game, The Wrath of the Lich King, we’ll look at how WoW’s PvP game became, quite frankly, a failure.

Wrath of the Lich King came with three changes that worked together to completely dismantle the game’s PvP.

Up the level cap to 80
Restart everyone on even footing as of level 71
Introduction of the Death Knight

Upping the level cap is a normal move for any MMO expansion, and follows with the previous 10 level jump we saw in The Burning Crusade (TBC), the first expansion. There needs to be significant increases in the status of player characters, so it stands to reason that a level 80 character would easily tromp a level 70 character.

Restarting on equal footing is almost a necessity given WoW’s PvE end-game. Now, first and foremost, WoW is a gear driven game. Everything you do to make your character more powerful involves gear. To help be better in PvP, you get better gear. To do better, and progress farther in PvE, you acquire better and better gear. The side effect of this is, a level capped character with full end-game PvE gear is far more powerful than a character who just hit the level cap. With a new expansion, and 10 more levels to grind through, Blizzard could not require high end PvE gear to continue through the new content or they would have very quickly lost a large portion of the player base (as only about 10% of the population really experience much of the end-game content).

So, the new area, Northrend, had to offer quest reward items and random world drop items that were almost equal in power to the previous end-game PvE gear, putting all characters back on an even footing. This means that everyone suddenly does more damage, has more health, and is overall significantly stronger (example: my best raiding DPS in TBC was around 1500. When I started raiding again in Lich King, I was already doing 2500 and quickly improving). In general, the calculations showed that a level 80 character started out about 2.5 to 3 times more powerful than at level 70.

The introduction of the Death Knight was long in coming, and heavily anticipated. A new class for WoW was just what the game needed to bring a fresh breath of air to the game some people had been playing for 3 straight years by then. It is a class with a novel new resource system (Runes and Runic Power), tons of new spells and abilities to master, and an entire new starting area built just for the class and its lore leading up to Lich King. Blizzard put everything into this class, they wanted it to be a huge success, and quite a success it has been, and a major sore spot as well.

With the triage of these three major changes, WoW’s PvP was doomed from the start. It didn’t take the theorycrafters long to crunch the numbers, to play with classes on the Test Realm, and to come to the conclusion that at level 80, characters were either going to do way too much damage, or they weren’t going to have high enough health pools to soak up the huge damage increase. Posts on the official forums and post on respected theorycrafting forums like Elitist Jerks showed, argued, and asked constantly for Blizzard to re-think their stance on character power at level 80, but Blizzard would have none of it. If there’s one statement seen the most, it was “We will just wait and see what happens” often followed by “We think it will be ok, characters will have enough health.”

Well the “wait and see” has happened, and the game’s PvP devolved to the worst it’s ever been. Healers gave up trying to heal, because you can’t heal someone who gets killed in 3 seconds or less. Entire classes stopped playing because they either couldn’t do the damage others could, or they couldn’t get out of the way of the incoming damage. It was, and in most cases still is, absolute mayhem. Skill has been shoved into a trailer and gear and choice of class is the king of PvP now. To see what I mean, here’s the top 10 ranked PvP Arena 3v3 teams as of the March 24th:

The top 10 teams of the 2009 Arena Tournament’s online qualifier as of March 24, 2009 are listed below:

Rank. Team Name	                Classes
1. well then                        Death Knight, Paladin, Warlock
2. BARKSDALE CREW             Death Knight, Paladin, Warlock
3. monkey attack squad        Hunter, Mage, Shaman
4. GET MONEY GET PAYCE     Death Knight, Hunter, Paladin
5. Walrus Attack Squad	        Hunter, Mage, Priest
6. Paradorn’s Team	        Hunter, Paladin, Warlock
7. NO LIGHTNING GEN BRAH	Death Knight, Paladin, Warlock
7. Nekos’ Team	                Death Knight, Death Knight, Paladin
9. faceroll tunnel vision         Paladin, Priest, Shaman
10. Wd’s Team	                Death Knight, Paladin, Warlock

Pretty obvious to see just how inbalanced the PvP game has become. The top teams, while good at PvPing anyway, are so much better simply because of the class composition of the team. Entire classes are absent of this list: Druid, Warrior, and Rogue, which ironically enough were always present in Arena teams during TBC.

Anyway, it’s a lot of talk to make a point, but the severity of the failure because Blizzard didn’t listen to the theorycrafters at all needs to be shown. There have been many steps since taken to “tone down burst damage” since Lich King’s release, but Blizzard has a long way to go. More time up front, and a willingness to admit that they were wrong, and Blizzard could have made huge strides towards preventing this catastrophe. Blizzard has been working hard since the release of TBC to make WoW’s Arena a viable “e-sport”, but with current state of Lich King’s PvP, they have taking a very severe blow to that work, making it that much harder to convince people that Arena is worth standing on the pedestal with games like Counter Strike and Quake.

Continue with Part 2

So the choice of theme made, the name came down to two: Forty-Two, otherwise known as The Answer, or Slartibartfast, because the name really doesn’t matter. I was leaning towards Forty-Two, and with an extra vote from a good friend of mine, it became the name.

I’ll probably update other parts of the site to fit the theme, like the subtitle and the categories. All in all, feels good to have a solidly named site.

Now, what do you get when you multiply six by nine?