"Parkridge Playground" level concept and analysis

I've always thought that children's playgrounds seem like an underused videogame setting - not only are they inherently modular and multi-path, but they appear in a variety of environments (malls, parks, all manner of neighborhoods) that crop up all the time. While I can see the potential concerns with using such a kit in a shooter (a shame given the range of interesting cover options), it could at least be used in a run-and-hide horror type of game, hence this nightmarish little test level.

 The central design concept is that the child-sized player must use the various tunnels and crevices to outmaneuver the eerie bird-maked creatures, who are too large for most (but not all) of the structure's openings. There's a nice cat-and-mouse feel, though the layout could certainly stand a few revisions. It's worth noting that the map uses very few models, all of which are low-poly and designed for Unity's built-in low-cost colliders. I also made the dubious decision to use triangular floor panels, which made for some interesting layouts but also required some tricky geometry.

 While the off-kilter shadows cast by a nearby streetlight certainly have an twisted, unsettling effect (I particularly like the grids cast by the chain-link fence), a dark map like this certainly requires a more hands-on approach to lighting, and I think the lack of attention paid here really shows. There's not a lot of indication as to where to go, and while it could be argued that this makes the high-stakes tag match a bit more challenging, there's a lot of missed opportunity for clever lighting tricks (i.e. shadows in the shapes of the ghostly pursuers). Perhaps I'll try my hand at this setting again in the future - in spite of the industry's constant re-assessment of "survival horror," I haven't seen many games which openly embrace the feeling of being chased. Aside from Pac Man, I suppose.

"Cougar Lake" atmospheric experiments and analysis

These further experiments in random terrain generation are the result of a new level-building process I've been auditioning. I suppose technical folks might call it "atmospheric prototyping" - essentially, building and exploring a rough open world, getting a feel for potential moods and components before moving on to layout work. 

