The Incredible Machine and a Billiard Ball Computer

By Kevin Ryan

Posted on August 9th, 2016

The Incredible Machine (TIM) is a computer game released in 1992 that is driven by custom physics and is very similar to Rube Goldberg and Heath Robinson machines. There were a few games in the series and it got a surprisingly large and loyal following. We won an “Honored Developer” award at the 1993 Game Developers Conference for it which I think was the first year that they gave out any sort of awards. I think I still have it somewhere – it was a pin or something like that. Later on TIM was inducted into Computer Gaming World’s Hall of Fame which was a very pleasant surprise.

TimTitle

Oh this looks neat!

In the summer of 1992 when I was partway through implementing the original group of parts in The Incredible Machine, I read about Edward Fredkin and Tommaso Toffoli’s Billiard Ball Computer. Roger Penrose also discussed it in his book The Emperor’s New Mind which I was reading at the time. Along with a technical description it had a nifty graphic showing a billiard ball model for an AND gate similar to the one pictured below.

bbc

Modeling an AND gate with Billiard Balls

Wow, that would be cool to implement! I realized that I already had the basic physics and collision frameworks in place and I could implement the needed parts in TIM without too much effort. Walls, incline, and balls were already working. Finding enough free time before shipping would be the constraint on whether I could get it done in time by the ship date or not. TIM had a very tight development schedule.

Coding The Incredible Machine

Coding on TIM started on March 26, 1992. I know that exact date from the title page of my design. On the day that I finished the design, I wrote the date on the title page, printed it out, went “whew, finally” and then immediately started coding in the unheated and unfinished basement of my home in Eugene. Note: this was not my parents’ basement – I was married and had three young kids at the time. Once I week I’d walk over to Jeff Tunnell’s office with the latest build on a floppy disk and show the build to everyone.

The Incredible Machine Design

Title page of the original design.

Collision System

The first order of business when I started coding was getting a collision system in place. No Google, no big Internet search space, so I ended up writing the collision code from scratch. I decided to go with polygon borders for all the parts. Everything had to be integers because at the time the speed of floating point operations on CPUs was slow.

The conversion factor for the 16-bit integers was: 1,024 in the physics space was equal to 1 in the screen space. A shift of 10 bits left or right would convert between the two coordinate systems. The 360 degrees of a circle were covered by 16-bits and went from 0 (0 degrees) to 65536 (360 degrees). In hex it came out as: 0x0000 flat facing up, 0x4000 vertical on left, 0x08000 flat facing down, and 0xc0000 vertical facing left.

All the parts collision shapes were defined by polygons which could be either concave or convex. The collision checks were line segment to line segment – projecting each point of the polygon to where the new position would be based upon the velocity, creating a line segment, and checking for collisions with other polygons. If a collision was found, then the projected line would be adjusted to the point of first collision.

As an aside, there are now terms for most all of this stuff which in many cases didn’t exist at the time. Lots of ad-hoc development here – making it up as I went along. So the segment-to-segment check would be what is now called swept collisions. There was also a broad-phase collision check. The way collisions were implemented allowed me to do a bit check on the high bit and reject roughly half the checks – less calculations – important because frame rate was a big concern. The fastest code is the code that isn’t executed.

The collision polygons for the Balloon and Birdcage became my debug test cases. I created graph paper version that exactly matched how they were represented in the game data. I would move the paper cutouts around by hand in various collision scenarios to verify that the code was working correctly. The hex values in the balloon and birdcage photos are the slopes of the line.

balloonAndBirdcage

Balloon and Birdcage. Testing models and how they appeared in game.

Physics Code

Written in parallel with the collision code was the physics code to apply forces to resolve collisions. Every part was a point mass with some parts being static and some dynamic. Each part had a density, mass, elasticity, friction, terminal velocity, and various other parameters. Sir Isaac Newton wrote the physics code for me roughly 300 years before TIM. I just had to put it in modern C code and make it fast and use only integers.

The structure for how the basic properties of the parts were defined is listed below. (Ugh, I don’t like the code style I used back then). Those last elements in the struct are function pointers. They pointed to general routines for the parts and I would override them with pointers to specific functions for parts that needed them. TIM was written in C and this is similar to overridable methods in C++ although I wasn’t familiar with C++ at the time.

