Compiler? I Hardly Know Her!

This week I've been working on a programming language I designed. Specifically, I've been working on a compiler. A friend told me about the LLVM Compiler Infrastructure, and after reading up on it for a while I decided to use it. Here are some reasons why I made this decision:

• LLVM supports multiple platforms.
• LLVM optimizes your code, and allows you to create further optimizations.
• Existing tools that work with LLVM will be able to work with my language.
• LLVM is tested and maintained, which means less testing and maintenance on my part.

Basically, you write some high-level assembly code, and LLVM does the rest of the work for you.

I've spent a long time planning out this language. However, actually writing the compiler has been pretty challenging so far. It's one thing to know you could look at an arbitrary program and compile it by hand. It's quite another to write something that does all that for you.

Since I've only made a little headway on the compiler, I'll talk a little about the language itself. My working name for the language is Virtual. Here are a few of its features:

• Virtual is designed to be performant (comparable to C++ and D).
• Virtual allows for flexible metaprogramming, including templates, and reflection.
• Plus, procedural generation of classes and functions.
• All compile-time expressions must be simplified before code is ever generated.
• This essentially allows you to do functional programming at compile-time.
• Lambda functions
• Shorthand loop syntax can replace most loops.
• C++: for (int i = 0; i < foo.size(); i++) foo[i] = i;
• Virtual: [foo.* = *],
• Tuples are first class citizens.
• and can be used as the return type of a function.
• Inline expansion can be forced, both for an entire function and for individual calls.
• Perfect forwarding is a natural consequence.

It may seem a little kitchen-sinky, but care was taken not to include conflicting features. Bringing all together will be a challenge, to say the least, but I'm looking forward to using it someday.

Break for Christmas

Forgot to post this yesterday, but no post this week on account of Christmas C: Happy holidays everyone! Also, read this if you need some cheering up!

The Space Jelly

Hey guys! So this week I don't have much to talk about, so I decided I'd write a little prose instead. It's a response to the concept art writing prompt on this io9 post.

"Our self is quite long."

So spake the space jelly. The creature arrived unceremoniously ten years ago. At first, it was taken to be a hoax. One can hardly blame people for being skeptical with headlines like, "Giant Jellyfish Found in Low Earth Orbit".

A Short Introduction to Template Metaprogramming

Template metaprogramming is a technique that allows you to do a lot of work at compile-time rather than run-time. It's a good way to generate code that is both flexible and fast. In this post, I'm going to walk through a simple example.

Edit: The examples in this post are written in C++.

So lets say that you're implementing a vector class. It might look something like this:

template <typename T, unsigned int n>
class Vector
{
    public:
        Vector<T, n> operator+ (const Vector<T, n>& v) const;

        T data[n];
};

You want to implement vector addition. You first thought would probably be to do something like this:

template <typename T, unsigned int n>
Vector<T, n> Vector<T, n>::operator+ (const Vector<T, n>& v) const
{
    Vector<T, n> temp;

    for (int i = 0; i < n; i++)
        temp.data[i] = data[i] + v.data[i];

    return temp;
}

This gets the job done, but it isn't optimal. We have to check the variable i every iteration to make sure it's still less than n. In an ideal world, we'd do this:

template <typename T, unsigned int n>
Vector<T, n> Vector<T, n>::operator+ (const Vector<T, n>& v) const
{
    Vector<T, n> temp;

    temp.data[0] = data[0] + v.data[0];
    temp.data[1] = data[1] + v.data[1];
    temp.data[2] = data[2] + v.data[2];
    ...
    temp.data[n - 1] = data[n - 1] + v.data[n - 1];

    return temp;
}

Unfortunately, C++ is not cool enough to have a straight forward way of doing that, so we have to get creative. That's where templates come in! We can make the variable i a template parameter and rewrite this function as a recursive function.

template <typename T, unsigned int n, unsigned int i>
void AddVectors(Vector<T, n>& result, const Vector<T, n>& l, const Vector<T, n>& r)
{
    AddVectors<T, n, i - 1>(result, l, r);
    result.data[i] = l.data[i] + r.data[i];
}

template <typename T, unsigned int n>
void AddVectors<T, n, 0>(Vector<T, n>& result, const Vector<T, n>& l, const Vector<T, n>& r)
{
    result.data[0] = l.data[0] + r.data[0];
}

