## Archive for the ‘Graphics’ Category

### Summer Project, Weeks 4-9

Tuesday, August 24th, 2010

Continued from part one, more details about my quest to make a fun game about shooting things into space.

### Week 4

Took the week off.

### Week 5

I only got a little bit done this week, but it makes things look better. Each astronomical body has a rotational rate that controls how it is drawn, and projectiles always rotate to face the direction of their movement. I know that you actually need an aerodynamic projectile which is inside an atmosphere to have this happen, but it’s aesthetically pleasing, so I’m keeping it for now. I’ll revisit it if I have any clever ideas when I’m making self-propelled projectiles.

### Weeks 6 & 7

These two weeks got eaten up preparing for and recovering from Otakon.

### Week 8

This week I rejiggered a bunch of the numbers for the solar system I was using so that my planets were actually close enough to one another and large enough that you can actually see them all. Previously I was using values from our real solar system, which gave me a set of stable orbits, but everything was so far apart that I had to assign the planets pixel-based sizes to make them even be visible. I now have a much smaller set of numbers, where everything is in much closer together. I then made a random map generator based on these new numbers. I also added a whole mess of asteroids to the maps so that I can have them swinging around. So that I can get the same random numbers and thus the same map on any platform, I grabbed a Mersenne Twister library to use in the project. No more crappy libc rand() implementations for me.

After that, I started on something a lot cooler – collisions between objects. Objects now bounce off of each other like pool balls, which can result in a fun mess if I send a planet careening through a mass of asteroids. I also had a bit of fun bouncing two planets in the same orbit off of each other, although slight imprecisions in the math resulted in their orbits eventually degenerating into an unusual arrangement, as you can see in these screenshots:

Finally, as you may have noticed if you were playing a lot of attention to those screenshots, I ported my work over to the Mac. Now that I have a laptop again, it only makes sense to keep this project cross-platform. Since all the tools and libraries I’m using are cross platform, it was only a minor inconveniece to set everything up.

### Week 9

Didn’t get anything done again. I’m rapidly running out of summer.

### Summer Project, Weeks 1-3

Saturday, July 10th, 2010

### Description

This summer I’ve decided to dedicate some time to working on programming a game. For eight weeks, from June 20th to August 14th, I am planning to put in at least a couple of hours three nights a week. At the end of this time I will evaluate my progress and the state of my project and set further goals.

Now, what is this game that I’m making? At its heart, it’s a 2 dimensional artillery game, like everything from Scorched Earth to Worms to the one with the gorillas that came with QBasic. The twist to what I’m doing is that the entire thing is set in space. Your planet, orbiting the nearby star, is firing upon other planets, also orbiting the same star. Everything is constantly moving. In order to keep confusion under control and to counter the fact that shots aren’t repeatable, I have plans for an interface to allow player’s to simulate where their shots will land. To the best of my knowledge, this sort of game hasn’t been built before. We shall find out if it was for good reason or not.

I’m going to try to post an update on my progress every week or so. Here’s a quick recap of what I’ve done so far.

### Indeterminate Past

Before this all started, I decided one day to write an orbital simulator, just for the fun of it. As I played around with it, I started thinking about making it into an artillery game. After I finished my initial project, and could sit and watch the planets of our solar system make their way through the sky, I wrote some game design ideas and set some development milestones, but didn’t do any more coding.

### Week 1

I got off to a rather slow start. All I finished in the first week was rearranging my old code some so that it looked a bit less like a weekend hack (which it was) and a bit more like the groundwork for a project that could maybe go somewhere.

### Week 2

I’d picked out a few UI libraries I wanted to try integrating things with, so I tried them out to see which to use. At first I tried Agar. I was finding it a bit heavy, and wasn’t sure it was what I wanted, so I decided to try out my other contender, GiGi. I couldn’t even get GiGi to compile (on Windows), so back to Agar it was. I then had to struggle significantly to get my existing Cairo-based drawing code to output things onto a graphics surface Agar was happy pushing onto the screen. Eventually I got all that done and was left with a solar system app that no longer supported any sort of user input and used more CPU than it used to. All around, a success!

### Week 3

This week I actually started tackling some of the new functionality I wanted to include. I’ve been pulling items off of my to-do list for a (very!) minimally playable demo. I’m going to stick with the philosophy of getting things “playable” as quickly as I can and then keeping them so at all times. This week I have added a placeholder UI, and established the basis of a turn structure by having the physical simulation hooked up to the “Fire” button. Today I finished up support for loading texture images off disk so that my planets don’t have to be flat colored circles anymore.

As a reward for a job well done I set two planets on the same orbit in opposite directions and watched them pull each other into the sun.

### Map Generator #2

Sunday, August 16th, 2009

Added from last time, I created a second layer of the map that marks which cells are part of which contiguous region. Currently the only regions recognized are land masses and bodies of water. In the future I will most likely also define rules to recognize hilly and mountainous regions. The regions themselves are discovered using a simple floodfill. The next step after this has me a little intimidated, as it will be to use spline curve approximations to vectorize the regions.

The code as it stands takes shortcuts – for example, the program will abort if more than 200 regions are discovered, as the region list is statically allocated. As things continue along rough edges like this will be dealt with.

Have a look:

### Map Generator #1

Tuesday, August 4th, 2009

After not doing any free-time coding for quite some time, I’ve started a new project. I intend to make a program which can randomly produce a high quality hand-drawn looking fantasy world map. As an example, I’d like output that looks something like this map. I have chosen to develop this as a Mac OS X application that produces scalable PDF files as output. This will involve a number of things that I do not have any real previous experience with. In this post I will discuss the initial terrain generation aspects. I anticipate the next task after that will be dividing the map up into a number of regions based on geographic artifacts and then a vectorization process. Once that is done I will then want to add additional features such as rivers, forests, and towns.

### The Code

The version of the code as of this writing is available for your perusal as you read this, as is the most recent version as I add more features. If you wish to follow along any, I will briefly discuss the main two files I created.

#### terrain.m

I had not previously had any experience with fractal terrain generation. A quick search revealed several useful sources. I created my algorithm from this description and images. I chose to not stitch the sides of the map together as most old-style maps are of a particular region of an entire world, so a loop would not make sense. The code difference is very small, though, so I may make it an option later.

The meat of this file is the function generateWithSmoothness. The basic terrain generation algorithm is the one described in the previously linked article. It’s fairly simple. Each step of the process is based on squares and diamonds formed by the points that have already been evaluated. The center points of these shapes are set to the average of the four corners, plus or minus a random offset. Adding points to the centers of squares in a grid creates a diamond pattern, and adding points to the centers of the diamonds creates a square pattern again. This is repeated until all points have been evaluated. In my implementation I perform this process iteratively instead of recursively as a depth-first solution will have problems with trying to use parent-level points that have not been evaluated yet.

I parameterized the smoothness of the terrain so that I could easily link it with a control in the UI. The smoothness factor controls the rate at which the random factor is decreased at each level of iteration. If the factor is rapidly reduced to near zero then all the points are just the averages of their corners, leading to a very smooth effect.

#### TerrainView.m

This class implements the component that owns the terrain class from above, tells it to generate, and displays the result. Most of the drawing code, in the drawRect function, was lifted from my earlier Demon project. It simply goes through the data returned by the terrain class, normalizes each point, and blacks out all points below a certain threshold in order to make a smooth surface for the “water”.