struct part_elements
{
   short          density;
   short          mass;
   short          elasticity;
   short          friction;
   short          acel;
   short          terminal_velocity;
   TIM_VEC        max_size;
   TIM_VEC        min_size;
   struct shape   **part_shapes;
   SSHAPE         **super_shapes;
   TIM_SCVEC      *shp_offset;
   TIM_VEC        *shape_size;
   unsigned char  plane_num[2];
   short          num_borders;
   short          part_bin_order;
   VOID_BPARTFPTR bounce_func;
   VOID_PARTFPTR  internal_func;
   VOID_PARTFPTR  reinit_func;
   VOID_FPARTFPTR flip_func;
   VOID_PARTFPTR  resize_func;
   VOID_RPARTFPTR rope_func;
};

 

So Where is the Billiard Ball Gate in TIM

Short answer: It’s not there. I ran out of time.

Slightly longer answer: I really wanted to make an adder just like the picture below instead of just making an AND gate. Defining the elasticity and borders needed for the billiard balls would have been very quick and easy, but getting all the parts lined up correctly even for just the simpler AND gate would have been more time consuming than defining the needed parts.

adderCircuit

Diagram of an adder circuit.

Game Dev Weight Loss Program

As best as I can remember, we shipped the first version of The Incredible Machine in mid-November of 1992. I remember that at the time getting to gold by mid-September was important for the Christmas season. Big orders by the distributors and stores were being made in September and then they’d duplicate a whole bunch of floppies and print up all the boxes. There was a lead time for all this so we would usually be shooting for mid-September to have a gold disk ready for shipment. It was a very bad thing to have bugs in the shipping floppy disk version because there was no simple way to get out an update.

So the summer of 1992 was a mix of implementing all the parts, tweaking the collision and physics code, and creating all the puzzles that would ship with the game. Creating new puzzles started becoming harder and harder. I was very busy and over that summer my weight dropped from 155 to a little below 140. It was fun! Really! I wouldn’t still be doing games for all these years if it wasn’t fun. But it was tiring too. Near the end of TIM development I started referring to it as a 6 month sprint.

TimPuzzles

Some of the puzzles from TIM. I would go through them all and reorder how they showed up in game to gradually increase difficulty for the end users.

I just played the first version of TIM for the first time in a long time – a very long time. I had to buy it from the Good Old Games website because I don’t have a running copy here. I see that Billiard Balls aren’t even in the first version, but they did make it into the “Even More’” version where more parts and puzzles were added. And they aren’t affected by gravity and are perfectly elastic so they had the correct physics attributes to implement the AND gate. But they would have still needed work to give each of them the exact same initial velocity when entering the gate and then there would have been lots of tweaking of position to get them working correctly.

Over the last year few of years I’ve been working on Contraption Maker with Spotkin. It is published on Steam and we continue to make updates for it. There is a different publishing paradigm in place. Now it is easy to do updates seamlessly to the end user. A Billiard Ball Computer is on my to-do list for Contraption Maker although the physics system being used would make it just a little harder because it doesn’t use swept collisions. Maybe someday in an update I’ll get it in there.

More Reading:

Conservative Logic a paper by Edward Fredkin and Tommaso Toffoli.


My Game Prototyping Process – Puzzle Poker

By Kevin Ryan

Posted on June 24th, 2016

A Quick Note

A quick note before starting in about my game prototyping process… I’ve added this email widget thing that I can use to notify you when future posts are made to my blog. I’ve written about 80% of the next post which is about the early concept and development of The Incredible Machine. Enter your email over there to the right if you want to get notified when future blog posts are made. ——>

Getting Started with a New Game Engine

Quite a few years ago Jeff Tunnell and the folks at Garage Games gave me a copy of Torque Game Builder (TGB) so I could take a look at it and try it out. I then spent a few days creating a game prototype that I knew my son, Aidan, would enjoy. Digging in and finishing a little game prototype is a good way to get familiar with a game engine. That first prototype after a whole lot of work eventually became a game called Buggle which was released for the iPhone. It’s not currently available, but we may release an updated version of it someday. Here is what it looked like:

iPhoneBuggle

Game Play

After this first prototype to get familiar with TGB, I then started work on the idea I had for Puzzle Poker. I started work on a Wednesday afternoon and by Thursday afternoon I had a prototype that played very much like the game in its current form. Here is the main game play screen of that very first prototype:

