TYPE HELP

I made a game for the NG Flash Forward Game Jam!

Here's some background about the genesis and execution of the TypeHelp game:

I recently read a bunch of books about game designers which got me thinking about my default game-design approach. My buddy shared this quote about writing from the Game of Thrones author:

“I think there are two types of writers, the architects and the gardeners. The architects plan everything ahead of time, like an architect building a house. They know how many rooms are going to be in the house, what kind of roof they're going to have, where the wires are going to run, what kind of plumbing there's going to be. They have the whole thing designed and blueprinted out before they even nail the first board up. The gardeners dig a hole, drop in a seed and water it. They kind of know what seed it is, they know if planted a fantasy seed or mystery seed or whatever. But as the plant comes up and they water it, they don't know how many branches it's going to have, they find out as it grows. And I'm much more a gardener than an architect.”

― George R.R. Martin

My "default" game design approach is much more "gardener" than architect. I've never really built a "level design engine," but tend to fly by the seat of my pants. This can make some pretty fun games that have surprising twists and turns, but I wondered what it would be like to be more "architect"-y about my design.

One of the books I read was about the history of Sierra Online and had a neat section about how Roberta Williams was very interested in text-adventures when they were the newest, freshest, thing. She didn't have any coding ability, but wanted to make one herself. Her husband, Ken, was a coder and wrote an "engine" that Roberta could use to fulfill her creative dream. In the book, Ken outlines some of the design approaches he used to make the text adventure engine (their engine was actually the first to combine rudimentary graphics with the text).

When I heard about the Flash Forward Jam, I wanted to do something experimental (not my typical action-game fare). I decided to try my hand at making a flexible, text-adventure engine. I wanted to make everything "text based" as a fairly significant design restriction (so it would feel like what you might see if you went back in time to early 80s computer hardware, but somehow, miraculously, had the easier internet access of today). One reason for this is that Ruffle doesn't have great text rendering and text-editing support yet, and I thought doing something ALL IN TEXT would be a fun challenge to address and be impressive to anyone familiar with Ruffle's limitations.

This text-only (no graphics, flowcharts, wireframes, or even drop-down menus/form elements) restriction, led me to settle on a command-line-like terminal interface... a-la Linux or DOS.

I put most of my development time into making the command-line-interface (CLI) very robust and enabling lots of flexibility in what it allowed the user to do, game-structure-wise, using the engine. I also decided, early on, I wanted to enable people to create and share their creations via the same CLI.

At some point, I decided it would be really cool, and "meta" to obscure the game engine within a text-based narrative. This way, the player would think "oh I'm just playing a text adventure game", then be slowly led to discovery of the CLI and, in fact, be forced to use the CLI to complete the "baked in" text adventure. I had recently re-watched "The Matrix" and wanted to try capturing that "the world around you is a sham" feeling, and the "you are actually a GOD here if you learn the right tricks" feeling.

In the end, the real design challenge was how to have the baked-in game fun and engaging and intuitive enough, while also slowly revealing the CLI, and not just DUMPING a HUGE game engine on the user all at once. For the record, I don't think I solved this design problem very well...

Most players just skimmed and bounced off the surface of the game, never realizing the real "meat" underlying it all. Those that did discover it, felt it was too cumbersome to use very intuitively. I attempted to help resolve some of these concerns by implementing a JSON export and import feature, but even that is probably too esoteric for the average player.

If I would have allowed myself to use graphics, and showed a flowchart of "rooms" and the various kinds of objects and their linkages (and let people click into nested object structures and edit them in a smoother navigation structure), I think it would have gone a long way to helping people get more immersed in the creative side of the game.

I only ended up with a handful of "user-submitted" adventures, even though I expected a lot more when I first launched it (I set up a website and server and everything to support my predicted influx of games... http://typehelp.org). WOMP WOMP...

Overall, though, I'm really proud of what I made and of myself for taking my personal challenge to be more engine-focused and "architect-y" to heart.

The recently-submitted game "B"-Al-Zebub's Rest Stop is a fantastic example of the kind of adventure game I was hoping people would make with the engine. If you want to check it out, load up the Type Help game and type:

cmd web play 5

I still hope that there will be a day, in the future, when the stars align for the right people to uncover what the game offers and get excited about it... kind of like how "Frog Fractions" took some "soak time" for people to really "get it."

MY GAMES ARE NOT DEAD

In really good news, Ruffle has made lots of progress on as2 support, and pretty much 100% emulates, in-browser, all of my as2 games. Most important to me is the ability to play Abobo's Big Adventure (since that is, so far, my magnum opus):

For the Abobo 10 year anniversary this coming January 2022, Rog, Pox, and I are going to get together and record a video of us playing through it with "Creator DVD Commentary" and put it on YouTube.

But also important to me is Portal Defenders:

I made a little video of the Portal Defenders ending as emulated in Ruffle to celebrate:

AXE AUTO-DETECTION SOFTWARE

I decided to revise my axe-gaming web-socket system to use RUFFLE as the rendering engine. I was going crazy hand-coding animations in HTML 5 for the axe games, so when I started fantasizing about using Flash to do all the animations and FX, it was just a pipe dream... then RUFFLE!

I've done tons of testing, and I officially believe that everything I need to do for the axe games can be done via Ruffle. Most-recently I tested Ruffle's support of as2's "External Interface" API - which allows Javascript commands to call functions within Flash and allows Flash to call Javascript functions on the page containing the swf embed. Here's a demo of all that working: https://usaxeclub.com/test/

Importantly, this means our games can step up to a more-modern standard of game visual FX and animation.

In other great news, my business partner has been working on a system to very precisely detect where an axe hits our projected targets using Python and MACHINE LEARNING AI MODELS!!!

I set up an API to send the auto-detection data through the web-socket system, and it's actually working! This video shows an early test where the lag was significant, but currently the "lag" is down to about 500 milliseconds, which seems near-instant.

This is opening up a lot of axe game possibilities... including DUCK HUNT (with axes)...

The Portuguese "national" tv service also did a report on our store!

My day job as a software developer has given me a lot more confidence in trying new things with code. Now that Type Help is in-the-bag, I'm turning my focus back to the Castle Crashing The Beard HD Reboot project, which is insanely close to being done... keep an eye out for that later this year.

Overall feeling pretty good about everything. I hope 2021 has a lot of good things in store for me, and YOU!

Thanks for reading, leave me a comment about what you're excited about in 2021!