I just posted an update for A Miner Adventure. It just fixes some bugs and added a couple of things (elevator call buttons and world.status updates).

I try to always have multiple projects to work on - not just projects to work on, but projects that I'm motivated to work on. Until I get the motivation to expand adventure mode, A Miner Adventure is getting mostly just bug fixes. Exordium & Terminus was put on hold in favor of Tiny Heroes, which I'm actively working on. As incontrovertible proof, here's another screenshot:



This leaves me with only one really active project, so I opened up my archive of projects that are so incomplete that they're not worth being in my byond/bin folder. Here are a few projects that have the potential to be my "backup" for when I need a break from Tiny Heroes.

RTS Framework / RTS/Defense Game

A while ago I posted about an RTS framework I was working on, but never got very far along. It's tough to work on when you don't want to make an RTS game. I wanted to make a sidescroller so that library was easy to work on. I recently took what I had written for the RTS framework and started turning it into a game.

I like tower defense games, but most end up being a bad version of Simon. You have to learn a specific sequence of what upgrades to get or towers to build. But, to make it even worse than Simon, you're not told the sequence and asked to recall it, you have to learn by trial and error. For example, if you don't build the towers that detect invisibility before wave 10, you'll lose because that wave has invisible enemies. There's often no way to know this, you just have to fail on level 10, realize how you have to adjust, then try again from the beginning by repeating waves 1-9.

I made some TD maps for Warcraft 3 and ran into another problem: how do you make it so there are different strategies that are effective without making all strategies effective? For example, if players can choose between two offensive towers, you have these possible situations:

1. Both towers stink.
2. One of the towers is distinctly better than the other.
3. Both towers are effective.

In the first case it's obvious that the player should not use either. In the second case it's obvious that the player should use the better tower. In the third case, the player has a decision to make, but ultimately it doesn't matter because both choices are viable.

TD games often have ways that players can be at a permanent financial disadvantage. For example, when an enemy slips through your defenses it'll damage your base, but it also represents lost income. When you're not prepared for a wave and enemies get by, you get less money than you should and it becomes more likely that you're unprepared for the next wave.

I've been trying to figure out a different angle to take that'll circumvent these problems. Here's the idea I came up with, but first, a screenshot:



This ends up straying pretty far from what you'd consider "tower defense". The player is given a set of units that they can order around. The map is more than just "here's a winding path leading up to your base", there's some area to explore.

The first issue (the Simon problem) is really twofold. First, you're likely to fail because you can't anticipate what is coming next. Second, when you fail you have to start over. To deal with the first problem it'll have random events. Instead of having to figure out how to conquer the static stream of monsters, you'll have to figure out how to make the best of certain events. For example, a treasure chest spawns at a random location on the map - how do you balance your need to defend with the need to venture out and get the treasure? When you get to the chest, you find an awesome weapon for your melee unit - how do you change your strategy to make the best use of your now-powerful melee guy? For the second problem, my best idea is a Gemcraft approach where the game is really a sequence of separate, smaller defense games.

For the second issue we'd make "tower" choice a non-issue by giving you a specific set of units. Instead of the question being "what's the most effective unit?" it's "how do I effectively use these units?". This is further enhanced by the random loot. In other TD games it would be poor design that all upgrades are equally beneficial, but the game isn't about figuring out what upgrade is most effective but how to make the most effective use of the upgrades you've been given.

Space Game

The player starts the game as the owner of a small spaceship. You can do different kinds of missions to earn money to upgrade your ship. The game would take place almost entirely in your spaceship and every mission would essentially be the same. The mission is to go from planet A to planet B safely. The trip is a sequence of events you have to react to. For example, you see an unfamiliar ship, do you approach it or avoid it? Based on what you pick, there might be combat (either they shoot at you or they board your ship).