prototypeGameScreen

I did all the art myself and really didn’t care what it looked like. It just needed to be roughly the correct size and convey the correct information to the player. At this point in game development I am only concerned with the game play. I can see in my mind how the final artwork will look, but there is no point in spending time and money getting awesome artwork created if the game itself isn’t fun. I am very good at quickly drawing bad artwork.

As a comparison here is how that exact same screen looks as of today in the game:

ppGameScreen

That wonderful artwork was created by Alex Swanson. If you look between the earlier screen and the current one you will see lots of the same information. Besides the real artwork the layout has also been changed to make it more user friendly. I am still not 100% happy with the layout and especially the wording and it’ll be tweaked and changed as we move toward final release. Design is a very iterative process as we craft everything to be as smooth and polished as possible. Making fun can be hard work.

Menus and Flow Between Screens

Along with prototyping out the game play, I also immediately hook up the flow of all the game menus. Many of the screens will just be stubs with only buttons that hook the various screens together. This gives me a way to quickly see how players will move between screens and make sure that everything moves smoothly for the player. Here is the main menu screen for that first prototype:

prototypeMainMenu1

On this screen each of the different buttons would take the player to a different screen, most of which had nothing more than a simple placeholder screen shot along with a return to main menu button. The play button would launch the game. Note the “Howdy” above. Originally Puzzle Poker was going to have a western theme – that went away over the course of development. Oh, and also at this point the game had a placeholder name of “cards” and the actual name wasn’t decided upon until much later. Again at this point in the development, the menus and flow between them, functionality takes a front seat and the look is very secondary. I usually I have a pretty good sense in my head how it’ll finally look, but that is not important at this stage of development.

For a comparison here is how the main menu in Puzzle Poker currently looks and works:

ppMainMenuCurrent

The exact same choices for the player are there, but it looks quite a bit different from the original quick prototype version. When I got around to implementing the GUI for all the different menus screens I decided to come up with a custom solution instead of using Torque’s built in GUI. I used sprites for each of the different choices and had them change size and rotate slightly when the mouse was over them. This gave a little more dramatic look to all the screens and also fit the overall game theme better.

Thanks Mom

One change you’ll notice between the prototype of the game play screen and how it currently appears is that there are now hint buttons present. My Mom got hooked on the game. When I first installed it for her, I was standing there giving her hints on how to play, telling her things like “try moving that card from here to there.” It occurred to me that I should put that in the game as a hint system. Someday I’ll write about how I implemented it. And that same hint system can be used for computer AI if I implement head to head play with computer opponents.

It is a good thing to watch inexperienced people play your game. You can see where the faults are, what isn’t obvious, and also come up with new ideas to make it better.

 

Steam Greenlight and Kickstarter

Puzzle Poker is currently on Steam Greenlight and also on Kickstarter. We’d really appreciate a vote for it on Steam if it is the sort of game you’d like to play. Just click on the graphic below:

greenlight

 

If you’d like to support us on Kickstarter click below to go to the Puzzle Poker Kickstarter page:


A Good Egg Named Alice – Physics and Design of the Egg in Contraption Maker

By Kevin Ryan

Posted on May 16th, 2016

aliceEgg

Alice rolls down next to Eggclops.

One of the parts in Contraption Maker is an egg. I’m going to write just a little here about its gestation and implementation.

I was looking through some old emails and chats to refresh my memory and found the chat listed below. The egg was originally going to be a breakable ball, but I decided to make it an egg instead.

eggChat

I thought that an egg would have more whimsy and character than a ball. It is obvious what it is to the end user and it is also very obvious that it is fragile. In addition to that it also has a different rolling motion than a ball has which gives the opportunity for more variety in the puzzles created.

One thing that I wanted to do to give the egg more personality was to have multiple versions with different names. And each of them also had a different look so they looked better and would give a more varied look on the screen than just a single white colored egg. Here are all the eggs along with the pop up window that lets the user select which egg to use.

cmEggs

Current batch of Contraption Maker eggs.

