A Brief Interlude with Virtual Brains

Last week I spent some time playing with an older project that I haven't touched in a while. It's an evolution sim where virtual creatures are controlled by artificial brains.

Virtual creatures. The white lines are trails.

In my senior year of college, I took that concept and turned it into a game. The idea was that the creatures would evolve as you fight them to get better at avoiding you. It was a fun little shooter, however, the evolution aspect never really played out well.

Virtual brain.

In my opinion, it wasn't a failure of the concept so much as a failure of my models. It turns out it's actually quite difficult to design a system that evolves well. Someday, I would like to make a spiritual successor to that original game once I've settled on a better model.

Selection. My senior game project. © 2011 DigiPen Institute of Technology

For now though I'm going to move on to other things. I recently discovered packrat parsers, and was inspired to work on the programming language I designed. If all goes well, I'll probably dedicate a few weeks to the task.

Making Me Crazy

I actually got some stuff done this week! Unfortunately, that 'stuff ' was overhauling my make files, so I don't have much in the way of pretty screenshots to show off. However, it's something I've been wanting to do for a while now and it feels good to get it done. The system is now a lot more modular. For example, the large scale terrain simulation I was working on is now properly separated from the game, whereas before I had to comment/uncomment code just to switch between the two.

I've never actually described my work environment in this blog before, so now seems like a good time to do that. I had to learn how to work in Linux at my last job. Having been spoiled on Windows my entire life, it was a trying experience. However, in time, I learned and got comfortable with it. Eventually, I got to the point where I actually preferred it. Currently, I have Fedora 20 installed on my home computer with the Xfce desktop environment.

I discovered something else during that time. A friend introduced us and it was love at first sight. I am of course talking about Sublime Text, the best text editor on the face of the planet. I tried it out one day and never looked back.

I've been using C++ for just about a decade now. It's actually kind of mind boggling to me that that's true. Needless to say, I'm comfortable with it, and that's what I'm programming my projects in. The compiler I'm using is GCC.

Editing my code on the left with Sublime, compiling it on the right in a transparent terminal, occasionally with a video playing in the background.

One of the biggest problems I've had with my personal projects over the years is that I tend to break them and then forget about them. The result is that I had little to show for all the tinkering I did. To mitigate this, I started using a personal Git repository. Now I can revert to earlier builds and show them off.

That alone wasn't enough though. I have some common code that is shared between projects. All too often, I'd make changes to that common code while working on one project and end up breaking all the others. This would lead to me avoiding those broken projects until they were long forgotten.

The first step I took to fixing this was to clean up my make system. Until now, each project had it's own makefile that was nearly identical to all the other ones. Now I have one common makefile that is used for all my projects (although each project has a small makefile for project-specific settings).

I also created a simple, but good dependency system. Each project can depend on any number of other projects and specify how the code for those projects will be linked to create the final executable. The three options are:

• Direct Linking - Object files from the dependency are linked directly into the executable.
• Static Linking - The dependency is built into a static library (.a / .lib).
• Dynamic Linking - The dependency is built into a shared library (.so / .dll). 

The list of dependencies is recursively expanded, with duplicates and circular dependencies removed. The order is preserved to ensure everything is linked in the correct order.

Build targets are determined by two factors. The mode (debug, release, etc) and the platform, which is a combination of things like OS and architecture. Corresponding preprocessor defines are passed to the compiler for when target-specific code is needed.

The plan for the future is to create a Git branch for each project. This way, I can change the common code used by one project without breaking all the others. I will need to occasionally update projects to reflect changes to the common code, but I'll be able to do this when it's convenient, rather than being forced to do it whenever a change is made.

Reaching Hidden Depths

Still feeling kinda stuck. I decided to play around with normal and parallax mapping a bit as a change of pace. I took the lazy approach with parallax mapping so it looks pretty bad at extreme angles. I'll implement a better method if I decide to revisit these things more seriously later on.

I also started cleaning up my makefiles. Hopefully my workflow will be a little more streamlined when I'm done.

I would really like to add some actual gameplay to this project. I had a lot of plans for how I was going to use information from the large scale terrain generation to create gameplay, but putting that on the back-burner also blocked my gameplay plans. I might just have to force myself to hack in new things for now and revise things later.

Another Day (Blog Post) Another Dollar (No Dollar)

My apologies to Tom Siddell for stealing your joke for my post title.

Sorry to say there's yet again nothing to show this week. I seem to be in a bit of a rut. I think it'd probably be a good idea for me to set aside large-scale terrain generation for a while so I can make some progress.

I honestly can't really think of anything else to write about at the moment. I might update this post if I get an idea later today, but no promises.

It's a Small World After All

I'm still working on large-scale terrain. I decided to try a hexagonal grid rather than a square one because it seemed more natural. Plus, it avoided the awkward question of whether or not I should have water flow diagonally. Here's a screenshot. The terrain itself looks more natural, but lakes and rivers no longer form quite as easily, which I have to work on.

Here's a screenshot showing the hexagonal cells. Each vertex is one cell. The lines show the connections between them.

One thing that's changed is that the different layers can now mix together to a degree. I'm not sure if this was a good move. It's more realistic in some ways, but the results aren't quite as interesting. Feels like two steps forward and one step back. There are still a lot of things I want to add (temperature, humidity, snow and ice, plants, etc), but I'm trying to get the parts I have now working as well as possible before adding more complexity.

Interesting fact: the area I'm simulating is roughly four square kilometers, but this can be scaled up.

Building a Legacy

No update this week. I hit a bit of a wall on the project. Then I bought Rogue Legacy and kinda got sucked into that for a few days. I'll try to have something more next week!

Large Scale Terrain Generation

This week I worked on large scale terrain generation. The plan is run an environment simulation for some amount of time to create large scale structures (such as lakes, rivers, and mountains). The actual game will then use the large scale features as a guide for more detailed generation.

I'm using a different algorithm to generate the elevation. Specifically, I'm using the idea described on this page. I like this algorithm a lot because it's very simple and produces good results. Compare a planet created with Perlin noise vs. the spherical landscape algorithm:

Using Perlin noise.

Using spherical landscape.

Perlin noise tends to be more uniform resulting in a planet covered in lakes. While this can be overcome by adding multiple noise layers together, there are a lot more variables that need adjusting to get it looking good. With the spherical landscape algorithm, on the other hand, you need only to adjust the number of iterations. It tends to produce more varied results, which look more like oceans and continents.

Currently, the environment simulation works by iterating on several layers of 'fluid'. I use this term loosely because what I'm doing is not at all physically accurate (and I'm applying it to soil and sand in addition to water). The bottom-most layer is rock. Rock doesn't flow at all, but it can be eroded, which results in sand. Sand resists flow more than water, and soil more than sand, which creates flat-lands and beaches. Rain is simulated by evaporating water from every point and redistributing it equally.

The environment simulation is pretty bare bones at the moment, but it's already producing good results. I'll probably continue working to make it better for a few weeks before using it to generate actual game terrain.