4/18/2021 0 Comments [CANCELLED] - Part 1 DISCLAIMER: This blog post was written back in 2019. Portions of this blog post have been rewritten to either omit certain information or update content to be more accurate to the current year. Despite these changes, most of the writing was kept intact for posterity. Today I decided I'd sit down and talk about dead projects. I think most game developers know how this goes. You come up with a fun idea that sounds cool, make a small game from it, accidentally expand that game far beyond its original scope, and then you have to cancel it because it doesn't have enough of a backbone to carry on to the end. It's been there since the beginning of game development history, and god only knows it'll be there when the sun collapses and obliterates us and our memories of "MARIO WITH A GUN V2.9." Of course, we think about those abandoned projects as trash that's not worth looking back on, but truth be told there can be some very interesting tidbits tucked away five folders deep. I've been making games for seven years now, and I will say with certainty that I have over 50 project files sitting around that were destined for mediocre reception on itch.io but never actually got there. Some of these projects are 2D, some are 3D, some are sneaky barnyard incest children of both, and others are made in 4D and require special goggles and an alien's brain to play without having a stroke. It's a confused bunch, but these games contributed to some very crucial tools and mentalities that have since shaped a lot of the workflow I use now. For example, a spinoff I made about my former friend's series of games contributed the backbone to what would become the Rush Player Controller. It might not seem significant, but those tools are the foundation for every single one of my first and third person games, including Cold Wick and Peeb Adventures. All of the unfinished games suffer from the problem I noted at the beginning. The initial scale was small, I hit that edge and wanted to do more, I pushed the scale of the game out onto a shaky wooden bridge, and then that bridge collapsed and I chose to abandon ship, run to the next bridge and shove another project to its inevitable doom. A constant cycle of believing I could improvise something entirely, messing that up, and never learning from my past mistakes. It was great for learning how to code better frameworks and to make new tools I would use from that point on, but ultimately it meant that I would never actually make games, just husks filled with memorabilia. Speaking of which - Little Habitats was modeled off of other wander-and-wonder games like 21: The World and the agonizing-to-play-like-you're-strapped-to-a-chair-and-someone-is-pressing-a-knife-into-your-brain yet fondly remembered LSD: Dream Emulator. The game hardly went anywhere without immediately collapsing onto its legs and crying because of its horrendous conversation editor and clumsily made environments, but for a period of time it was the hot ticket issue for me. I only cared about making this game, but being as inept as I was, it just swam in circles for months. Conversations were a big part of the game, something that wasn't present in any of Little Habitats' inspirations. Talking to characters could mark triggers with values, and these values could affect how other events in the game carried out, and blah blah blah blah it doesn't mean anything. The editor may look somewhat complex, but the kind of results it managed weren't that amazing. Hell, to have conversations carry on from previous progress, each conversation leading up to it had to be specially marked so it would automatically load the next one, and then the next one, and the next one until it finally reached the place the player left off. Things like this made development incredibly sluggish, and having little to no experience with Blender at the time, characters and levels weren't looking much better. Little habitats was definitely directionless, but the things I ultimately came away with were helpful. I learned to better manage my frameworks so things would flow better (looking at you, conversation editor), I began to dip my toes into refining my first-person player controllers more, and I started to push further to simplify my workflow in general by making everything idiot-proof from then on. The next game on this list is Sergeant Sparkplug, a sort of arena shooter where you had to rapidly switch weapons. Its plot circles around a mercenary robot being an idiot and accidentally obliterating peaceful planets that were just retaliating to his outright hostility. The game was one of the first few I made where I focused on actually making a game and not some generic walking simulator, and it features your usual assortment of mechanics like rocket-jumping and going ham on the mouse buttons. This game's primary mechanic was that weapons had limited ammo, and without a way to refill them you were required to chain weapon-to-weapon to keep fighting. You could throw your current weapon with 'G', and your fists also worked to stave off enemies in an emergency. The UI was so neglected it developed some kind of "bad idiot-baby design" fungal infection and just got progressively worse. The upper-left features a horrendous health-bar that makes no sense and doesn't adhere to the game's nearly non-existent style, and the weapon tab on the bottom of the screen is so generic its placeholder backdrop was my dev group's logo from the time. The game itself isn't horrible, and features some design philosophies I still use to this day when making FPS games. The prefab based weapon system and polymorphism integration may not be remotely advanced or original in the realm of FPS games, but the learning process changed the way I viewed programming and frameworking as a whole. Sergeant Sparkplug was also the first game where I actually sat down and animated weapon viewmodels properly, and the animation philosophies I used then would continue to affect all of my following games. Sergeant Sparkplug's life was short-lived. Surprisingly, this wasn't because I ended up trapping myself in a whirlpool of bad design choices, but mostly because another project was being developed concurrently and ended up taking all of my attention. This project was also cancelled, but it does have an interesting story behind it. Blip was originally supposed to be a small test game between Kirkas and I. We wanted to make a tiny horror shooter where you just played as this small guy with a pistol. Instead, we ended up with an intricately organized framework and so many assets we were motivated to expand it into a full game. Truthfully, the core issue was the lack of direction. We both wanted different things from the game, and at its core we didn't really have much of a plan for how it would all come together. I wanted a weird, slowly-paced horror shooter and Kirkas wanted a fast-paced action shooter. Mixtures of these design philosophies can be seen in some of the game's screenshots, and it was ultimately the thing that ended up killing the game. With no agreement on a good core, it just didn't have the foundation to go anywhere. It's a shame too, because the game was definitely more complete than most of the items in this list. Blip's artstyle was also contentious during design. I wanted a high-contrast art style that used saturation to highlight important objects (projectiles, enemies, etc) and Kirkas wanted to flex his art muscles more and create a broader palette for the whole game. I was initially against this notion until we found a middle ground where environments would be color coded, and they would contrast well with characters and projectiles. This might seem like an obvious choice now, but for a time I had extremely strong sentiments about how the game needed to come together. I pictured a lot of psychedelic and off-putting environments with freaky enemies, and ultimately we ended up in a weird in-between where there wasn't a lot of horror or tension. It was a fun game, but it wasn't remotely similar to what I had originally envisioned for it. Even with Kirkas doing most of the art, once in a while I would slip something of my own in. This can be seen with the femtoplasm boss up above, which was the last attempt I made at preserving the horror aspects of the game before I accepted that it would just have to become the action game it was evolving into. Blip would eventually see a revision called "Conduit", but it was abandoned before any significant changes were made to the base game's artstyle or mechanics. Maybe someday Blip will finally be finished the way it was meant to be, but there's no promise of that. Despite being at the end of the list, this project actually came after Little Habitats and before Sergeant Sparkplug. The Door was a horror game designed as a sequel to another completely unmade game called The Mist. In it, society collapses due to parasitic worms eating everything in sight and drinking almost all of the usable water. However, as the game's narrative expands it's revealed that there's a supernatural force called "mother" who is attempting to demolish the world to reshape it in meat. The game would evolve from its grungy and dark aesthetic to become more hellish and meaty as you went deeper, and out of all of my attempts at "horror" around that time, this was as close as I got. The game is deliberately styled like a 90s retro-3D game, with its tank controls and use of the mouse to interact with the screen like a point-and-click adventure game. There were a good deal of subtle scares planned, like shadows moving when they're just in the corner of your vision, or paintings briefly changing when you looked at them. These were never implemented, and the game is mostly an empty husk. On a smaller scale, the game's narrative follows a man named Edward as he tries to piece together what happened to a rich neighbor down the road. Edward eventually gains entry to his neighbor's mansion, only to find that he has been converted to a cult that prays to mother and has begun some terrible rituals in tribute. The game's title refers to a door in the basement that leads to somewhere Edward suspects his neighbor ran to hide when everything was falling apart. After some tense encounters in the basement, Edward would go through the door to find out it was actually a portal to the dimension mother lives in, and he would finally discover the truth about the world's demise. The time this game takes place in is very difficult to place. The buildings are dilapidated village homes, but their interiors sport conveniences that only really came into existence in the last century. Most if not all of the objects in the game can be interacted with to receive some flavor text, and I was hoping to make good use of this to tell the story of what happened. Most digital or organic objects in the world had flavor text in a different color that hinted towards the overarching narrative of the world's eventual conversion to meat. Anything that had a digital signal became corrupted and would either play a specific song or would just show twitching meat on its display. The Door was a promising game, but ultimately I was sick around the time it started to go places, so it was put on ice permanently because I didn't want to immerse myself in a miserable game world while I was physically suffering. Ultimately, it was for the best; like most of the projects on this list, I didn't actually have anything formally planned out for the game. I was going entirely on a whim, which is always a recipe for disaster.
Anyhow, this was part one of my little retrospective series. I'll consider adding onto this soon enough, but for now I'm going to go submerge my head in some ice water so it doesn't explode. If you want to see what I'm working on, you can follow me on my Twitter.
0 Comments
Leave a Reply. |
ArchivesCategories |