One other nice side benefit was that I was able to name the eggs after friends and acquaintances and let them be in game – if only as a egg. Once I had the egg implemented it seemed only natural to have it attract the dog Tinker if it broke.  Once you’ve added a new part then suddenly more possibilities open up about how it can interact with all the other parts in the game. As you add more and more parts you end up with a rich cacophony of interactions between them all.

Here is a short animation of how the egg attracts the dog when it breaks.

dogEgg

If you look underneath the hood you’ll see that this is accomplished by a method in the egg class that is called when any other part sees it. If the calling part is a dog then the egg returns the dog attract info, otherwise it returns NULL which means no attraction.

CMPartAttractsInfo *CMPartEgg::getAttractsInfo(CMPart *part)
{
    if (mCracked && (part->mType == PART_DOG || part->mType == PART_SCAREDY_DOG))
        return &sDogAttractsInfo;

    return NULL;
}

This is the structure that is returned to let the dog know how attractive the egg is to it. Since the dog may see multiple other items besides the egg, it is up to the dog’s AI to take this attracts info along with any other attracts info it gets from other parts and then figure out what to do. (I’m formatting code below to look okay within this blog post.)

// Constructor for the attracts info returned
// - Att postfix is the attracts values
// - Rep postfix is the repulses values
CMPartAttractsInfo(
   int minDistFrontAtt, int maxDistFrontAtt, int minDistFrontRep, int maxDistFrontRep,
   int minDistBehindAtt, int maxDistBehindAtt, int minDistBehindRep, int maxDistBehindRep,
   int priorityAtt, int priorityRep,
   bool canLookBehind, bool shouldRun, bool edible,
   int repulseHighPriorityDist=FLOAT_TO_INT32(50))

// The attracts info for the egg attraction for dog
// Only attracted to eggs in front of it that aren't more than 230 units away
static CMPartAttractsInfo sDogAttractsInfo(
   FLOAT_TO_INT32(0),FLOAT_TO_INT32(230), 0,0,
   0,0, 0,0,
   ATTRACTS_PRIORITY_ONE,ATTRACTS_PRIORITY_ONE,
   ATTRACTS_CANT_LOOK_BEHIND,ATTRACTS_SHOULDNT_RUN,ATTRACTS_EDIBLE );

One last thing on how the design evolves. These are all “good eggs.” If there are “good eggs” then shouldn’t there be “bad eggs?” It is on my internal list of parts to someday implement. Bad eggs would be smelly and repulse lots of other creature/character parts.

In closing here is the code that implements the egg:

CMPartEgg.h

CMPartEgg.cpp

 


Collaboration and Trust in Work and Life

By Kevin Ryan

Posted on May 6th, 2016

This is going to be a very short post about what I was just thinking about while taking a short 25 minute walk along one of the trails near our home just now. I got a email this morning from my long time friend and off and on work colleague Jeff Tunnell. It had a few suggestions about making my blog better from the titles of the posts and also about the content. Some of what he wrote echoed what my wife had told me the other day. Now I’ll definitely be doing some of his advice, maybe not all of it, but I’ll sure consider all of it.

So as I was walking along through the drizzling rain we are getting here right now, it got me thinking about collaboration. Jeff felt comfortable sending me suggestions along the lines of “hey here’s what you can do a little better” and I was fine receiving them. I think that is the result of long time collaboration that has built up trust. Although I think our personalities are such that it was probably there almost from day one.

I’ve been blessed over the years to work with a whole bunch of talented nice folk. Two of them were Jeff and Damon Slye who were at Dynamix with me as co-owners. They started it up. As I walked along thinking about how people interact in good and bad ways, what popped into my mind was this one scene in a game that Damon and I had planned for David Wolfe: Secret Agent. Somewhere along the line as development progressed, Damon told me that Jeff was really uncomfortable with the scene and preferred it didn’t go in there. Not “Jeff says take it out.” It meant a lot to Jeff, we took it out.

I’m thinking that is one reason Dynamix did so well, because there was mutual respect and trust. Oh, it did help that Jeff and Damon are super talented, basically the best at what they do. But it seems that there needs to be more present than just that; and our willingness to listen, change, and improve – collaborate in a good way – made the sum greater than the whole of its parts. And now here I am collaborating with Jeff and his latest company, Spotkin, on a game (Contraption Maker) over 30 years after we met. And my son is working with Damon at Mad Otter Games on their Villagers and Heroes game.