I've been on another posting hiatus to focus on development, doing the rather unsexy work of revamping old systems, optimizing performance, and developing tools for myself. Over the past few months I feel I've accumulated enough of that stuff to make for a post though in the future I think I'll stick to shorter updates.

Design Thoughts

Reflecting on the release of other games with the word "infinite" in their product description, I feel that I should again clarify what I mean by the game being set on an infinite wall. Yes, players can climb forever in any direction. However, the interesting areas of the game are hand crafted as a part of a narrative. I do this partly to avert procedural blandness, eschewing infinite but predictable "variety" in favor of structures that are placed with intention, everything naturally connected rather generated via algorithm.

The main story path will be a series of unique locations, usually centered on settlements made by the people of the wall. The path will be marked with bright flares that can be seen from afar, so players will know where to go next from the start.

Outside of the critical path are the satellite locations. They're lower in profile than cities and towers, and are there for less casual players that want an additional challenging goals to reach. Climbing to and from them would not be easy, but they're completely optional.

Beyond the satellite locations is the hinterland, a procedurally generated waste that stretches on and on, full of random biomes but not much else (I recently re-added the automatic biomes after an overhaul of the generation code, placing them with voronoi noise). The challenge in these outer areas lies in finding those extremely rare generated save points while staying alive. Also, I may sprinkle a few handmade secrets in this vastness, very far off-path. This expanse is for hardcore world-climbers only.

This seems like a natural way of spreading things out, letting players choose their own difficulty level. There are no invisible walls gating you, just a stark nothingness beyond. Hard constraints are usually a good thing in games, keeping players focused on specific goals and keeping the action moving along. In early years of the project, I struggled with the idea that players would stray off the path and unintentionally spoil their experience. Now, I'm more inclined to trust players to forge their own paths.

My one constraint has been the introduction of save points, so that if players do indeed wander too far, they can easily undo their mistake and return to the beaten path by reloading. This also makes setting out from the safety of a settlement a more meaningful event. No more save-scumming after every jump! A misstep won't take you back a few steps but back into the last visited town. Did I ever mention that I am a huge fan of the Dark Souls franchise?

New Wand Model

I've made so many iterations of the wand while developing the game. I've always wanted to make it feel more like a tool than a magic wand, and this version comes closest to that intention.

New Locations

I've created models for two new locations. The first is a structure inspired by ICO, a series of towers surrounding a monolithic fortress. Note that the texture is temporary, it shouldn't be this grey in the end.

The second location is an outpost/lighthouse/waystation. It features a large crystal that refracts sunlight in every direction, meant to be a sort of a guidepost for players.

Region Builder

I've created a world-editor that will help me generate and set data. This will speed up my ability to create levels, place props/bricks, and override procedural biomes. I call this my "Region Builder." A region is my internal term for a group of neighboring super chunks.

As an example, below is the brick editor. It gives me the ability to move, and re-type, and resize bricks. Beats directly manipulating data. I have similar tools for chunks, super chunks, props etc.

Next Steps

Right now, I'm in the process of rebuilding my levels in the Region Builder. I'm trying out new image effects that will improve the overall look and feel of the game (hopefully without too much of a performance cost).

It has been a while since my last post, sorry about that. Thanks to everyone for being patient and cool about the long dev cycle for this project. It's been a huge undertaking, but this game is my baby, and I want to get it right before I release it into the world.

I've recently redone the game's state system, weather, biomes, brick generation, props, saving system, settings, you name it. The task ahead is still huge, basically just the actual reconstruction of the game world (that is, level design). The tech side of things is close to where it should be, except for whatever bugs pop up.

Now it's a matter of placing all the props and polishing the game until it's release-ready, content and level design. Creating 3D art has always been my greatest weakness. It often feels like a futile exercise, taking me weeks to produce any given asset, and I've never been quite satisfied with what turns out. For now, I'll just use placeholders for everything that I cannot do myself, and just focus on getting the levels playable.

