One of the things I am currently working on is an architectural change to the engine- previously, our most basic graphic object would be rendered with a 2-component vector designating position (translation in OpenGL terms) and another 2-component vector designating orientation, or rotation and scale. This has worked fine for us so far, but it means we have to modify the vertex geometry of the object if we want to do nonuniform scaling or shearing. Petri and Martin talked about “juice” in a great GDC talk from a few years back, and in order to make the game more juicy I thought about the 12 principles of animation – more specifically squash/stretch – which meant we needed more options. Thus, the basic graphic transformation is now described by a 2×3 matrix just like fixed-function pipeline uses 3×4 (4×4 actually, usually only the first three columns are relevant for world transform) to give us more options.
Now, I normally do not like to talk about features that are in such early stages of development – there is simply nothing here to look at, and if it doesn’t pan out there’s not much to learn from it. We do a lot of experiments in code as well as in design, and a good chunk of that work will never see the light of day. Doing this change, however, gives me an opportunity to talk a little bit about the history of the engine and the KISS principle which, when I have interviewed and evaluated engineers in the past, has been a common problem for inexperienced software engineers.
The kind of work we do can be very sporadic in that we wear many different hats as developers and without any strong deadlines we are free to experiment with things we may want to add further down the line. While being detrimental to progress (and, to be honest, maybe the biggest reason why we’ve spent so long on this), it does mean we are free to work on what we like. Enthusiasm is important too.
One of the things that we have been experimenting with is player customization – I personally have been torn on what to do with that, as we did not want to give the impression that your loadout somehow affected your ability to solve puzzles, and I did not want to make vanity items that could be confused with free-to-play moneysinks. In the end though, personal expression is meaningful and with the simplicity of our art customization is a pretty quick thing to do. One of the things we’ve created for customization is the ability for the player to change the avatar color with this hue wheel.
We have mentioned and shown a couple of times that our basic level art is mainly made out of small chunks corresponding to pieces of geometry – flats and corners with different sizes and decorations. With colored outlines and world-mapped patterns this makes it relatively quick to add basic art to a level, but depending on the complexity of the geometry it can still take the better part of an hour.
Since we are only two people with limited time, a while back we added functionality to automate the placement of these pieces – removing the mundane tasks of giving the level shape and readability to allow us to focus on the creative side of making each level look distinct.
The brush is one of the central pieces of input in Backworlds – we have gone over a few iterations on how it works and we will probably go over some more, but these are some of the steps we have taken to get us where we are. Continue reading
Most of our data in Backworlds is stored in either XML or plain text. There are a lot of benefits to using human-readable data, it is usually trivial to add or remove information to the format without destroying backwards-compatibility and it is easy to make changes even before any tools have been written. That said, it is a lot less efficient than storing things in ready-made binary chunks and to reduce the performance loss we use a lot of hashing. Continue reading
We strive to bring an element of procedural generation to a lot of the art of Backworlds – this gives us the opportunity to create large amounts of content without spending too much time, but more importantly it gives us the opportunity to animate the art from the way it is generated. As an example, this is an in-development effect regarding a smoke particle.
Hello! after last month’s overview of some of our early graphical effects, I thought I would go into a bit more detail about one of them.
I started running Backworlds on a Surface Pro recently in order to determine how much work it would be to port the game to tablets – rather than the porting itself, the big challenges are how we change the controls to feel good on a tablet. The Surface Pro is practically a laptop running Windows 8 which meant I could immediately run the game, which was nice.
Since both of the Surface models come with a pressure-sensitive stylus this also gave me an excuse to connect this to the drawing – so if you are playing the game with a digital drawing tablet or display it would be more responsive. Implementing pressure-sensitivity with SDL in Windows wasn’t a straightforward affair though, so I thought I’d collect some of the things I learned in this post.
We are currently hard at work with the leveldesign (iteration, iteration…) and working out how the themes of the game tie into the narrative and aesthetics. Taking a break from that, today I thought I’d go over one of our effects.
In the Backworlds demo, we spawn the player character into the level by gradually drawing the icon into place. We liked the effect for this and decided to try and implement it in several places, today I will give a brief overview of our quick-and-dirty solution to doing this.
Last time, I covered briefly how our playback system works within the game client – strictly speaking this is everything we need, and in the beginning it was everything we used. It did require our testers to take an active part in sending us the playback files though, besides being unreliable it put higher demands on our testers and forced them to tell us directly how much they had played – removing some of the advantage of letting them play on their own terms. Continue reading