I've been spending some time redoing art assets for the game. The above picture is a new version of the first city of the game (without final textures). The city has the same two straightforward paths, but I've created some paths for people who wish to wander the rooftops. It's pretty much an optional maze. Will hide a few easter eggs in there.

I've also started modeling a small city that is inspired by Ponte Vecchio in Florence. It is a pair of towers with a causeway in between. The causeway will be lined with buildings that are hanging just off the side. There will be several paths that lead into the city, all involve some brick platforming. Here's a picture of some very early models of this city:

Everything is grey because, well, I hate texturing. I'll need to find someone to handle that aspect of the game's development. I'm still looking for artists, though I need someone who can devote quite a bit of time to the project. Meanwhile, I will keep on handling the actual model creation.

I'm going to GDC in the coming week, which will be a ton of fun. Perhaps I'll meet some artists there as well. That's it for now!

Let me update everyone on the project a bit. I've been marketing, designing, bug fixing, and getting ready for a few events. Early in the month, I made plans to attend GDC this year. My game will be on display at Kill Screen's GDC party on the 8th. This is my first GDC, and I can't wait to be there!

Tomorrow I'll be presenting my game at the New York Indie Dev Meetup at NYU Poly. I'll be doing a playthrough of the alpha and answering some questions. Also, on Thursday I'll be presenting at the NY Gaming Meetup.

On the practical side of things, I've been testing my game on various platforms for compatibility, with the help of an organization called Eyebeam. The game doesn't run well on older Macs, and Macs in general are very iffy with all the settings on. I will need to buy a mac in the near future, I think. The playtests at Eyebeam were also helpful, in terms of seeing how people play the game, where they go, and how they tackle puzzles.

Finally, I've added XBox controller support back into the game's Windows version. Other versions of the game will still the XBox controllers, but not as extensively. Today I uploaded a new version of the game with this feature added.

I've added a zoom feature, ala Portal 2. The camera's field of view becomes smaller when the player rolls the middle mouse button forward and backward. The camera is also less sensitive while zoomed in, allowing for more precision.

Players cannot fall over edges while crouching, borrowing a mechanic from Minecraft.

Detail maps for the wall are now a single image repeated at regular intervals across all wall surfaces. This was done to reduce the appearance of stretching. Also, fewer textures will be loaded as a result, as the detail map will be the same across all brick variations.

GUI appearance has been changed and key bindings work a bit better. Secondary key bindings were removed.

The wand is now incredibly tiny, rendered by the main camera rather than a HUD camera, and placed right on top of the main camera. This way the wand is able to take on the lighting effects of the environment around the player. This also means that I no longer need the HUD camera at all, meaning there is one less camera rendering objects per frame in the scene (slightly better performance).

Head bobbing is now only applied to the wand and not the main camera. Before, bobbing the player's "head" made it a bit more difficult to aim at far away objects, since any movement would adjust the position of the camera. Taking a cue from Portal 2, I took the head-bob function and turned it into an animation for the wand, keeping the camera itself steady at all times.

I've removed crouch toggling and precision jumping. These features were unnecessary, a broken, and did not really add anything to the game.

Today I released an updated version of Against the Wall! There is one new area in the forest that serves as an introduction to gold (auto-retracting) bricks. There are also a number of visual enhancements and gameplay tweaks. Most notably, there is an option for "Falling Death" in the options menu. With this on, falling at a rate of around 50m/s (~112 mph) causes the player character to die upon landing. It is off by default, but I would still like some feedback on it.

I've been working on this update for much of the past two weeks. Some of the gameplay additions from December and from my time in Texas are not a part of this demo. Rather, those art assets and brick types will be saved for closed beta releases and the final game.

This week my composer Zoe Blade will be working on the soundtrack for the game. I'll get back to you with updates on how that goes. Also, I'm going to begin looking for artists in earnest now. I'm at a point where the game is playable and fairly stable, and I need to populate the world with interesting environments and events.

