More Pinballesque!

• A new table: a proof of concept for multi-level tables. It’s a rough cut to try out two sets of flippers. The idea is that there’s a high risk/high reward upper table with really wide set flippers, and if you lose the ball, you can still recover it on the easier, narrower table.
• In an attempt to shorten the aiming learning curve, I’m displaying a prediction line when the ball is resting on a flipper. I also show the full range of angles that can result from the flipper position.
• Simplified gamepad controls to moving flippers in sync with each other, instead of each stick moving a flipper independently. It didn’t add much and made it much harder to learn. You can use both thumbsticks in unison to move the flippers faster.
• The gap between the flippers is now constant. I used to keep one flipper near the centre to make juggling from flipper to flipper easier, but it’s kind of redundant now that the ball has more friction force from flipper movement.

I changed the GUI from ImGUI to NGUI in preparation to do the bulk of the UI screens. (I’m thinking Jetpack Joyride-style minigoals). NGUI is frustrating the hell out of me. Anchored objects work fine for a little while, then freak out and go walkies later on, and I still haven’t been able to identify why. The featureset of NGUI sounds awesome, but I wonder how much of it is riddled with bugs?

A new Pinballesque build is up:

Physics/Controls:

• I’ve redone the flipper physics so that they no longer glide frictionlessly under the ball. (Setting a Box2D rigidbody’s velocity directly is more respectable than teleporting its position. Using forces was simply too laggy)
• The flipper bases now have nubbins on the end opposite the flipper to stop the ball from rolling off.
• Added gamepad controls. I’ve only tested them on a 360 controller so far. Gamepads give you the ability to move the two flippers independently.
• Flippers can now cross the center-line by a smidge, to help out when you lunge with the wrong flipper.
• Mouse sensitivity is now consistent between different resolutions.

Visuals:

• The combo blocks now have symbols associated with them to make it easier for colour blind folks.
• I animated the combo blocks entering the combo stack. I use a depth mask above and below the stack and suspect it may cause compatibility problems. Let me know if you see blocks poking out the end.
• Added light effects when you collect a combo block.

I’ve been experimenting with different art styles for Pinballesque. Here are some of the test renderings I’ve made with Zen Photon Garden, a 2D raytracer (the high quality batch version, not the web based one).

Zen Photon Garden is unusual because instead of the output being based on lit surfaces, it’s a map of photon density across a 2D area. This gives an interesting smoky look where every shaft of light stands out in stark relief.

Some promising results, but for consistencies’ sake I’d have to do lush shading on all the rest of the art too, which is daunting. The dark lines extending from the ends of the walls are an artefact I’d like to get rid of. I think I can fudge it in my Unity -> ZPG exporter by rounding the corners of the boxes.

In the wake of Sochi, the IOC have opted to discontinue certain events due to adverse outcomes:

• Men’s Deep Jump
• Super heavyweight pole vault
• Clean and Jerk and Throw
• Shouting (Men’s Lorem Ipsum)
• Equestrian Half Pipe

I spent a big chunk of this week trying out moving targets in Pinballesque. They’re tempting because they’d let me build a game out of spawn patterns and movement behaviour rather than table geometry, which would be less work. It turns out they suck pretty hard in this game:

• The combo system is all about making patterns, so inadvertent hits are really punishing. This rules out spawning a big jumble of objects. In Breakout it’s a good thing if the ball makes it through the outer layer and starts bouncing out of control in the interior layers, but that’s death with this combo system. I wound up restricting them to a single layer and tried to make sure the return angles were fairly straight.
• I needed to move the objects very slowly, so the player has time to wait for the ball to roll to the right part of the flipper. To change the configuration of objects at more than a glacial pace, I rhythmically pulsed the movement.
• I needed to make the objects fairly large as well.

Add it all together and the experience isn’t really that much different from a series of ramps that periodically cycle through colours.

Here’s the pinball redesign I’ve been working on for the last couple of weeks:

Play Pinballesque

• As I mentioned in the previous post, I want the goals in pinball to have more internal consistency underlying them. I’ve made a combo system where you get points if you collect colours in some kind of pattern (consecutive repeats, rainbows etc.). Sorry colour-blind folks, I really ought to add symbols too but I haven’t gotten to that yet.
• You can move the flippers from side to side. They rotate as they move to allow a range of shot angles, so I can tighten the flippers’ flick angle down, which reduces the precision of the timing that a player needs to hit a target.
• They’re also gigantic flippers with a very gentle slope. All to get a larger timing window.
• I’m still playing around with different schemes for moving the flippers. I ought to play around with different input -> response curves.
• Always keeping the pair of flippers adjacent to each other felt too Breakout-ish. Making one flipper mirror the other made transferring the ball from flipper to flipper really hard, as did moving them in synchronisation on their own halves of the track. I haven’t tried mapping them to thumbsticks yet, but it’s promising.
• It’s hard to evaluate how successful I’ve been with the crappy table design. I feel like there’s a ton of room to improve on that, but table design is tricky and it really is a time sink.
• For fun I put in some tinkly marimba notes with pitches driven by the sequence of colours.

