Rktcr: Path Select

Rktcr, as text, is pretty much free association. I know what I want to happen in the game, and it flows relatively freely into the code. This isn't to say that things work properly on the first try -- many of the systems in Rktcr have undergone (and are undergoing) refinement.

Of course, you can motivate this refinement by downloading the demo and providing feedback.

One of the systems in the game that I've been having a fair amount of trouble getting right is path selection. In the current demo, path selection looks like the above shot -- a simple way of picking any completed trajectory through the zone.

This path select doesn't really give one a good idea of the content of paths, or how they vary -- e.g. two paths that are the same except for the last five ticks are displayed entirely separately. It also strikes me that path select mode, with its holistic view of trajectories, is a good place for timeline-based editing.

The (work-in-progress) screenshot above shows my current progress in playing with these ideas. I'm generally liking the two-level timeline (detailed view and overall view) for showing the controls applied along a trajectory, though I dislike the redundancy. Perhaps I will test a magnification-in-context style as well. I also like the faded-wheel trajectory visualization (n.b. this is animated in game, though I'm still trying to find the right sort of curve to use to animate it -- right now it's a sine wave, and feels a bit too smooth).

However, I'm struggling to figure out how to show different paths in this context and how to select between them. In broad outline, I know I want to use a tree structure, which should make common segments of paths clear. Indeed, I have a fair number of sketches of potential display and control options. Unfortunately, no option is clearly the correct one yet.

Rktcr Demo Zero Video

I believe I recently mentioned that Rktcr Demo Zero is out.

As a further enticement to just go download it, already, I've created the following compelling piece of documentary cinematography.

I'm sure you will agree that it is a great success, though perhaps overburdened with symbols in -- I would say -- the surrealist tradition.

Rktcr Demo Zero is out!

The title says it all. Rktcr demo zero has been unleashed upon the world.

