Ways to draw tracks on 4-connected grid

Question

I'm working on a grid based puzzle game involving tracks, and I'm having trouble finding a nice way to have users draw those tracks on the grid in a way is easily understood. For simplicity I had the idea to make the user draw tracks by dragging/drawing on the grid. I thought this was a nice way to do things, since both mouse and touch inputs could be handled in the same way.

As how I have designed the game right now, the only tracks that are possible are straight and 90 degree turns, which I believe is also referred to as a 4-connected grid. I have a limit of two track pieces that can exist on one tile. This way the game supports junctions and crossings, which are an important part of the puzzle design, but things remain relatively clear.

I have looked at other grid based games that involve tracks or track-like connections, but many do not support junctions and crossings (Like the awesome Cosmic Express, and in some capacity Flow Free by Big Duck Games).

A game I know of that does support this is Trainyard by Matt Rix. There, when your dragged path connects three (adjacent) grid cells, a track on cell number 2 is created that connects cell 1 with cell 3. I personally find this method quite clear, and this is the system that is in my game right now, but prototype play testers found it quite difficult to draw the shapes they wanted and they made a lot of errors in the process, which became frustrating.

I can't really think of any other way than how Trainyard does it, at least at the technical level. In the end to build a track you need to know which sides to connect, so by dragging you have to touch at least three cells. Perhaps you can make assumptions at certain points to make things more streamlined? Or perhaps it is just a matter of better visualization? If anyone has thoughts on the matter, I would be very interested to talk about it! :) If you know of other games that have players draw tracks that support junctions and crossings, I would be very interested to see how they are doing it.

I do recognize the fact that you might need to have had some experience playing games with this system, so for what it's worth: The free version of Trainyard called Trainyard Express is still available on Google Play. The iOS version is gone unfortunately. It's quite an old game and hasn't been updated very regularly.

Edit 1: Currently track build logic is as follows: When dragging starts (mouse down on area where grid is shown), I start keeping a list of tile coordinates that the mouse is touching. When, while dragging, a new cell is reached, that new cell coordinate is added to the list. When the list length is 3 or higher, the last three coordinates in the list are used to create a track. So, for example, when the list is ((0,0), (1,0), (1,1)), a track on (1,0) is created with a turn that connects (0,0) with (1,1). Then, when (1,2) is reached, a straight track on (1,1) is added that connects (1,0) with (1,2). Hope this clarifies, else I could add a graphic representation.

Edit 2: Some issues that arise when using pure Trainyard drawing system:

• Wanting to draw a straight line going right, starting at (1,1), accidentally grazing over the edge entering (2,2) below, resulting in a turn from (1,1) to (2,2) on (2,1). Then correcting back onto the correct row, and reaching to (3,1), resulting in turn on (2,1) from (2,2) to (3,1).

• While wanting to make a turn to connect (1,1) with (2,2) via (2,1), users often start drawing on (2,1), resulting in no track being drawn.

Answer 1

This is Matt, the creator of Trainyard. @DMGregory summoned me here! :)

It sounds like you're working through the same issues I had to deal with. It's a tricky problem where there isn't necessarily a perfect solution.

One thing to consider is the constraints of the problem. I was targeting a 50mm wide screen on the early iPhones, and Apple's recommendation was that touch areas should be at least 7mm wide, which led to Trainyard's grid having 7 columns. This is also why Trainyard's touch system is based almost entirely on the grid tiles themselves and not any kind of sub-regions. This also meant that any visual indicators on the tiles themselves were entirely hidden by the player's finger. Since you're targeting modern devices and mouse-based interfaces, that may open up some new options to you.

I knew Trainyard's system would be counterintuitive at first, but it also allowed for extremely quick and reliable inputs for players who understood the system. I put a lot of effort into making sure the tutorials were very clear about dragging across tiles. Players still got confused by it occassionally, but I had many thousands of "casual" players who were able to get very proficient with it, so it served its purpose. I did try adding "edge touches", but at least on those early devices, it led to more instances of unexpected behaviour, and it was also harder to explain to players.

