David Kim – Playing with Pinball

Storm the… Gordon Field House? Strong Museum?

Demo Days for Storm the Castle!

For our final, instead of a typical exam, our final was in the form of presenting and demonstrating our pinball tables at two events: Imagine RIT, RIT’s signature showcase events, and a pinball workshop hosted at the Strong National Museum of Play. As such, I had brought Storm the Castle! for demonstration, both in its physical layout and the version made with Visual Pinball.

Imagine RIT

Imagine RIT was hosted on April 26, 2025 across the entire RIT campus, showcasing all the various aspects of student activity at the university; for us, it was a place to show off what we’ve been working on all semester.

There was more than just this sign, believe me.

I showed up a bit early, mainly to make sure I was there, but also to get the gist of how others were running the table. It was mainly just answering questions or explaining how the Pinbox 3000 kits worked, but it also served as a way to promote the upcoming workshop at the Strong Museum, which was exactly one week later.

Being at the table was a very interesting experience, all things considered. We had people of all ages show up, but there were a significant amount of children; I anticipated seeing children, just not to the extent that we got.

Most of the questions came from adults asking about the class, or the design process that came behind making the tables. A lot of the times the only things we’d say to the kids were to just be more gentle with the machines, as they would mindlessly smash the flippers on the Pinboxes. In fact, I had to replace the rubber bands on my table because kids wouldn’t stop being so aggressive. (I don’t think Storm the Castle! would’ve been my final concept had I known most of the people trying it would be kids…)

Since I spent more time at Imagine RIT than I initially anticipated, I left the Visual Pinball version of Storm the Castle! at the table for people to look at; there weren’t as many comments on that, but I suppose that’s fair given the fact that there were cardboard pinball tables right next to it, and those are definitely more of a rarity.

Refinement

Since we had a week between Imagine RIT and the Pinball workshop at the Strong Museum, we had one last class before Finals Week to tweak any issues we had with our Pinboxes or Visual Pinball tables. Since I’d basically already finished the latter already, I just used that time to repair my table; I set some more hot glue on loose spaces, replaced the broken rubber bands on my kit, and fixed up the bent flag on the castle. Besides that, there wasn’t much left to do besides bag up the Pinbox and get it ready for a trip to the Strong.

The Strong National Museum of Play

In case you’re not from around the Rochester area, The Strong National Museum of Play is a museum dedicated to, well, playing; whether it’s toys, board games, video games, the Strong is a place for people of all ages to understand this sort of entertainment. Because of the large impact that games have on play, they’re featured very prominently, and pinball is no exception to that. The Strong has Pinball Playfields, an exhibit dedicated to the history of pinball, with many machines available for anyone to play (given they have the tokens, of course.)

Being at the museum before opening felt very liminal.

On May 3, 2025, our class helped with a workshop all about making Pinbox 3000 kits just like the ones we made for our class, assisted by none other than one of the co-creators of the Pinbox 3000 kit (and founder of the Cardboard Deck Instantute) Ben t. Matchstick. Not only were our kits showcased for people to see, but several other kits made by the Cardboard Teck Instantute team were also present, executing ideas that I wish I could’ve come up with. It was a really pleasant delight to meet with some of the team there and talk with them a bit about the kits that we’ve grown familiar with over the semester.

A cardboard sign for a cardboard pinball table. What an absurd idea.

We had demo tables up just like the ones at Imagine, but this time the Visual Pinball tables we made had a bit more of a highlight. Passers-by noticed the Pinboxes more, mainly due to the concept of making a pinball table out of cardboard. Ben came by and played all of our tables, and having one of the creators of the Pinbox 3000 system compliment your idea and execution for a pinball table was a very nice feeling. Of course, because the Strong is all about play, more children were present, which meant the ever-continuing struggle of making sure they don’t smash in the flippers to the point of breakage. Besides that, both the workshop and our showcases went off without any hitches.

*Storm the Castle!* in its two forms, ready for action at the Strong.

After that, we had the rest of the time to ourselves, so I just went around the Strong Museum and its numerous exhibits (mainly getting some calories burned on the StepManiaX stage) until the others in my carpool group had enough.

Postmortem

Since the Strong Museum workshop was our last real “assignment” for this class, there aren’t going to be any more posts or updates from me here. I’m deciding to use this last post to talk about my time with this class.