Last weekend I was with relatives in Austin, Texas. Not much of a vacation for me, especially since we were on the outskirts and did not go out much. No matter, I got a ton of work done with the game.

After two days of solid work, I created inverted "cave" bricks. Rather than move out from the wall and into the sky, these bricks move into the wall, forming recessed shelves. This brick type would break how the game world was originally programmed, so a ton of work was needed to get them to work.

I won't keep you in the dark about what I did, but this will be a bit technical: The wall is divided into small grids called "chunks", each 64x64 meters in size. Each chunk has one box-shaped collider which covers collision for all the bricks that are flat on the wall. Cave bricks would require me to punch holes in this collider, which really isn't possible. However, the scripts that detect, highlight, and interact with bricks all require the box collider. Solution: If the chunk generator finds an cave brick, it turns the box collider into a "trigger," thereby removing normal physics collision but allowing the brick manipulator to find bricks on the wall. The game then generates a complex "mesh collider" that is based on the mesh used for the chunk's bricks, only with holes where the cave bricks are. This mesh is placed right on top of the trigger and is used for physics collisions with the player and other objects.

In the process of solving some problems with cave bricks, I had to invent "persistent bricks." Normally whenever a brick is flat against the wall, it has no collision or scripts of its own, it shares all of that with the chunk that it belongs to. Special bricks would become inactive as a result. For example, bounce bricks would stop working while not extended. The solution was to add a function to the bricks that would prevent them from being assimilated into the wall. Cave bricks have special scripts that would be lost if they ever merged with the wall, and this prevented that problem once and for all. Also, bricks that surround the cave bricks would have to be persistent to ensure that their full geometry is drawn when flat against the wall. Otherwise, only the front face is drawn and the cave bricks would expose the undrawn areas.

The whole process was actually much more involved than that, as issues kept popping up that required solutions. The most typical problem was the frame rate dropping because of too much memory being used to generate all of the cave bricks, the geometry of the persistent bricks, and the mesh collider. I eventually whittled it down so that now the performance cost of a chunk with cave bricks is only a little worse than a normal chunk.

Since the weekend, I redid the cloud system so that the meshes are procedurally generated and all use a texture atlas. This will save a bit on performance. I also created bricks that auto extend once retracted, fixed a bug with the cave bricks and optimized their generation, and compressed the brick texture atlas so that it runs faster, using less memory. That's just about it for now. Will keep you all posted!

EDIT: Added the image and adjusted the title, and elaborated more on persistent bricks. I've also decided to rename the inverted bricks a "cave bricks", which is a bit more descriptive.

Minor update: The past week I spend a lot of time making a number of refinements to the game world.

Fall damage will now be in the game. Movement speed of the player character (PC) when hitting a surface determines how bad the damage is:

< 20 m/s, the PC will land safely.

At 28 m/s, the PC will stumble but can still move.

At 36 m/s the PC collapses into a heap for a second or so.

>45 m/s the PC will die. (Terminal velocity is 60 m/s).

Of course there are huge liberties taken with physics for playability. The PC has to hit a surface at 98 mph in order to die! Even though this is generous, it still only takes three seconds of falling to die (a distance of ~60 meters). To do: I'll also make this damage cumulative. PCs will die if they receive a good deal of damage over a few seconds.

Fall effects were added. The camera will change its field of view when the PC moves at high speeds. The FOV is corrected as the PC slows down. There is also a special wind sound effect that gets louder as the PC's speed increases.

I added dust special effects to the moving bricks as they come out of the wall. To do: add these effects between extended bricks that are moving.

I changed the side textures to mitigate some of the stretching. It is still noticeable, and I will eventually have to split the textures between high and low res.

Optimized some of the audio scripts and fixed a a few glaring bugs.

My next step is to create two new brick types: inverted and auto-extended. Inverted bricks go into the wall rather than out. They are rather difficult to pull off, since they require special treatment with regards to the procedural generation script and they modify the bricks that surround them. It's complicated. Auto-extended are the opposite of the auto-retracting gold bricks, they always pull themselves out when pushed in, forming barriers that the player will need to dig past.

