The first Okami was a great game, but more than anything it was a game that exceeded expectations. With the Sumi-e style graphics and distinctively eastern themes it was easy to assume that it was going to be a short art game with no distinctive features but the rendering style, but it was a long and well-polished game with deep story twists and interesting mechanics. Even the painting mechanics worked really well even though the input was limited to the PS2 thumbsticks. With this in mind – and my recent complaints about DS games tending to overstay their welcome – I might not have been completely fair to Okamiden, but it still does not really live up to the legacy.

Most action-adventure games (and it seems a disproportionate amount of realtime games can be fit into this category nowadays) get some slack on one or a few areas. Maybe the fighting is really good but the puzzles trivial. Maybe it’s the other way around, or maybe they are both derivative but there is a really good metagame with leveling and character development backing them up – whatever the reason, we have gotten to the point where a long list of more or less orthogonal features are expected to be in a game, and even good games choose to focus on a few and use common formulas for the rest.

The problem I have with Okamiden is that it all feels like filler. The fighting has very little strategy to it, the story is clichéed and presented in overly long cutscenes and the puzzles does not really require anything but patience to solve. In a game with highs and lows at least there is a buildup of anticipation in the boring sections, but Okamiden never gets interesting so there is little incentive to keep playing. It’s not horrible – I would say it delivers a slightly better experience than Spirit Tracks – but it’s bland.

In fact, let me return to the puzzles for a bit since Okamiden has a particularly clear display of a common error in games nowadays. David Hellman wrote about something similar a while ago and the brilliant You Have to Burn the Rope is an interactive demonstration of the point – the solutions to puzzles are being handed to the player before the puzzles are even being presented. Enter a room with a locked door and a button and you will be told to press the button to proceed. Everytime you need to use your power to proceed in the game, the screen will focus in on the location and tell you straight up what you need to do. It is demeaning in a way, it ruins the inherent mystery of a magical world and it reduces all of the puzzles to a tedious list of trivial tasks. More importantly, it discourages exploration and makes an already linear game seem even more limiting which in turn makes the select few puzzles where you are not presented with a solution harder – I suppose in some way this is because the player is accustomed to not having to think, but I would blame it at least in part on lazy design. If you need to tell the player how to solve a puzzle, it is not a very good puzzle in the first place.

It would not have taken much to make Okamiden into a good game, just some extra time spent on any of the pieces would have made a big difference. Maybe even the extra immersion gained from playing it on a big screen would have been enough to make it more entertaining, but it does not feel interesting enough as is.

Posted on Jul 25/11 by Saint and filed under Reflections | No Comments »

/* */



… So I decorated the walls of my apartment this weekend. To be honest, this has little to do with anything else that has been posted on this blog but as this is as good a place to document the process as any I will do it here.


When starting out, I only really knew that I wanted to do tree silhouettes so I drafted up a quick blueprint of my walls in Inkscape and then made a mockup with some images of oaks I found and liked. I honestly cannot remember where the specific images came from apart from the small one which was part of the art collection by HammedHareet that we used for Backworld, but that matters little. I had been really sloppy in the exact locations of electrical outlets and lightswitches in the blueprint, something that came back to bite me later – but I am getting ahead of myself.

At this point I had cleaned up the images and made them into silhouettes. As the images had different origins I tried to make them somewhat similar – this meant adding branches to the stylized trunk and removing them from the photograph. In retrospect I should have spent a lot more time on this as some of the branches have really uneven thickness, but that is something to remember for next time.

I added the grid in order to break down the process of scaling up the image into manageable parts – it is a lot easier to replicate and enlarge one square at a time than an entire image. You are also almost guaranteed the image will not be distorted. Someone suggested I should project the image on the wall and then pencil the shapes – this would probably have been a really good idea if I had been painting, but either way I did not have the equipment for it.

Day one

It was suggested that I use contact paper instead of painting, I did some tests with scrap pieces and it worked out really well. The only downside was the poor availability of colors but since I was only going to use black anyway it mattered little. The image shows the first piece – it can be hard to see but I pencilled the grid on it to do the upscaling.

The back of the contact paper actually already had a grid, but it was in half-inch increments and my measurements where in centimeters. Had I thought about this before I could probably have saved myself some time measuring the grid, although I would probably still have had to draw it.

Finally, the keen eye will notice that the print of the pattern is actually mirrored since I was drawing on the back of the paper – not an absolute necessity, but I find minimizing the possibility of mistakes speeds up work. I had mirrored and normal printouts both with and without grid for reference as the grid sometimes obscured details in the image.

Just before attaching the first piece to the wall. It is a bit faint in the picture, but I improvised a plumb by attaching a screwdriver to a piece of thread and then taping it to the ceiling. I then taped the corners of the trunk to the wall in order to make sure it lined up properly before attaching it – it turns out I was needlessly cautious as the contact paper was really easy to attach. It doesn’t crease so as long as you get one small piece attached correctly the rest will not be a problem, and should you fail it can easily be detached and placed again.

First branches attached.  Discounting the leaf this is now three separate pieces, but in normal lighting conditions you really cannot tell unless you walk up and search for the seam.

Another picture of the workspace. The branches (as well as everything on the other walls) were drawn out with the contact paper lying horizontally whereas the trunk was a vertical piece. This made a lot of sense from an economical standpoint as there was little waste even with big pieces, but as it turns out the difference in light reflection gets really obvious when you join two pieces rotated 90° to each other. For this particular tree it was okay since it does not get hit by direct sunlight but later on I made sure only to rotate the pieces 180° on the roll.

All done with the first wall. I had to cut off and modify the right branch since I had been sloppy with placing the lightswitches on my blueprints, but other than that it was easy. Getting the first tree up took around four hours, but I was overly cautious so it took longer than it had to.

