Blobs in Games: 2007

From Red Blob Games's Blog

Transport Tycoon #

I've been playing Transport Tycoon for a very long time. It's a simulation game involving transporting goods and passengers — the kind of game I love, and once wanted to write. I started playing again early this year, with OpenTTD (an open source “clone” of the game), and then got interested again once I tried their nightly builds with lots of new features.

The weird thing about Transport Tycoon is that the original game didn't keep my interest. The AI was horrible, and the game balance didn't work for me. It was too hard at the beginning of the game and then once you had enough money, the game was too easy. Instead, what I and others have done is come up with our own game goals, treating it more as a “software toy” than a game. In some games I avoid making any changes to the terrain; I work within its constraints to create “natural” looking routes. Other times I challenge myself to connect every city, or handle all resources of a certain type.

One of my favorites is designing high capacity routes and stations. I once built a custom scenario with around 100 coal mines and a single power station, and then designed routes that could handle all the coal. OpenTTD opens up new design possibilities, with changes to track building, station size and shape, and routing algorithms (see pre-signals and advanced signals).

One of the things I've been exploring recently is having multiple industries near one another. Instead of one station per coal mine, I can have lots of coal mines surrounding a high capacity station. Here's one of the stations I'm working on:

To increase the space I have available for coal mines, I built tunnels underneath some open space, where I'll place mines. The concrete tiles to the northeast of the station are considered station platforms, and extend the “reach” of the station. Using those as tendrils I can make the station area larger, and place more coal mines within its reach. On the other end of the line is a large station next to a power plant; all the trains go from here (and similar coal stations) to that power plant. You can see to the lower left that there are many tracks to handle the trains, plus extra space where I'll add more tracks after I add coal mines. The challenges here are keeping the trains running, dealing with breakdowns, handling the capacity, and making a nice layout.

Once I started playing with tunnels, I designed this station for passenger traffic:

It looks like two stations but it's actually one. I built a longer one, then removed the tracks in the middle. The station fits into a 20x20 space, but can handle 40 trains. As shown all the trains come in from the southeast, but it's also possible to use this station with 20 tracks handling northern traffic and 20 for southern traffic, either as a through station or as a terminal. The gap between the two blocks has to be 6 tiles, so there are 14 tiles left, meaning the trains can be at most 7 tiles (14 cars) long. I haven't actually used this station anywhere, but with the tunnels at the ends, it could be quite useful for tunneling underneath a major city.

There are lots more interesting layouts for stations and tracks. Take a look at this guide and this forum post for some examples. You can do a lot with the three signal types (each having their own algorithms); the routing is the most fascinating part of this game. This experimental station is an example of the weird things you can express with advanced use of pre-signals.

As OpenTTD adds more features, it opens up new possibilities for layout and routing. Coming soon are building tracks on slopes (allows more compact layouts), new road stations, trams, one-way roads, new airports, new types of cargo, new scheduling options, and new signal algorithms. It's not a game for everyone, but it's definitely a game for me.

Interactive illustrations #

When I'm taking a class, or reading a textbook, or reading an article, there's text that explains a topic, and sometimes illustrations that help visualize the material covered in the text. Sometimes there are diagrams that show things that are not in the text, and charts that summarize data sets that are not included in the text. When these materials are put on the web, those illustrations, diagrams, and charts remain as they were in print: they're static.

In class I often would wonder what would happen if something was changed. For example, in the programming languages course we saw a program and what would happen on the stack and heap to store data. What happens to the stack if you change the order in which you declare variables? I now know the answer to the question, but it would have been nice if I could somehow walk up to the board, change the program text, and watch the diagram of the stack update itself to reflect the change. Although in small classrooms you might be able to convince the instructor to do this, it's completely impractical in a large class to answer every student's question this way. I can't change things in textbooks or articles either.

But now we have the web. There's the possibility of interacting with the course material. Why don't we see much of this?

• When teaching a subject, you have a set of points you want to illustrate. With an exploratory tool the student may or may not actually reach all the points you want to teach. When those points come up in an exam, the student might not be able to answer all the important questions.
• It costs much more to develop interactive material than to develop static material. It's not only the cost of development but also in design.
• Web technology for interactive sites (Javascript, Flash, Java) is still somewhat unpleasant and non-portable. The dominant technologies did not win for being elegant or fast or easy to use; they won for other reasons.

