Puzzle Catcher is my best work so far, and I’m very proud of it! Come take a quick tour of the studio and see some of my sketches, notes, prototypes, and behind-the-scenes tools.
A little background: I’m a game coder from the 1990’s, and I’ve decided that I want to write game for the rest of my life. Every decision I make is in preparation for the creation of my masterwork creations many decades from now. I tend to write games as if I’m building a nuclear fallout shelter… using the most reliable, hardened, and easiest to maintain technologies. (That would be C/C++ for maximum portability and all the speed you’ll ever need.)
Here are a few pictures of my studio where I invent stuff every night:
Up the Stairs
I work above my garage. I’m big in to retrocomputing, so there may be a few Commodore Amiga computers laying around for tinkering and inspiration. I should bring out my Commodore 64’s soon.
The Big Screen
We write games that support mobile devices, but I primarily work with a touch screen laptop running Windows. I prefer editing my code on the laptop screen, and then running the game on a 55 inch TV. This helps me see every pixel! If I could afford a 100 inch TV, I would buy one. (That would make it a lot easier to see “every pixel” at 4k resolutions)
The Amiga Corner
Scorched Tanks is the first game I ever released way back in 1993, and it’s running great on this Amiga 500. My trusty Amiga 1200 is off screen, and that’s where I can be caught playing Megaball AGA from time to time.
The Books That Built Puzzle Catcher
These books served me well during the creation of Puzzle Catcher. The quilting book “Color Play” taught me about color theory and patterns. “Computational Geometry in C” and “Graphics Gems 3” had algorithms on various ways to slice and dice lines and polygons. Books about M.C. Escher and tessellating patterns were hugely influential in creating tile sets and board designs. And to write my new User Interface (UI) framework, I had to bring out the “big guns” for programming a system that is 100% data-driven and supports scripting. (Lua is awesome!)
Tacking on the creation of the Zoom framework caused this humble six month project to turn into a four year adventure. However, it was also a once-in-a-lifetime opportunity to write the technology that will keep my games working great and looking razor sharp in the distant future. Writing your own game engine in C/C++ is a serious commitment, but it’s safer in the long run than just buying an engine off-the-shelf.
(CAUTION: New developers first need to make a name for themselves with any tool they can find. The “long run” is for after your games start to “capture lightning in a bottle”, when it’s worth looking at 10 to 20 years down the road. I’m already there, so your mileage may vary.)
In 2014, I finally had the opportunity to create a prototype for the game I had been dreaming of during the development of Super DX-Ball. It took me 10 years to finally take the plunge.
Super Puzzle is Born
Using a ton of technology lifted from Super DX-Ball, I threw this game prototype together in a few weeks. (level editor, brick collisions, brick falling code, etc…)
Too Many Screen Sizes These Days!
Up to this point, we were able to tweak Pocket Tanks to look good on all the latest iOS and Android devices. It wasn’t easy, but we managed by manually adjusting everything every button to all the wild new device resolutions. But if we were going to make new games, and easily update Pocket Tanks in the future, we needed a fully modern UI framework that can handle every resolution. Enter Zoom, the BlitWise in-house UI framework.
Somehow this simple game idea turned into the poster child for a huge engine technology upgrade. If I had known that Zoom was going to take 3+ years to create, I might have never started writing the game! The trouble is that there are simply no open source UI frameworks for plain old C/C++. After exhaustive research, I decided that a combination of QT’s QML language and World of Warcraft’s XML/Lua modding framework sounded just right for us.
Zoom Lives!
This doesn’t look like much, but it took me a year just to get this far. Writing an entity-based engine that is similar to the latest and greatest tools like Unity3d is very exciting work, but deeply technical! It’s fun to write this kind of stuff, but wasn’t I supposed to be writing a game? It’s hard to be a jack-of-all-trades game programmer sometimes.
Interns to the Rescue
After a year of working on Zoom, I invited some talented students to visit the BlitWise studio once a week to help me test out the new Zoom system. No C/C++ compiler was needed, just a text editor and the ability to edit .xml and .lua files. We made silly demos like this “Bubbles” example. Here, Lua code is attached to each bubble object causing it to wobble and float to the top of the screen. This is a radical departure from my typical 1990’s C/C++ “hard code everything” style.
It’s often a bad sign when game developers start writing tools instead of games all while quoting Carl Sagan’s famous line, “if you wish to make an apple pie from scratch, you must first invent the universe.” I definitely fell into that trap, but eventually there was enough of the Zoom finished so that I could start writing the actual game. So I rolled up my sleeves and got back to designing.
Start With The Logo
For some reason, I can’t take a game project seriously until is has proper logo and title screen. It’s like I need the logo to anchor my mind and set the tone for the rest of the project. As you can probably tell, these early sketches were not doing it for me. I really needed a name that I liked.
Getting Close
I was looking for something with a demoscene vibe, and this lettering fit the bill. The triangular curved tiles on the bottom helped hint at the gameplay as well as give it a sporty & energetic look. I was still trying to sneak “Catcher” in there somewhere. This was close enough, so it was time to bust out Blender3D and make it come to life.
Time to Make the Title Screen
With a proper logo designed, a title screen sets the stage for the entire game. This is pretty darn close to exactly what I made for the final game.
Early Game Screen Sketch
Originally I wanted the “tumbler” on the left to be a GameBoy-like sci-fi device that projected the “hologlass”, a solid holographic display, on the right. I worked hard on several graphical effects to sell that idea, but mobile devices just didn’t have that kind of horsepower back in 2016.
With a mind full of ideas, a notebook full of sketches, and even some finished artwork, it was time to start getting stuff on the screen!
Super DX-Ball’s Level Editor Saves the Day
Back in 2003, It took me a year to write TEdit, the level editor for Super DX-Ball. TEdit is perfect for exploring the possible tile sets and also making the board packs. This is “Happy Frog” from the Brilliance Pack.
Filling Things In
To create a board, I use the tiles to draw a level. Later on, when loading the board into the game, I use various algorithms to punch out that hole where the tiles were placed on the screen. When playing Puzzle Catcher, all you see is an empty shape where you can place any tiles that you like. This is the “Fiery Steed” level from the Fire Diamonds Pack.
Beautiful Patterns
Often I create board packs with recognizable objects and catchy names that are easy for players to remember and talk about. But towards the end my level design efforts, I took a chance and made levels with more abstract patterns that are inspired by quilting. My wife does not quilt, but this is her favorite pack! This level is “Around the Clock” from the Rolling Stars Pack.
Dreams Come True
This was the first time that the Zoom framework was used in a real game. We had a few bumps and bruises along the way, but this technology makes quick work of UI that look great on iPhone3G, iPhoneX, iPad Pro, and the Android device flavor of the month.
Putting It All Together
After several years of combined engine and game work, it all started to come together in 2017. Here you can see the sketches and board designs come to life.
In the final analysis, I should have had a team of 8 people to complete this game in 6 months as originally planned. Some folks would say that I tried to boil the ocean by making my own UI framework. It was more like I tried to boil a swimming pool, but I got it done eventually. Writing your own game engine from scratch is not for the faint of heart, but it is the best way to gain mastery of your tools. If you switch tools/languages/engines every 5 years, the you will always be a generalist and will eventually fall behind. If you want to be writing games for your whole life, then you should consider crafting your own tools and start crystallizing your experience today. When you actively enhance the same code base over a long period of time, that’s better than starting over and over with someone else’s frameworks. Who says that their ideas are better than yours anyways? Be bold!
Puzzle Catcher was a pleasure to make, and it’s built to last. I’d be honored if you would download it today and give it a try. If you would like to chat with me about this game, or any of my other game projects, then come visit our BlitWise Games community forums. See you there!