Day two

At this time, the trunk consists of four pieces stacked on top of each other. The second-highest piece, the one with the branches, was one of the longest I did for the entire project, but thankfully attaching big pieces of contact paper to the wall was no problem at all. Corners turned out to be a bit of a problem though, and I probably should have cut up the base piece in two and put one piece on each wall – making sure it was aligned with both the doorway and the ceiling while crossing the corner was cumbersome and even now it is slightly angled. Luckily, the tree itself is by no means straight so it does not show.

Second piece of the trunk done, discounting leaves it is 8 different pieces. Compared to the earlier tree this looks kind of jagged and abstract which is ironic considering it is the only piece based on a real tree, but then again I could probably have done a better job cleaning up the picture when I was at that stage. I had spent at least five hours on it at this point and it was well past midnight so the rest would have to wait.

Day three

Done with the second wall. The only difference is that I attached four branches, two on each side and five pieces in total. And some leaves. These pieces are kind of big – around one meter each in length – and while this produces a lot of waste contact paper it is a lot easier to attach it and get it to look good since it more or less takes care of itself once you have positioned it. In other words, less pieces = less attachpoints = less potential issues. Finishing up this wall took between three and four hours.

Onto the final wall, again I am placing the contact paper horizontally and building the trunk up in pieces. It is actually too wide to be made in one strip anyway. The first three pieces are relatively simple – in retrospect I probably should not have bothered drawing out the entire grids on the paper – and I am done in less than two hours. To be on the safe side I am using a plumb again but I really did not need it.

Day four

With the help of a chair, I managed to put up the last pieces of the trunk. This is now seven pieces – as many as the last tree in height, only that one had a couple of branches in separate pieces while this only has the one.

Left branch. Due to the complexity of this branch and the complexity involved in splitting it into pieces, I have now spent more than seven hours of the day. During the course of the project I have occasionally decided to change the design slightly when branches where just a bit too long to fit inside the bounds of the contact paper, but doing it too much would make the tree look ugly. An alternative would have been to think about how the pieces would be cut out when I drew the design, but I chose to work with less limitations out of personal preference.

At this point I have finished the first roll of contact paper – 18 inch by 75 feet, meaning I have drawn around 900 squares.

An image of the first piece of the right branch, and the mess on the workspace that has now begun to overflow down to the floor.

Finally done. I spent somewhere between 9 and 11 hours on this during the day, meaning around 12 hours on the tree as a whole and maybe 4 workdays on the entire project – but it was all worth it as my home is a lot less bleak now. Most of the images were taken at night with artificial lighting, but here are a couple of images of the finished pieces taken in sunlight;

Putting giant stickers on the wall is nothing new, of course, there are a few companies that specialize in just that. I personally have a Blik in my bathroom that I really like, and considering that most of my time with this went into drawing and cutting out patterns getting pre-existing decals instead would have been a lot faster. There is something to be said for decorating your own home though, and if nothing else this was probably the cheapest way to go about doing it.

Posted on Jul 19/11 by Saint and filed under Homegrown, Meta-blog | 1 Comment »

/* */



A couple of weeks back, programmer Poya Manouchehri posted a piece about pitfalls in hobbyist game development to #AltDevBlogADay, I am going to use this a ridiculously far-fetched lead-in to something I wanted to write about anyway as I liked this quote of his:

I guess if had to summarize “agile development” (as overloaded as that term is) in a sentence it would be: Write enough code to do the job, no more, no less.

While certainly not an idea unique to agile, to me it encapsulates how agile can be a really good practice – if you use the tools provided by agile to provide simplicity and focus, it can help you solve some of the issues that might pop up in game development without introducing new ones. But I am not going to write about agile – while interesting it has been a hot topic since I started working with games and I have little more to add to what has already been said. What is interesting – bothersome, even – to me is how project management practices in general are sometimes misused in small teams.

In recent years, budding studios have adopted more and more complex development strategies – at first it seemed like this was mostly out of a desire to operate like studios in the large-scale games industry rather than a way to solve a problem. There are numerous annoying results of this; projects caught in eternal meetings as all information must be shared and all sharing must be documented, small teams where individuals refuse to do any development work as they consider their roles administrative and in general projects where the integrity of the development process comes before the quality of the game.

Now, whereas in larger teams (the ones in need of a solution for communication problems) enough people might work in every discipline that solutions are needed to make sure everyone is heard, in smaller teams where people know each other and know who needs what, it is usually faster to just talk to people directly. There is some idea that bringing all decisions through a committee will help people from different disciplines reach consensus, but I would say this is rather ineffective – which finally brings me to my point.

Most people in the AAA game development industry will tell you working with people from other disciplines is difficult. It is a bit eerie, really – it certainly seems like the kind of working relationship a programmer and an artist have, for instance, would create an understanding for each other fairly quickly. While this is true to some extent, with development focus comes a set of goals, methods and priorities. Rather than making sure all details of every change is discussed and agreed upon by each discipline, we instead try and solve issues in ways that allow each other to be creative in as large a space as possible without breaking the game.

While a relationship built on virtual limitations might seem bleak compared to mutual understanding, I would say referring to it as distrust is missing the point. As a programmer, given a broad description of a system instead of a specific feature allows me to build something coherent and robust – as an artist, having tools that will not allow you to create assets that break the game allow you to think about the art instead of  the rules you need to adhere to. More importantly; creation itself is inspiring and by doing more of it we get new ideas.

Some things, like high-level design, will require everyone’s involvement – especially in small projects where people are more invested. But in terms of other things, I find that one of the marks of experience in the games industry is the insight to foresee potential and problems in what you do, and the ability to allow others to do their thing.

Posted on Jul 11/11 by Saint and filed under General game development | No Comments »