The components used to generate this dead, frozen forest were put together in a single afternoon, and while the terrain is admittedly pretty sloppy (particularly in regards to the haphazard grass placement), I think that it was quite a successful experiment in regards to mood-based brainstorming. While I certainly could have focused on finding a perfect level flow before tweaking the atmosphere, the randomized layout suggests some interesting elements that simply wouldn't have occurred had I had been adhering to a rigid plan. Certainly, future designs for snow-based levels will be pieced together from this experiment's hits, and informed and inspired by its misses.

 

 Perhaps the biggest success story to come from this little jam is the new approach to trees, a simple-but-effective forest building script which randomly places, scales, and rotates meshes from a determined folder (the same script determines the level's rock formations, with admittedly less success). I've grown to know Unity's built in tree system pretty intimately, and while it handles distant backgrounds and small brush acceptably, it's quite pathetic at handling such vegetation up close. I'm still racking my brain for a memory-friendly leaf solution, but this approach has proven fairly effective at creating a believable dead forest.

Alternately, the biggest failure here is the water, which is the standard Unity asset and really stinks up the look of the place. After this attempt, I resolved to never again touch the built-in water and instead devise a system of my own - more on that in the near future.

"Mindzone" game screenshots and post-mortem analysis

After some hands-on experience with a vintage "Battlezone" machine, I decided to temporarily retreat from realism and experiment with a minimalist faux-vector art style. The vector influence may have been lost along the way, but the end result allowed for a looser playspace, a workable sandbox to refine some fairly ambitious systems. Visually speaking, it's certainly a bit rough, but the bold and highly contrasted look is much easier on the eyes than some of my previous attempts, and the game's surrealist, Jack Kirby-inspired weirdness allowed me to play with some unused creatures from my pixel art years.The (extremely simple) gameplay here largely stems from an attempt to expand on the unfinished "Glitch Hunter" random level building, which ended up working surprisingly well here. The abstract feel of the world helps to disguise a lot of the seams, and I'm particularly pleased with the feel of the nerve-like root clusters, an extremely simple bit of code which adds near infinite variety to the world. I also cooked up a fairly decent water system, wherein the neon-colored sea will start to rise once the objective is complete, leading to some (surprisingly) tense scrambles to find an exit before the player inevitably drowns. Honestly, these races against time were far more thrilling than the rather half-assed gunplay, and I'm bound to further revise this concept in the future.

As a narrative-minded gamer, I instinctively wanted to attach a story here - but now that it's behind me, I think that it works better as a mysterious abstract sort of piece, perhaps in part due to its arcade-inspired roots. One discarded premise involved a VR program allowing the augmentation of human memories, in which the player would be tasked by an overbearing client to destroy traces of painful conversations. It's the kind of thing which seems novel when first brainstormed, but reveals itself as too esoteric and convoluted when forcibly inserted into the game. In the end I'm glad I exercised the plot completely, as I don't think the addition of text storytelling would have added much.

While I don't foresee myself going back to fine-tune this (enjoyable) mess, there were certainly some powerful lessons learned over the three weeks I spent playing with it. Namely:
1. Progress on individual systems moves much more quickly in a temporary "jam world" built around those concepts, rather than trying to balance them within an ongoing (and constantly expanding) project.
2. Procedural generation is easier than it might seem, but in this iteration isn't quite ready to craft anything resembling a traditional game level. It does, however, make for some extremely unpredictable on-the-fly playtesting, and is in many ways more informative than using a single pre-made "test arena."
3. An abstract approach makes for good prototyping, for several reasons. Most notably, it helps me curb my perfectionist tendencies and experiment with quickly-made temporary assets. It's easier to work on things that matter (scripts, layouts) when using models that don't require perfect realism.
4. Bright, unsaturated colors hurt the eyes as well as the brain. While the liberal use of black here is quite helpful on that front, use of these neon tones is a bad habit that I'd personally like to shed.
Most importantly, the game jam approach is both inspiring and rewarding, and I look forward to working on similar short experimental pieces (perhaps as part of a more prominent, and team-oriented, jam) before trying my hand at another big project.

"Glitch Hunter" screenshots and analysis

The concept of "Glitch Hunter" sprung from a desire to apply tangible gameplay to the various unrelated levels I had been working on, sticking the player in a self-referential, purposefully unfinished product. After unplugging from a long gaming session, the player surrogate finds that ten years have passed, leaving them stranded in a bizarre future, occasionally experiencing hallucinations that they are still in a game. Ideally, the sense of fourth wall demolition would explain differences in lighting and mood, as well as any rough patches in the layout or gameplay.

True to form, I ended up becoming quite attached to the premise, thanks in no small part to my rapidly evolving (and admittedly intoxicating) coding skills. I think that codephobia is the number one thing which holds back budding designers, just as the limitless sense of "I can do anything now!" is in fact a massive stumbling block for those who have freshly conquered such fear. This iteration of "Glitch Hunter" may have buckled under the weight of such liberation, but it's not dead by any means - just sleeping an a cocoon state, metamorphosing into something stronger.

Naturally, a number of creatures have been auditioned in this setting (including sentient kombucha bottles and swarms of luminescent insects), but the most interesting story-wise are the remote drones. Produced by a range of fictional corporations and piloted by housebound consumers, they were designed to eventually fill any number of roles - merchants, civilians, street gangs, protestors, cannon fodder under the control of experienced hackers, you name it. The lack of a working text/dialogue system is one of the really glaring omissions in this attempt, as it means a lot of missed potential for in-game microfiction.

 The more brightly colored and visually confusing screenshots are from inside of Glitches, wandering holes in reality which can either help or hinder the player. I acknowledge that they look pretty ugly in this iteration, and plan to constrain them to a fixed palate rather than the "random color" approach which seemed so novel at the time. Naturally, the gameplay specifics of glitches is bound to evolve as different types of levels are played with, and at this point they don't do much aside from allowing the player to bypass the edges of the map.

 The square, tablet-like device at the bottom of each shot is, fittingly, named the H.U.D., or homeowner's utility device - serving as both the player's visual interface and defense method, it's meant to feel a little out-of-date with the rest of the world's technology. It fits as a sort of gauntlet in the right hand while the left controls the touchscreen, and has a wide range of practical/impractical attachments (flashlight, keychain, CD player). These are installed in pairs and controlled by left and right mouse clicks - which ideally will someday make for a wide range of customizable play styles.

 It's probably worth mentioning that a portion of these screenshots are from procedurally generated stages. Random worldbuilding is, in my view, a very interesting method of squeezing a lot of gameplay out of very few assets, and while I certainly didn't nail it here, I at least got a good sense of what not to do. Namely, these maps generate in real-time (a massive blunder, causing flash-freezes every few steps), and have all sorts of problems with altitude changes. Still, a noteworthy lesson, and big stepping stone towards subsequent improvements.

Design-wise, there are some outstanding visual blemishes, like the jarring color choices and inconsistent textures, as well as a general lack of direction in regards to gameplay. Certainly to be expected from a first prototype which did quite a bit of on-the-spot evolution, trying to accommodate a wide range of early programming experiments. While I label my early paper maps as "blueprints," this is really the first thing I've done which fits that word, and I can now recognize that a single hour with a shifting in-dev game like this is more beneficial than a thousand detailed design docs.