I played Screwjumper the other day. It’s a new game on XLA developed by Frozen Codebase out in Wisconsin.
Now, full disclosure. I consider their CEO a friend of mine and as such while other people have ripped on Screw jumper I think this is more of an educational experience than anything and want to treat this post as such, rather than just ripping on the?.
The ultimate question is “is this a good game”. And with the best will in the world, I’m not sure that answer can be “yes”. It has everything that a good casual game should have – decent production values, a relatively new mechanic, decent sound, at least genre standard graphics etc.
Yet it seems to fall short because it’s damn difficult and there seems to have been attention spent on area’s that frankly, aren’t important – cinematics of ships dropping miners off are eye candy of the most un-necessary sort. Building the infra structure for this was wasted time – time that should have been spent on the main mechanic.
I have a few rules for Casual games that I think are worth following. They don’t guarantee success but I think following them puts you in a better position. There’s some tough love in here for the screw jumper dev team, but better to be faced with reality than shielded by un-reality.
Jakes Casual Game Rules
1) As few clicks/time to getting into the game play as possible. Quake III made a point of it being 3 clicks to playing. Even if you have screens of text to wade through before getting into the game, enable people to click past them instantly. Same with any cinematics. They may satisfy the inner movie maker in you, but they are un-necessary to the gamer. These are casual games and we don’t need to worry about ‘pushing narrative along’. Let people get in instantly.
In the case of screw jumper we are treated to the “what buttons do” page twice, a loading screen and a cinematic before I am playing. I don’t care about the cinematic, and I have a suspicion that I am sitting at a loading screen because of it. It needs to go because as a gamer I don’t care. I want to play, not watch.
2) Your game mechanic can be complex. It can have lots of effectors (ie powerups or stuff that changes how you play) and all that good stuff. But Do Not Include ANY Of Them On The First Few Levels. In the first few levels you want to pare down your game play to the barest essentials – nothing un-necessary. Literally, you are training people to play at the bottom level – how to walk, not how to hurdle. For Screw Jumper I would have had 3 or 4 levels of purely JUST those platforms you can smash. None of the ones that stop you if you are just dropping, just training people in how to drop. I wouldn’t even have turned on the accelerator thing, nor would I have given them dynamite.
Then I would have added at level 5 those ones that stop you, and introduced the way to actually destroy them, with dynamite or with the accelerator. As it is you start the game with lots of abilities you don’t know how to use.
As for those little things that zip around and shoot you, I have no idea what they are or how to stop them. They shouldn’t have been introduced until much later.
So introduce abilities or mechanic effectors slowly, one by one, and get people used to them before you add more. This enables you to slow your difficulty curve.
3) As an addition to 2), MAKE PEOPLE INSTANTLY SUCCESSFUL. If there is _any_ secret to making casual games, its this one. The first few levels should be achievable by a brain dead Moron. The whole idea is to entice people with instant success and the feel of power, and then very slowly turn the screws, doing so only after you know the player has mastered the basics. Screwjumper does not do this – it dumps you right in the middle and it’s hard.
4) Kleenex test (ie use people who’ve never seen your game before that you’ll never use again) your product YOURSELF. Never wait for the publisher to do it – do it under your control. And LISTEN to the results. Never dismiss them as “well you don’t know how to play it”. No, they don’t, and if you don’t do something about those complaints no one will ever spend the time to learn.
5) If you ?on’t have a root mechanic that can be communicated via a YouTube video (ie you can just see what you have to do, and how you go about doing it without having to play or have multiple pop ups or explanation screens) then there’s something wrong. Watching a video of Screw Jumper wouldn’t have made it all obvious to me what was going on. I got the green / red separation of disks you were supposed / not supposed to hit, but the distinction of “This disk stops you if you are dropping and not accelerating, And these ones don’t” wasn’t clear and obvious unless you are looking very hard at the game, which most people aren’t. They are playing this as a bit of fun, not the result of a dissertation – remember that when designing effectors. If it gets too complicated to predict and follow immediately, people will not comprehend and they will stop playing.
6) Popups. If you have to repeatedly stop the action to explain how to do something on a casual game then something is wrong. Now this is a multiplier kind of thing – a slow game like Uno it’s ok on, since it’s not a twitcher game. You’d Just About get away with it on Peggle, but on anything fast, you just shouldn’t do it. It’s an indicator that you are trying to introduce too many things too fast.
And now a couple that are screw jumper specific
7) The control of the character is way way too hard. If there is inertia there (and it feels like there is not) in the direction you fall, at least double it. I was constantly fighting the controller to get the guy falling in the direction I wanted – this was not good since this was the root mechanic that everything else was based on. Until this feels ‘right’ then you aren’t sitting on a good foundation.
8) The bit where you hit the bottom is cheesy. Yeah, I know why it’s there, to give the fiction some basis for reality and to have a consequence. But it’s cheesy and I suspect you know that. I don’t doubt lack of time and money that affected this, but still…c’mon…
9) There are too many informational screens, and they are badly formatted. They just look…amateur. There are some great fonts you had in there, but they weren’t used enough and the end of level status screen was just amateur looking. Some time polishing that would have been good.
So what did they do right?
Well, they tried something different, which is always good. It’s a very simple mechanic at root, and with all simple mechanics, the root control is what makes or breaks it, but hey, kudo points for not re making frogger.
The production values were pretty good. Some of it was a little ragged around the edges, but there’s a complete system under there (animation, effects, cinematic importer, world builder etc) which will server them well in the future.
There was some attempt at a learning curve. Not enough, but it was there, evidence of someone actually thinking about it…
So, Frozen Codebase people – don’t be too despondent. I understand there was not enough time / money to do everything the right way. I still think there was attention on things that were not important, but on the other hand you’ve now shipped a game. That, in itself, is MASSIVE, particularly for a group where only one of you had done so in the past.
The end result is a game that’s not great – it has to be said because that is the reality and you _have_ to face up to reality – but on the other hand it’s provided you with a codebase that works, and all the learning necessary to make a better game.
Treat this as a learning experience – you have all the tools in your tool box, now go out and use them.
Good luck with the next gig.
- February 2015
- January 2015
- August 2014
- July 2014
- May 2014
- April 2014
- February 2013
- January 2013
- December 2012
- March 2010
- February 2010
- May 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- January 2007
- December 2006
- May 2006
- April 2006
- March 2006
- February 2006
- January 2006