Main menu

Main menu

Mining screenshot without filled textures

Mining with unfilled tiles, or…

Mining screenshot with filled textures

Mining with filled tiles?

Placeholder shopping menu

How the “Art Deco” aesthetic currently manifests itself in the shop.

Flying around the solar system

Flying around the solar system

I’ve been working on a game for a bit now. Its working title has been “Blocks in Space” (BIS), but I won’t be using that since it’s already in use by someone else. Sad.

In the hopes of getting some feedback, I’ll go into some detail on the current prototype. (Well, prototype-oid. It’s heavier than a prototype ought to be, but I hope that it will serve as a platform for many small prototypes.)

BIS arose out of a fairly simple premise: “What if Tetris had gameplay more like ‘mining’, and you got money/experience from clearing lines?” From that seed grew a fairly complete game idea… probably irresponsibly complete.

The Art

Along the way I got bored with the standard space game UI elements and decided I’d try, somewhat arbitrarily, to try utilizing an Art Deco aesthetic. This post and prototype is as much about that aesthetic choice (and whether it works at all) as it is about the gameplay. You may notice it’s not bursting at the seams with art deco-ness, but that’s an on-going effort.

In general, I’m aiming for strong geometric shapes and lush/opulent colors. Most of the colors you see here are taken from either the real colors of the metal (e.g. copper is properly copperly colored…ly), or from various famous Art Deco pieces. I’ve drawn inspiration from artist Tamara de Lempicka, stark geometric line art, posters, as well as architecture and product design from the period.

Making good use of this inspiration with my meager art skills has been challenging, but enjoyable.

The Game

The gist of the game: You’re the proud owner of a rusty, barely spaceworthy, new-to-you spaceship. Your ship is equipped with various stations, each providing unique space-y functionality. Using this functionality you explore the stars, seeking your fortune. Then, you spend that fortune upgrading your equipment, hiring crew members, battling hostile ships, etc. All this you do in pursuit of pieces of the “One True Block” (OTB). (trope incoming) ~The OTB fractured centuries ago, scattering around the galaxy. Legends say that reuniting the pieces will grant wondrous powers to whomever possesses it.~

Your ship’s functionality is manifested in various block-placement puzzle games (described below). You access them from an abstract main menu, which you can see to the right. The pattern behind it is an animated homage to Earthbound’s psychedelic backgrounds, though with concessions to match the art deco aesthetic.

Currently under consideration, in addition to the core “block mining” mechanism, are quite a few other puzzle minigame “modes” representing the different things you might want to accomplish. These modes are broadly split into three subsets of gameplay, depending on how the “block field” works.

1D (playfield is a long cylinder, as in classic Tetris)

  1. Mining: You can mine a planet/asteroid/moon(/star/black hole?) you’re orbiting for fun and profit. Most similar in feel to classic Tetris, but you dig downwards, have some special abilities, different block shapes, etc.
  2. Warping: While warping between locations, you encounter various obstacles. Asteroids/comets, gravitational distortions, etc. Clear lines to pass these obstacles.
  3. Mimic: A 2-player social game played against NPCs in bars. Each round, one player starts by solving a block puzzle in a certain way. The following player then must attempt to duplicate the first player’s solution as much as possible, not knowing the block spawn order.

2D (playfield allows freeform placement on any side)

  1. Tinkering: Gradually upgrade equipment you acquire by playing 2D tiling puzzle similar to tangrams, using your available block shapes.
  2. Training: Rather than simply applying skill points, your success in a tiling puzzle determines the magnitude of skill growth
  3. Tactics: Positioning your ship correctly in battle is important. In the tactics mode, you place your spawned blocks on a set of possible battlefield locations. At any point you can activate one of these locations, your ship then traveling to it and benefiting from various bonuses based on how well-formed that location was prior to being activated.
  4. Tractor Beam: Gather materials by placing enough blocks around small floating rocks to pull them in

Circular (similar to 1D but the playfield rotates, either ‘around’ you, or you sort of ‘orbit’ the playfield)

  1. Scanning: Uncover new locations to travel to, map out threats in space, search for pieces of the OTB, find jump gates, etc. This is a “circular” puzzle reminiscent of radar sweeps, requiring skill in rhythm and timing in addition to the classic block placement skills.
  2. Battle: (these may get merged into one mode with both goals)
    • Shields: Ships have shields, circular block fields around the ship, which you must repair as they are damaged by placing blocks. Your goal here is the opposite of normal block puzzles: you want to create the most obnoxious field possible so that your opponent has trouble getting through your shield.
    • Turrets: To damage the enemy ship, you must clear lines in the shields as you would when mining. Your goal here is to overwhelm your opponent’s shield reconstruction effort, by choosing which weapon to fire when each line clears. Different styles of line clearing interact with the efficacy of each weapon type.