In terms of overall artistic direction, I am making a world that needs to feel like a "beautiful void," in the mold of Myst. The wall is a lonely, lifeless place where you are a small helpless speck clinging to its surface for survival. This world doesn't know or care about you. it's a monolith that will continue existing on forever, long after you abandon it. However, at the same time this strange world can be scaled, explored, studied, and eventually understood for what it is.

Actually executing on this vision has been nothing trivial. I constantly feel like the end is in sight, yet in execution it feels like it's miles away.

Right now I'm tackling my redo of the prop and saving systems, and will move onto biomes before getting back to the meat of the game's content.

For biomes, removed them originally because they were distracting, and filled the wall with clutter. I really love how lonely, small, and isolated it feels on the bare face of the wall. But still, I want a bit of variety, so isolated zones of the game content will contain hand-placed biomes, and much further out will be procedural ones for the more adventurous player. I am considering having some random hideouts/save points in this procedural wilderness, but that is a low priority feature.

Props

I've redone the prop system of the game. Before, I had two scripts that defined how world objects called props behaved: Prop and DynamicProp. These scripts each had variables that further distinguished one prop from another in terms of functionality (e.g. a DynamicProp could also be called an Entity or Activator depending on how it was set up). Now, I have made a seperate script for each type of prop:

Static Prop - props that are saved and loaded with chunks, and never move from their position. E.g. buildings.
Dynamic Prop - props that are capable of moving and transitioning from one chunk to another. E.g. doors, elevators.
Entity Prop - dynamic props that can be interacted with, usually picked up and moved around. E.g. debris, small objects
Activator Prop - props that are stationary execute a state-changing function (open -> closed, off -> on) when activated. E.g. Switches, doors.
Trigger Prop - invisible objects that trigger events when the player touches them. E.g. checkpoints.
Container Prop - dynamic props that track and are responsible for other entity props. E.g. an elevator containing cargo.

Super Chunks

Also, I have created a script that defines "SuperChunks." SuperChunks are an area of space occupied by groups of 64x64 regular chunks. The player's current SuperChunk is always in a square that is at 0,0,0 in the lower left corner and 4096,4096,0 in the upper right. When the player walks from one SuperChunk to another, the entire world shifts so that the new SuperChunk fits into the square. That way, the player is never more than a few kilometers from the world origin. This cuts down on floating-point errors that arise when the player coordinate numbers get to high.

Getting Up To Speed

My redo of the game project is proceeding as planned. One change is that now instead of a 1-camera setup, I have three cameras, to render equipment, the world, and the sky separately. A "camera" functions as the player's eyes in a scene. Each camera has a near and far clipping distance, it'll only draw objects within this specified range. When there is a wide range in these values, there are more rendering issues that you'll encounter. Also, I can apply different effects and filters to each camera.

Unity 5

Recently I upgraded to Unity 5 for the new version of Against the Wall. I didn't realize this at first, but my old custom shaders (code that tells your graphics card how to draw something) were no longer compatible with the new version of the game engine. Everything pretty much looked flat and washed-out, but I didn't realize how bad it was until I looked at the two versions side-by-side. I spent last Monday after work updating my shaders to the new stricter guidelines and standards that the engine requires. Fun times.

DirectX 11

The final Windows version of the game will not utilize DX11 for graphics rendering. Why? for some reason, it does not play well with the "atmospheric scattering" shader that I use for my sky (that works perfectly well under the older DX9). I spent much of Sunday fixing it, but the result left much to be desired. The alternative skybox shaders and scripts that I've found either don't render cloud planes, or are hard-wired to have a horizontal horizon. Crazy, right?

Also, not developing with DX11 in mind makes things simpler for me, since it is not compatible with Mac OS X or Linux. More differentiation between each release platform would have meant more dev time making sure the look and feel of the game is consistent. I'm already strapped for time as it is!

Also

I am going to the Boston Festival of Indie Games this weekend to show off my miniature fighting game called Nothing Good Can Come Of This. Stop by and say hi if you're there!

The game has been on hiatus for quite a while. I started a new job and had to step away from it for a bit, not really finding the time to work on my passion project.

