Kickstarter and Official Game Title!

As the end of development nears, we decided to put together a Kickstarter page to help us secure a bit of additional funding and push to the end. For those that don't know, Kickstarter is a great site that helps small companies or individuals get creative projects off the ground. The neat thing about the program is that people who help fund a project receive special gifts for their support. In our case, people who help us out will receive things like a poster, original art, soundtrack, special thanks in the credit, or, of course, a copy of the game!

We are really excited about the opportunity to get people more involved with the development process and hope that you or someone you know chooses to partner with us! The other big news today is that we have decided to use our Kickstarter campaign as a platform for officially announcing the title of our game:

That screenshot is from the in-game title screen, and is also a first peek at the art style that will feature in the game's cinematics and character portraits. The name "Fara" is derived from Old Norse, meaning "to travel", and plays an important part in the game's story. If it sounds strange, don't worry! We will reveal more about the world of Fara soon! Also, we'll be sure to give several updates regarding our Kickstarter progress, as well as an outtakes video revealing just how many takes it took Texel and I to make the video for the site. So stay tuned!

Texel’s Technical Tribulations Pt. 4

Following along with our discussion of sounds, I wanted to talk about the sound system. Currently, it supports Wav, Flac, and Ogg. We support wav since it's the most basic sound file to support. I wanted to support Flac files mainly because we develop on a remote subversion repository and I wanted to be able to commit lossless files while still conserving bandwidth. Ogg was chosen over Mp3 because of the licensing issues associated with Mp3 decoders. Now, the iPhone has its own decoder, but it is only supported on iOS devices (I plan on one day porting this over to the Android, and I wanted a cross platform solution). It may still be prudent to hook up the hardware Mp3 decoder for music (I'm playing this one by ear, hehe, right now).

Most of my codecs are using open source projects from Xiph.org (Their website has been very helpful). For future projects, I am very interested in there CELT codec (though it is still in heavy development).