Some of the events are just dice rolls (ex: if you choose to avoid the enemy ship it's just a coin flip to decide if you get away or not). Some events would be action-based. When an enemy boards your ship, it'd be realtime combat. The time in between events would be spent managing and repairing the ship.

You get money and can upgrade your ship. Upgrading your engines would influence the coin toss that decides if you escape an enemy or not. You can also upgrade your ship through a building mode where you can change how it looks. A bigger ship can hold more cargo and increases the range of missions that are available to you.



Each player would control a single crew member. As you get a better ship and harder missions you'd need a larger crew and you could have other live players join your crew or you could hire AI-controlled mobs.

I've put more thought into the RTS game but I have graphics made for the space game. It's a tough call what I'll work on.

Monster-Based RPG
Edit: This is probably the most complete of my abandoned projects, but is the one I want to go back and work on the least. It's worth some of my consideration, at least.

My main idea was to take common console RPG gameplay elements but emphasize the ones that should get emphasis. What I mean is that console RPGs have a lot of things to annoy the player. What's fun about the game is the content, but the games have a lot of mechanics to slow down the player so that you experience the game's content at a limited pace - the game deliberately limits how much fun it is. Exploration is fun, but you get random encounters every 10 steps to slow you down. Reaching a new dungeon is fun, but you need to kill the same enemies 100 more times to level up before you can make it through the dungeon. Even combat is an example of this, attacking is fun but you have to use a clunky interface and wait for text and animations.

Instead of having a long distance separating two towns and requiring that the player face 10-15 random encounters to reach the second town, my RPG would boil that down to a fixed number of fixed encounters. There are two reasons to do this:

1. When you get random encounters every ~10 steps you're less likely to explore. It's safer to head straight to the next town.
2. The journey to the next town is usually as hard as the single hardest fight you get along the way. You can heal up between battles, so testing the player by asking them to beat the same combination of enemies 10 times is no more challenging than asking them to beat those enemies once.

Here's what the world map looks like:



Each numbered tile is a fight. To pass over the tile you have to beat the enemies. Once you win, the tile becomes grayed out and you don't have to repeat the fight. The reason being that if you passed the test once you can pass it again. Why make the player repeat content that we know isn't a challenge to them?



Console RPGs tend to have lots of boring battles instead of a few interesting ones. For every character you know what their strongest ability is and you use that every turn. The only "strategy" is figuring out which enemy to kill first, but that becomes obvious after you've seen all the enemies once. Combat in my RPG would be like a turn-based tactical strategy game:



You can move your unit freely around the shaded area and use attacks. It also allowed for ranged attacks (shown in the second picture).



Dungeons would be similar. Each floor of the dungeon is a fight. Once you beat the enemies, your character can freely explore that level of the dungeon. When you return to that floor later, the enemies would still be gone (or maybe they'd be replaced with new enemies, but this would be a scripted thing).

Your character doesn't participate in the combat. Instead you have monsters to fight for you. Character development would be a combination of a few things: salvaging monster parts from defeated enemies to construct new monsters, monsters learning abilities from their allies by fighting side-by-side, and growth by "traditional" leveling up. I say "traditional" because there are no experience points. When you beat a monster that's your level or higher, you earn a level up. When you're level 10 and you construct a new monster that's level 1, it only takes 9 fights to get him up to speed (and there's no permanent experience disparity between your new and old monsters).

There would be potential for random encounters. You'll need an endless supply of fights to level up your new monsters or to gather monster parts. It'd be like grinding, but it's not meant to slow the player down. It's a necessary, but optional, element - you need a way to collect monster parts, but you don't need to collect monster parts.

Sidescroller

The library defines the on_left, on_right, on_ground, and on_ceiling vars for mobs. These vars are boolean values that indicate on what sides the mob is touching a dense object. These come in handy for some simple things. For example, you can only jump when on_ground = 1. If you wanted to make a new effect, like wall climbing, you'd use on_left and on_right.

I would like to extend this to be a bit mask that can provide more information about the objects you're touching. For example, the first bit would tell you that there's a dense object on that side but the second bit will tell you that the object on that side is slippery. This way you can check if(on_ground) to see if the player can jump, but you'd check if(on_ground & ICE) to check if the player should slide across the floor.

Currently I don't have the motivation to work on this.