I figured the best way to get things going again was to completely restart production. I created a new project and began importing and re-factoring my old code, leaving out anything extraneous, creating a new versioning repository, not including any of my old 3D art, etc. The idea was to start as fresh as possible while still retaining the core functionality of the game. I still have a way to go, but it feels good so far.

The biggest gameplay change that I'm planning: you can only save the game at certain points, located in the cities or in remote shacks. Thematically, these locations are hideouts, complete with hearth fires ala Dark Souls. This will make the game considerably more challenging, no more saving after every jump. It will also give players a focused mid-term objective of finding the next hideout.

The game has also been upgraded to the latest version of the Unity Engine (took longer than I imagined to get that working), and the final game will support DX11 on Windows machines.

Progress on Against the Wall has been rather sporadic. I upgraded to Unity 5 and have been fixing bugs. Otherwise, I have not been able to devote real time to development. For this game, I need solid weeks of time for any new feature or level, which translates to me needing extra cash to support myself. I just don't have the resources to continue working on it full-time and also pay for food or rent (or maintain my sanity).

Currently, I'm working at a local game company while holding a TA position at NYU. I'm also developing smaller, more minimalistic games that I can churn out in a week or two. AtW is rather over-scoped for one person. I feel stuck and unable to make my dream a reality. I know, poor me, but that's the truth.

So what now? A Kickstarter campaign is an option I've been floating, but that would require quite a bit of work to create the video and plan the rewards. I could use some help in this area, if anyone has ideas. I also have a second game called Asterisk that I made back in school which is about 3/4 of the way to completion. It's like a multiplayer FTL crossed with Star Control, yet somehow minimalistic. That game could perhaps use a little crowd-funding love as well.

Also, today marks the release of GameLoading: Rise of the Indies. It's a documentary that's wider in scope than Indie Game: The Movie, though it still does focus on the more established indie scene. I'm in the film a total of five times, dropping some hard-earned truths (with a smile). Mostly, I talk about the difficulty of surviving in the industry from the perspective of a solo, independent developer

My ultimate dream is to create cool, fun games that kinda mess with peoples' heads, while still making enough to support myself. Nothing makes me happier than watching other people react to my work, shouting orders at each other in a co-op game, talking smack in my local multilayer joints, or remarking in wonder as they explore a mysterious, strange, and twisted world that I made.

Since grad school restarted in January, it has been difficult to find solid blocks of time to devote to the game. I have since graduated from NYU and completed the business incubator that I participated in over the Summer. I now have more time to give to AtW, so I should be able to update more frequently.

My focus continues to be on art and level design. I am more of a programmer / game designer than an artist, much more comfortable with solving technical problems over aesthetic ones. Over my time in school, I've developed more of a hyper-minimalist art style, making games that did not require a ton of artistic skill. With more complicated 3D art, it takes me a good deal of time to create the smaller assets. I may compromise by making everything everything even more visually abstract and emphasize on gameplay and scripted events.

Level design requires frequent play tests, which I will conduct publicly every Thursday at 5 at the NYU Game Center in Brooklyn. This is a content-driven game. Procedural code is limited to brick layout, rather than the creation of structures in the world. At one point I had full randomly generated biomes in the game, but it ruined the feeling of being exposed on the side of a bare flat wall, in addition to introducing performance issues. There are currently six different biomes in the game that I have manually placed around the level areas. If I do reintroduce procedural biomes, they would be sparse, infrequent, and away from the central story area.

This past week, I occupied myself with a few tasks, major and minor. A number of these changes relate to the game's presentation, player interaction with the world, and the game's feel.

Just Another Brick in the Wall

For a while now, I have been using a texture that defines the border of a brick, and attempts to simulate a bevel. Without it, the wall appears as a solid grey stone surface. The texture would stretch out over each brick face indiscriminate of the brick's size. As such, 1x1 bricks and 8x8 bricks both had their front faces largely defined by the same image, the latter with noticeable stretching. To fix this, I created a large texture atlas with 8 permutations of the texture, each of a different size. When a brick is created, it is given the coordinates of the correctly sized version of the texture. Here are the results:

As you can see, the older brick texture is stretched out over each of the bricks. It's a huge improvement, artistically (looks more clean and professional). The sides of the extended bricks will also need to be included on the texture atlas, since stretching is still visible there. I will be experimenting with adding some slight discoloration to each brick to add some variation. I will also experiment with adding random cracks and imperfections to the bricks.

Holding Things and Wand Motion

I did a major overhaul of the system that governs picking things up and putting them back down. It's smoother, feels better, and much more stable than the earlier implementation. This system accounts for all player interactions with the environment that are unrelated to brick movement, so it was important that I square this one away.

Also, the wand is no longer fixed in place in front of the player... or rather, it is, but it does not feel that way. It rotates a bit in response to player movement, complementing the wand's movement bobbing. The player turns left and it takes a little time to rotate back into position. In other terms, before it felt like a Doom gun, now it's more like the device from Portal.

Dynamic Weather

Before, weather was static depending on your current biome. Rain, snow, fog, etc. each effectively had their own biome. Well, I now have a more dynamic system that randomizes the weather every X minutes, based on the "climate" attached to the current biome. Should be a nice atmospheric touch. Now I am debating whether adding a day/night cycle is worth it. Could make things that much more interesting if the world is always changing around you.

Misc

I did some content work on a city. I had an idea for a simple one-shot puzzle mechanic that I think will be fun. That's all I'll say about that.

I am going to Steam's Dev Days in Seattle tomorrow. It will be a welcome break from NYC, and there will be a number of interesting panels there. I want to get my hands on one of those Steam controllers to see what the deal is with them. I'll do a post next week on what I've learned there.

For the last week, I've been working out many of the kinks in the game and taking some time to update the art. I am happy with the progress so far, but I have a long way to go.

I'm using an app called Trello to manage all of my tasks and bugs. It's pretty satisfying to fill out and label a card, then drag it into the appropriate column. You should check it out if you have an extensive todo list (it beats paper).

Next week, I'll be going to Steam Dev Days, a small Seattle conference for indie devs. I was invited thanks to Against the Wall getting greenlit on Steam. No clue what to expect from it, but I'll keep you posted.

Art

My time spent on the art was to give things a flatter, slightly more abstracted look. Check out this comparison:

The new textures are much nicer, but perhaps they could use a bit more color. This will be an ongoing process.

For the game's reticule, I am now using a single dot in the middle of the screen rather than a crosshair. This dot has a shader that inverts the colors behind it, like the crosshair in Minecraft. When pointing at a dark surface, the reticule becomes white, and when pointing at a bright surface like the wall, it becomes black. This is so that it is almost always visible.

Oh, and now when you look directly at the sun, the sun beams grow and fill up the sky, a blinding white light. Just a little "game feel" thing that I quickly put together.

Biomes

Okay, the biomes are just not working for me. They clutter the wall in random props, slow down world generation, look ugly from a distance, and feel mechanical and out-of-place. Generally, I prefer the big, empty bone-white wall as an imposing edifice to climb. The plan now is to manually place the biome chunks in areas around each town to provide those locations some context. Perhaps I can make procedurally-placed biomes very rare and small. Eh. Right now I should focus on the core game experience, then I can come back to the peripheral stuff.

Head-Bobbing

Or rather, wand-bobbing. I don't move the head from side-to-side like I did in early builds, just the wand in the player's hand. There are a couple reasons for this: first, when aiming at something, any movement would change the target as the player's head swayed left or right. Second, this kind of bobbing can induce motion sickness in some people.

I'n Portal 2, the gun is semi-fixed in front of the player and moves from left to right using a sine-wave. The exact same "animation" is the jump/falling animation. They also have the gun interpolate its position and rotation to match a point in front of the player, making it sway slightly when the player moves from side to side or jumps/lands. Half-Life 2 guns work the same way. Basically, they use a few very cheap tricks to get across the feeling of head movement. It makes the gun feel less stiff, taking a second or so to catch up with the player's adjusted direction.

So the wand bobs instead of the player's camera. I tried the interpolation trick, de-parenting it from the camera and having it move to the position of an invisible object in front of the player. However, the wand kind-of jerks around as it tries to reach the correct position/rotation, and can disappear if the player spins fast enough. I think that I can fake it by keeping the wand parented and faking the interpolation. I do not want to spend too much time on this, but really, the wand feels very stiff right now, like a mounted steady-cam.