Also, I am visiting family in Texas tomorrow. I'll be working via laptop during this time, but I do not expect to get a lot done until this Sunday. I will need to release a testing version of the game to my beta testers in a week or so, to test the falling mechanics and brick types. That's it for now.

I didn't exactly go on vacation this weekend. I was working pretty much non-stop, save for a family function:

I fixed problems with the texture atlas generator, which will allow the wall and bricks to use multiple textures with a minimal performance cost.

I created a new brick type: bouncy bricks. They function similarly to the repulsion gel from Portal 2. When you bump into one, it throws you into the air with a force proportional to your speed before you touched it. Unlike repulsion gel, you cannot safely walk on top of it before jumping, it will launch you into the air as soon as you touch it, and it has a strong minimum force. It's a ton of fun to use, really. Also, since I arc the player slightly upwards, I'll be able to set up puzzles where the player is bounced around the world like a pinball! Bounce physics also apply to any dynamic objects in the environment (that is, non-kinematic rigid bodies)

I also tweaked the physics for when players hold objects to run more efficiently. Still need to fix some of the jittering that happens when pressing an object such as the scarecrow into other objects.

Also, the shader for clouds has been tweaked so that they now interrupt the sun's rays. I also experimented with giving shadows to clouds, and for darkening the sky when the sun is behind one. However, I did not like how such effects interrupted gameplay. It is harder to make out individual bricks when there are always random shadows moving over them.

Following a suggestion from 3phen, I've changed the player's hit box so that he fits into 1x2 meter areas easily. In addition, the player model will no longer be caught on the edges of bricks when being pushed.

Here are a couple of shots from two sets of models that I whipped up yesterday. Note that they currently lack any textures.

Following my decision to go big and physically-incorrect, I've created new assets for a farm set and a mine set. The farms (first picture) have fields suspended in the air from giant metal rings, and are fed water from tanks. The player's path will cross by a few of these fields, though most of them will be there for decoration to give the impression of an expansive farming community. Some other field models will be built for resources that grow on vertical surfaces. There will also be granaries, farm houses, and sky piers.

The second set is for a "mine" area. Mines explain where metal and stone resources come from. Players will be able to step slightly into The Wall from these mines. The super-structure that extends from The Wall includes a storage platform that is connected to a short pier. Above the pier is a rail for a crane.

Will be working on some brick types for the rest of today. Will keep everyone posted!

Over the weekend, I produced a (mostly finished) game called Abandon for the Ludum Dare competition. I've learned a lot from this experience, and will be incorporating scripts, artwork, and concepts from my project into Against the Wall. For instance, large-scale buildings based on real-world architecture.

During the competition I realized that I wasn't experimenting enough with my designs. I was being too practical, thinking too logically when it came to the physical scale and structure of buildings. How would a dome or arch work structurally if it is sticking out of The Wall horizontally? Wouldn't a tower be useless if there is always higher ground? Where would people get the material for all of these buildings?

These questions are a bit similar to the one that I keep getting about how the trees stick out horizontally rather than face the Sun. One answer: Every tree uses the same model at various rotations, in addition to the Sun moving in a circle around the sky. I would have to create a large number of tree model variations AND animate them in order for the trees to face the Sun constantly. Another answer is that they are not really trees.

The gist of what I'm saying is, If I bind myself to a conventional understanding of physics, I may have fewer people questioning the game world but I also limit what I can do there. Remember the size of the facility in Portal 2? That game was set on Earth, and the physics and logistics of the whole complex make no practical sense whatsoever! The game was so cool that people suspended their disbelief and just enjoyed the ride. It would be presumptive of me to suggest that Against the Wall is as cool as Portal 2. However, the underlying premise of my game is as absurd as quantum tunneling devices and sentient robots.

I'll concentrate on making a strange, gigantic world that is fun for people to wander around, above all other considerations.