Download it now, while you read the rest of this post. (Zip file contains versions for Windows [32-bit], OSX [10.7+; 64-bit], and Linux [32-bit]. You'll need a decent video card to play.)

This is the first public release of the game, and -- thus -- a great opportunity to provide feedback. I'm very interested in what you, the players, enjoy about the game and what you not-so-enjoy. You can let me know by contacting me directly through e-mail or instant message, by commenting on the game over at Steam Greenlight, or simply by commenting on this news post.

I look forward to hearing about your experiences with Rktcr. Have fun!

Making The Worst Case Less Ugly

Nearly everything you see in Rktcr -- sprites, fonts, backgrounds -- is vector-based. Sprites begin life as marked-up SVGs, and are meshed by some tricky planar-map code, then stored as triangle lists; fonts are the same (as I posted about previously); and backgrounds are procedurally generated meshes.

What this means is that without some decent antialiasing or a high-resolution screen, things can go horribly wrong -- lots of jaggies and illegible fonts. My solution to this problem was to add code that "bakes" meshes to textures (this code is only used when antialiasing isn't available). It isn't perfect, but it does make 800x600 a more pleasant playable resolution.

The Results (menu)

The left image has 16-sample antialiasing; this is how the game is meant to look. In the center, I show what the game looks like with meshes baked to textures -- it's a bit muddier, but still decent. On the right, I show what the game looks like without baking or antialiasing; pretty horrible.

The Results (lab)

You'll probably need to click on these images to see them large enough to judge the differences. The order is aa, baked meshes, no baking, as in the previous comparison. Some interface elements are not static meshes (e.g. the timer in the upper left) and -- as such -- remain jagged.

The Fonts of Rktcr

This week, I've been working on refining the Rktcr experience in anticipation of a public demo. Particularly, I've been working on redoing the tutorial.

The old tutorial (above) was nice looking, but it's also a static .svg, which means that it's non-interactive, presents a lot of information at once, and includes keys that may not be current.

The new tutorial is visually simpler, you get to test out concepts as they are introduced, and the keys mentioned are actually the controls you've configured.

Part of what I had to do in order to make the new tutorial possible was add a new font to the game -- which got me thinking I might as well do a post about fonts in Rktcr.

The Font System

The basic unit of a font in Rktcr is the glyph. Glyphs contain information about their graphical representation, along with a table that indicates how to advance the cursor for subsequent glyphs.

Glyphs can represent arbitrary strings of characters; this allows for complicated ligatures. When typesetting text, the longest prefix of the string that corresponds to a glyph is used. In theory, this should also allow the code to support UTF8 without extra decode steps, but in practice I chose to explicitly decode UTF8 in a preprocess (mostly as a way of catching malformed strings).

Rktcr loads fonts from specially-tagged .svg files. Any group labeled as "font:xyz" creates a glyph for the character sequence "xyz", and groups labled as "adv:" specify cursor advances between glyphs. This makes it relatively easy to create new fonts in Inkscape. (I don't use the official SVG font specification because... well, I didn't know about it.)

The Fonts

I've drawn five fonts for Rktcr so far, though only two of them appear in the game at present.

Blank Check

Blank Check is the main Rktcr font. It attempts to capture the graphical ethos of the game: it has the classic presence of a pixel font, with a love of circles only a pure-vector system could espouse. It isn't the smoothest-reading font, but it brings a certain naivete and optimism (which I share) to the table.

Control

Control is the font I use for representing keyboard keys. It makes use of ligatures for keys like "space" and "escape". Its corner-cut design is based on some very early concept art. Like other fonts in the game, it is incomplete (but complete enough to be useful).

Madness

Madness is a serif-font experiment I started around the same time as Blank Check. It doesn't appear in the game (but what a different game it would be if it did!).

Rktcr

Rktcr is the first font I slapped together for the game; turns out to be painful to read, so I took it out. It does have a nice ligature for "rktcr", though I decided to move away from that style for the title.

Temporal

Temporal is a simple 7-seg digit font that used to be used for times. It was supplanted by a set of dot-matrix-style digit sprites (for the path computer) and blank check (everywhere else).

Rktcr Beta4: Bursts and Bobs

This weekend, I'm pleased to be able to unleash Rktcr beta4 upon the world. It's not jam-packed with dramatic new improvements, but it does contain a few important refinements (enough of which have potential to break on Intel GPUs) that I figured it was worth sending out a new build.

This beta build also includes the challenge level style improvements that I talked about in a previous post. (Indeed, these are one of the main GPU-worry-causing improvements.)

By the way, if you'd like to be playing the beta, drop me an e-mail and I'll get you a Desura key.

Gameplay Refinements

This build contains two graphical tweaks that make the game more "readable".

Indicator triangles show which of the control keys are pressed, even when the game is paused. This creates a strong visual connection with your control inputs.

The play-pause indicator now lives at the bottom center of the screen, and has shadows that show the current speed that the time-forward and time-backward keys will reach. This position feels more sensible, given how essential to the game time control is.

Burst Graphics and Sounds

Bursts were one of the last remaining items in the game without at least a first-pass visual style applied to them. Well, this is no longer the case. I've also updated the burst collision and activation sounds to a sizzle and a sizzle-y pop, respectively.

More Levels

I've added two new world levels. And, thanks to the extra connections these levels afford, I've been able to generate clover-free worlds (if you have been playing the beta, you probably know what this means).

I've also added four more challenge levels -- these all go in the middle filing cabinet.

Miscellaneous

Sometimes you do amazing things and want to show them off. Pressing 'v' will replay your path in the current zone; pressing shift-v will replay your entire journey. During the replay you can change the speed of time and move the camera. I'm looking into what it would take to encode and upload to youtube from within the game.

Loading has gotten dramatically faster -- at least on my SSD-containing dev boxes. For instance, it used to take 20 seconds to load all the in-game sprites; it now takes 88 milliseconds.

Blueprint-style Challenges in Rktcr

I recently re-styled the challenge levels in Rktcr to have a sort of "sketchy" look. This has been on my TODO list for a while, but was pushed toward the top by comments on the Steam Greenlight page.

In this post, I describe how this style works, and show examples from a new challenge level.

The Basic Idea

The heart of the paper style is a paper height map. To make natural-media-esque strokes, I simply treat the stroke's alpha value as a "pressure", and (soft) threshold this pressure against the paper height.

As the above example strokes show, this gives a nice break up of stroke pigment as the alpha value changes.

As an additional surface roughness cue, I added a pass that performs bump-mapping (with a canonical upper-left light source).

Putting It Together

The style used in the challenge levels is built out of a stack of quite a few layers (as you can see to the right of these pictures). Here's what goes into getting the static platforms looking good. The same methods are used for dynamic and distruptable platforms, but with different textures.

Shadows

The first layer to be drawn is a subtle shadow pass. This helps the platforms "pop" off the background slightly.

Fill

The comes a solid fill color. This isn't broken up by the paper texture, but it will be influenced by the bump-mapping later.

Fill Texture

Next comes a fill texture, as one might see on a blueprint to indicate a solid area. This texture has some ugly hard edges, but the stroke drawn in the next step will cover them up.

Stroke

Finally, a nice natural-media-ish stroke bounds the static platforms. My code insets the stroke so that its top edge pretty much exactly matches where the vehicle actually rests.

Bump-mapping

Finally, lighting is applied to bring out bumps in the paper texture. This completes the look and ties everything together nicely.