Caravan Experiment Newsletter #11
Hey everybody!
11 weeks down and 5 more to go. I’m feeling… cautiously optimistic. I tested the game on somebody else’s computer for the first time this week and it works!
Thanks for reading, and please continue to reply with comments and suggestions or just give me a call. I’d love to hear from all of you.
Follow-up: Design a Creature Round II
Well I got some great suggestions. My favorite was “beetle that grows fruit on its back”. But unfortunately I didn’t deliver. I decided to squeak in one last feature after some feedback from my friend Chris during our does-it-work-on-your-machine testing.
Call to Action: Join the Playtesting Discord Server
Pimping this Discord Server again: https://discord.gg/CRPscxH.
The first version of the demo will be available there starting next Wednesday.
Design Notes: Continuous Tactics
I have not previously discussed the combat system in Caravan, but if you have studied the gifs you may have noticed that it is turn-based and involves a number of units moving around on a 2-dimensional field to attack each other and stuff.
Generally speaking, turn-based + unit positioning = “tactics”. If you don’t know what I mean when I say tactics, here are two titans from the tactics genre as potential touchstones: X-COM and Final Fantasy Tactics. Both of these games task the player with moving teams of units around on a 2-dimensional grid. At some point many years ago, for a reason I will laboriously arrive at by the end of this post, I decided that I could make a tactics combat system without a grid. Caravan has inherited that combat system idea for better or worse.
For my money there is one major design problem with leaving the grid behind: I call this problem noodling.
Noodling exists in many tactics games of the past and present to greater and lesser extents; it is an issue for games on a grid, but its problematic nature is magnified greatly when the grid is removed.
To understand noodling you need to understand how the player controls the movement of units. The fundamental law of tactics movement is that any given unit on any given turn can only move to a target location if there exists an unobstructed path from their starting location to the target location and that the total length of that path is less than or equal to some value (we’ll call that value their “speed”).
In this example, our unit is the red dot. He has a speed of 5 tiles. The yellow blocks are obstacles that he cannot pass through; the green spaces, then, are all the viable spaces our unit can move to on this turn. The computer helpfully calculates this movement range for us and displays it just like in the picture above. To move our unit we just have to click on one of the green tiles and he will follow a path to the chosen tile.
Now we’ll introduce some conflict:
We want to kill this blue dot. On our turn, after we move, we are now allowed to punch and kill any unit that is standing in an adjacent tile. Of course, Blue has the same thing in mind. To our advantage, Blue is slower. He can only move 4 spaces compared to our 5. Since we can’t reach Blue in one turn, we have to spend a move closing the distance. But where should we move?
Assuming Blue will not turn tail and run, the superior tactic is to move to the tile just in front of our unit that I’ve indicated with both an arrow AND a yellow star for some reason. That way, no matter where Blue moves to on his next turn, he cannot hurt us and we are guaranteed to kill him on our following turn!
If that decision was trivial, I’ll make it harder:
A few more enemies, with different move speeds (denoted by the blue numbers), placed at diagonal angles to your unit; suddenly it’s a real head scratcher. There’s a simple solution to this though: let the computer do the work and tell you which tiles are safe:
But of course we need to make things more complicated. Imagine our red dot now has a gun. The gun fires a bullet that can be thought of as a baby unit: It follows the same movement rules as a unit, except that it originates from our unit’s position (and maybe has a different speed). When the bullet lands on Blue… bang!
So this is where noodling finally comes in. Your turn now requires considering two ranged actions in sequence:
move your unit
shoot your bullet
Ideally, we want to position our unit so that one of the very outer tiles of our bullet’s range contains the enemy unit (so we can stay as far away from harm as possible). But in order to test where the extents of the bullet’s range are we have to move our unit first.
Imagine choosing a movement location for our unit and only then seeing the visualization of our gun’s range. Imagine how easy it would be to choose a placement that is off by one or two tiles. Then you have to undo your placement. Now our unit is back where it started! What was that tile I just picked? 4 up and 3 right? So… I should do 4 up and 4 right…?
This is noodling. It’s an iterative series of range-finding click actions that a player has to do in order to dial in their unit’s position + target. It’s a pain in the ass in grid-space and it is hellish in continuous space.
What a movement range might look like in continuous space
Continuous space is not really continuous of course; its just a huge grid whose resolution is the same as your monitor: every tile is one pixel large. Imagine noodling with that granularity. If mis-placing by one or two tiles in grid-space is annoying, imagine being off by 1 or 2 pixels.
So what is my great insight that made me think I could do a continuous-space tactics game? My solution to noodling: shoot first, then move.
Instead of thinking of the gun’s bullet as a child of our unit, think of it as a child of the enemy’s caved-in head. The bullet shoots backwards from the enemy’s head into the barrel of our gun. The maximum range of the gun including any unit movement is simple to calculate: add our unit’s range + the gun’s range. Because we know all the places a bullet can go, we can just select our target first, then decide where we want to stand. The valid places to move are a Venn diagram of the gun’s range centered at the target and our unit’s move range centered on our initial position.
Caravan is the only game that I know of to do this inverted tactics sequence of attack -> position. That is really cool and really scary! Cool because I may have actually innovated; scary because I cannot believe I’m the first person to think of this. Perhaps there be dragons down this path… We’ll see! In any case: phew. This was a long post. Thanks for reading and here’s a gif:
Caravan Experiment Newsletter #10
Hey everybody!
10 weeks down and 6 more to go. I’m feeling… anticipatory. I am now completely done with features and am only working on bug fixes and content for the demo. I can’t wait to get it out there.
Thanks for reading, and please continue to reply with comments and suggestions or just give me a call. I’d love to hear from all of you.
Call to Action I: Join the Playtesting Discord Server
If you missed it last week, here’s the link to the playtesting Discord server: https://discord.gg/CRPscxH.
I’m a bit ahead of schedule so there may be some activity there starting next week. I’ll send word via email when the first playable version is available to download.
Call to Action II: Design a Creature Round II
Since I’ve got time, I figure I can crank out a few more creatures. If you have an idea you want to see in the game send it my way. Keep in mind it doesn’t have to be anything too in-depth; “frog with wheels instead of legs” and “burnt horse” are both perfectly acceptable submissions.
New Feature: Ailments and Boons
FINALLY and OFFICIALLY diarrhea is in the game.
Diarrhea is an “ailment”: a time-limited effect that is detrimental to a creature. In this specific case, diarrhea causes the creature to arrive late to any battles (turn order delayed by X) and the creature will suffer this affliction for a number of weeks (each time you move to a new space on the map, a “week” passes).
And of course the opposite of an ailment is a “boon”: a time-limited effect that is beneficial. Boons will show up as rewards for certain encounters or even as items that you could hold onto until the right moment.
Boons and ailments can even be “intrinsic” to a creature:
When this creature joins your party it comes with an intrinsic boon called Melting that increases its power. It’s very strong but after a few weeks it loses this boon and you’re left with its otherwise lackluster stat line. What a bummer.
Caravan Experiment Newsletter #9
Hey everybody!
9 weeks down and 7 more to go. I’m feeling… coiled. Approximately 5 work days to go before we’re feature complete for the demo.
Thanks for reading, and please continue to reply with comments and suggestions or just give me a call. I’d love to hear from all of you.
Call to Action: Join the Playtesting Discord Server
The alpha build of the demo (Windows and Mac) will be available to play on April 22nd. There will be bugs. And worse, there will be gameplay that while technically correct, doesn’t make sense and you won’t know what to click and I’ll have to tell you that you need to drag the item instead of clicking it and that I’m sorry. I’m hoping those of you who are feeling strong-willed and game-literate will join me on the front lines to iron out the wrinkles.
Debugging will require hands-on collaboration so I’ve set up a Discord server here: https://discord.gg/CRPscxH. In the coming weeks I’ll be posting all the relevant set-up and debugging info there. Stay tuned.
In May (exact date TBD) there will be a (hopefully) stable demo release for everyone with a feedback form.
Design Notes: Nothing!
No time, but here’s a giant gif:
Caravan Experiment Newsletter #8
Hey everybody!
8 weeks down and 8 more to go! I’m feeling… incredulous. Can’t believe we’re at the halfway point already.
Thanks for reading, and please continue to reply with comments and suggestions or just give me a call. I’d love to hear from all of you.
Design Notes: Room Type Distribution
Immediately veering of course from the stated topic to go down a jargon rabbit-hole: what word comes to mind if I ask you to describe the things circled in magenta in this picture?
I personally think of the word “space” or, if I need to be more precise, “board game space”. Examining the purpose of spaces, the ubiquity of spaces, and the unspoken rules of spaces could be vital if we need to someday explain monopoly to plants but luckily we don’t yet.
The point of the digression is to say that Caravan has spaces too, but I (and other people making games) would call them “rooms” (and will call them rooms from here on). The etymological shift from spaces to rooms probably has something to do with games’ employment of random generation to create dynamic layouts as opposed to the static layouts of board games, but I don’t know why I’m writing this sentence.
When you land on a room in Caravan something happens. What exactly happens will always be somewhat unpredictable. No matter how many times you play the game, you will never know with certainty what will happen. This is good and fun. But it can’t be completely unpredictable or else a player would have no reason to choose one room over another.
For that reason, rooms in Caravan need to have an element that is known to the player: the room’s “type”.
Battles
High risk; high reward
Exclusively rewards new creatures
Elite Battles
Highest risk; highest reward
Exclusively rewards mutations
Trials
Low risk; low reward
Treasure
No risk; high reward
Rare
Shop
No risk
Resource exchange
Camp
No risk
Exclusively rewards health
With the possible exception of the Treasure room, they are all circumstantially desirable. While shops and camps are both free of risk, their value drops off significantly if they are visited multiple times in close proximity (i.e. you’ve already spent all your money, or you’ve already fully healed your team). Trials are generally low risk, but they come at the opportunity cost of a higher reward battle. It’s no mystery that the player’s best strategy is to choose riskier options when they are relatively stronger (such as just after healing from a camp, or just after spending money on powerful rewards from a shop). As a designer I want that strategy to be obvious to the player, because the question I am asking the player is not “where should I go next?”, but “how strong do you feel right now?” A probabilistic question as opposed to a discrete one.
For the demo there will be a variable number of total rooms generated per map, but each path through the map from the bottom of the tower to the top will contain exactly 15 rooms. Each room gets assigned a type randomly, with a few extra considerations. Firstly, there are places on the map where we want to “hard code” certain room types: the 8th floor will always be a treasure room, and the 14th floor will always be a camp before the boss. Secondly, the distributions of room types are variable over the course of the map. This is mostly to ensure that camps, shops, and elite battles don’t appear before the player can make good use of them. Finally, actual random distribution is bad. It has a tendency to make weird things happen like 5 shops appear consecutively in a row. So there is a penalty factor that gets applied to certain room types when they appear too frequently along a contiguous path.
Caravan Experiment Newsletter #7
Hey everybody!
7 weeks down and 9 more to go! I’m feeling… great!
Thanks for reading, and please continue to reply with comments and suggestions or just give me a call. I’d love to hear from all of you.
Follow-up: Jane’s Creations
My sister Jane has been seriously getting into the Caravan spirit. She drafted some sweet creature concepts:
I have not had time to realize all three, but I did manage to get that “Prickly Pear Bear” in the game:
She is a PLANT type creature with the special mutation “Thorns”. Whenever she’s attacked in battle she deals damage back to the attacker. Ouch.
Jane ALSO started work on an awesome new logo for Caravan. Very excited to show it off when it’s done.
New Feature: Encounter Scripting Tools
Lots of refactoring work was done this week to move functionality that used to be "battle-only” to a more generic place. Among other things I now have the ability to “cast skills” from my “encounter” scripts. Here’s an example encounter script:
And here’s the same encounter script as it appears in the game:
This is very exciting because I am finally nearing the point where I can start making content for the game instead of just building its systems.