Hey! You! beta-testing people! We are just sorta starting to think about beta testing, (probably wont have a beta-ready version for a few weeks yet) but if you are interested, then email me at support@benbritten.com, with ‘Snowferno Beta Test’ in the subject. It will need to come from a real email address (or I wont be able to tell you where to get the binary) and I will need your device ID.
to get your device ID:
Launch iTunes.
Connect your device to your computer.
Select the device in the Devices list.
In the Summary pane, click the Serial Number label. It changes to Identifier.
Choose Edit > Copy.
Paste your Device ID into an email.
Be sure to include your name and device name in the email.
Cheers!
-B
Thought I would jump in here and talk really quick about the tools we are using to build Snowferno.
We are using Basecamp for the central location of files and calendar events and to-dos and things of that nature. Basecamp is pretty good, and I think it is a useful tool, but it doesnt blow my socks off. One thing that annoys me to no end is the writeboards.. ack! the formatting is terribly hard to deal with.
To get around the terrible writeboards in basecamp, we use a private install of MediaWiki (the same software used for wikipedia) to handle all our documenting needs. It is much easier (i think) to use than the basecamp writeboards.
As for desktop tools Brent did a post on the sound stuff he is using, so that is covered :-).
I am using Unity3D to build the game. We currently have only a single indie license, but we are thinking of upgrading to pro before we go live (although truthfully, the indie is a very very capable license)
For all the 3D art assets I am using Cheetah3D which is a surprisingly fantastic 3d modeler. I used to have a copy of Maya back during my time in the film industry (still have a seat that is a few versions old laying around here somewhere…) but I find cheetah to be much simpler to use. (and for what we need, Maya is a bit overkill anyhow)
For 2d stuff, textures and whatever, I am using the industry standard Photoshop/Illustrator pair. Although I must say, I love illustrator, but I kinda hate photoshop these days. I really dont like the CS3 interface changes. (I actually just recently upgraded, so I am still getting used to it) but to be honest, I am looking around for something photoshop-like that I can switch to. (while I probably use %15 – %25 of illustrator, i maybe use %5 of photoshop, I could really get away with much less… and before you say “Gimp”, I will admit to not having tried it recently (and by recently, i mean in the last 8 years or so) SO I should really bust it out and see how it has changed… but I will say, that the x11 stuff turns me off a bit. (I know, I know…) I am even a unix guy from way back, but I just like to keep things simple.
As for version control, I use beanstalk and that has worked just fine for me for awhile now.
I think that is about it..
Cheers!
-B
First off, let me say that this is our first game. All three of us are veterans of various creative environments, and building a game is surprisingly similar to putting on a theatrical production of making a movie. That said, some people might wonder just what our general process has been for this game.
Well, first off, we decided that we wanted to build a game, and decided to build it for the iPhone. (mostly because I had already done a few apps for the iPhone and I have wanted to build some games for awhile now, but did not have any viable distribution platform, the iPhone solves that problem :-)
Next we all sat down and talked about what kind of game we wanted to make and started brainstorming ideas. Most of these ideas were quite good, but not really feasible for our first game outing. We finally chose to go with the rolly-ball genre because it is a nice simple gmae mechanic with lots of room for creative level/world design.
I built a prototype game, this was very basic and was mostly just a game mechanic demo really. the ‘levels’ in the original prototype look nothing at all like the ones in the current release. We probably spent three or four weeks just working out the best way to have the character respond to the inputs.
We originally had a two-axis accelerometer control, and the original snowball was fully physics based. This turned out to be too realistic, and it was sorta frustrating to control. One thing we didnt like was that you had to tip the phone away from you to move forward, this made it hard to see the screen. SO we moved away from the forward-back for the throttle and added an on-screen control.
Then we slowly moved the character away from a purely physics based movement model to a more controlled pseudo-realistic model. This way we can control via code how and when the character reacts to things. Now you can speed up and slow down easier, and the turning is much smoother, giving the user a feeling of more control.
Once we had a good character control mechanic we moved onto some level designs.
We started off a bit crazy and had all sorts of ideas and sketches for level designs and artwork. Ultimately, the reality of the iPhone and the scope of the project began to put limitations on what we could and could not do. At this point we tried to standardize on a handful of puzzle mechanics. (like switches, boxes, moving platforms, snowpiles and fires). Once we had a good feel for the pieces of the puzzles we could start designing levels in earnest.
As one of us would design a level, I would mock it up with Cheetah3D, and build the level in Unity. then we would play the level and modify it until we were pretty happy with the puzzle or feat of dexterity required to pass that level.
Now that we have most of the levels finished, I am going back through each one and adding proper textures, remodeling parts that need it and generally giving them all a once over in preparation for beta testing. During this time Mike and Brent have been writing all the music.
The next step, which I am just starting on, is to get the user interface under control. Up to now it has been very minimal, just enough to start the levels and do testing. I want to go into beta testing with the UI at 95% if possible. the UI sets the mood of the game so much that it is imperative (i think) to have a representative UI to go along with the game play. (and just to be clear, by UI I mean all the screens that you have to wade through to chenage settings, the opening screen, the score screens, the ‘fall out’ screens, and the game elements that are part of the HUD during gameplay.)
Once we have a halfway decent UI, we will go ahead and do some wider beta testing and tweak the levels and gameplay based on the feedback we recieve from that, then it will be time to add all the final bits n pieces and submit!
Cheers!
-B
Mike and I are creating the Snowferno soundtrack in Ableton Live and Digital Performer. Each track is meant to loop of course, so (at least within the limitations of the phone hardware) we want the loop’s seams to be as transparent as possible.
Both Live and DP have great features for looping playback, but exporting the final audio from each app as a loop requires two different approaches.
Live is totally loop-centric out of the box, so there is simply a switch in the “Export Audio/Video…” window to “Render as Loop”. This switch causes Live to do something pretty cool. It makes *two* passes of the track and uses the first pass to calculate what reverb tails, delay feedback, and so on should carryover and be sounding at the beginning of the exported audio file.
DP is more linear by design, so it doesn’t provide a one-click solution. You need to fake it — which I do by pasting a copy of the final measure of MIDI again before the first measure of the loop. My “Bounce to Disk” selection area includes that pre-measure as well as one extra measure of breathing space beyond the last measure of the loop. I set the “Bounce to Disk” window Import setting to “Add to Sequence” and then bounce it. Next, I slice out the exact region of the loop from the just-bounced/imported soundbite minus the extra pre/post measures and export that soundbite from the Soundbites List. It helps if you rename the sliced soundbite and delete the unused bits. It’s little more work, but it gets all the material that will still be sounding at the end so that it can be triggered and sounding still at the beginning of the track. Plus, I’ve found DP needs a little space for things to ramp-up and down. Adding those pre/post measures lets all my Waves processors get humming far away from the parts of the audio where a loop seam will be.
The final loops go in to Unity as AAC-encoded files so that the iPhone decodes it in hardware. We’re still experimenting with what the final bitrate will be — once all the tracks are done, we’re going to find the balance between great-sounding music and needless app size bloat.
Today i am going to try out the new development blog! The snowferno website is nearly ready to go live, so this is where all the new content will live.. for older stuff (although there isnt much) you can check out my blog at : benbritten.com/blog or the Rollover blog at fatlabmusic.com/blog.
So, to kick things off let me just give a bit of backstory on this project. We started it roughly at the end of the year last year (sort of xmas time 2008). And by ’started’ I mean we decided that we wanted to collaborate on an iPhone game, tho we had no idea what to make.
Ultimately the idea to do a rolling ball game was made, I think mostly because the ‘rolling ball game controlled with the accelerometer’ seems to be the ‘hello world’ of game genres on the iPhone. So it seemed like the right place to start.
In early january I started looking at my options for coding the game ( I am doing all the coding, the boys at Fatlab are doing all the sound/music and most of the level design). I knew we were going to want to use ‘real’ physics, so that was really the only requirement I started out with.
I have written my own ‘game engines’ (if they can be called that, a more apt term might be ‘openGL|ES code harness’) and was trying to figure out how long it would take me to bolt a physics engine onto my existing tool base.
During this time I looked at a dozen or so open source physics libraries, and they all looked capable enough. However I also remembered my old friend Unity, and had heard that they recently released something that could build apps for the iPhone.
So, in the midst of downloading and evaluating all the physics libraries I also got a trial copy of unity and tried to build a quick prototype. Turns out, Unity has a pretty shallow learning curve, and I had a working prototype ‘level’ (if you could call it that) in about 3 hours.
That pretty much sealed the deal for me and Unity. I bought a copy later that week and started learning Unity in earnest.
This is about the same time that the Fatlab boys came up with the excellent idea of the snowball rolling through hell. Thus, Snowferno was born :-)
