Fun art projects #

I've not been in the mood to write articles lately, so instead I've been working on some fun projects instead. Watabou posted about Dyson Hatching, which got me thinking it might be interesting to constrain the hatch lines to Voronoi cells. I implemented that and then got carried away with colors, line spacing, line width, and other fun things. The demo is here. You can drag an image onto the diagram to use the colors from your image.

Hatch lines applied to an image

Types of projects #

When I started writing articles on my site, sometimes I had great results, like writing the hexagonal grid guide in 6 weeks, and sometimes I had terrible results, like writing article about curved roads in 5 months. I eventually realized that the difference was that with hexagons, I understood the topic well, but with curved paths, I spent most of the time trying to understand the topic. To make matters worse, because I had a high standard for my articles, I spent too much time trying to polish the article about curved paths, even before I understood it well.

Back in 2013 I decided to create a separate directory /x/YYWW-name/ where I'd put the lower effort and experimental pages, numbered by year and week. For example, 1942-isometric means year 2019, week 42. Over the last few years I've realized I do two different types of projects:

Curved region rendering #

Around a month ago I had an idea in my head: a voronoi grid modified to have rounded cells that change in size. I made an attempt here for single cells changing size. The next step was to merge cells together, as I had done on this project. I decided that the way to demo this would be to simulate some kind of belief/cultural systems that spread over time across a map. I tried this here.

Screenshot of influence map experiment


Procedurally generated annotations #

Imagine exploring this dungeon:

Dungeon map
Procedurally generated dungeon map


Chaikin Curves #

Sometimes I want to draw Voronoi or similar polygons in a rounded form:

Rounded polygons. Lots of them.

I use a process called Chaikin's Algorithm for this.


Verb-noun vs noun-verb #

I went to the Roguelike Celebration over the weekend and enjoyed Thomas Biskup's talk about Ultimate ADOM. Among the many interface improvements they're making based on user testing is they're simplifying the controls from the traditional roguelike controls to W A S D + E F. I don't know how roguelike game players will respond to that but I'm a fan! This reminded me of two things from my past, so I thought I'd say a little about those.


Square tiling of a sphere, part 3/3 #

In the previous post I described how I learned about the cube/sphere geometry so that I could put a square grid on a sphere. I ended up spending too much time on that, because it turns out the mapping from cube to sphere wasn't as useful as I had thought. This happens to me sometimes, where I find something fascinating, spend a lot of time on it, and it turns out to be not that important.

As the final step in learning how to work with square tiles on a sphere, I wanted to make something on the sphere. I decided to make a dungeon map.

Dungeon map on a sphere
Dungeon map on a sphere

Labels: , ,

Square tiling of a sphere, part 2/3 #

In the previous post I described how I learned about HEALPix because I wanted to try covering a sphere with square tiles for a game map. During that exploration I realized that HEALPix with 12 square regions is similar to cubes with 6 square regions, but HEALPix has some nice properties for numerical calculations such as spherical harmonics. I don't need those properties. Instead, I am looking for something that's simpler to program, so I explored cubes.

Diagram showing the Earth mapped onto a cube
Earth mapped onto a cube

The goal is the same: I want to play a game on a flat top-down tile map (roguelikes, Dwarf Fortress, Factorio, etc.), but these games have one of three approaches to the map:

Labels: , ,

Square tiling of a sphere, part 1/3 #

I almost always work on 2D game maps, but occasionally I get intrigued by planetary maps. I'd like to make a planet that uses a grid. The topology of a sphere requires a few things:

  1. Moving east or west you eventually wrap around the world → easy
  2. Moving north/south you eventually reach a pole, and then all directions are south/north → medium
  3. Wrapping around the world east/west is shorter near the poles than near the equator → hard


Labels: , ,

Coordinate transforms, still #

Last post was about my attempt at explaining coordinate transforms. Progress has been slow. I've implemented many of the diagrams but I'm still having trouble with the narrative. Last time I said this was my outline:

  1. Show a side scrolling game with some cool camera effects.
  2. Introduce world coordinates vs screen coordinates.
  3. Solve the problem of scrolling: subtract an offset.
  4. Introduce transforms. (may need to be later)
  5. Introduce inverse transforms, for mouse clicks. (may need to be later)
  6. Introduce cameras. More complicated than offsets, but can do more.
  7. Show some cool effects with cameras. (may need to be earlier)
  8. Introduce chaining transforms.
  9. Show some cool effects with chaining.
  10. Demo showing all concepts together.

I've been experimenting with different orders for the topics and now think there are two intertwined “tracks”: the concept track introduces mathematical concepts and terminology, and the problem solving track shows solutions to specific gamedev problems. These two tracks are paired up:

Problem solving Concept
scrolling world/screen coordinates, translate transform
following the player cameras, view coordinates
tile grid coordinates scale transform, chaining transforms
mouse clicks inverse transforms
? function composition
? transform matrices

I think in each case I should start with the problem to be solved, then show the immediate solution, then explain the concept behind the solution. The concepts then lead to a reusable solution. Example:

  1. Problem: we want to scroll the screen
  2. Immediate solution: add an offset before drawing
  3. Concept: we're transforming world coordinates to screen coordinates
  4. Reusable solution: a translate transform is a function or object that converts coordinates

The next section is:

  1. Problem: we want to keep the player in the center of the screen
  2. Immediate solution: use the player plus half the screen size as the offset
  3. Concept: a "camera" points at the player, using view coordinates
  4. Reusable solution: a camera object is placed in the world, and we use that to build the translate transform

What order should I present these topics? I'm not sure. I know I want to put scrolling first. If I put mouse clicks second, then it's fairly easy to solve, and there's less motivation to learn inverse transforms. So I might put that later. If I put tile grid coordinates second, then it leads to chaining transforms together, which will be useful for following the player with a camera. Or if I put following the player second, then it leads to view coordinates, which might further motivate chaining transforms.

I think the main problem is that I'm not feeling particularly inspired right now, so I'm working very slowly.