Texture Tweaking

Against the Wall Brick Textures

I’ve given the different brick types their own textures. This adds a bit more variation to the wall, in addition to making the brick stand out a bit more in contrast to each other. Also, this will hopefully help color-blind people differentiate between certain brick types immediately. The way things are currently set up, bricks will be sharing the same five textures drawn from a 2048×2048 image. I may bump the size of this image up to 4096×4096 and have twenty-one different textures to choose from, but much of this could be wasted space as there are only about twelve brick types planned. There are actually two textures per type, one for the front face and another longer one for the sides. This helps reduce some of the stretching on narrower bricks.

I had implemented multiple brick textures in the past, but the results were not satisfying to me, appearance-wise. I think that it finally looks presentable enough. Part of the problem is the distortion and stretching that happens on the brick side faces. It is really noticeable when a texture has been smashed into a narrow space like that, especially if the texture has many little details. The texture for the regular white bricks is passable in this case, being mostly noise without distinct features. One solution would be to up the size-up the source image and include texture variations for each brick size. Right now, things are passable, so it is not really an issue for me. I should not be spending too much time on such finicky details, rather concerning myself with more level design.

Practice Makes Perfect

Right now, I am preparing for an event at NYU called Practice; I’m attending it as a student of the NYU Game Center. So far, this semester at NYU has been an interesting experience. I can summarize it as a series of game jams laid back-to-back and overlapping. Physical games, digital games, board games, etc. just cranking out new things all the time. It’s been giving me a ton of new ideas for Against the Wall, in terms of goals, set pieces, and art.

Art in particular has been by current focus for the game. This past Summer, I spent too long on optimizations and basic functionality. This was a task that could have potentially gone on forever, there is always something that can be improved. It is much better to get things to a working state, then moving on to other tasks.. As a result, I have not been touching code outside of bug-fixes and tweaking the game’s feel. I’ve been experimenting with and churning out art assets, then testing them as level elements on the Wall.

My current strain of thought is to continue embracing minimalism and using my limited talents in the area of modeling and texturing as a constraint, rather than as an obstacle. The art style of the game will be guided by what I am capable of using the tools and skills I have, rather than stress out over not looking like an Unreal engine game. I’m making the art according to a set minimalism theme, then moving on before I become obsessed with details.

I’ll post some screenshots later. Right now, the event has already started and I should go out there and mingle a bit.

IndieCade Recap

Against the Wall at IndieCade

The other week my game was featured at IndieCade. I traveled out to Culver City in LA to show off my game in the “Digital Selections” tent. First, I participated in the IndieXChange, a meeting of many of the devs who submitted to the festival. It was an interesting meet-and-greet, and I felt at home with all the other New York City people who were there. The following days were spent inside the tent, which was rather packed. I had to do a number of random bug fixes that patched over issues that broke the save function.

IndieCade Selection 2012

While I managed this fix, auto-saving at checkpoints just was still not happening. Despite this, people managed to climb up to the forest area without too much difficulty or falling at all. I spent the better part of one day just sitting back and covertly watching people play the game. Having the developer hovering over somebody’s shoulder can be intimidating to some, and certainly changes how people play. At no point did people seem lost or frustrated with the controls, so that was a huge relief. I managed to get some good feedback all-around.

This past week I gave a short talk at NYU that was supposed to be me going over my IndieCade experience, but instead I just went on a rant on my ambitions for this project. All well and good. Met a few fans of the game there as well!

Right now, my plan is to submit to a few festivals and also get a Greenlight page up as soon as possible. I’ll need to create a new trailer at some point soon as well. If anyone is willing to assist me in creating a video for credit in the game, send me a message through the site’s contact form.

Recent Changes

Current Events

Against the Wall is now one of IndieCade‘s Official Selections. This is still an honor to be recognized, even though I didn’t get a nomination (there’s always next year!). Also, this Wednesday I’ll be showing off a newer version of my game at the NY Game Conference.

Yesterday was my orientation for the NYU’s new MFA program for Game Design. I’m very excited to have the opportunity to attend and act as a pioneer for future graduate students at the NYU Game Center. There are 18 other people attending the program, coming from a variety of backgrounds and skill sets, all with a common passion for game design. Keep in mind that Against the Wall is still my full-time job, and that I’ll be working on it in tandem with school work.


