Solipskier through the ages

During the development of Solipskier, we kept around a dozen or so versions that we would occasionally show to other developers for feedback on where the game was going. Because of this, we still have these versions and we thought they’d make for an interesting peek into some of the decisions we made along the way. Mike will talk about the prototypes and Greg will talk about the mockups.

Idea

We first had the idea after a decent brainstorm session over the concept of “parallax scrolling”. We started with that simple idea and tried to focus it into a gameplay concept that would highlight that sort of depth scrolling. We mainly talked about speed though, since they are pretty tightly knit ideas. It’s hard to say how exactly we arrived at the idea but the main idea was to not settle on something less than exciting. It’s easy to say “sure” that’s a good idea let’s try it, but if the idea wasn’t exciting us we tried to move on or change it some way that might lead there. Eventually Mike blurted out with wide-eyes that it could be a game where you paint the terrain to determine the speed of the character. We were both thinking snow, maybe a snow-mobile. Then we went into our rooms and started working.

Prototype

Mike:

I got started that night building the prototype, I could see exactly where the focus of my time would be from the initial seed of the idea, and I had enough familiarity with heightmaps from working on Dinowaurs, and flash bitmap drawing from EON, that I knew I could whip up the basic drawing mechanic very quickly.  Within a few hours I had a red ball which moved forward at a static speed and moved up when it drove across a slope and slowly drifted downwards when it was in mid-air.  The drawing was 1:1 with the mouse, so you could draw any kind of slope you wanted, including a sheer vertical cliff, and you could draw over your previous terrain if you wanted and the ball would just pop to the top of whatever terrain shared it’s X position.

I quickly threw in the three gates, to get the basic idea of a slalom style challenge and just so you would have something to give you a reference point, the snow being pure white and the background being black gave no sense of speed or movement, just a bobbing up and down on a waveform.  It was obvious that there would need to be some sort of indicator to signal when a gate was coming, as at high speeds you would have no time to react to something just appearing on the screen.  The meter counter and behavior of the indicators to craw to the right side of the screen was really the only idea I had.  It seemed very weird to have the indicator move to the right when the gate was moving left, but I had no other ideas to go on, and I still don’t really have any better ideas for it.

There was still no sense of speed or, ironically enough, parallax scrolling, but the basic idea of drawing your own terrain was implemented.

Mockup #1

This was done the night we had the idea for the game. I always start making stuff in grayscale, no matter what. I like to add color later where it’s necessary or makes functional sense. In here, I wasn’t sure what the game would play like in terms of its objectives and etc. so I stuck with the grayscale and focused on some simple visual forms to get across the world the skier would be in. There’s a lot more thinking going on behind the scenes of this mockup other than just making a winter scene. We weren’t sure what the character would be (or if it’d even be a character) or if there’d be a set distance you’d travel and so on.

The right side of the screen being a gray square isn’t a mistake either. I was thinking that the screen would be completely blank where you hadn’t painted yet to further push the whole “You are the Wheelman!” angle. Eventually that ended up being impractical and all-together unnecessary. But most of the basic forms are in there as far as the buildings, trees and background elements. The contrast is also a problem. Looking at this image, it’s hard to immediately understand what’s active and what isn’t in the game.

Mockup #2

There’s quite a lot going on here in this mockup that’s changed since the first. After seeing Mike’s prototype it was clear we needed a lot of bonus type things to use in the game, as well as clearly defined gate types. Because the game can go by at such a fast clip, clear and present colors were a must. Anything beyond crispy clean was just not going to read as well. That’s also my tendency, so it didn’t hurt to fit it into my system here. :)

Beyond the stark contrast of the bright colors with the dark background though, the night time atmosphere was also another big driver early on. For instance the aurora borealis going on there, I really wanted that to get in there. Thing is though… that’s a huge task for something that’s purely window dressing (probably would start showing up after playing for a certain amount of time) since Flash doesn’t really have the shader chops to pull something like that off without a ton of experimentation/pain. We axed it as a hailmary some-day feature and moved forward with what was in front of us.

The dotted line star thing was an effort to show correlation between bonuses and total score but we ended up doing something much simpler that fit into a later UI design with the floating score boards. Also, you’ll notice the background elements (lodges and trees) are coming from the top of the screen as you draw, instead of the final solution you see on the game today (from the bottom). We did end up trying that, but it ended up being quite distracting and ultimately a little weird looking at high speeds. Sort of like a zipper. It’s one of those ideas that seems really cool in your head but doesn’t work in practice.

Beyond that, the only other thing missing here is the character. Character design/animation is most certainly my weak point so I tend to leave it until the end. I’m never really happy with the characters I design and that’s probably because they’re always showing up towards the end of the mockup process. I do like the idea behind the Solipskier though, with his large ego-tastic head balanced on a tiny stick figure frame. It makes sense to me and gives me a chuckle.

Version 0.1

Mike:

I was actually pretty blown away by Greg’s concept pieces, the idea of being a skier instead of a snow-mobile brought all sorts of new ideas for gameplay concepts, and it made the slalom concept make more sense thematically. I quickly threw the backgrounds into the game and set up the parallax, this did a great job of giving you a sense of speed, just as we had hoped, and cemented our belief in the game as focused on speed.  I also began playing with the drawing mechanic, smoothing out the lines and keeping slopes from getting to vertical and unrealistic for a skier to climb.  I made the physics of the skier a little more complicated, sticking him to the terrain for down slopes and slowing his climb on up slopes, which made his motion much more smooth and weighty.  He was still stuck to the center of the screen, however, and he lacked a real sense of liveliness, his only motion relative to the screen was going up and down, it lacked character.

At this point I had the idea for the tunnel obstacle, it was an obvious extension of the gate obstacle, but I wasn’t sure how it fit in exactly.  We still didn’t have much of the score and multiplier system in place, and multiplier system didn’t affect speed so it was difficult to determine how tunnels fit in relative to gates. I just thought it felt cool to see the tunnel gates whiz by so rapidly, and it was a fun challenge to stay within the bounds.

Version 0.2

Mike:

At this point we started animating the skier and adding motion blur to the moving pieces to help give a sense of real speed.  This was quite easy to implement using flash’s internal blur filters and didn’t add a ton of processing time.  I had assumed I would need to write my own blur filter using Pixelbender, but anything I wrote by hand ended up draining way more resources than just using the built in filters.

Version 0.3

Version 0.4

Mike:

We generally have a hate/hate relationship with tutorials and try our best to never implement anything that holds the players hands too much while they learn to play, and we decided to take that a step further with Solipskier by removing any barriers between starting the game and playing.  After the intros are loaded, we decided that all the player has to do to start the game is click, and this screen served as the only “main menu”.  We tested this with our friends and found most of them simply didn’t understand what to do and clicked once, which resulted in falling to their deaths instantly.  This seems like a harsh first impression of the game, but the time between failure and restarting is so short that we felt it was the best way to teach the concepts of clicking and dragging the mouse, and we feel it keeps the game simple and instantly accessible.

Version 0.5

Mike:

At this point I started trying to replicate the rainbow effect from Greg’s mockup, and initially I drew the rainbow by replicating the terrain drawing effect and just swapping out the colors.  This was ultra-fast for rendering, just like the terrain effect, but it didn’t match the player sprite very well and seemed fairly non-reactive.  I decided to try to physically simulate the rainbow as if it were a scarf or cape to see if it would bring in more life.

I was also starting to work out scoring mechanics, deciding how to get a high multiplier and how to lose it.  This shot shows the “Buzz the Tower” bonus which is key for getting a high multiplier early in the game by jumping through gates instead of simply skiing through them.  We wanted to reward players who had the confidence to release the mouse button and stop drawing terrain, so the rainbow ended up being a reward for those who were jumping the gap, as well as the automated trick system.  Tony Hawk was a bit of an inspiration for us, we wanted a similar trick system which would allow the player to feel bad ass the more and more the stakes were raised by doing difficult maneuvers at very high speeds.

Version 0.6

Mike:

This was my first shot at doing a scarf which rippled in the wind, and rose up as your speed increased.  It was very different from Greg’s initial idea and neither of us were satisfied with the way it looked, but the physical simulation did add life to it.

Version 0.7

Mike:

Here I took the best of both worlds for the scarf, keeping the physical simulation but adding the horizontal stripes of Greg’s mockup.  I also added in the initial drawing method for the rainbow that extends behind the skier when he jumps, which brought both systems together.

Version 0.8

Version 0.9

Version 0.91

Mockup File

And here’s a little snapshot of my Illustrator file. One of the reasons I love working with vector art so much is due to how well it can translate everywhere. I don’t have to worry about hi-res so that it can work in a poster or a postage stamp, it works everywhere, especially in Flash! The mockups that I make in Illustrator directly translate into Flash movie clips that I can tweak slightly and there is hardly any headache sending them through the pipeline. Beyond that is just animation and making sure the text is set properly and etc. There’s always a point where the work in Illustrator vanishes and I start working directly in the Flash library which ends up being the bulk of the work (read: polish) but getting started is certainly easier for me with this method.

Thanks!

Well hopefully that was interesting/helpful… Add more.


5 Responses to Solipskier through the ages

  1. Kirkpad

    Nice read! Thanks for the behind the scenes look.

  2. Kris

    Quite interesting indeed. Thanks for sharing.

  3. WillC

    Overall, it looks like development was a pretty straight forward process. It’s interesting to read how previous projects helped streamlined development. Reading a lot of the feedback on the App store and looking at how you guys are two, I was curious, in future projects, are you guys going to be aiming towards games as services? Providing periodic updates and more features over a period of time is a business model I’ve read a lot of “casual game” developers are moving more towards, will we see this from you guys as well?

    • Honestly I don’t like the “games as a service” concept from a developer standpoint, once we finish a game we’re pretty much done with it and would like to move to the next idea. It’s pretty obvious that continuing to support a successful game is great for business, and Valve is a great example of a company doing very good work and business over the long term on their games, but I would have to really like the game even after release to want to have to do any more work on it.

  4. Tor

    hey, liferaft has been in the works for a while now, since before you guys were officially together. Can I look forward to an awesome game, or has the project been dropped?

Leave a Reply

Your email address will not be published. Required fields are marked *

*