Mars Tycoon, The "Sandbox World" Strategy Game

extollIT Enterprises is developing a new kind of innovative video game. We call this genre the Sandbox World game. There are three other games I know of that are similar to our concept, but only one can be credited with its inspiration:

• Dwarf Fortress
• Infiniminer
  
• Minecraft
• Roblox

If you haven't heard of these games, I suggest trying Minecraft or Roblox. Dwarf Fortress has inspired Mars Tycoon, but it is very difficult to get into if you are a novice gamer.

Our small team of three has been developing this game since the fall of 2008. You are a space-pioneer in the year 2492 and desire to escape the chaotic political climate of Earth to investigate a strange new mineral on Mars (and beyond) first discovered on a small asteroid that impacted Earth. Scientists have dubbed it with the name Loganite and although it's chemical signature has long been familiar to scientists it has never been found in nature let alone in vast quantities.

Loganite has significant commercial value as a nuclear fuel as well as having other peculiar benefits. Scientists are only just beginning to discover Loganite's value to mankind.

Your job is to establish a mining base on Mars, extract the Loganite, and compete against other nations scrambling for the mineral. You will have to defend your mining base from saboteurs, natural disasters, and skirmish attacks.

Launch of Mars Tycoon is scheduled for 2015. If you posses any of the following skills / experience / knowledge and would be interested in joining our team, please contact us using the About -> Contact Us menu at the top of the page:

• 3D Modeling / Animation
• 3D Programming Experience
• Programming for CG, CUDA, PhysX
• AI Programming Experience
• Biochemical Engineering
• Mechanical Engineering
• Civil Engineering
• Chemical Engineering
• Geophysics
• Horticulture
• Astrobiology
• Genetic Engineering

"Wait a sec! These are pretty steep qualifications!"

Actually not really. Although some of these "qualifications" demand post-doctoral work, you don't even need to have a post-secondary degree here. Self-directed study is very acceptable. For example, we are interested in people with Chemical Engineering knowledge to help us design a realistic Asimovian Sci-Fi experience.

We have a rich and comprehensive vision for Mars Tycoon in terms of both storyline and gameplay mechanics, so Mars Tycoon will be an introductory game into this universe. If it is successful, we plan to release sequels and prequels each sporting both an expanded storyline and new gameplay mechanics.

Computing Arc-Length of a Spline - Advanced

Here is a snippet of my own software used in another project that computes the arc-length of a spline using the Gauss-Legendre quadrature (numeric method of integration) implemented with recursive template meta-programming in C++:

First-off, you will need a constant 5x2 array of doubles to initialize the abscissae for, which is essentially a pre-computed table of the roots of the Legendre polynomials of order n. In this example I use order of 5, which was accurate enough for my purposes:

const double ABSCISSAE_5[5][2] = {
    -0.90617984593866399280,  0.23692688505618908751,
    -0.53846931010568309104,  0.47862867049936646804,
    0.0,     0.56888888888888888889,
    +0.53846931010568309104,  0.47862867049936646804,
    +0.90617984593866399280,  0.23692688505618908751
};

Stub out an exception to generate runtime errors when incorrectly implementing the class:

class CalcEx : public std::exception {};

Below the recursive class template is defined. It uses template-inheritance and since templates are interface-agnostic, you will need to define this method on your class: inline real f (const real t) const. It's essentially providing the implementation for an abstract method declared in the base class.

template <typename T, typename Derived, int NN>
class GaussLegendreInt
{
    private:
        template <int N> T abscissa (const unsigned int i, const unsigned int j) const
        {
            throw CalcEx ();
        }
        template <> T abscissa <5> (const unsigned int i, const unsigned int j) const
        {
            return static_cast <T> (ABSCISSAE_5[i][j]);
        }

        template <int N> T summate (const T val, const T a, const T b) const
        {
            return val + summate <N - 1> (
                abscissa <NN> (N - 1, 1) *
                static_cast <const Derived *> (this) -> f(
                    (b + a) / 2 +
                    ((b - a) / 2) * abscissa <NN> (N - 1, 0)
                ),
                a, b
            );
        }
        