Last weekend I attended the Babycastles Summit. I define Babycastles as a DIY arcade hacker collective. They often take existing games and build unusual interfaces around them, such as Ms. Pac Man played on the walls and ceiling of a room or original Mario Bros with an unwieldy giant controller. Also present was my friend Joe Kowalski, a graphic and interface designer at Double Fine. He had a great presentation that centered on doing things that he was never asked to do at work. For instance, when at Harmonix he designed the Guitar Hero logo in his off hours, and did the same with the Rock Band logo later on. He also designed the main menu interface of Double Fine’s Brutal Legend without initially being assigned this task. Kotaku’s Evan Narcisse did a write up on Joe and his video pitch for Guitar Hero III (which was not adopted). Continue reading “Recent Changes”

Game Feel

Last weekend I attended a class on “game feel” taught by Steve Swink of Blurst fame, now of Enemy Airship. The whole class was about how tweaking small details of a game’s design can contribute to the player feeling more connected to the game world. Basically, input response time, responsive special effects, good sound design, intuitive controls, and cohesive rules all contribute to the player suspending disbelief and becoming immersed.

Steve actually canceled a few projects because the “feel” was off. It’s my hope to learn from his experiences to improve Against the Wall. Here is my takeaway from the class as it relates to Against the Wall:

  • As a general rule, all input-response time should be kept below 240 milliseconds, otherwise people will experience a disconnect in the actions they are performing. Anything below 100 ms is an optimal speed to shoot for. According to the human processor model, humans can’t really process their senses faster than this, on average.
  • On slower machines or when the framerate dips, there is more lag between the input and response. Sometimes, jumping can take a full second from when the player hits the spacebar. This was because the movement script was being updated at fixed intervals of time while the input of pressing a button was measured once-per-frame. As a result when the frame rate went down, the gap between the fixed interval and a frame update would increase dramatically. I corrected this and measured the input-response gap. It’s now around 50 times faster on my computer! (Note to Unity developers: Avoid using FixedUpdate() for anything besides physics calculations. I was using this for the character because I wanted a time-dependent update, but that could be easily be implemented by checking to see if the game is paused each frame in the Update() method.)
  • When players run, jump, or land, they should kick up dust at their feet. There should also be more visible dust generated whenever a brick extends or retracts fully.
  • The wand and its animation do not reflect the pulling and pushing of bricks. I’ll have to redesign the wand or tweak these animations in order to make shooting feel more connected to the effects that it has in the game world.
  • Players can feel disheartened falling short distances. This can lead to people save-crawling through the game or quitting when obstacles seem insurmountable. My solution to this would be to improve the feeling of jumping, slow the player down at the apex of the jump, giving them more air control, increasing the jump height by a tiny amount, and saving the player if they just barely miss the edge of a brick that they are jumping towards. Hopefully these changes will mitigate some frustration.
  • I need to create some more ambient, softer sound effects. The current footstep and wind sound are too harsh for my liking. Also, too much time passes between each footstep.

I’ll be getting a copy of Steve’s book to see what else I can do to improve the feel of the game. Continue reading “Game Feel”

Blocks Result

Building Blocks

Since the last update, I’ve been working on several tools that will help speed up the game’s production. My most recent tool is something that will help me with art and level design. It’s a Minecraft-like block based construction tool. Basically, I can create procedural structures out of a set of textured blocks. This first point wasn’t hard. I have experience with procedural generation, as you may know, so it took me all of a day to implement a basic block system. The hard part was adding details to the blocks so that they wouldn’t appear flat and boring.

  • This will supplement actual modeled props, and will be used mostly for generic shapes, platforms, and planning.
  • It isn’t a feature of gameplay as in Minecraft. This is for internal use.

Here is the result. Keep in mind that the game is still an alpha and the art is not finalized.

Blocks Result

In the above screenshot, we have a cluster of wooden blocks with a thick trim around each block, with small cubes at the inner joints that cover up some gaps. The trim expands to surround the structure as blocks are added to it.

Low Quality Block House