Miscellany

This week I'll be moving through my backlog of issues. QA for this game has been and continues to be an enormous task.

I've had pretty much only art and tech days for this past week, and not content. I think that tomorrow, I'll whip up a placeholder collectible item. I also want to have interactive bonfires and fireplaces. That might be a nice touch.

Hey everyone. Winter break just started, and I've begun to shift my full time attention back onto Against the Wall. I can say with confidence that I will miss the "Late 2013" deadline for Against the Wall. It's a real bummer, but I don't really have the manpower (money) to get this game completed in a timely manner. Lack of funds also means I can't be on this project full time, so I'll have to make the most of the hours that I have.

So here's the plan: I'm free until the end of January, then grad school starts again. I'm going to work every weekday, and try to post small updates each day. Every day will have a focus: tech, art, or content.

Tech days are devoted to bug fixes and optimization, which, as it turns out, is my favorite thing to do in terms of game development, concept and design work aside. Other days will focus on art development.

Art days are for art creation, experimentation and optimization through draw call reduction. Right now, I'm planing on giving the game a low-res minimalistic look. I feel I have overused realistic textures that do not fit my low-poly models. It would be easier for me to go all-in with the low fidelity models and textures, I don't have the time or skill to make anything more complex.

Content days are for the creation of locations in the game world, tweaking how the game feels, and experimenting with mechanical changes.

The last one is the trickiest. Right now, the game has immediate goals (extending the correct bricks to get from point A to B) and an overall narrative arc has been planned for players' long-term goals. What I've been struggling with are the intermediate goals: what drives you forward, what small tasks do you complete on the way, what emergent tasks could the player create for themselves, etc. Right now, the mechanics are so stripped-down that there is not a ton of room for this kind of goal. That is, there is no player inventory, no concept of, say, sleep, health, energy, etc. that would give the player a reason to create a side quest for themselves. I don't want to make to game too complex, of course, but I do think it needs something else for the player to manage besides just extending bricks. I'd appreciate any feedback or suggestions that I can get on this front.

Really, I've been playing a number of survival games lately: Minecraft, Starbound, Don't Starve, Lone Survivor, and Teleglitch. Against the Wall could be considered minimal survival game. Such games usually have a hunger stat and an inventory in some form. I wonder if I do need an inventory after all. Perhaps there is away around a traditional inventory, such as the one implemented in Miasmata.

Today's Progress

There was this bug where, when exiting one chunk of bricks, the game would completely lock-up, but only on some playthroughs. Such lock-ups usually happen when a program enters an infinite loop (that is, the program gets stuck executing the same bit of code repeatedly and cannot move on to anything else). I spent a total of five hours tracking this one down. It was a tough one to reproduce. Here was the cause: when a dynamic entity falls off the side of the wall, it continues falling until it reaches the bottom edge of the generated world. At this point, it disables itself and adds itself to a list. Now, whenever the player changes chunks, the program would check the list for any such props to re-enable them if they are close enough to the player. There was an apparently infinite loop that iterated through the list when changing chunks. The problem would only happen on playthroughs where I chucked the scarecrow entity off the side of the world, adding an item to the list for the loop to be caught on.

I did some other optimizations, mostly dealing with C# events. Boring stuff to relate, honestly.

What I'm Playing

Survival games, as mentioned. Also, The Legend of Zelda: A Link Between Worlds, which is fantastic game that brought me back to my childhood. Gone Home was a nice little story. Didn't care for the nostalgia-baiting bits, liked the atmosphere, though the architecture was rather wild (e.g. the second-story rooms are not built above any first-story rooms). I finally beat FTL for the first time, bought the PC version of Dark Souls (loved it on the XBox) and played the hell out of Spelunky. There is a free indie game called Naev that I charged through until it began feeling rote. Finally, I played Icarus Proudbottom Teaches Typing, a surreal edutainment experience in the spirit of Frog Fractions.