Web pages are still (mostly) written in the style of books and articles. This is understandable. Films were originally in the style of stage plays. It took experimentation to discover the things you can do by changing scenes, camera angles, etc. A century later, filmmakers are still experimenting, and developing new techniques (examples: showing simultaneous scenes, time lapse, bullet time, showing the same scene from different angles at different times). Web authors have experimented with frames, multiple windows, Java applets for computer algorithms, and writing entire web sites in Flash. I think there will be many more decades of experimentation.

For many years now I've been wanting to put interactive illustrations on my site. There are concepts like distance, movement, pathfinding (A*), scripting, grids, AI, and simulation that I'd like to illustrate. For example I used a Java applet to demonstrate a UI for building roads in simulation games. However I wasn't happy with it. It was a separate page, not integrated into an article that explained the concepts. Java was heavyweight and tricky to get working across browsers. Several authors have produced standalone A* exploration applets or applications, but they too weren't integrated into an article. It wasn't until I saw Raigan and Mare's article about collision detection that I saw what I wanted. Their article uses static illustrations to demonstrate concepts without using interactivity, but makes those illustrations interactive to allow the reader to explore on their own. This addresses my concerns about interactive tools not showing the student the important points. They use Flash to implement their illustrations. Flash is so lightweight that at first I didn't realize their illustrations were interactive. There's no “loading” screen and your browser doesn't slow to a crawl. I don't know how the cost of developing them though.

I had mentioned a few months ago that I haven't been working on my transportation game. It's true, I haven't. I've continued learning Flash but I'm working on diagrams for my site instead of a game. So far my experience has been rather positive. Flash has been easier to learn and use than I expected. The raw graphics libraries are nicer than what I had used before (PyGame, OpenGL, SVG, and Java2D); however, the user interface libraries (buttons, scrollbars, etc.) are worse than those in Java Swing. I especially like that the graphics libraries include things that are useful for illustrations: overlays, translucency, and bevel/glow/shadow effects. For example, you can draw an arrow overlay on top of the illustration without redrawing the illustration itself, or add a glow effect to the object you want the reader to pay attention to. Flash's performance is reasonable. The library reference is nice. There's a free command line compiler for people who don't want to use Adobe's fancy IDE. I'm enjoying it.

My first project has been developing a grid library, using the algorithms from my grid article to generate the illustrations on this page and this page. The most surprising thing for me has been that the 300k of images on those pages could likely be replaced by a 10k Flash file. So far my Flash program compiles to 6.5k, but it doesn't have a UI that lets you select various algorithms and heuristics, and it also doesn't allow you to draw your own obstacles on the grid.

I'm going to follow the style in Raigan and Mare's collision detection tutorial: using Flash to replace static illustrations, not to use Flash for the entire site. I'm also keeping the images as fallbacks for people who don't want or use Flash. Since most of the illustrations need to stand alone without user interaction, the fallback technique works well in this context. While working on the A* illustrations, I realized that my A* pages are nearly ten years old, and my thoughts on the subject have changed somewhat. I'd like to go back and update them to reflect my new thinking. But first, I'm going to add interactive illustrations.

Update: [2011] - I wrote this post in 2007, when Flash was my best choice for interactive diagrams I could embed into a web page. Browsers have advanced quite a bit since then and I'm using HTML5 (SVG and Canvas) for most of my new interactive diagrams.

Labels: flash

Learning Flash 9 #

This week I switched from Flash 8 to Flash 9.

Since last year I've been playing with Flash 8, using the Motion-Twin command-line compiler mtasc. I was using it to write a transportation game, and I had something running and was making progress, until Supreme Commander came out. Then I went back to playing games instead of writing them. Although I'd still like to work on that game, I've found that I also want to use Flash to build interactive demonstrations of concepts I describe on my site. For example, in my article about grids I'd like to make those diagrams interactive so that you can better see how the coordinate systems work. Diagrams are now what I'm using to learn Flash; I may go back to the game later (or maybe not).