You clearly already know this, but the key with this drawing system is that you are really defining track between edges and not tiles. The reason each track piece requires three tiles is because when drawing track in tile B of ABC, you need the edge from A->B and the edge from B->C. For that reason, if I were to revisit Trainyard today on modern devices I would try doing edge touches again. I'd hope that the new larger screens would make it work better, or that maybe I could figure out the right amounts of tolerance to make it work predictably.

A few other features of Trainyard's system:

• I show little arrow indicators on the edges the moment they've been drawn across to make them clear to the player. I'm not sure how much this helps since they're mostly covered by the player's finger, but in theory it helps with the latency problem that @DMGregory mentioned. I do keep them visible for a second after the track has been drawn, so the player does get to see them and start to develop an intuition about how the track drawing works. In a modern implemenation I might try showing a "ghost" version of the track as the player got close to a second edge.
• If you return to a tile right away, I ignore the first time you entered it. So for example if you have tiles ABC and you drag from B->A->B->C, I'll treat it as if you did A->B->C so you'll just get a horizontal track through B. This is pretty obvious but I'm just making it clear it's a bit more complex than taking groups of every 3 tiles.
• If you draw over a tile with existing track, I make that new track the the "active" (top layer) of the two tracks. On the other hand, if there are already two tracks on the tile and the exact same track path is already active, I destroy the other track on the tile.
• If the touch moves more than the size of a tile in a single frame, I act as if there have been multiple touches along the path. This allows players to draw long vertical and horizontal lines very quickly without worrying about "skipping" a tile.

So in summary, you should go with the things @DMGregory suggested in this answer, but I'm just trying to provide a bit of insight into the decisions I made. Also I apologize for the game not being available anymore. It was written in 32-bit pre-ARC Objective-C with a modified beta version of Cocos2D, so it's been a bit of a nightmare to modernize ;)

Hope that helps!

Answer 2

I think you can solve the two pain points you indicated with a few heuristics.

One is a little hysteresis: once the player is drawing in a particular row/column, keep their drawing cursor locked in that row/column until their mouse/touch point strays more than ~30% of the way into the next row/column.

That gives more tolerance for error, so the player has some wiggle room to draw less than perfectly straight across a row and still get a straight line result.

The other is to detect invalid commands and try to infer the player's intent. In this example...

Once the track from (1, 1) to (3, 1) has been drawn, we can fairly assume that an input that starts in (2, 1) and touches or crosses this middle line is intended to connect to or modify the existing track. Based on which half of the tile the player started on, we can add the entrance from (1, 1) or (3, 1) as an extra "first point" of the path.

The other issue may be that you require the player to swipe between three tiles in order to draw on one. That adds a latency between when the player thinks their input should be clear to when the game recognizes it, which can be frustrating or add uncertainty into the player's mental model of how the mechanic works.

You might want to consider counting "edge touches" as points for your drawing. So if I swipe from the left edge of (4, 1) to the bottom edge, without ever touching (3, 1) or (4, 2), that's still counted as a valid corner. That lets you start showing track drawing feedback earlier in the gesture, helping the game feel more responsive, and showing the player their mistakes closer to when they made them, so they can understand how their input caused it and can adapt their play, rather than blame it on a "bad recognizer". 😉

Answer 3

I would suggest that if your testers found it difficult to draw track shapes they wanted, this may have to do specifically with your using a 4-connected grid (of a certain coarseness of resolution).

Have you considered:

• increasing the resolution of the grid, a finer grid giving the player more control over how the track is drawn, while keeping the tracks created ON that grid still large enough to be easily visible
• allowing diagonal tracks (8-connected grid)
• A 4-connected grid with tracks angled at multiples of 22.5 degrees (16 directions) which can span multiple tiles
• A non-grid based system where tracks can be drawn freely by the user, then reduced in complexity to just a few segments, once they release the drag?

Amongst these, I'm sure you'll find your answer.