Rktcr: Beta3 and the Paths Computer

I am discovering that deciding when to release a beta of Rktcr is all about balancing imperfections. There are the rough edges I know about -- e.g. the missing lab functions in previous betas, or the relatively thin writing in the scripts -- and the imperfections that my testers invariably find -- e.g. blank screens and crashes on Intel GPUs.

The first kind of imperfection slows me down -- makes me want to take longer between betas so I can add "just one more thing." But the existence of the second kind of imperfection pushes in the other direction. Adding many new features and then finding a bug gives one a much larger amount of code to review.

I'm releasing Beta3 because of both kinds of imperfection. I've added a significant new feature -- the paths computer -- and I think I've worked around or solved a few antialiasing bugs I introduced in Beta2.

The Paths Computer

If you are one of the lucky(?) few who have been playing Rktcr, you know that the world can be confusing. Infuriating even. The connections between zones are complicated, and the game doesn't provide a map. To be clear:

This is by design.

(And that's why the paths computer is off by default.)

However, if you want to give up on thinking for a while, you can turn that 'ol beast on and it will act like a GPS -- pointing you to the fastest path it knows of that wins the game. It draws on both the par times built into the levels and on any paths you've completed with the current team.

More Level Styling

It's getting to that point where I want to convince people that Rktcr is an interesting game. Which -- in part -- means prettying up the levels a bit. This beta includes a first pass on that styling, with a low-key green geode style going into all previously unstyled passage levels, and a (actually rather ugly) draft of a blueprint-y style going onto the challenge levels.

Planar Map Refinements

I wrote some planar map code a while back to help in translating SVGs (with their attendant annoying fill rules) into nice OpenGL-drawable meshes. I ended up working with integer coordinates in the map code because it makes things like exact line-side tests a heck of a lot more feasible.

Unfortunately, the kind of detail I was putting into sprites was running up against precision problems, leading to some jagged edges on small features. So I revisited the code and pushed my hacks just as far as I could. I think the results are good; however, sprites have about 40% higher polycount than before. Almost certainly something I will need to revisit ... again.