template <typename T, unsigned int n>
Vector<T, n> Vector<T, n>::operator+ (const Vector<T, n>& v) const
{
    Vector<T, n> temp;
    AddVectors<T, n, n - 1>(temp, *this, v);
    return temp;
}

There are still a couple of problems with this though. First, we're still not gaining performance; we've just traded condition checking for function calling. Second, C++ doesn't let you partially specialize functions. To solve the first problem, we use the inline keyword. This gets rid of the function calls and puts the code direction into the calling function. To get around the second, we can put the function in a template class like this:

template <typename T, unsigned int n, unsigned int i>
struct AddVectors
{
    static inline void Func(Vector<T, n>& result, const Vector<T, n>& l, const Vector<T, n>& r)
    {
        AddVectors<T, n, i - 1>::Func(result, l, r);
        result.data[i] = l.data[i] + r.data[i];
    }
};

template <typename T, unsigned int n>
struct AddVectors<T, n, 0>
{
    static inline void Func(Vector<T, n>& result, const Vector<T, n>& l, const Vector<T, n>& r)
    {
        result.data[0] = l.data[0] + r.data[0];
    }
};

template <typename T, unsigned int n>
Vector<T, n> Vector<T, n>::operator+ (const Vector<T, n>& v) const
{
    Vector<T, n> temp;
    AddVectors<T, n, n - 1>::Func(temp, *this, v);
    return temp;

}

There! Now you have a function that adds two vectors without a loop and without extra function calls! This is just a simple example, but the same technique can be used on larger, more complicated problems. However, I should mention a few caveats before you start going crazy using it everywhere.

First of all, compilers are pretty good at optimizing. In the simple example above, the compiler would probably get rid of the loop anyway. Metaprogramming is best saved for recurring problems that come up frequently in your program (vector math, for example). Second, the inline keyword isn't guaranteed to work. The C++ standard leaves it up to the compiler to decide what should or should not be inlined. The inline keyword is really just a request from the programmer. There are usually compiler-specific keywords to force the compiler to inline a function, but using them requires extra maintenance if you ever want to support a different compiler. Lastly, if it wasn't already apparent, code like this is much longer and much harder to follow than normal code. It can also significantly increase compile times. If you're working with other people, the performance gains might not be worth the confusion.

All that said, there are definitely real and useful packages out there that use template metaprogramming. Both boost and Eigen rely on it heavily. I have a lot more to say on the topic, but I'll save it for later posts.

Of Groups and Other Things

My goal is to make a grid-based cube world, not unlike Minecraft. However, I don't want it to appear outright as boxy as that, so I'm going to include other shapes, not just cubes. Here's how I can to decide on which shapes to use.

The first shape that came to mind, other than a cube, was a slope. Naturally this led to corner slopes as well, both inner and outer. I then decided I wanted slabs, blocks that are only a portion of the height of a full block. This led to the idea of scaled slopes as well. I decided to divide the shapes into four possible heights. Not content to favor the vertical direction, I decided to include all rotations and reflections of these shapes.

At this point, the number of shapes had already climbed into the thousands. It became evident that if I wouldn't be able to handle each shape by hand on a case by case basis. I needed to to use math!

So I started thinking of mathematical ways to organize the different shapes. The easiest thing to do was to categorize each block by which slices you'd have to make to carve it out of a cube. For the slopes, that meant cutting diagonally. For the slabs, cutting flat across the middle.

Because I wanted four levels to my shapes, I just had to figure out all the slices that only cut across fourths on each edge. That way, there would be no awkward shapes that wouldn't match up with any other shape.

This actually turned out to be quite challenging. In 2D, the idea is pretty simple. You just pick any two points on the outside and draw a line through them. It's doesn't work out so nicely in 3D. There are lots of ways you can pick three points that don't result in a valid cut.

I spent a long time on that, but it seemed that no matter which way I organized the shapes, there'd be a couple of gaps full of invalid cuts. After many hours of trying to make that work out, I went with a somewhat simpler approach. I start with a tetrahedron made by slicing through three of the cube's corners. Then, I take that and scale it on each axis. Then I take those shapes and extrude them along each axis. Then, I also include the inversions of all those shapes.

When all is said and done, I end up with 54,000 different combinations. This way of doing it also has some nice properties. I can arrange the whole thing in a 30x30x30x2 grid, which allows me to look things up easily. I can encode the position of a shape within this grid using 5 bits for each axis and a bit for inversion (encoding each axis separately allows me to discern qualities of a shape easily). This is exactly 16 bits, which allows me to use 2 bytes per block rather than more, and doesn't waste them. I can also tell whether two shapes cover the same cross section along an axis by checking if they're in the same line in that grid.