I like mtasc. However, it only supports Flash 8 (Actionscript 2), and is not going to be updated for Flash 9 (Actionscript 3). It's a dead end. Flash 9 is not only significantly faster (almost as fast as Java), but it also has major changes to the libraries. Instead of mtasc, you can use HaXe, which is a new language similar to Actionscript/Javascript/ECMAscript. HaXe looks neat (better types, type inference), but it's a different language, not Actionscript. Part of my goal is to publish my source code so that others can use it, and it's less useful to publish code that isn't usable in Actionscript. It's also less useful to publish code that requires an expensive development environment (for example, Flex, at $500). And it's easier to learn a language when there are lots of other users, posting tips. So I've been staying with mtasc; the same code works with both mtasc and the Flash 8 development environment.

Last week Rich Collins pointed me to the free command-line Flash 9 compiler, mxmlc. Wonderful! It's free, it's Flash 9, it's command line—just what I was looking for. I spent a few days learning about Flash 9, and found this tutorial and these tips to be most helpful. My initial thoughts:

• (yay) Flash 9 has much better libraries than Flash 8. The sprites (movieclips), the event handling, and the graphics commands are all nicer.
• (boo) Actionscript 3 is more verbose than Actionscript 2, with types, packages, public, override, and other annotations. It's less of a scripting language and more like Java. This is bad.
• (yay) Flash 9 is much faster than Flash 8, in part thanks to all those type annotations.
• (boo) The mxmlc compiler is significantly slower than mtasc, in part because it's written in Java, which has a high startup time.
• (boo) The mxmlc compiler is not open source.

I've been converting some of my code from Flash 8 to Flash 9, and despite the increased verbosity, I've been happy with it. If you want to use Flash 9 with free command-line compiler, start with this tutorial.

Update: [2007-07-28] [2010-03-25] You can download the Flash command-line compiler (Flex mxmlc) for free, without registration, from Adobe. Once I learned the language, the Flash 9 library reference became my #1 source of information.

Labels: flash , programming , project

Distances on a triangular grid #

As part of my article on grids, I'd like to provide basic algorithms for grids. I already know how to compute distances on square and hexagon grids, but I didn't know how to compute them on a triangle grid. I initially tried changing coordinate systems, inspired by Charles Fu's coordinate system. I normally use the coordinate system from my article on grids:

The first coordinate (which I will call u) is the position along the horizontal axis; the second (which I call v) is the position along the southwest/northeast diagonal. The Left/Right parity introduces some compliation; I let R be 1 and L be 0. This coordinate system is nice for storing maps in an array, but it's not as clean, because triangle grids have three axes but only two of them are expressed in the coordinates. For the horizontal axis I used 2u+R as the position; for the second axis I used 2v+R. I guessed that the position along the third axis would u-v. I drew some grids on paper, wrote down the u,v values, and then computed the three positional values. They behave properly for computing distances along the third axis, but the system falls apart when computing distances not on the three axes.

Frustrated, I decided to step back and approach this problem in a more principled manner. In Charles Fu's three-axis coordinate system, taking one step in the grid changes two of the coordinates and leaves the third alone. For a triangle grid, the dominating feature is the straight lines in three directions. I looked on the web for any articles describing distances on triangular grids, but didn't find any that satisfied me. This paper was promising but unfortunately gives an iterative algorithm and not a clean formula. However, it uses an interesting coordinate system, which is useful for computing distances. If you take one step in the grid, you will cross exactly one line. The distance between two locations will be the number of lines you have to cross. I wanted to use a coordinate system in which crossing a line changes a coordinate:

I want to map the u,v,R coordinates I normally use into the alternate coordinate system a,b,c, where exactly one of a,b,c changes when you cross a line. Here's where I decided to use algebra. In u,v,R space, the black triangle has coordinates 0,0,0; the triangle to the east of it has coordinates 0,0,1; to the west, -1,0,1; to the south, 0,-1,1. In a,b,c space, the black triangle is 0,0,0; the east triangle is 0,0,1; the west triangle is 0,-1,0; and the south triangle is -1,0,0.

