11
\$\begingroup\$

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).

Accidental double turn instead of straight curve

  • 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. Skipping junction track
\$\endgroup\$
8
  • \$\begingroup\$ If you have an option to draw the crossings and junctions but the user finds it unintuitive, maybe improve on that part like a more detailed tutorial that tells the user how to draw the shapes. If crossing a line creates a crossroad, ending on a road could create a conjunction. Maybe improve the detection range of the start point to snap to an existing road for creating a conjunction could help. But to know for sure, we would need to see your existing implementation to be able to improve it. \$\endgroup\$
    – Zibelas
    Nov 13 '20 at 9:52
  • \$\begingroup\$ Hi Zibelas, thanks for your comment! I will add a more detailed description of the current implementation, but it comes down to "exactly what Trainyard does" :) \$\endgroup\$
    – Rutger
    Nov 13 '20 at 10:14
  • \$\begingroup\$ I updated the description. Is this helpful or do you need more to get a better idea of how it works? \$\endgroup\$
    – Rutger
    Nov 13 '20 at 10:26
  • 1
    \$\begingroup\$ "play testers found it quite difficult to draw the shapes they wanted and they made a lot of errors in the process," Can you exhibit some specific examples of shapes they found difficult to draw with this, or specific errors you saw occurring? That can help focus answers on mechanics or feedback & communication strategies that will solve those specific pain points. \$\endgroup\$
    – DMGregory
    Nov 13 '20 at 10:40
  • \$\begingroup\$ Sure thing! I can quickly think of two scenarios that occurred regularly, but they are a bit difficult to explain in words. I'll try for now and perhaps later today I can make some GIFs or something. First thing: When drawing a straight line, accidentally deviating into a cell on the side results in two turns. Second thing: When trying to make a junction, people often started on the cell on which the junction track had to be added, resulting in it not being drawn at all. \$\endgroup\$
    – Rutger
    Nov 13 '20 at 11:01
28
\$\begingroup\$

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!

\$\endgroup\$
5
  • 6
    \$\begingroup\$ Welcome to GDSE! Trainyard was an amazing game; it had all the tools you needed to solve the later really hard ones. \$\endgroup\$
    – Almo
    Nov 13 '20 at 18:44
  • 1
    \$\begingroup\$ On topic, the input method on Trainyard was fantastic on my tiny 1st gen iPod touch even with my fat thumbs. Intuitive, low error rate, and the way the ordering of multi-track worked I could have all my switches done right the first time. Off topic, I miss Trainyard something fierce, and would pay into a gofundme to get it updated. \$\endgroup\$
    – Logarr
    Nov 13 '20 at 21:35
  • \$\begingroup\$ If you release the source for (some of) the engine, you'd certainly get volunteers to help port it – at the expense of ending up with a cross-platform libre clone. You could keep the assets, though, which would let you keep a certain degree of control over the game. Case study: Gish. \$\endgroup\$
    – wizzwizz4
    Nov 13 '20 at 22:26
  • \$\begingroup\$ Hi Matt! Many, many thanks for taking the time to share your experience on the issue and thank you @DMGregory for summoning you here. I hope you can imagine I'm quite excited to have the opportunity to talk about this stuff with the guy behind the game that actually does what I'm looking for! :) You did a great job on Trainyard as a whole, and I don't need to tell you that, but I am telling you that you also did a great job on the input system, which is a thing compliments are a bit more unusual to receive for ;) I still have some things I'd like to respond, but they don't fit in this box! \$\endgroup\$
    – Rutger
    Nov 13 '20 at 23:18
  • \$\begingroup\$ Comments are not for extended discussion; this conversation has been moved to chat. \$\endgroup\$
    – DMGregory
    Nov 14 '20 at 0:46
6
\$\begingroup\$

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...

enter image description here

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". 😉

\$\endgroup\$
1
  • \$\begingroup\$ Hi DMGregory, thank you for your thorough answer! Your proposed solutions/heuristics are all very interesting to try out and test. I like your idea of edge touches, which on its own could already drastically change the way drawing feels. Sticking to rows/columns might be helpful too, but the levels will probably be quite compact, so it might in some cases work against the user by making turns harder to draw. I also recognize your point on latency and delayed feedback. When combining with edge touches, perhaps showing a preview as soon as the user is close enough to an edge can bridge the gap. \$\endgroup\$
    – Rutger
    Nov 13 '20 at 12:28
1
\$\begingroup\$

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.

\$\endgroup\$
1
  • \$\begingroup\$ Hi Engineer, thanks for your answer! I do get the feeling that you are imagining a different type of game than what I have tried to describe. The grid is very coarse and that coarseness is an integral part of the design. Track pieces are the same size as the grid cells, so I'm not trying to work around the fact that a grid is used. I think that if you take a quick look at screenshots from the games I have mentioned in my question you'll understand what I mean :) \$\endgroup\$
    – Rutger
    Nov 13 '20 at 11:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.