I don't have this fully setup, yet, but one of the things I'd like to support is letting the build system control the Ogg compression quality, sample rate, and maybe even the mono versus stereo. The idea is to have a config file that defines platform specific settings, and then during build, it converts it to those settings. This would be nice, because right now one of the limiting factors on the quality of music is package size (We're trying to be under the 20MB limit for OTA downloading). We have a lot of space consumed by the in-game textures, and I'm not sure exactly where we'll be at the end. So, it would be nice to very easily tweak a couple of settings until we find the right number (alas this may not happen for this project).

The next big thing I hooked up for the in-game effects is the notion of location-based sounds. This was a little tricky given the top down perspective. Make the sound listener from the players perspective was disorienting. In the end, we create the sound from the user's perspective (emitters on the left side of the screen play out of the left speaker). Also, the further the camera is from the sound, the quieter the sound will play.

The last thing I will definitely need to add is to move the audio streaming into a separate thread. I've noticed some hitching when I page textures in and out.

Maximum Tune-age: Your Game Needs Music!

Ableton Live WorkspaceFirst off, we'd like to apologize for the lack of frequent posting in our development blog. We've been working on the game very hard as of late, so it has left little time for updates. But, never fear! We promise to hop on every now and again to share our thoughts as the game continues to come together.

Texel recently completed development on the sound system for our game, so lately we have been implementing sounds and I've been writing some music for the game. I thought I'd share a little about this process, as it's been some of the most fun I've had working on our project! First off, I primarily use Ableton Live for my writing, and recommend that anyone with interesting in recording check it out! I've used Logic, Protools, etc. in the past but I really prefer Live and the way it seamlessly lets you try out different compositions. It's fairly user-friendly and there's some great documentation online for getting started with it.

As far as the style of music in our game, I knew that I wanted it to be reminiscent of past classics like Zelda or Ys, but I didn't want to completely ape the chiptune style. I also really enjoy symphonic scores in games, so I decided to incorporate a mix of string samples with old school synthesized sounds (primarily square and triangle wave). So far I've been quite pleased with the results, except for one major issue. Due to our desire to squeeze the maximum performance from our game, we decided to go with 22 kHz, mono .ogg files for our music. Initially, this lower quality did not make too much of a difference (many of the monosynth style sounds I use have quite a bit of noise anyway), but my string samples were really suffering. In order to alleviate the issue, I have had to make sure to stay within a certain "safe" range for my notes (nothing too high or low), as well as avoid too much violin in string sound. As a result, I think I've been able to get pretty good results.

The final thing I'd like to mention in relation to our music is the mastering process. I can't stress enough how important it is to spend some time mastering your music, and trying out different settings with whatever mastering software you use (I'm using some that came with Live). The difference between different levels of compression is pretty amazing, so its worth experimenting some especially when working with music that eventually gets crunched down to 22kHz mono. For instance, I have found that using triple compression (usually a technique used in the loudness war) works well for dealing with our limitations. Additionally, it really helps to have all music at a similarly normalized level, so you don't have to spend all day fixing levels in the game engine itself.

As a final note, we'll make the music from the game available as a full album once the game is released, so be on the lookout!

What's Old is New: Finding the Retro/Modern Balance

Recently, The Smithsonian American Art museum unveiled the winners of a 2012 exhibition that will display videogame art. Out of the 240 nominees, 80 were chosen, and, for the most part (uh....I'm looking at you Battle for Middle Earth II) the choices were sound. Because videogame art seems to be getting a lot of press lately, I thought it would be a great time to discuss the art style for our forthcoming game.

Before starting our project, I thought a lot about how our game should look. We knew it was going to be 2D and I knew that I wanted it to have retro inspired look. However, with Texel's engine, we could do a lot more than simply draw sprites or tiles (as I mentioned in one of our earlier posts), so I also knew that I wanted to incorporate some more modern aspects (like particle effects). The final piece of the puzzle was the fact that the entire game world would be one, large single canvas.

I quickly came to the conclusion that the world should be a highly rendered, painterly environment. With the ability to work on such a large canvas, and no need for repetition, this was a natural choice. Next, I needed to determine the look of the painting. The past few games I've worked on focused more on layer styles in Photoshop, mixed with clean design and occasional cartoon exaggeration. I love this sort of style, but I knew for our game I wanted to try something different, so I opted for a super saturated, detailed oriented look. Also, I made sure to paint from a predetermined palette for each world area, so all of the colors would feel unified. Working in this way has been really enjoyable, and I've loved trying to pack as much detail into every screen as I can.

Once my first area (a beach and a forest) were complete, I began to think about how the characters in the game should be portrayed. My initial impulse was to paint them in the same style as the background, but this yielded terrible results. The main issue was that the characters meshed too much with their surrounding environment, and the whole thing started to feel muddy. Without the ability to easily tell environment from character, I worried the gameplay would suffer.

At this point, I started thinking about past games I've played, in particular The Secret of Mana (which can be found in the gallery at the top of this post). This Super Nintendo classic used outlines around all of its character sprites to differentiate them from the world. As a test, I took my test character, drew a hard black outline around him and placed him on top of my world canvas. The effect was a success, as an easy distinction between the character and the world became apparent. The only remaining issue was that the highly painted character looked out of place with a black outline, which was more reminiscent of classic games (try this site out for great examples of old school pixel art). I tried redrawing him with a more retro inspired flavor and found it not only unified him with the black outline, but the different style helped him stand out from the world even more.

As time wears on and I draw more characters for the game, and look at my completed environments, I feel that I have developed an art style that is beautiful without intruding on gameplay. Because in the end, the game's art style should compliment the game design. After all, that's what makes a video"game" fun, and video"art" something you were forced to talk about in your college art history class.

Texel’s Technical Tribulations Pt. 3

The next programmatic problem I am tackling is the one about save games. Now, first I'd like to preface this discussion with several limitations in common save game implementations.

The first limitation is the notion of a version history of a user's particular progress. Most games don't really handle this, you either have multiple saves that can be like a history, or you just don't have one at all. There are several saved game bugs that can be difficult to diagnose, and would be easier with a kind of built-in versioning system to saved games. Imagine a player gets assigned "Quest A" and does part, but not all of it. Then the player decides to start and finish Quests B-E. Lastly, they go back to A only to find a bug, and the quest is broken. As a developer, you typically would load up the save, and see why its broken. However, lets say its broken because a value in the actual save file is wrong. The problem is when did the value become invalid? If you don't have multiple saves, then all you can do is ask the user (Beta Tester if your lucky), and you'll get a laundry list of things to try to reproduce (which may or may not be helpful). For the most part your simply SOL. However, lets say you have multiple saves. In this case you have a little more to work with. You could manually go through the saves and load them up and look for the 2 saves that represent the region where the value became invalid (It was fine in Save X, but broken in Save Y). This is usually a fairly tedious process, but it is your best bet. Bottom line is this is something I'm hoping I can improve upon.

The next limitation of common save games (actually more of a missing feature), is the ability to transfer your saved games. Lets say you have all of these: Mac OSX, iPhone, and iPad. And lets say you really, really like a particular game and so you download it on all three devices (Play on iPhone while waiting in line, iPad while on a plane, and Computer while at home). Now, the problem is you can't really play the game on all three because your save is only on one. However, many large game studios have started working on putting saves games in the cloud (Mainly Valve). Again, this is something I'd like to work towards.

So what I've decided to use is an SQL database to store the user saves. Each Class gets a table and each object a row with a Version ID. I then have an Object Header table that associates the Table Name with the object. Then I select all the objects from one table with the matching Version ID and build the objects. Once I've done this for all relevant tables, I build the hierarchy.

I considered using one of the new Object Oriented Databases, but these seem too new. Also, they don't have a lightweight version like SQLite. The closest I found was one called EntropyDB, but this is written in cocoa (not very portable). For this particular game, I will save the a screen every time the user leaves it. And this will provide me a nice automated save system that's not too large. Plus, if the Database starts to get too big I can always delete some of the old revisions. The nice thing about using a database, is it's really easy to inspect the contents of the save. There is a nice visual editor for SQLite files called SQLite Studio. I just load it up and run a couple select statements to see the values of certain objects.

Lastly, whats easier to replicate into the cloud than a database. It would be that hard to hook up an Amazon EC2 server with an elastic replicated database in the backend and then just periodically sync user saves to that database. Now, I probably won't do this on release, but I may try to do it sometime after launch (if the game is popular enough).