I want a formula that computes a, and I expect it to be linear, so I write a = au*u + av*v + aR*R + constant. That's four unknowns, but we know the constant will be 0, so it's really three unknowns. To get three equations, I plug in the values for the east, west, and south triangles, then solve for the coefficients. Let's see what happens:

  For each s in (a, b, c), and each triangle i:
  si = su*u + sv*v + sR*R

  East triangle: u,v,R = 0,0,1
  s1 = su*0 + sv*0 + sR*1
  therefore: sR = s1
  
  West triangle: u,v,R = -1,0,1
  s2 = su*-1 + sv*0 + sR*1
  therefore: su = sR - s2
  
  South triangle: u,v,R = 0,-1,1
  s3 = su*0 + sv*-1 + sR*1
  therefore: sv = sR - s3

When s is axis a, we look at a for triangles 1 (east), 2 (west), and 3 (south), so a1 is 0, a2 is 0, and a3 is -1. The algebra tells us that aR = 0, au = 0, and av = 1. That means the formula is a = v. Pretty simple. Doing the same for b and c, I get b = u and c = u + v + R.

These results are simple enough that if I played with the grid enough, I would have come up with them. However the algebraic approach works for other constraints, not only the simple ones. I also used it to create a coordinate system with 2u+v+R, u+2v+R, v-u (this is 30 degrees rotated from the one above), which may be useful for other algorithms. Algebra and calculus also come in handy for defining movements (e.g., splines), growth rates, equilibria in interacting systems, and other types of interesting behaviors in games.

What is the distance between two locations in a triangular grid? Each step involves a line crossing, and we want to count steps, so we add up the line crossings along each axis (a, b, c): distance = abs(Δu) + abs(Δv) + abs(Δ(u+v+R)). This looks just like the Manhattan distance formula, but for triangles instead of squares.

Labels: grids , math , triangles

Transportation mini-game, where is it? #

A few months ago I posted about a transportation mini-game I had started. What happened to it?

I've been a bit distracted and haven't worked on it much. I did learn some Flash, and posted about command line tools for Flash, and then I went to the Game Developer's Conference, which made me think about what kind of game I was working on.

The first comparison that came to mind was Lemmings. In Lemmings, a stream of lemmings is coming into the world, and your goal is to give a few lemmings a job. Jobs include digging through the ground, floating through the air, building steps, turning other lemmings around, etc. The lemmings with jobs affect how the rest of the lemmings move through the world. In the transportation mini-game, there is a stream of packages coming into the warehouse and your goal is to direct them to their goal. You place objects like conveyor belts to change the flow of packages. As with lemming jobs, there are a variety of objects you can use. However you don't use the packages themselves to do this, and there's no terrain to modify.

More recently I ran across a series of “tower defense” games, in which a stream of monsters is walking by and your goal is to shoot them. Just as there are many types of lemming jobs, there are a variety of guns that you can place on towers. The most interesting of these games is Desktop TD, in which the monsters have to walk around the towers you build. This adds a layer of strategy: where you place your towers matters a great deal because if affects how the monsters walk around them, and where the monsters walk affects where your towers should be. In this YouTube video, you can see an example of how you can arrange towers into a maze to force the monsters to take a convoluted path to their goal:

Desktop TD is a lot of fun. It combines a building game with a shooting game. The monsters have a pathfinding algorithm controlling them, and you have to think about how your buildings will affect the results of that algorithm. You also have to think about different kinds of monsters, different kinds of towers, and whether to upgrade existing towers or build new ones.

Unfortunately after playing it for many, many hours it made me less interested in my transportation mini-game. It satisfied my desire to play a game with flowing objects. I'd still like to work on this game but I've been busy with other projects and don't know when I'll get back to it. Maybe someone working on a tower defense clone will incorporate aspects of the transportation mini-game instead, and then I can spend many hours playing their game. ;)

Labels: project

Game Developer's Conference #

Despite the talk of GDC 2007 becoming more and more like E3, I'm going to go to GDC this year. I'm interested in the Wii, DS, mobile games, online games, and web games, as well as graphics, music, sound effects, design, algorithms, and storytelling. I'm interested in just about everything but business/legal aspects; I expect that working on games will remain just a hobby for me.

Silverfall Demo #

I've been playing the demo of Silverfall (see the preview on IGN). Like Dungeon Siege and Titan Quest, Silverfall reminds me of Diablo 2, which I loved. It's a role-playing game in which your character goes on quests, fights monsters, collects treasures, upgrade items, learn new skills, etc. The graphics are great, or would be, if my computer was fast enough. Some of the more interesting things about it:

• Graphics. The characters are surrounded by a black outline. See this screenshot (and others) on IGN. It reminds me of cartoons, where the outlines help separate the important characters from the backgrounds. It's more than this though. Silverfall's graphics look hand drawn, at every angle and zoom. I can't figure out how they did this.
• Physics. It can take advantage of a physics accelerator card. I didn't see much that would benefit from physics though, and it's sort of annoying to have to install a physics library.
• UI. The UI is really smooth compared to Dungeon Siege, although not quite as nice as Diablo 2 for reasons I'll list below. The use of the mouse and hotkeys is nice.
• Factions. The nice twist on this type of game is Nature vs. Technology. When you complete or reject certain quests, you gain favor with either nature or technology (these are diametrically opposed). When your favor with either faction increases, you gain access to better items and skills. Also, in the story your faction becomes stronger, which changes the storyline and the appearance and buildings in the city. A third path is to favor neither side, accepting quests on behalf of both. This gives you more experience from quests, but you no longer have access to the special items from each faction.
• Quests. A consequence of the nature vs. technology factions is that some quests will make you worse off. In most RPGs, the more quests you do, the better. But here, the quests can hurt your standing with one of the factions, and you can lose access to items, skills, and further quests. So you need to think about which quests you accept.
• Skill Tree. Like Guild Wars and unlike Diablo, you can change your skills, at a cost. I think this increases the enjoyment of the game the first time through, because you can try out several approaches without starting over, but it may decrease enjoyment the next time through the game. It's a good tradeoff though, because it helps a large number of casual players at the expense of a small number of dedicated players.
• Classes. There are races but no character classes. Instead, you can choose your skills to build your own style of character. There are skills for melee, ranged weapons, light magic, dark magic, faction (nature or technology), and your race (human, goblins, trolls, elves). This yields a large set of styles of play. I tried one which combined melee and dark magic, and a different style that combined light magic and nature skills.