To sum up a long story, here is a picture taken from within that grid of possibilities.

Playing with Blocks

To be honest, I mostly just played Skyrim this week. And I regret nothing!

How do I say this? Basically, I wanted to make Minecraft before Minecraft was a thing. Or, more accurately, I wanted to make a game like Dwarf Fortress that was played from a first-person perspective. It annoys me now that making such a game would immediately be taken as a Minecraft knock off, when it'd really be a Dwarf Fort knock off. Truthfully, the Terraforming game is actually this same idea, but with a different theme.

I started on such a project during my senior year of college. This is as far as I got before schoolwork and prepping for graduation started monopolizing my time.

What I learned from the experience is that Minecraft is much more technologically impressive than one might think. My project ran at about 15-30 frames per second, where a comparable Minecraft world easily did 60 on the same computer.

Recently I've been thinking of starting up the project again and working on it. For now, I want to stick with a fantasy theme, rather than working on the Terraforming game. The reason for this is that I have a much clearer idea of how I'd want to carry out the design in a fantasy setting. Fortunately, most of the work should carry over to a game set on Mars.

Before I left the project, I had only accounted for square blocks. In an effort to make things look a little less blocky than Minecraft, I'm going to include other block types. These are the three basic shapes. Each of these can be rotated and scaled to produce many different shape types. Additionally, the shapes can be inverted (replacing empty space with filled space, and filled space with empty space) to produce more even more shapes.

Hopefully, by next week, I'll have something more to show. However, given that both Thanksgiving and my Anniversary are coming up, I'm not anticipating getting a lot done.

Words, Words, Words

Salutations! So I bounced back a forth between a few things this week. I did a little more work implementing the programming language I designed. Bittersweetly, I encountered a few small problems I hadn't foreseen. While this was frustrating, it was also nice to have them called to my intention.

I also worked some more on the math library (see this post for relevant links). At one point, I modified the game to start using it, so now the game's kinda stuck until I either finish the math library or at least get it working well enough to function. My choice to include concepts from geometric algebra is making it difficult to complete. It's hard to find good reading material on the subject, and often even harder to wade through it. I love the subject, and I've enjoyed learning about it, but it can be a little overwhelming at times.

