The Case Study: Following Up on Feedback

Changing a game’s theme is risky. Parts of the design were shaped around the previous theme; they might not fit the new one. Through the Jungle has proven to suffer from this issue, and I’ve been putting thought into how to fix it.

At its inception Through the Jungle was a game about traversing a no-man’s-land between World War I trenches, trying to sneak across in the darkness while avoiding searchlights. In that context it was perfectly sensible for the searchlights to move quickly, steadily, and in more-or-less predictable patterns.

When I refitted the game with the current evade-hunting-animals theme, I retained the movement system designed for searchlights. That seemed reasonable from a gameplay perspective—it was tried and tested. Board gamers often hear that games are re-themed by their publishers after the rules are set in stone; I figured that since I was going to be wearing the publisher hat, I could do as they did.

Unfortunately, the results weren’t quite what I was hoping for. Jay has accurately pointed out that the current way movement is handled doesn’t feel right for animals. They’re sweeping about at a constant pace (don’t the animals ever slow down to investigate something more carefully, or speed up to give chase?), over all forms of terrain (picking a path through overgrown jungle doesn’t slow them down? Climbing a steep cliff doesn’t either?). I’d fallen into the dreaded trap that makes board gamers sigh when they hear about publishers altering a game’s theme at the end of the process: the new theme was merely pasted on.

There was another problem as well. It was perfectly logical for searchlights to be able to catch multiple people; if one illuminates them all, they’re all busted. Jay noted that it makes a lot less sense for an animal to be able to do that. Presumably it only has one set of jaws with which to drag prey back to its lair.

In response to this feedback I’ve tried two modifications to the game:

1. Animals only “see”—i.e., can capture—in front of them, and “pounce on”—move into the space of—the first adventurer they spot. This was immediately unsatisfactory; most of the time the animals were still moving like searchlights.

2. As above, but with everything taking place at a smaller scale: the board is 10 x 10 rather than 20 x 20, animals move three spaces (with the chance at an extra “pounce” move), adventurers move two spaces. This sort of worked; having the animals move more slowly gave more of a feel of stalking prey, and sharply limiting the adventurers’ movement demonstrated that getting through the jungle was not easy.

However, this approach still had the animals moving in a very mechanical, arbitrary fashion. Furthermore, it’s not yet clear how rescuing should work: ought hearing ranges be reduced, just as the animals’ line of sight has been? It’s exceptionally difficult to arrange a safe rescue when adventurers only move two spaces; is that a valuable source of challenge, or is the game now just unwinnable?

Neither of those is likely to end up being the way Through the Jungle ultimately goes. Having things up in the air isn’t a bad thing, however. The game needed fresh eyes on it to progress, and now it’s getting them! Breaking Through the Jungle down is a vital step in building it back up better than it was.

Try the game out if you haven’t, and let me know what you think. For my part, I’ll be at the library. I need to do some reading on the hunting behavior of great cats . . . .

Advertisement

The Case Study: New Version

I’ve just updated Through the Jungle’s page with new versions! They include changes inspired by Jay’s feedback: the full game rules can now be accessed from the main menu or during play (press Detailed Rules in the upper right corner of the How to Play screen), and the water that served as a border for the map has been replaced by mountains on the three sides where it’s not possible to escape.

Jay also made the excellent suggestion that the animals should behave more like animals. For example, their movement should feel more like stalking and pouncing, and less like a sweeping dragnet. I really like that, and am going to put some design work in to figure out exactly how that would work and what other changes, if any, would be necessary to balance the very different gameplay experience that would result.

This is one example of why feedback is so valuable. I was too close to the existing movement system to see even the possibility of a different one, much less its advantages over what I’ve been doing. Get playtesters involved as early and as often as possible!

As always, let me know what you think, and if you run into any issues!

The Case Study: Debugging . . . the Rules Screen

In what I can only interpret as a warning against hubris, my efforts to put a “detailed rules” screen into Through the Jungle at first failed so catastrophically that any attempt to view them crashed Unity. Some crashes were been so bad that they changed the layout of the IDE windows! Remind me never to think “I know how to do this, it’ll be easy.”

The crashes are now resolved. Unfortunately, figuring out what was causing them* took so long that the more conventional work of getting the screen scrolling properly, getting everything hooked up internally, etc. is still underway. Owing to the talk I won’t have time to work on it tomorrow, but I’ll have a go at it again on Friday.

* I spent a long time looking at the code, but as it turned out the problem was a misclicked setting in the IDE relating to one of the GUI elements that handles scrolling text. I’m not at all certain why that caused crashes as opposed to just a weird-looking interface.

The Case Study: Without Further Ado

Here it is!

On the page for Over the Next Dune you’ll find links to versions of the game for PC (Windows 64-bit), Mac (universal), and the Unity web player.

The change log since Wednesday is brief:

– Problems with the “Attempt Rescue” button are fixed; it will now appear and disappear reliably in weird scenarios (e.g., an adventurer drags a searcher over another adventurer).

– “Quit” button implemented. (One doesn’t feel the lack of this within the IDE. Lesson learned!)

– A bug wherein the “End Turn” button wouldn’t appear when the last adventurer escapes while all other adventurers are captured has been fixed.

There are also some bugs I’m aware are still present:

– Terrain can extend beyond the bounds of the board. This has no gameplay effect, but is visually weird. Unfortunately fixes for this are, depending on who you ask, either quite involved or flatly unavailable.

– When three adventurers conduct two rescues simultaneously–that is, they rescue two different adventurers from two different searchers with a single press of “Attempt Rescue”–things don’t work right. I know where the problem is, and just need to get the time to solve it. Fortunately, this situation is very rare.

– The rules screen doesn’t look right in the Windows builds. It’s fine in the web player version. Not having a Mac myself, I don’t know what it looks like there. 😉

You’ll see that the game has gone through a name change. “Over the Next Dune” just wasn’t relevant to the new theme. I’m not satisfied with the new name–“Through the Jungle”–and am going to put some thought into a better one now that I’m not constantly thinking about other issues. 😉

Please feel free to leave feedback as a comment to this post, or by email at (the name of this blog, all as one word)@gmail.com. Please don’t leave comments anywhere else; if they’re in those two places I’m sure not to miss any, and it’ll always be clear what version a comment applies to.

At the moment I’m particularly curious about:

1. Difficulty. How often did you win, out of the games you played? Did you find the challenge too great, too low, or about right?

2. Theme. What do you think of the new traversing-a-deserted-island theme?

3. UI. Are the buttons big enough in play? Too big?

4. Bugs. If you encounter a bug that’s not listed above, please let me know!

The Case Study: Change Log

Following up on last time, the change log as I get ready for Friday:

1. The rules are now available through main game screen. (As I expected, this was a simple thing that took a long time. 😉 Unity’s UI system is definitely something I need to put a lot more practice into.)

2. There’s now a turn counter.

3. Searchers now correctly report locations for players to re-enter the game, even when overlapping with other searchers. (This turned out to be completely trivial, but I had to get a bunch of practice with Unity’s 2D physics engine before I could understand the problem and how to fix it. Here’s what happened:

The game needs to determine whether there’s anything in each of the 16 spaces around each searcher. It doesn’t matter what the thing is; if there’s anything in a space, that space is no good for re-entering.

In order to make that determination, the game used Physics2D.Linecast to send invisible lines from the center of the searcher to each of the 16 spaces. Each space got three lines: one that would respond if it hit a player, one if it hit a searcher, and one if it hit the edge of the board. If any of those lines reported that they’d hit something, that space gets marked as occupied.

Unfortunately, this system had a critical logic error. When searchers overlapped, the lines looking for searchers would hit something—the other searcher—instantly, as soon as they left their point of origin. The space would be marked occupied, but the line hadn’t actually gotten that far!

The fix was to send the line from the space to be checked to the space to be checked. Physics2D.Linecast, it turns out, allows one to have the same point as both the start and the destination; it will send a fractionally tiny line at that location, and if that line hits something it will report back normally. Using those fractionally tiny lines made it possible to check just the intended space. In the end, the entire fix was changing one word in one line of code:

hit = Physics2D.Linecast(start, surroundingSpaces[j], searcherLayer);

was changed to

hit = Physics2D.Linecast(surroundingSpaces[j], surroundingSpaces[j], searcherLayer); )

4. The rules now include players leaving trails in the sand, and the searchers following those trails.

5. Various smaller bug fixes, mostly relating to the UI.

So far so good; we’re on track for Friday!

The Case Study: Where We Are Now

By request, some screenshots. 🙂

4-27-15 - OtND Main Game Board

The main game board. One issue with Over the Next Dune in physical form was that it was difficult to manage searchers that overlapped each other; players had to lift and replace searchers to see where the arrows on the covered searcher(s) were pointing, always making sure that everyone got back where they belonged. The PC version easily fixes that by using see-through sprites that reveal arrows that would otherwise be hidden, as with the two searchers in the upper left. Transparency is expensive for board games, but it’s trivial on the computer.

4-27-15 - OtND In Play

An example of the game in play. One adventurer tried to go up the left side of the board, but left a trail (some of which can still be seen in the lower-left corner) and got caught by the highlighted searcher. It’s up to the remaining adventurers to mount a rescue.

The “main menu” button in the lower-right was inspired by a game fair where local designers are invited to demo their games. Players in that environment tend to wander from game to game, often leaving things unfinished. I wanted to make sure that players who come upon a game in progress are able to get back to start.

Actually, now that I think about it the rules should also be accessible from here; as I have the game set up now they can only be read by quitting the game and returning to the main menu. That shouldn’t be necessary.