I chose to take this class as I was still in need of filling up some free electives, and I had gotten an email from the IGM department in regards to some classes that would be available for the spring semester. Since this email came to me at the right time, I decided to take a look. None of the classes really stuck out to me, save for a class called “History and Design of Pinball”. I think you know what happened after that. I emailed Professor Jacobs, he allowed me to enroll in the course, and it all started to come together after that.

I enjoyed my time putting everything together for this class, from the Skee-Balltelle to both incarnations of Storm the Castle!, and while there were some notable crunch times to get things done (one hour is not enough to get any work done in this class, sadly), I’m still very happy with what came out of my efforts, and it seemed like others enjoyed them, which matters a lot more to me. In fact, it seemed like a lot of people held Storm the Castle in high regard amongst the class’s Visual Pinball tables, which gave me a feeling of solid satisfaction.

This class allowed me to exercise some creativity on something this semester, which was already full of required classes that gave me some significant stress, and honestly just learning about the history of something like pinball is fascinating. If you find yourself needing a free elective and you’re even only slightly interested in pinball, try and sign up for this class. You won’t regret it.

Professor Jacobs also announced his retirement at the end of this semester, so I’d like to wish him the very best in the future, as well as thank him once again for allowing me to take this course.

The Mr. Potato Head tap dancing on the sign for the Toy Halls of Fame will never leave my mind.

Storm the Castle!: Visual Pinball Edition

The original iteration of *Storm the Castle!*, in Pinbox 3000 form.

As mentioned in my previous post about Storm the Castle!, I said that I would be revising the layout I made in my Pinbox Pinball project in Visual Pinball, an open-source pinball engine, with a list of definite fixes for the virtual layout. Just so you don’t have to go back through the other post, what I said I’d be doing is the following:

Move the castle a bit back and have all the bumpers forward, that way it seems more akin to attacking an opposing force.

Add some sort of visual representation for each of the troop types (infantry, cavalry, artillery), perhaps with a little cutout drawing on top/in front of each bumper.

Change how the castle works. I can’t exactly keep the balls stuck in a hole in Visual Pinball, since that’ll result in a softlock. I’ll most likely make the castle a walled-off kicker with a rail being the only way to get into it, but we’ll see once I get started on getting this together.

Changes

I not only incorporated the changes listed above, but I also did the following:

Change the enemy troops from being bumpers to drop targets. This would make the concept of taking out the enemy forces much, much more tangible, since hitting the target would remove them from the board.
- This posed a separate problem of not having much to do once targets were eliminated, so I decided to incorporate another mechanic: Waves. Once you knock out a group of targets (Infantry, Cavalry, Artillery), you would get a point bonus for routing (taking out) that respective group, and they would all pop back up.
- I also decided to have all troops pop back up once your ball was out of play. That way you wouldn’t have to launch a ball into an essentially empty board.
Add a spinner to the castle ramp. That way you still get some credit for hitting the ball up the ramp, even if you don’t actually breach the castle.
- At first it doesn’t give that big of a bonus, but if you can manage to successfully breach the castle, it’ll give you more points. The more you breach the castle, the more points you’ll get.

Design

Thanks to Visual Pinball being a virtual pinball editor, I didn’t have to worry about making the table itself; the engine has a preset for a completely blank pinball table.

The default blank table *Visual Pinball* provides.

The trickiest part of getting the table working was the scripting. While including simple things, like a bumper, drop target, trigger, etc. is as easy as dragging and dropping, Visual Pinball is kinda archaic; if you want to do fancier things, like group targets together or have a kicker hold a ball for a certain amount of time, you’ll need to use Visual Basic scripts to make things work; however, because Visual Pinball has been around for so long, forum posts and really old websites provide a lot of the exact code you’re looking for.

The pinball table in one of its earlier stages.

Thanks to those online sources for making the scripting process easier, I was able to add a lot more functionality than I’d hoped for, including the following:

Incorporating a light that will go out if you hit its respective target.
Including a multiball mechanic every 5 times you breach the castle.
Increasing the amount of points you get every time you knock down a set of targets or breach the castle.
Having an end of ball (Assault) bonus, which would be dependent on how many times you breached the castle or knocked down sets of targets.
- I would’ve loved to have the Assault Bonus show each part one at a time, similar to your typical pinball table after you lose a ball; however, timers were hard to manage and I ultimately couldn’t get it done in time.
Pressing F5 to reset when the game is over.

However, there were still some issues that popped up that were a bit out of my control. These included:

The pinball itself could completely miss the kicker in the castle, which meant that you’d be shafted out of points if this happened.
- I decided to justify this one by saying that cannons won’t always hit their mark; just refine your aim and try again.
Score updating and displaying text representing bonuses (i.e. defeating a troop type or breaching the castle) was wonky.
- This is why there are two separate displays for the score and flavor text; that way, score can be displayed while bonuses are clearly described.
- There’s an issue of how consistently the text updates when you get a bonus, and while that could be rectified with Timers in Visual Pinball, it ended up just not working when I tried to program it.

The first final (oxymoron?) iteration of *Storm the Castle!*, complete with art pass and display text.

Playtesting and Feedback

Unfortunately, I couldn’t get much peer feedback because my table wasn’t in a playable state when we needed to playtest the tables in-class, so I had to improvise with feedback from friends and from Imagine RIT, which is RIT’s signature event for makers.

I’ll talk more about how the Imagine RIT experience went when I talk about the Demo Days, but in short, feedback at the event was overall positive. The biggest critiques were in regards to the lights; the orange and yellow lights had minor issues with contrast when under certain viewing angles. It also seems to be a game in which players are either capable of extremely high scores or super punishing, and there’s not much in-between there.

I’m overall very proud of how things turned out with the Visual Pinball iteration of Storm the Castle!. I’m glad I was able to put in most of the functionality I wanted into the table, and it’s super satisfying to play now.

Storm the Castle!

For my Pinbox Pinball table, I initially wanted to do a magic/wizard-themed pinball table, as the idea of a “Magic Missile Multiball” mechanic sounded really cool. However, as many others had a similar theme they wanted to execute, I decided to pivot to a more general medieval theme; one that would keep the era the same, just with a different overall theme. As such, I went with a castle siege.

Design

The main thing I wanted to implement was a central castle that would be the fastest way to “win” the game. You could only get in via using a ramp to launch your ball into the castle. Alongside that would be supporting forces to defend that castle, all of varying degrees of strength.

The initial concept for the table layout.

The overall playing field was designed to represent the kind of field a castle would be in, complete with a moat to deter any ground invasion.

To fit the theme of trying to attack the castle, I designed the launcher track to have a cannon motif. It’s most likely not 100% era accurate, but I think it works much better than having a top-down view of a trebuchet or catapult.

When it came to building the castle itself, I admittedly had a lack of foresight into the design process; as a result, launching a ball up the ramp into the castle was extremely difficult. Because of this, I decided that getting a single ball in the castle, under any circumstance (whether actually using the ramp or some sort of crazy bumper shenaniganery), would result in an instant total victory. Additionally, I included a crown motif to represent the significance of attacking the castle; with the fall of the castle, the kingdom would fall too.

Around the castle were the bumpers representing the defending forces. Because of how I placed the castle, it was harder to hit the bumpers towards the top of the table (aside from the initial launch of the ball); as such, I made bumpers towards the top of the layout (i.e. “behind” the castle) represent more points. Additionally, I had a very basic score rating based on the amount of points someone got before the game was over, representing how successful your “attack” on the castle was.

The full final table, with rules, scoring, and ranking.

Playtesting and Feedback

Feedback for Storm the Castle! was overall positive. Many people compared shooting balls toward the castle to playing a carnival game; a bit ironic, seeing as my bagatelle table was Skee-Ball, which would fall under similar circles. (Maybe this is a calling for me to design carnival games?)

The main things people praised were:

The visual presentation of the board itself.
- This came as a huge relief for me, as that was easily the most time-consuming part.
- I feel like I might’ve exhausted some of those paint markers entirely…
The use of the plastic chip stacks to represent the bumpers/enemy forces.

The castle was both a point of praise and a point of criticism. While everyone loved the design concept for it, a good amount of people found it placed awkwardly (i.e. too close to the flippers) or hard to play around. Lots of people enjoyed the idea of going for the castle, while others called it too prominent and luck-based.

Other points of criticism included:

Lack of a topper with the game’s name.
- This would’ve been a lot easier to deal with if I hadn’t already used the included one for the Skee-Balltelle.
Balls could get stuck in the launcher, as the exit path was a bit too narrow.
Balls launching off of the table, mainly due to an unintended lip in the ramp.

I’m planning on revising this layout in Visual Pinball, since I think the core idea is still fun and could be improved. What I plan on doing is:

Move the castle a bit back and have all the bumpers forward, that way it seems more akin to attacking an opposing force.
Add some sort of visual representation for each of the troop types (infantry, cavalry, artillery), perhaps with a little cutout drawing on top/in front of each bumper.
Change how the castle works. I can’t exactly keep the balls stuck in a hole in Visual Pinball, since that’ll result in a softlock. I’ll most likely make the castle a walled-off kicker with a rail being the only way to get into it, but we’ll see once I get started on getting this together.

In the end, while there were a few issues that prevented Storm the Castle! from being the absolute best it could be, I’m satisfied with how the Pinbox turned out. I’m glad I could keep the idea intact throughout the design process, and the end result, while not perfect, was still a fun prototype; it gave me the exact steps to take for making it in Visual Pinball.

Skee-Balltelle

Inspiration and Design

Image from Pete’s Game Room:https://www.petesgameroom.net/skee-ball/

When the class was first covering the concept of bagatelle, I noted a lot of emphasis on luck and skill. That was the primary reason I decided to base my Pinbox bagatelle design on Skee-Ball; it’s a familiar test of consistency with a bit of luck involved.

The initial design of the bagatelle board.

My initial idea was to essentially fully adapt a board to be like that of a Skee-Ball table; Have the same form of grouped scoring areas and have people shoot 9 balls, but adjust the scoring regions to follow how bagatelle balls are launched (i.e. up and around from the side rather than just straight below in your typical skee-ball machine).

A few problems arose as I tried to do this:

There would be no holes in which the balls would fall into and return to the player.
The smaller scoring regions (50, 100) would only fit one ball at most, given my initial size drafts.
Following a Skee-Ball layout 1:1 (i.e. having the 100 region off to the side) resulted in being able to score 100s into a trivial task of just launching with as much force as possible.

The revised design for the bagatelle board that would essentially become the final design.

Revisions

These were the things I did in order to fix my initial tests:

Remove the 100 scoring region entirely.
- Since this resulted in a LOT of overshooting, I added some pins at the end of the launcher’s trajectory to allow scoring to be a bit more consistent.
Provide a point bonus to compensate for being unable to fill other regions. If you managed to get a ball in every scoring region, you would get an extra 30 points.
- I did this so that if you get one ball in every region, then scored 30 for the rest, you would get a total of 300 points. This is the exact same as scoring one ball in the 50 and 40 regions and then scoring 30 in the rest.
- It was designed to emphasize that test of luck, skill, or consistency.
  - If you want to be technical, this mechanic makes it more like Fascination, but since this mechanic is optional, I’m still insisting on calling it Skee-Ball.

Feedback and Postmortem

Playtesting feedback went about as well as I had anticipated; the main points of criticism came from how scoring was designed (more specifically, its wording) and its overall visual presentation (or lack thereof.)

Turns out the 30 point bonus I tried to implement was worded a bit too ambiguously; I should’ve stated that at least one ball in each region would’ve provided the bonus.

Additionally, the lack of eye-catching visuals was just entirely an issue on my part. I could’ve definitely refined how the game looked, but with how I drafted the initial project, I backed myself into a wall and couldn’t give the game the visual flourish it desperately needed.

One thing I should’ve anticipated was people having issues with having all 9 balls. Between play sessions, balls would get stuck in the return chute; this resulted in people not knowing that all 9 balls were actually there, and as a result I had a lot of feedback regarding that. It sucked, because I had thought I dealt with this problem while testing it on my own, but it seems it still persisted despite my best efforts.

Another piece of feedback was that it seemed a bit too easy; the balls bouncing off the pins at the end of the trajectory made things too consistent for some people. To an extent I understand this point, but I also choose to believe that the person who said this just managed to master the game better than I did, since I don’t think I could keep things that consistent throughout my numerous tests while prototyping.

If I went back and revised things, what I would focus on would be the following:

Visual polish, obviously. The game was very visually basic and on a paper white background.
- I’d try to make the colors more akin to a real Skee-Ball machine, but I’d first need to find a consistent color scheme for it, because even the official machines seem to lack that.
- I’d also like to make the marquee a bit better. I don’t think I did a bad job at emulating the Skee-Ball typeface when making the one I currently have, but it just lacked color.
Using holes for the scoring regions. This would eliminate the need for 9 balls and also make it so scoring in the same region multiple times was possible.
Trying to actually implement a 100 point scoring region. The game’s score is woefully small because of the limitations of the current board, and the game didn’t feel quite right without the high-risk, high-reward that the 100 hole provides. I’d have to spend a lot more time in prototyping to figure out where it would work best.