Here, I quickly expanded the cluster from the first image into something that vaguely resembles a shack. Right now the only texture is “wood”, and there is only a basic set of trim objects. The next phase is to add some variety so that I have the materials to create complex structures. Continue reading “Building Blocks”

Forest Biome Windmill

The Forest Biome

This was a very productive past week, especially with regards to the “Forest” biome. First, I added a persistent “pollen” particle effecThis is to add some movement to the world around the player, here in the form of bright yellow puffs floating about. Second, visibility decreases when the player enters this biome and the lighting/fog is tinted green. As you can see in the pictures below, the trees form a sort of canopy that blocks out the sun. It makes for a very moody experience.

I also decided to scrap my hand-designed tree models in favor of procedurally generated trees. Unity has a tree-generating engine that I understand is based on middleware called tree[d]. The upside to using this engine? The trees models are made on the fly, taking up little space, and I can revise their appearance with a few clicks. The trees now gently sway in the wind, they’re dynamically animated, and they also cast some performance-friendly shadows. They look rather pretty as well, putting my own models to shame. The downside? Well, Unity’s trees work best when attached to a “terrain” system. The terrain creates the tree’s colliders, batches them together to make the game run faster, and also replaces them with low-poly trees when far away (LOD). Also, without the terrain the procedural tree will not randomize, which means that every copy of the tree will look exactly the same as the first.

I managed to jury-rig a collider by taking the tree and stripping out the leaves. These mesh colliders are high-poly and taxing on the system, so they will only be generated when needed, really. I’ll need to find a way to efficiently simplify meshes in Unity before I can freely apply this collider. I’ve also planned my own LOD alternative, but that could take a while and it isn’t a high priority.

Finally, In the third picture below you can see the green and orange bricks snaking through the forest. I’ve managed to procedurally replicate the patterns that I manually created in the alpha demo. The paths all connect together and pass under the trees, forming random mazes and obstacles.

I’ve also been implementing some new editor tools for my own use in speeding up the game’s production. I’ll do a post on that when it’s nearly complete. In addition, I’m ditching the simplex noise generator as a way of determining biomes, favoring a Unity-ported version of the LibNoise library. I’ll be using Robert Whittaker’s biome graph as a guideline, the same graph that was used by Notch for Minecraft. From what I understand, this means generating two sets of noise data (one representing rainfall, the other representing temperature) for each chunk. For example, if the rain variable is low and the temperature is high in one chunk, it would be a good spot for a desert biome.

Forest Biome Windmill

Forest Biome Trees
Forest Biome Wall

A New GUI, Sound Design and the Beginning of Summer

This past week, I’ve completely converted the game’s menu interface so that it uses the NGUI middleware for the Unity game engine. It’s a real joy to work with, especially compared to my old system, EZ-GUI. The old interface system was a huge pain to use, hasn’t been updated in over a year, and produced low quality texture atlases that made everything look blurry. I was able to recreate everything in NGUI in a fraction of the time that it took me to put the old interface together. In addition, the new interface can be navigated using a controller, which is a must-have feature in case I get the opportunity to port the game to a console.

Also, I recently purchased some sound recording equipment: A Tascam recorder, carrying case, a boom mic, boom pole, and a bunch of cables. I’ve been playing around with the equipment, trying to get the feel for using it. I don’t have much experience with sound recording, but it’s one of those things that I’ll have to learn to complete this project.

On the art front, last month I created a number of sets that essentially function as levels for the game. I did some research as well, playing Journey for the first time and replaying Ico and Shadow of the Colossus. I also managed to play a bit of Skyrim at my friend’s house… that game is mighty pretty. Anyway, what I drew from it all was this:

  1. There seem to be about 4-5 different tree types in the central forest of Shadow of the Colossus. One of them is a very tall tree with leaves that form a canopy, blocking out the sky. Also, the fog/lighting in this area tints slightly green and sunlight becomes more scarce (Minecraft and other games do the same thing). I have created a canopy tree type, and will modify the biomes so that light/fog gradually change while wandering through them.
  2. I’m keeping my minimalistic art style, but will be emphasizing the blockiness of it all. This isn’t to the same extent that Fez takes it (even the trees are boxy in that game). Rather, I’ll be creating/modifying structures so that they have rectangular molding, with more hard edges and 90 degree angles.
  3. The game will no longer use texture atlases, save for the GUI. I will be using mostly generic textures (wood, stone, metal) and applying them to surfaces as needed. This will slow things down a bit as objects will have to be redrawn for each additional texture. However, it will reduce the amount of work that needs to be done for each model, I would be able to apply procedural textures to the models, and it would reduce the overall file size of the game. Really, I have hundreds of untextured models to work through and I cannot make atlases for them all.