It seems silly, but I think the black outlines and the hand-drawn look of the characters and other objects are a sign of something important. Before 3d accelerator cards, graphics were drawn by programmers and artists, and games had lots of different visual styles. With 3d cards, a certain style supported by the card is cheap, fast, and easy. All other styles are more expensive, slower, and harder to program. This has led to a far less diverse set of visual styles. Okami is a rare exception. (Side note: I'm not sure how the Silverfall developers implemented their outlines. At first I thought it'd be a single pass over the buffer to look for differences in Z values, but when you zoom in you can see the outlines are at the vector level, not the pixel level, so it's possibly a shader that looks for normals perpendicular to the screen. And I have no clue how they made everything look hand-drawn.) In old-style art, it was easy to identify objects. You could tell what was clickable, what was a button, where a person was, etc. Artists weren't looking for realism. They wanted to express concepts and emotions and ideas in game art. Newer games tend to be cluttered. Just look at how much harder it is to see all the objects in The Sims 2 vs. The Sims 1. Newer games are more realistic, but less artistic. The harder it is to see what's on the screen, the more effort the player makes in seeing things, and the less effort the player can make in deciding things. Although there are games like Quake and Halo where much of the challenge really is in seeing things, I don't think RPG and strategy games fall into that category. I like games where the challenge isn't in seeing the objects on the screen, but in deciding what to do. I hope the shaders in graphics cards enable game developers to explore more visual styles.

Since I'm on the subject of displaying information for players, there are several things that Silverfall seemed to get wrong:

• Camera rotation. I spent way too much time rotating the camera in Silverfall (and Dungeon Siege). I spent no time doing this in Diablo. Does rotating the camera add to the game? No, I don't think it does. Yes, it's “cool” and people seem to expect it, but it didn't make the game better. In fact, it made it worse.
• Zoom. You can zoom in to see your character close up. The character looks really nice when zoomed in. But this mode is useless when actually playing the game. For playing, you want to be zoomed out as much as possible. (In fact I'd like to zoom out even farther than Silverfall allows.) This means that all the effort to make the zoomed-in camera work (for example, distant objects, level-of-detail terrain, and expensive high-resolution texture art) is a waste. Unfortunately you need some of this to put on the box so people will buy your game. But it's a big waste.
• Loading zones. When you travel from one zone to another, the game stops and loads the next zone. That's a minor annoyance. The big problem is that all your spells are cancelled. Techniques for avoiding loading screens are well-known. I don't mind if there's loading when you enter a tunnel or cave or dungeon. It's when you see arbitrary boundaries unrelated to the game that it becomes annoying.
• Terrain. The demo takes place in a swampy region. The terrain is very bumpy. It looks like it was randomly generated (maybe Perlin noise?). The small problem is that the random-looking terrain adds nothing to the gameplay. It just gets in the way. The big problem is that the slopes that are walkable and the slopes that are not at not distinguished in any way, except by clicking and finding that your character doesn't move. At the very least the cursor should change color or shape to indicate that some area isn't accessible.
• Map. This is actually a complaint about lots of games. If I were Indiana Jones and I had to go to 3 places to collect artifacts, I'm going to mark those 3 places on my map. Far too many games have a notion of an “active” quest, and only show that one place on the map. No! Make the map work like I would actually use it. Show me all the important places I need to keep track of. Let me add markers. Let me add notes. Let me draw lines. Don't make me keep a second map on paper because your map is so lame.
• Quest Listing. There are some bugs in the Silverfall quest list, which I'm sure they'll fix before release. For example, it doesn't remember where you were the last time you brought up the list. A bigger problem though is that the quests do not keep track of who assigned the quest (and where). I found myself often re-reading quest descriptions, trying to guess who would have assigned such a quest. Some of them are on the map and some are not. Some of them trigger the rewards automatically and some do not. It's a mess. Just as with maps, the quest listing should match what I would do on paper. I would keep track of who gave the quest, where I need to go, and what the potential rewards are (especially related to faction). I would allow adding notes, assigning priorities, and sorting the list. For example, there was one quest I received that I was not ready to do. I'd like to move it to the end or otherwise mark it as “later” so that it doesn't clutter up the list of active quests I want to work on. And if the map shows all quests, it should also use different markers for active and postponed quests.
• Trees. I've saved my biggest complaint for last. The graphics in Silverfall are great. I admit that. The problem is that the swampy area has lots of trees. In the default zoomed-out view, the canopy of trees blocks your view. So the game very helpfully hides the leaves. In addition, tree trunks block your view. So the game very helpfully hides the trees near your character. But tree trunks still block your attacks. So you now have a completely mysterious and maddening situation in which invisible objects block your attacks. Your attacks are blocked and you can't see why. This is truly bad. Just get rid of all the trees. They don't add anything to the game. Alternatively, since it's unlikely the developers will do that at this point, just let me walk and attack through the trees.

I really liked the demo of Silverfall. It's really promising and it could be lots of fun, except there are some little (easily fixed) things that really detract from the experience. Even with the flaws, the demo was more fun than most other games I've tried. I hope the developers read this post and fix these problems before release. (Oh, and if you're reading this: lose the cheesy box cover art.)

Labels: review

Transportation mini-game, rough design #

About a year ago I decided to stop working on Simblob, and started working on a transportation game (more about the design here and here). My progress has been rather slow, in part because I keep playing other games instead of writing one.

One of the components of the transportation game is the Warehouse. If you view your transportation network as a graph, the Warehouse is an internal node, the Supplies and Sinks are the endpoints, and the transport types (trucks, ships, trains) are the links. The Warehouse is a key component of your transportation system. Goods come in and goods go out. Sometimes goods are stored, repackaged, relabeled, inspected, and assembled. In the network, Warehouses can be used as:

• Buffers. Goods come in, a stored for a time, and then go out. The time the goods are supplied is earlier than the time they are needed. For example, it may take several months to produce the toys that will be bought in the Christmas shopping season; those toys need to be stored somewhere until shoppers are ready to buy them.
• Switches. Goods come in from several sources and go out to several sources. For example, a grocery store chain may have supplies coming in from farms, ranches, orchards, etc., and may have those same goods go out to several neighborhood stores.
• Caches. Goods aren't needed all the time, and their demand is unpredictable, but when the demand is there, the customers want the goods right away. The solution is to keep some near the customers, so that when they need some, they can get it quickly.
• Transformer. Goods arrive in one condition but leave in a better condition. For example, a Warehouse may add tracking, labeling, and pricing information to the goods before sending them on to stores.
• Multiplexing. Goods arrive in large shipments from suppliers, but each store needs a small amount of each good. The Warehouse can repackage the goods into smaller units. For example, an electronics retailer may receive a truck full of VCRs, a truck full of TVs, and a truck full of speakers, and the Warehouse can reshuffle these into three trucks, each with VCRs, TVs, and speakers. That way only one truck has to be sent to each retail store.

Warehouses are an interesting enough part of this game that I decided to try making a mini-game out of them.

In the mini-game, the goals (switching, multiplexing, etc.) are given to you, and your job is to design the warehouse to meet those goals. Goods come in from the left and exit on the right. There are multiple types of goods, each represented by a color (or shape). Your job is to get the goods from the left to the right, while achieving your goals.

The warehouse is laid out on a grid. The basic component is a conveyor belt, which takes up 1 grid space. The conveyor belt pieces are linked into a chain that defines the flow of goods through the warehouse. What makes the game interesting (I hope) is the special pieces you can add to the conveyor belt. A color filter only allows a certain color to pass. With it you can separate a mixed flow into separate products. Similarly, a shape filter only allows a certain shape to pass (I may end up combining shape and color filters into one). A counter filter has a counter, and only allows an object to pass when the counter reaches a particular value. For example, a 3-counter filter will allow every third object to pass. These filters are used to separate a stream of objects into smaller streams. Note that a 1-counter is the same as a regular conveyor belt; it filters nothing. A mixer mixes objects from multiple streams, in some proportion. For example, a mixer can be set to take 1 green circle and 2 purple triangles, and the resulting stream will have twice as many purple triangles as green circles. A packer takes multiple objects and packs them into a single object of a different type; an unpacker takes a single object and unpacks it into multiple objects. A carousel stores objects, up to its capacity, until the output stream(s) have space for unloading objects. It can be used to even out a highly variable flow. There are more objects I can imagine: shelves, aisles, employees, forklifts, labelers, inventory trackers, etc.

The game involves a series of levels of increasing difficulty. Each level has a grid, some supplies, some demands, some parts to use to construct the conveyor belt network, and some goals to meet. The grid may have objects on it already, which cannot be moved.

At each time step, all goods (objects) move one space, according to the rules of flow:

1. The conveyor belt defines the directions the object can move.
2. An object cannot move in the direction of an incompatible filter.
3. An object cannot move to a spot that has an object, unless that object is about to move.
4. Of all directions available to move, the object chooses one at random.
5. If a box cannot move, it sits still. If it sits still too long, it breaks.

If you think about these rules hard enough, you'll see that they may be difficult to implement. In particular, rule #3 says that an object can move if another object can move. And that object too may be subject to this rule, leading to an entire chain of dependencies that have to be solved. I have an algorithm partially designed but I'm not yet convinced my algorithm will work; if it does not, I'll revise the rules.

The puzzles I'm less sure about, but here's what I've been thinking about:

• Slow packers. Split the incoming supplies into several streams so that you can have several packers handling them, then coming the streams into one.
• Irregular supplies. Demand is steady. Build a large buffer so that you can handle supplies being late.
• Multiplexing. As described in the electronics retailer example, suppliers send large shipments of a single product type. Build buffers so that you'll have enough of each product type. Unpack the large supplies into small ones, mix the goods together, pack them into shipments that get sent to retailers.
• Bad supply. Some of the incoming goods are faulty. The supplier will lower quality as much as he can get away with. It's too expensive to check everything, but if you check nothing, the quality will keep going down. Check some of the goods to keep quality high enough to satisfy customers.

Time, quantity, quality, costs, and profit can all be part of the goals. For example, incoming goods might cost $4/box, and outgoing goods might bring in $5/box. Each box you send through the system gives you $1 in profit. If a box breaks (due to sitting on the conveyor belt for too long), you lose the $4. You might be willing to have a less reliable system to keep costs down, or you may want to make it more reliable to minimize losses.

At this point the design is only on paper. I plan to create a prototype soon to try to judge how fun or interesting the game might be.

Updates: [2014, 2015, 2016, 2017, 2023] See Great Permutator's clever puzzle pieces; also see SpaceChem, Manufactoria, Factorio, Big Pharma, Blueprint Tycoon, Production Line, Shapez, Manufactoid (2008).

Labels: project