First impressions of Unity’s 2D support

• The sprite renderer looks handy. I dig the new editor handles and the atlasing support.
• The 2D physics engine is way less configurable than PhysX, and I regret that I didn’t just use 3D physics with one dimension and 2 rotation axes locked. It’s missing some really obvious stuff: moving/rotating objects without teleporting to the final position, a ConfigurableJoint equivalent, configurable bounce/penetration thresholds and so on.
• That said, being able to edit the polygon of the PolygonCollider from inside the editor is really, really convenient. (Shift and Ctrl click on the collider outline)

Sound in Unity

This is my first time using sound in Unity. The built-in support is monomaniacally focused on sound in 3D environments without any of the other stuff a game typically needs (control over polyphony, priority/duplicate handling, ducking, loop boundaries and loop mode, variant sounds). I previously thought GUIs were the most unloved part of Unity (and the most likely to be summarily replaced with an Asset Store hack), but sound’s definitely a contender.

(I love that it has tracker module support out of the box, although  - characteristically - there’s no control over the playback. No channel volumes, no tempo control, no seeking to patterns)

The dumbest thing is that FMod is built into Unity, you just can’t see any of it from the script layer. My former co-workers, the Curry Brothers, have managed to do an end run around this by writing C# bindings for an FMod DLL that they include along with the exe. Surprisingly you don’t need Unity Pro for this. It won’t work for web player builds, of course, but it’s an interesting possibility for a full game.

My non-Mostly Tigerproof work is coming to a close, and I’m back to prototyping weird ideas again. This time the theme is pinball.

I’ve always loved pinball. During the 50-ish years between the advent of flippers and coin-op pinball’s commercial collapse, it has become a well-tuned and richly elaborated class of games, so it might not be obvious why I’d choose it as something to try to improve upon. In spite of how much refinement it’s seen, I believe the game still has glaring problems.

I play vastly more video pinball than real pinball. I grew up on video pinball, as did nearly everyone younger than me. In some ways pinball is poorly adapted to what is now an overwhelmingly software-based existence:

• It’s fundamentally portrait in a landscape world. I’m looking for ways to make better use of wide screens.
• There’s no consensus on what the role of nudging should be. Is it cheating? Is it essential, because you have no other defence against the outlanes?
• Nudging is usually poorly implemented in video pinball, due to its partial legitimacy. If nudging is part of the game, it needs better feedback: on-screen counters of how many nudges I have left before a tilt, hints about how far the ball will be nudged, maybe even a nudge training table. If nudging isn’t part of the game, the game needs redesigned so it won’t be missed.
• And speaking of outlanes, they’re shitty design. They prevent good players from playing indefinitely (a particular worry in coin-op), but they do it through random instant death. There have been a couple of attempts to replace them with timers (Goin’ Nuts, Safecracker), but hitting a time limit almost feels even cheaper than getting an unlucky bounce. Luckily there’s no shortage of ways to make a game hard.
• Pinball tables don’t do a good job of communicating goals during play, and the goals are arbitrary without much internal logic to them. Flashing lights and voice prompts are very helpful, but personally there’s so much unexplained stuff I wind up reading the manual. Reading the manual is a chore though. It’s a chore that recurs on every table, which might be unnecessary. Could there be a system of goals shared between a family of tables?

I think pinball’s most fundamental drawback is its uneven learning curve combined with its heritage as a game of chance. The challenge in pinball is directing the ball to where you want it to go. Catching the ball in the crook of the flipper is easily learned, but it takes precise timing to shoot at the angle you intend. A pinball will roll off a flipper in a second. During that second, the resulting angle of the shot varies by 60 degrees or more. What’s worse is that most of that variation is compressed towards the tip end. Each frame matters.

It’s wonderful that pinball rewards such high levels of finesse, but it’s hateful that even after hours of practice, beginners find their performance is dominated by random chance. Even when they do achieve things, it’s hard to take pride in it with the knowledge that flukes outnumber intentional shots. I think pinball should do a much better job of reflecting the player’s intent, even if their timing isn’t dead on. I’d love to bring the experience of being good at pinball to a wider audience, while giving old hands even greater challenges.

Those are my high-falutin’ design goals. More on my specific approach in the next post.

I quit PikPok this week. I’ve been at Sidhe since mid-2006, and working in the PikPok mobile label since the start of 2010. I’ve met some startlingly talented individuals there and it’s a shop with great prospects, but it’s time for a change. I’m quitting to work full time on my own projects - I want a train-wreck I can call my own.

When I’ve got something ready for public consumption, I’ll announce it here.

A sci-fi story

Kelly checks her work items. Uh oh, a client freeze. The KickStarter milestone’s been slipping and the money is starting to run out. Right now, showstoppers are exactly what they don’t need.