One thing that’s missing here is a turn counter. I’ve been torn between wanting it to look nice, and wanting to hurry up and get that important feature implemented. Having a deadline should get me over that, one way or the other. 😉

4-27-15 - OtND Rules Screen

The rules screen. Again inspired by the game fair, I decided to boil the rules down as far as I possibly could so as to be within tolerances for someone who’s curious, but not yet invested. Detailed rules for those interested in the nuts and bolts of the game are to be available in a separate window.

Oddly, I’ve found that the rules screen works perfectly fine when I build for the Unity webplayer, but breaks when I build for Windows. That’s not going to be a fun bug to track down.

Nor is it the only bug:

– When searchers overlap the game sometimes incorrectly reports that there’s nowhere for a rescued adventurer to appear.
– UI buttons appear over the win and loss splash screens.
– Splash screens snap into view rather than fading in.
– And more. 😉

The Case Study: Alpha Version on May 1

Court deadlines impose a certain amount of discipline on a lawyer. It’s not possible to iterate forever; at X time on Y date, you must file. That limit forces attorneys to prioritize, to use their time wisely, and ultimately to make arguments and advance their clients’ causes.

I appreciate the value of iteration, but I also think the discipline created by deadlines–even self-imposed ones–is valuable. So: on Friday of next week, May 1, I’ll post the PC implementation of Over the Next Dune. It will be as bug-free and complete as I can make it in that time. Doubtless there will be more to do thereafter, from both technical and gameplay perspectives, but it’s time for the “feedback” part of the feedback loop to get underway in earnest.

If you’re looking to play the game early, the print-and-play version is available. I promise that the PC version looks . . . well, it at least has colors. 😉

The Case Study: Now with Rules Enforcement

I’m happy to report that as of today Over the Next Dune’s PC implementation is fully rules-enforced! Everything you can do in the board game you can do in the PC version, and everything you can’t do in the board game the PC version prevents.

As I coded the last rule (players leaving trails and searchers following them) I realized that one element of the rule wasn’t satisfactory: how searchers deal with encountering multiple trails at once. In the current board game searchers that encounter trails leading in different directions follow the center-most trail relative to the board as a whole. That works, but it’s arbitrary. Nothing about being in the middle of the board makes a trail more of a priority; if anything, following those trails might tend to keep searchers in the middle of the board, when the whole point of the trails was to draw the searchers toward players on the edges.

I’ve now changed the rule so that searchers prefer to follow trails that are closer to the players’ finish line. My thinking is that that will encourage the searchers to chase players closer to the goal, hopefully leading to some exciting photo finishes. It will also help keep the searchers relevant by encouraging them to move upward as the game goes on and the players start to occupy the upper portion of the board. A small change, then, but I expect it to be a beneficial one.

Coding a board game isn’t always easy, but I’ll say this for it: it forces me to look at each rule in isolation. When working on a game as a whole it can be hard to drill down and say “is this little part as good as it could be?” Having to program all those little parts creates opportunities to ask that question.

The Case Study: See for Yourself

Following up on the last post, today League of Gamemakers posted an excellent comparison of dice and cards as design tools. I was particularly struck with the idea of drafting dice, which I didn’t think of when writing Monday’s post but which is a great way to manage randomness. Be sure to give Mr. Caputo’s article a look.

I also wanted to follow up on this post regarding the status of Over the Next Dune. A picture is worth a thousand words, so:

4-8-15 - OtND AlphaThe rules enforcement is almost complete; all that’s left is players leaving paths in the sand. While the art is simple, it beats the strictly-abstract print-and-play by a country mile. Every day sees a few more bugs squashed. I was hoping to have the alpha version available by the end of the week; that might not be feasible, but we’re definitely getting there.

The Case Study: Sooooo Close Now

While working on the PC version of Lines of Questioning, I realized that I had incidentally learned how to do everything that had previously prevented me from doing a PC implementation of Over the Next Dune. Since one of my current goals is to get OtND in front of more playtesters, and being able to put a ready-to-play version of the game up for download would certainly help with that, I decided to give it a try.

Currently sitting on my hard drive is a version of the game that works. It’s rules-enforced, although a few rules aren’t implemented yet. It has art–not anything that would win awards, but at least something that demonstrates a theme.

Unfortunately, as of last week the game had two bugs. Absolutely game-breaking, comical bugs. One allowed the enemy to Time Walk the players; the other caused everything to screech to a halt and the game to enter an unrecoverable state.

Today I squashed one of them.

One more bug and the game will be playable, albeit in a cheerfully feature-incomplete alpha state. A few additions past that, and some polish, will have the game ready for speedy distribution to playtesters. At that point we’ll have both a PC version of the game and freely and broadly distributable playtest copies, all in one go. Not bad . . . .