Finally, I was interviewed by Kevin Ohannessian for an article featured on Gamespot! Also, Adam Smith of Rock Paper Shotgun covered my game for a blog post. Thanks guys!

Biomes and Getting Lost

For the last week I’ve been experimenting with biomes, ala Minecraft. Basically, I was successful in creating some randomly placed forests using a simplex noise generator. Perlin noise is widely used, so there isn’t a ton of support out there for simplex. However, simplex is faster comes out with nicer looking results. Since I’m a freak for optimizing code, I couldn’t let myself use Perlin. The results are pretty cool. The next step will be to tweak the borders of these regions and make sure that they blend into each other. Right now, there are hard lines between regions. Blurring these lines has been a bit tricky, but I can handle it.

The only real problem that I have with biomes is that players may go out to explore these areas rather than follow the linear path that would take them further up the wall and through the game’s story. I wouldn’t want someone wander off to some random volcano in the distance thinking that they can get a boost there, when really the nearest elevator is a kilometer in the other direction. It’s a linear game set in an open world, so there is a real possibility that players could get hopelessly lost.

My solution may be to have a system that clearly defines waypoints for the player. Mirror’s Edge had a button that would turn the player to face the next waypoint in the sequence. The challenge would be to teach the player to use this function. I’ve designed the game to be mostly intuitive, using WASD + mouse controls. Adding another button to the mix is unintuitive, which means an on-screen prompt/tutorial would be required. I have been resisting adding unnecessary complexity to the game, but this may be unavoidable.

An alternative would be to have some clear and consistent visual signal that would indicate where the next waypoint is. A light, a flag, etc. would serve this purpose. Will have to experiment a bit with both systems and see which one works best.

Oh, and Against the Wall was featured on Giant Bomb the other week!

One-Year Anniversary

I’ve been developing Against the Wall for over a year now! Working on this game has been a life changing experience. For instance, it has helped me get into NYU’s new MFA program for game design starting this Fall. This could slow down production of the game a bit. Then again, I may be able to form a team using the connections that I form at school. Who knows? I’ll be playing it by ear, and doing my best to complete as much of the game as possible before the school year starts.

Last week I was on the Kickstarter panel at NYU Poly, describing my experience with crowd-funding and giving my advice on the subject. It was a good experience for me, even though public speaking is not exactly my favorite thing in the world.

This month I’ll be concentrating on level design and creating models. I really need to flesh out the world and create more locations for players to explore. My current goal is to design four levels by the end of this month.

Bridge Town

I’ve completely redone the bridge town that I modeled several months ago. The old design felt  boring to me, and I wanted something more imposing and unusual. I’ve created a set of tower models, redid the bridge structure, and added some interior locations. Note that the textures here are all temporary placeholders. The level is straightforward, requiring players to climb to the top of the towers in order to access the upper portion of the town.

Bridge Town Exterior
Wide shot of the town.
Bridge Town Street
On the street of the lower bridge.
Bridge Town Tower Interior
Inside one of the towers.

Windmill Varieties

The people of the Wall rely on the wind to power their technology. I’ve modeled a variety of windmills that will be placed around the environment, connected to devices, machines, and so on. These models are mostly based on windmills found in the Prince of Persia game from 2008. There are two vertical-axis windmills, a hexagonal windmill with 6 triangular vanes, and a corkscrew shaped windmill (retooled from a model that I made in December). I’ll be sure to add other wind-based power sources as I develop more levels for the game.

Windmill types.
Double-vertical, vertical, hexagon, and corkscrew windmills.

That’s it for now. I’ll update again once I have more to share.