Thank god Jack’s the one on the forums trying to pass a vote on paring back the milestone requirements. If he can’t get the ‘No’ vote lower than 43%, refunding that percentage of the users will send them insolvent. It takes preternatural calm to operate at the intersection of community management and project management.

She takes a deep breath and pulls from the QA repo. There’s several thousand session recordings in here, but her filters only show the busted ones. Sure enough, there’s a new fork in the replay tree and it’s red. “Watchdog violation: Over 1000 frames since input was last polled”. The offending fork doesn’t look much different from its sibling forks: same sequence of button presses, slightly different timings. If not for the freeze, the QA guy on topiary duty probably would’ve coalesced it into the sibling test cases.

Hmm, the work item has a VM image attached, but with everyone pushing changes like mad throughout the morning, she’d rather repro on the current codebase. She enables the audit log on the client that’s allegedly going to be the victim of this scenario. She taps the tip of that red branch and her PC’s displays take on the appearance of a surveillance system as the various game clients start up one by one and begin replaying the session that lead to the freeze. She rouses the cat from her lap and heads to the kitchen for a coffee.

Five minutes later, Kelly plops back down, coffee in hand. Bingo, it’s still busted. The game phase coroutine is stuck. At least it’s deterministic this time. Looks like the player was in the middle of dismounting their horse when the game froze. The coroutine’s waiting on the end of the dismount animation, but it never comes.

Oddly enough, the player’s current animation isn’t dismount. Where the hell did that value come from? Kelly has her IDE generate a data flow tree for the state variable. Her PC grinds away at rerunning execution from the last checkpoint.

The character animation state machine was a mess of amateurish hacks they’d picked up at auction from a somewhat unluckier project that’d gone belly up. They’d come to regret cutting that particular corner.

Aha! The state is passed around as if the authors were laundering a drug fortune, but the root of the problem is that a grapple interrupted the dismount. This isn’t supposed to happen. Dismount is sacrosanct.

Who implemented grapples? She squints at the fine print in the blame margin of the editor window.

“Radko (12/10/21): Fix exploit where jumps cancel grapples“

Hmm, where in the world is Radko Stamboliyski? Remote contractors had been going AWOL since the finances starting looking bad. They haven’t been able to get in touch with him for a week. He could be anywhere in Bulgaria. Hell, maybe the Bulgaria thing was a lie all along? Either way, she’s not getting an explanation for that commit.

A quick check in the animation timeline reveals the problem. The annotation that suppresses the animation being interrupted stops a frame short of the end. Argh! First frame inclusive, last frame exclusive! When will people learn.

One frame glitch. That explains why it survived until now. Hardly seemed worth the panic. Looks like the fangirls might get their Renaissance action-romance after all.

Inspired by:

• Slightly Mad Studios living up to their name
• The Inform 7 Skein
• Reversible Debugging

I’ve made a fresh new version of Satellite Launch and posted it at Kongregate. You can also play it at Mostly Tigerproof.

I’ve been eyeing up Kongregate’s Unity support for a while now, though it’s not much of a business proposition at the moment. Unity games on Kongregate get 40 times fewer hits than Flash games. Still, I figure it’ll be an interesting experiment, and I’ll get to see what their ad rates are like.

I’m mindful that I’m exposing it to a gamer audience instead of a game dev audience, so I’ve made a limited attempt to polish it up, but I’ve hit my self-imposed deadline before I’m truly satisfied with it. In any case, I’ve been operating in a vacuum for too long, and it’s time to get some feedback.

Scoring Overhaul

I ran out of momentum prototyping the concept 2 years ago because I couldn’t see any interesting progression mechanics to pair up with basic challenge of trying to launch as many satellites as possible. That and there was a fairly boring dominant strategy where you can just queue up a lane of satellites in the same inclination.

In the new version, the objective is to link up pairs of ground stations. This provides an incentive to spread your satellites across different inclinations. Also, picking orbits to cover the most stations possible makes the game feel a bit more tactical.

The scoring is now a multiplication of two numbers, so linear improvements in the player’s skill grant quadratic improvements in the player’s score. This is nice because when you’ve been playing something for a while, it’s discouraging when the law of diminishing returns kicks in. I want to compensate for that by spreading out the high end of the score distribution. Yet another little thing I learned from Geometry Wars 2. That game is an education.

Other Changes

• I fixed some problems with the input that were hampering the player’s ability to place satellites over the ground precisely. Added an orbit prediction line too.
• UI redesign. All the crappy programmer art has been replaced with programmer art that’s somewhat less crappy. Yaay!
• The game ends now. It used to just run indefinitely, and save your highscore when you’d achieved a new personal best. This is the part I’m least sure about. You’re allowed only 5 collisions, so there’s a bit more tension. It feels more like Jenga now. That said, if I’d made an Undo function instead of a lives system, it’d be less frustrating.

While I’ve been writing this, the game’s been played more times at Kongregate than in the last year at Mostly Tigerproof. Heh.