Anders wrote a couple of weeks ago that I will be taking a break from Backworlds development and I just wanted to elaborate briefly on my reasons.
TL/DR – the news I have to share this month is that Juha has decided to take a less active part in development for a while. I will let him elaborate on that on his own, but development on Backworlds continues and he will remain involved in all non-trivial decisions regarding the game.
To elaborate on the state of things on my end, I’m going to go into some history after the break…
Keeping the trend of “things that have been disproportionately helpful” from my last technology posts, today I am going to talk a bit about why curves are awesome. I am a bit late to the party on this one so if you have been working with particle effects during the last five years or at all with animations then chances are this post will not give you a lot of new insights. Sorry!
We have been thinking about and working on themes and art styles for our different worlds recently. I made a mockup in Photoshop for our inverse gravity world and thought I’d record the process of beginning to implement it into an actual level. The inspiration for this theme is, vaguely, Leonardo Da Vinci machines and Treasure Planet (which in my mind is easily the coolest Disney movie thematically). This obviously needs a lot of more work, it’s only the beginning stages, but should give you and idea of the direction. Some of the art assets I made before I started recording.
Music: Final Fantasy X – That’s Besaid The Point OC Remix by Anticitizen
The Backworlds editor is, as we’ve previously mentioned, a set of menus in the game itself allowing us to make changes to the levels as they are being played – rather than being built from the ground up as a level building instrument it has been patched together over time as tool for manipulating game data within the context of the game. While this has the advantage of really short iteration times, it has the disadvantage of being slightly inconsistent and with a quirkier workflow than an actual level editor. I am no expert in either usability or data mangling, but for a small project such as ours I have noted a few small changes that had a big effect on workflow.
Following up the video about one of our previously scrapped worlds, I show and tell a little about “time”.
Apologies for missing last month’s update – this was partly due to a personal hardship, lack of time due to day jobs and other obligations and – to be quite honest – a lack of things to write about. We have been refining designs for some time now and while it can certainly be interesting to look at individual puzzles and see how we changed them in response to playtest feedback, doing so now would be premature as we are not done with them. Also, it would spoil the puzzles themselves.
This month, I am going to tell you an anecdote about a bug hunt that was somewhat amusing as it illustrates the cascading effects small changes can have on a codebase.
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.
I want to write about my own fluctuating motivation for Backworlds this month, this will be mostly personal so I won’t go into Anders feelings on the same subjects.
Our progress has been slow the last half year, with some stints of hard work with building level progression, adding some new mechanics and preparing gameplay tests. Just like Anders I have a full-time job within computer software and I find it exhausting to sit at the computer 8 hours a day and then go home and work for several hours more on our game. Which I have done in certain periods, but I personally can not keep it up for too long. Besides the mental drain it is plain bad physically to be static that much of the day and it is not very social so it takes a toll in several ways.
I do constantly think about the game however as me and Anders discuss it every week. At the moment we are talking a lot about how to present the story and we are experimenting with different implementations. It certainly helps to have another person to keep you on your toes and not procrastinate too much. The fact that we have people that have contributed money to our development and that there are people who seem to like the game is also very important and helps me keep coming back to it.
Perhaps it sounds like I have to force myself to work on it, but I really do love it. It gives me artistic satisfaction in a way nothing has done before. I’m proud of what we are making together and I want to make clear I’m not looking for sympathy about my “exhaustion” mentioned above. I only want to explain and perhaps you can relate to this if you are within software/game development yourself as many of us tend to have hobby projects.
Thanks for reading!
A few months ago Juha talked about our “no paint” levels and why we decided most of them had to be scrapped – today I will briefly go over some of the ideas we toyed around with in the original “Backworld” prototype and why they had to go.
The game was made in a very limited time – we were not really sure what kind of game we wanted to make and we opted to make many levels rather than a small amount of polished ones, so cutting these ideas were not as tough of a decision. Nonetheless, it explains some things about the nature of the game as it is now.