These modes are somewhat overwhelming, especially if all of them made it into the same product. To that end, one of the neat-o features (IMO), well-aligned with SRG’s mission, is that the NPC crew you hire will be able to play any or all of the modes for you. They will develop skill in each mode, improving their performance there. So if – perish the thought – you find a mode’s gameplay unpleasant, you don’t have to forego the benefits of success in that mode. You can task one of your crewmembers with getting really good at that mode, and just forget about it.

Essentially, each mode can be active simultaneously. You’ll get reports periodically about how your crew is doing, including any unusual outcomes, and otherwise just get to reap the benefits of their hard work. Nifty.

Stay tuned for more details on, y’know, everything!

Demon wrestling is part and parcel of the indie dev life. Lately I’ve been meeting the following three in the ring:

  1. Being too close to your project makes them, paradoxically, hard to see. Changes seem miniscule (progress feels more stagnant than it is). Clear flaws are overlooked.
  2. Finding the local peak in your game’s designspace takes time. Gathering feedback from extensive testing is slow. Slower still is the feedback processing by your subconscious mind.
  3. Project velocity is “feast or famine”. States of flow are fickle. More often, your game is your Sisyphean boulder.

I’ve hatched a ridiculous plan to best these demons. Years from now, remembering this plan will likely force a cringe, but the sweetest fruits aren’t found on the well-trod paths.

The Plan: Game creation is a pipeline (think GPUs).

Made concrete: More games under simultaneous development. Code quagmires and demotivation will be met not with grit but with give. A given day may yield greater leverage on another project, and free of deadlines or external demands, that’s where I’ll go. Additionally, in those foggy hours where I can’t code, I may still be able to productively test, or draw, or do some other mentally orthogonal task. Victory.

Clear downsides:

  1. Nothing ships until the pipeline gets filled.
  2. What hype a game may find could die in the longer wait for release.
  3. Provides more opportunity to fall prey to idea theft, if I happen upon something compelling.
  4. Greater task switch overhead. Slow to switch, but also demands more documentation to ensure nothing is forgotten.

I expect (1), (2), and (3) to be ameliorated by breaking the pipeline metaphor. It’s less a strict pipeline, more a technique to defeat the aforementioned demons. Rather than spending time uniformly, I will lean heavily into a handful of games. “Shipped” is an important feature! When I get stuck, I switch. Let my subconscious figure it out in the interim.

On (3): Cloning is a real problem, but the fear of idea theft is much exaggerated. Everyone in the industry is awash with their own ideas – why would they want yours?

If a Product X of mine miraculously gains popular appeal, and gets stolen before I can ship it, c’est la vie. Hopefully my diverse portfolio will shield me somewhat.

Time will tell.

(4) I think less a drag and more a boon. It requires correct documentation practices; clear, intuitive design; and thorough journaling of the game’s history. These will support debugging and improve chances to catch design flaws. They also create a solid feedback loop on how well I’m coding and commenting, and will help expose where in the product lifecycle I’m weakest. Not concerned, altogether.

Anticipated/observed upsides:

  1. Distance between you and your creations provides fresh perspective. If it’s boring, you’ll realize it. Rabbit holes and feature creep have less pull. Personal testing will be strengthened by forgetting the “happy paths.”
  2. I expect feedback only grows more diverse with time. The pipeline insulates us from our knee-jerk reactions, allowing time for accurate feedback to emerge and take shape. The game is better for this.
  3. Repetition of each phase of the software lifecycle helps delineate exactly what each phase is, what it requires of you – a learning opportunity!
  4. Unexpected connections enrich designs. Serial work on one game limits chances to see parallels between mechanics and themes. A pipeline full of games being revisited regularly provides ample opportunity to make those connections. Each game is better for this.
  5. The Pipeline demands toolchain investment. The pain of kludgy solutions may be ignored when infrequently felt, but becomes intolerable quickly with regular repetition. Though costly, the amortization is made clear. Higher efficiency and quality are the prize.

These arguments may hold up, or they may not. Without data, they carry no weight. It wouldn’t take much to shift the plan from awesome to awful or vice versa.

I know of no data other than the great mass of teams who seem to do just fine with serial development practices. Popularity has never made particularly great arguments, though, especially where intuition drives.

The cost of implementation is low enough, and the upsides tempting enough, that I will give it a shot.

I would like to re-arrange the site soon, to align better with the pipeline. I may need to find a new hosting platform/tech to make that palatable.