In preliminary mission design, where you determine the high-level architecture of the trajectory, you just try a bunch of sequences, like Earth-Earth-Mars-Earth

In preliminary mission design, where you determine the high-level architecture of the trajectory, you just try a bunch of sequences, like Earth-Earth-Mars-Earth-Comet (EEMEC) etc. I'm guessing they avoided Venus flybys for this mission because that would overheat this particular spacecraft. (Venus is too close to the Sun.) There's only a finite number of possible, reasonable-duration sequences of Earth and Mars flybys to try, so you just get a computer and try them all. Once you pick a sequence (e.g. EEMEC), you scan across a range of launch dates, maybe incrementing by half a day… Okay, so now we've picked out a flyby sequence and a launch date. Next up is to pick the date of the first flyby. You can scan across those in half-day increments too. Once you pick the launch date and the first flyby date, you treat the leg as a two-body problem. You know the initial position vector, the final position vector, and the leg duration: it's a "Lambert Problem." Typically, there's only a finite number of solutions, so you just try them all (or all the reasonable ones, anyway). (Aside: In this mission, the first transfer was a one-year Earth-Earth transfer. It was a "resonant transfer": there's actually an infinite number of ways to do those, but the set of ways is topologically equivalent to the surface of a sphere, so you just try a finite number of points on that sphere. I digress.) In preliminary mission design, you just treat the gravity-assist flybys as instantaneous kicks to the spacecraft (instantaneous Delta-V maneuvers). Next up, we pick the date of the second flyby. Again you can scan across all those in half-day steps or whatever. Once you pick that date, you now have another Lambert problem for the second leg. It's handled the same way as with the first leg, only there's an added complication: Once we've got the first and second leg transfer orbits selected, we can ask the required flyby altitude at the first flyby. If it's below the surface of the planet, then that particular second leg is a no-go, and we can stop considering it. And so on. Eventually we end up at the destination. The trajectory model is just a bunch of conic sections (solutions to the two-body problem) patched together at the gravity assists (which have no extent in time or space). It's a "patched conic trajectory." What if the spacecraft does a Delta-V maneuver at some point? Yes, that's common, but it's also just a few more free parameters, so just throw them into the bag and try a bunch… Most of the time is spent just trying all the possible combinations. Each individual trajectory takes almost no time to calculate. Once you have a bunch of candidate trajectories, you can just compare them using whatever metrics matter, e.g. final mass at the target body, total mission duration, does it pass any interesting objects? And so on. Often there are constraints to satisfy as well. For example, operations people don't like it when maneuvers happen on the other side of the Sun from where the Earth currently is, because they can't communicate with the spacecraft at that time: the Sun is in the way. Once a preliminary trajectory design (or set of designs) has been chosen, one can simulate a more detailed model (e.g. one that adds the gravity of Jupiter), but the overall trajectory architecture doesn't change.