When I started the original library (years ago before I'd even heard of geometric algebra), I used templates to implement things (including some fancy recursion and inlining to avoid unnecessary loops). I continued that way for a while, but it quickly became more trouble than it's worth. So instead, I wrote a program to generate the code for me.

Another one of my interests, not mentioned till now, is language. Specifically, constructing languages. Years back, I started work on a conlang (short for constructed language). It went through many revisions, but I eventually stopped working on it. It's been gathering dust since. Fast forward to now, when I decide to drudge it up and start working on it again! The thing I always had the most trouble with was actually making up words. You might be thinking, "if you weren't making up words, then what were you doing?". Consider that making an interesting language (i.e. not just replacing English words with new ones) involves phonology, morphology, grammar, etymology, and a whole slew of other considerations.

For anyone who might be interested, this site has lots of good resources on language making. For breaking away from English pronunciation, you might want to look into the international phonetic alphabet. This site has interactive charts, complete with sounds. I recently learned about the Swadesh list. A short list of basic meanings. It's been very helpful, and has given me a good starting point for creating words. Here are some similar lists one can use.

Well, that's all I got for right now. See you next week!

Turning Things Around

I've been thinking a lot about what I'm doing with my life right now. It seems like my whole life (or at least my whole 'adult' life) I've wanted time to work on my own things, without being interrupted by school or work. When I decided to take a year away from work that was originally the intent; just to give myself time to do whatever I wanted. For various reasons I stewed on that decision for a long time. I didn't actually act on it until half a year after I'd decided to do it. During that time I had the idea that I could make games to support myself and continue not working a normal job. And I could do that, I still might, but that's not why I wanted to do this.

Since I moved I haven't really been happy. I got rid of work obligations only to build up artificial obligations around myself. It's been hurting my personal life and my relationship. Thankfully, I think I've started to turn that negativity around. So I'm going to get back to the real reason I'm here. If I happen to end up making something that makes me money, then that'll be awesome, but if not that's okay too.

I'm going to keep updating this blog, but from now on it'll cover whatever I happen to work on. You might see updates regarding the game (or other games!). After all, it's still something I want to work on. I just don't want to dedicate myself to it exclusively.

----------------

Now for part two of this post. I'll talk a little about the non-game things I've been doing. While I was at my job, I spent some of my spare time designing a programming language. I may eventually go into more detail about it, but for now I will sum it up by saying it's roughly halfway between Lisp and C++. Working with Regular Expressions in the past two weeks got me interesting in getting back to that. After a year or so of design considerations, I finally did some actual work on it. I used Bison and Flex to make a parser for it. A friend of mine suggested using LLVM to compile it. For those unfamiliar, LLVM allows you to write low level code that can then be optimized and converted into machine code for various platforms, rather than having to create each implementation yourself.

I did actually work on the game a little too. I started working on a 3D model of the basic robot in blender. If I ever get around to writing a PLY parser, I'll import the finished product into the game.

Back to Regular Expressions

So way back when I wrote this post, I mentioned I was working on a regular expression parser. I put that on the back burner for a while, but decided to revisit it this last week. I based my implementation on this article. I felt pretty pleased with myself once I got it working, though I'm still working on submatch tracking. Once that's done, I'll be able to use it to parse text based files like OBJ and PLY.

I feel like I should address why I'm not using any 3rd party engines or libraries. It's not exactly a wise choice for a game developer, especially for an indie. I don't really have a good reason beyond that I don't want to. I want to use this time as much for learning as for game development, and I enjoy tackling these sorts of problems. I like doing things my own way, and I get a certain kind of foolish pride out of knowing that all the code was written by me. Good choice or not, I'm going to stick to that.

Updated Concept Sketch

Well, I didn't end up spending much time sketching, but I did manage to whip up some better concept art for the basic robots. Considering all the dust on Mars, I'm pretty sure that this sort of robot would do really poorly on the planet. Fortunately, I'm much more concerned with making the robot adorable.

Considering how often I have little to nothing to write about in these posts, I've decided to try switching to weekly updates rather than daily. Hopefully this will mean longer, more interesting posts. So from now on, I'll be doing a post every Tuesday.

Until We Meet Again

Still debugging. Not much else to say really. It's looking like I'll be pretty busy today and tomorrow (in addition to being away this weekend). So no posts until next Tuesday. Hopefully, there will be some concept art doodles by then.

Compile, Run, Crash

Well, I'm now using the new math library in the game, but there are still bugs I have to fix. I'll be house sitting this weekend so there won't be any posts on Saturday, Sunday, or Monday. I also won't have my computer with me, so I won't be able to work on the game. I'll try to get in some drawing time and maybe have some concept art to show by next week.

Still on a Tangent, but Winding Down

I'm still on my math tangent, but I'm winding down. I finally understand spinors and multivectors well enough to implement the basics. I found a really good primer on geometric algebra which filled in a few gaps in my knowledge and cleared up some misconceptions that I had.

My plan is to finish up a basic implementation of spinors (generalizations of complex numbers / quaternions), and then replace the hard coded math library I've been using with this general one. Why? Mostly because I can. My game doesn't really require super complex math, but it may come in handy.

I've been trying to get away from some of the bad math used in computer science, not just in this game, but in all my coding projects. In addition to basing things on geometric algebra, I'm also using tau (2 pi) instead of pi. Despite the work it took to learn these concepts (and more importantly, how they change traditional theories), I can happily say that they've actually made things easier.

More Links!

So yep, I'm still working on math stuff. I should probably stop, because it's not really necessary for the game, but I'm enjoying the tangent.

So here's a list of some nice games you might not of heard of!
Papers, Please - A game about stamping passports at the border. All about making tough choices.
Shelter - In this game you play as a mother badger protecting her young from the dangers of the world.
Space Chem - From a while back. An awesome puzzle game about chemistry (sort of).
Last Year's PAX 10 - All good games. Check the link for descriptions. Towerfall and Ridiculous Fishing were particularly good.

My family is visiting today, and I probably won't have much time to work. I think I'll skip tomorrow's post. Be back on Tuesday!

I Got Nothin', Have Some Reading Material

Still working on more of the same. Since I don't have much I can say about my personal progress, I'll put up some links! For fellow programmers out there (or anyone mathematically inclined), I would highly recommend reading up on Exterior Algebra (also known as Grassmann Algebra) and Geometric Algebra. Both are ways of extending Vector Spaces to be more useful and awesome. The two are very similar, but Geometric Algebra is more powerful.

Eric Lengyel gave a very good presentation on Exterior (Grassmann) Algebra at GDC 2012 (one that I saw in person!). It goes over what Exterior Algebra is, why everything you know about rotations and lighting is a lie, and what some good applications are.

Probably won't have much to report tomorrow either, so I'll try to dig up some non-mathy links to share then.

Edit: Retroactively linking a really good Geometric Algebra primer.

Another Day in the Land of Math

Nothing much to report. Just making slow progress. I also drudged up an old vector/matrix library that I want to use. I'm making a few changes to it to incorporate things I've learned since writing it.

The Job Process

Finished up the revisions to pathfinding. I've been thinking about how to get the robots to automatically pick up and finish jobs, and this is the process I'm going to use.

1. Create job at location. Jobs have required resources and required labor.
2. Find the nearest available resources and create a hauling job for each one.
3. Find the nearest and most qualified robot to complete the job.
4. Once all resources have been gathered, signal the robot to come complete the task. 

In general, jobs may depend on other jobs being completed. Most will require at least one hauling job to move something from one place to another. The only part of that process I'm still shaky on is finding the best robot for a given job. For example, how far away does a well qualified robot have to be before it's better to just pick a nearby under qualified robot?

Variation

Still refactoring code, but making good progress. For one thing, there can now be multiple terrain types. The grid is now fully 3 dimensional. Pathfinding will now consider not only the tiles the bot is moving through, but the tiles it has to move over as well. Objects and units have been consolidated into a common type, and there can now be multiple objects on a single tile. Basically, all changes under the hood. It's not much, but here's a screenshot showing off multiple terrain types.

Pause for Maintinence

Whelp, I inadvertently ended up taking another day off. Sort of. Laundry and dishes had been piling up so I decided to take care of those and ended up spending the whole day cleaning. So yeah, sorry for another day of no progress.

And On the Seventh Day, He Had a Hangover

Well, it's a little late for a 'morning' post, but here it is. I had a great time at my friends party. So great in fact, that I spent all of Sunday recovering from it. I did, however, get a lot done before the party. Unfortunately, that mostly involved refactoring, so no new screenshots. Still working toward getting some AI and having a better rendering pipeline. Made some changes to the way pathfinding is set up, which I'm hoping will be more efficient and flexible. That's all for now!

Architecting Robot Intelligences

TL;DL, it's going to take me a while to get real, interesting gameplay, so I'm putting last week's goal on hold. I'll still be working on it, but I'll focus on other things in my posts until I get a little further along.

Did some more work on fleshing out a rendering pipeline today. It's a little new for me. I'm familiar with graphics programming, but I've never had to set up a pipeline for it. The projects I've worked on either had someone else working on that or were too small to need a robust pipeline. It's an annoying problem because there is an absolute 'best' solution (fewest possible GL calls), but in practice, it's better just to settle for a 'good' solution.

As far as actual gameplay goes, I did a little work on that as well. You can use the menu to create build orders now, but I still have to write some AI to make the robots actually carry out those orders. And the more I think about it, the more I realize that that's going to take a while. Since orders can be scattered about the map arbitrarily, I need some way to determine which robot is closest and most qualified to carry out the order. In principle, there could be obstacles in the way (for example, a wall that you had built earlier), which means it's more complicated than just picking the closest robot.

I also need to somehow keep track of which robots are working on which jobs. The robot needs to know so it can work on the job, and the job has to somehow be marked as 'in progress' so that other robots don't take it. Additionally, resources are needed to complete jobs, so those have to be moved to the job site, meaning that I need to give the robots an inventory.

No post tomorrow, I'll be out with friends. And I think I'm going to start writing posts in the morning rather than before bed, so next post should be Sunday Monday morning.

Rendered Speechless

Slow day. Still thinking on how exactly I want to do things. I took off on a tangent and started thinking about ways I could make a better rendering pipeline. Not much else to say today. Probably no post tomorrow Saturday night. A friend invited me to a housewarming party, and I expect there will be drinking.

Debugging: Hours of Hard Work Just to Break Even

Today I fleshed out the GUI system and made it usable. I added in a sub-menu to test it out; it should be easy enough to fill out the items as I need them. Aside from that, I got sidetracked with a handful of annoying bugs that took a while to track down. One was in my bitmap importer. It was turning some of my textures red. There was another with a small change I made to the input system. Turns out I just wasn't calling the function. The goal for tomorrow is to be able to order robots to be built. Not sure how long it'll take me to write AI for the bots to actually carry out those orders. I've been playing a little Dwarf Fortress in my spare time hoping that I might pick up some ideas on how to implement it. Additionally, I headed into the city and had a few beers with some people I know, because it's important to leave the house occasionally.

Uneventful

I'm trying to put together some kind of event system for the menus. It's making me miss C#. I love C++, but its pretty much terrible when it comes to event driven systems. The whole thing's proving to be a bit more tricky than I anticipated. I've never really thought in depth about how to make a good GUI from a programming perspective. Will continue working on it and have another post tomorrow.

What's On the Menu

Today I renovated the text renderer. Once drawing text was no longer a huge hassle, I started working on the GUI and now I finally have one! The buttons don't do anything yet, but they're there and they're being drawn. Here's a break down of what each button is for:

• Log - Opens up the mission log. This lists important events in the order they have occurred.
• Construct - Choose robots and/or buildings that you want built.
• Orders - Order your robots to perform certain tasks, like mining and paving roads.
• Stockpiles - Designate where resources and other items are to be stored.
• Mission - Checklist of mission goals.
• Robots - A list of all your robots and what they're doing.
• Jobs - A list of jobs in progress and which robots are working on them.
• Priorities - Order the importance of various tasks.
• Status - General status.

Obviously, those are all subject to change, as is the layout and sizing. Tomorrow I will work on getting the buttons to actually do things.

Slow and Steady

Didn't get a whole lot done today. Some, but not a lot. Slowly dissecting a giant main function into proper classes. Did some thinking about how I want to do the GUI. Worked on improving text rendering a little to make working on the GUI easier. Been making slow progress these past few days, but progress nonetheless.

Pause

Didn't work on the game yesterday. I did that thing where one goes out into the world and socializes with other people. I'll also be taking Sunday off to spend time with family.

All Work and No PLY

Whelp, I got sort of sidetracked today. I figured I'd work on writing some code to import models. I started an OBJ importer a while ago, but abandoned it. I worked on it briefly, but then decided to look into some other formats. I've written an FBX importer before. I'm not a fan of the format, for many reasons. I'm in no hurry to use it again any time soon. Additionally, I'm planning on using Blender for modeling. While Blender does have an FBX exporter, it doesn't officially support importing FBXs, which is inconvenient to say the least.

So I looked into STL and PLY. It didn't take long for me to dismiss STL, but I was quite taken with PLY. I started writing an importer. By the time I had nearly finished it, I had started thinking about how often I seem to write parsing code and decided it was about time I just wrote something that can handle regular expressions. By the time I had done a little of that, the day was spent.

I'm not sure how much more time I'll end up spending on those things. It may be a few days, or I may set it aside for a while and get back to focusing on the game. In any case, I'll leave you with an appropriate comic from XKCD.

Another Day, Another Blog Post

Not much of note happened today. I've mostly been refactoring code. Which is to say, I've been fairly productive but have little to show for it. My goal for the upcoming week is to have all these things happening:

• Player can create orders to build the Basic and Solar robots.
• Robots automatically carry out these orders.
• Solar robots gather energy from the sun.
• Other robots receive energy from Solar bots when they're running low.

Once I have that much, it should be easy to build more off of it. I also thought up some more possible resource types: hydrogen and carbon. Plastics are mostly made up of these two elements. Thus, these elements would go into 'fast' robots (to complement silicon for 'smart' robots and iron for 'strong' robots). Hopefully tomorrow's post will be more interesting.

A* is Born

I finished up implementing A* today. There were a lot of bugs I had to work though, but it seems to be working now. There's still a minor bug left. Under certain conditions robots will go through an extra square. It's weird, but predictable and doesn't break anything so I'll look into it later.

For those familiar with A*, I'm using an unusual heuristic that I learned from one of my professes in college. The robots can only move to adjacent squares, diagonals included. The heuristic returns the shortest possible distance obeying those rules. It's cheaper than Euclidean distance, but more accurate than Manhattan or Chebyshev. Incidentally, because the robots can only take those kind of paths, the heuristic is also admissible (it'll never over estimate the distance).

I've also added a travel cost to each tile. This can be used to make tiles more difficult to travel through. For example, rocky terrain would have a higher cost than paved roads. Here's a picture of the pathfinding in action. The black tiles are walls, and the green tiles are the tiles considered by the algorithm. The robot is moving from left to right.

How Shall I Path to Thee, Let Me Count the Ways

Worked on pathfinding today. I'm a little disappointed in myself that it's taking me more than a day to implement A*, but in my defense, I was trying to be clever about it. I want the game world to be as close to Mars in size as possible. Obviously, I'm not going to be pathfinding for the whole planet at once. I plan to only simulate the area the player is focused on at any time, while approximating time passing in other areas. However, the more efficient I can make things, the larger the area I can surround the player with. For now though, I think I'm gonna strip it down and make things simple. I can complicate matters later.

Day 6

Got some rudimentary text up and working. It's just a bitmap ascii font (lifted from Sublime as a placeholder), but it'll do the trick for now. I also whipped up a texture and slapped in on the placeholder spheres to make them look more like robots. The rest of the work today was mostly code cleanup and math related. Tomorrow is my boyfriend's birthday, so I'll (probably) be taking the day off. After that, I plan to start tackling game logic.

Day 5

Blar. I didn't get to work on the game today. We still have a few boxes laying around from after the move, so I decided to go through the one that was full of paperwork. It was boring and time consuming. I'm going to try to get some text and other GUI elements in tomorrow.

Day 4

I started writing code today! I setup a very basic world layout so I can start working on game logic. I've got a skybox and a 100x100 grid. The spheres are placeholder robots (with color denoting type). I haven't written any code for them, so they just sit there for now. Not much else to report today.

Day 3

Today was more productive! Although it will still sound boring! What I did today mostly involved spreadsheets. Here's a couple of things:

For now, I'm going to start with a relatively simple 3 resource system, although I'll probably revise the system later. For now you've got:

• Iron - Roughly corresponds to the size and 'strength' of the robot.
• Silicon - Roughly corresponds to the computing power or 'brains' of the robot.
• Energy - Used for building and for carrying out tasks.

Iron and silicon can be mined or extracted. Energy can be harvested from various sources (I spent a good deal of time today looking into the pros and cons of different kinds of primary energy). Robots also require energy to stay operational, and have to recharge when they get low.

The types of energy sources you use are important. Some might result in pollution (which might actually work to your advantage). Wind is clean and cheap, but unreliable. Hydro power is very efficient, but first requires you to fill mars with water. Fission is a good source, but also results in dangerous, long lasting waste, not to mention the possibility of catastrophic failure.

I also started working on the numbers behind several robot types. I'll introduce a couple for an example. Basic Bots (featured in yesterday's sketch) can perform any mundane task, but not very well. Other bots specialize at a single task. Mover Bots, for instance, cost more to produce than Basic Bots, but they can carry a lot more.

It's kinda like comparing a Swiss army knife and a screw driver. The knife can do more things, but the screw driver's better if all you need to do is turn screws. Now, lets say Movers can carry twice as much as Basic Bots. This means they have to cost less than twice the price of a Basic Bot, otherwise you could just build two Basic Bots.

In actuality, there are more variables involved, and the numbers aren't quite as nice, but you get the idea. I filled in some rough numbers today, but I still have to work on balancing them.

Day 2

Whelp, not much happened today. Got sidetracked by car troubles which took up a good portion of the day. A conversation with my boyfriend helped me flesh out some story details and gave me a few gameplay ideas. Hopefully I'll have something more interesting to post tomorrow. In the meantime, I'll leave you with some sketches from about a month ago.

So It Begins!

So after saving lots of money and quitting my job, it's finally time to begin making an indie game! An endeavor that will hopefully become my career. I'm excited and terrified, but hopeful.

For months I tossed around game ideas in my head, but I eventually settled on one: a game about terraforming Mars with self-replicating robots. The game will focus on resource management, and will play somewhat like Dwarf Fortress. The player's job is to plan and issue commands, which the robots carry out automatically.

I expect the project to start slowly. The first few weeks will be likely be dedicated entirely to research and design. I'd like to try for daily updates on this blog. I probably wont have much to say in the first few weeks, but I want to get in the habit.

I've done some brainstorming and research already. Today I started refining those ideas and fleshing out the details. Robot types, resource types, player goals and actions, etc. In particular, I'm also considering the 'big problems' of terraforming. The long term player goals that need to be met. These include things like raising the temperature, improving the atmosphere, shielding from radiation, etc. All large-scale actions will have multiple effects; some good and some bad. An important part of the gameplay will be balancing the effects of your decisions.