        template <> T summate <0> (const T val, const T a, const T b) const { return val; }
        
    public:
        inline T compute (const T a, const T b) const
        {
            return ((b - a) / 2) * summate <NN> (0, a, b);
        }
};

Now it's time to put our algorithm to use and build a class that takes a spline object (usually four points or two points and two tangents) and computes the arc-length using the Gauss-Legendre algorithm we've prepared:

template <typename Spline, typename real>
class ArcLength : private GaussLegendreInt <real, ArcLength <Spline, real>, 5>
{
    private:
        const Spline & _spline;

    public:
        inline ArcLength(const Spline & spline) : _spline(spline) {}

        inline real f (const real t) const
        {
            return MAGNITUDE(_spline.computeAt (t));
        }

        static inline real calculate (const Spline & spline)
        {
            return ArcLength(spline).compute(0, 1);
        }
};

The spline object assumes a function called computeAt that returns a vector (2D, 3D or whatever) of which the function MAGNITUDE computes the vector magnitude of. You will define these yourself including your implementation of splines. There are plenty of examples on the Internet on how to implement splines. Some examples include Cubic B-Splines, Catmull-Rom Splines, and NURBS.

Innovation 101 for the Perfectionist

To innovate is to introduce something new to the public that is usable and meets a perceived need. This article will dispel some common misconceptions that the perfectionist may have with his approach to design. Since women are perfect anyway and have this area covered, I will only use masculine pronouns. Actually it's for the sake of brevity. As someone who IS a perfectionist, this article is written for other perfectionists just getting his or her feet wet with this stuff. I suppose you could say that a perfect design goes hand-in-hand with proven innovation. But as the perfectionist I cannot say I've always shared this perspective and it's difficult to get over it. Hopefully this article can dispel some of the myths holding the typical perfectionist back from greater success.

MYTH: Perfection in design is necessary.

The fundamental reason perfectionism fails as a good approach to software design is because perfectionism does not factor human error into code design. Human error is inevitable and "nobody's perfect". To expect consistent and perpetual perfection from yourself, your team, or even your customer's requirements is unrealistic. Therefore, the perfectionist must accept human error as a valid and acceptable factor in the design process. It is haphazard to turn a blind-eye to this variable. Expect loose-ends to come from anywhere. Probably the most dangerous assumption to make is that the customer has a good understanding of his or her business challenge. In the end trial and error is inevitable to evolve and refine a product.

MYTH: Perfectly designed software leads to a quality product

How do you measure the quality of a product? Simply by how accurately it accomplishes its original purpose, which is defined by the customer's requirements. But how often are those requirements written in stone? How often can we say that they everyone understands those requirements perfectly? The perfectionist operates with these assumptions. Furthermore, it takes too long to develop a product that is perfect. Since software requirements change quite frequently, the result can be a lot of wasted time on a polished but irrelevant design. If you can't get it out the door, if it's incomplete, then it is far from perfect. One key characteristic shared by all of the most successful products out there is that they each do exactly one thing very very well and that has been attained through multiple iterations of trial and error.

MYTH: A perfectly designed product is highly maintainable.

Since details of implementation are often up to one individual programmer, his perception of perfection may be way-off the mark to someone else. Furthermore, code that conforms to standard OO design patterns religiously is not maintainable because it proves to be an overwhelming task to trace program flow through a deluge of, however highly cohesive and decoupled, unfamiliar classes. An experienced developer knows that any algorithm that can fit conveniently into various design patterns is common-place and more than likely already in a reusable framework somewhere anyhow. For the rest of your intellectual property, you yourself know that it doesn't fit conveniently into standard design patterns. Moreover, you know that your product isn't innovative because it is common-place. And so it becomes necessary to bend the rules while ironically keeping in mind other developers who might have to look at it later.