Blar

I didn't have anything of interest to report about my projects this week, so I tried to come up with something else to write about, but ultimately came up with nothing. I tried to write something about the philosophical implications of the statistical nature of society, but couldn't find the words. In retrospect, the idea sounds kinda pretentious anyway. I hate to have yet another empty blog post, but frankly I'm burnt out on trying to come up with something at the moment.

Parsing Problems

Last week I mentioned that I'm going to be working on a parser for the programming language I designed. I've been trying to refine and simplify the language's grammar before starting that. For the most part, the language is C-like and most of the grammar can be summed up with a precedence chart. However, a few of the operators work strangely and throw a wrench into that.

The best example I can give is the colon operator. The colon operator fills the roles of both constructors and type casts. It is typically used like this:

foo int: bar + 10,

Which declares a variable, foo, of type int and initializes it to bar + 10. When the colon operator is used for casts, it might look something like this:

foo = bar + int: baz + 1,

Which is parsed like this:

foo = (bar + (int: (baz + 1)),

Basically, everything to the right of a colon 'belongs' to it. However, this creates a problem. It doesn't fit neatly into the precedence chart. The left side of the colon has a different precedence than the right. This makes the language's grammar more complex.

The behavior of the colon operator is usually pretty intuitive when actually writing code. Likewise, it's not particularly hard on the parser. However, it does substantially complicate learning the language. Instead of a simple precedence chart, I have an unwieldy spreadsheet.

The colon operator is not the only thing complicating the grammar. Right now, I'm trying to change things to reduce weird parsing rules. It cases like the colon operator, I would like to preserve it's general usage without making the user type a lot more.

IOU

I've been pretty distracted this week. That might have something to do with Zero Escape: Virtue's Last Reward. I'm gonna be lazy right now and instead write up a post tomorrow. In the mean time, I'd highly recommend the Zero Escape series. The games are engaging, well thought out, and occasionally funny to boot. Definitely start with the first though; the second builds on the first.

Anyway, I'll have something more interesting to say tomorrow!

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.