After The Fall

Well, after yet again coding right up until the last seconds of PyWeek, our game is complete and uploaded. We were determined to stretch our capabilities this time, and we're pretty satisfied with what we ended up with.


 
After the Fall is an exploration-based platform adventure rendered in a stark and haunting monochrome style. It features skeletal animation based on motion capture data, a world pieced together in CSG by our homemade level editor and a story told through the letters and objects left behind in an abandoned palace.

(log in to comment)

Comments

the title name is a bit suspect - recalls a pop-rock title from 80's, like Pyweek 4 - http://www.youtube.com/watch?v=Htxf3GOK4AA
Sadly, we couldn't get Journey's permission to use that song for our end credits.
I played it for a while. Very stylish! Just FYI, the loading screen stays up for about two minutes for me, and the game runs at about 3-4 frames per second. The controls are still responsive, if extremely slow, so that's good. The choppy graphics and sound probably detract from your artistic vision, but I can imagine it smooth. Anyway, I definitely appreciate whatever optimizations you did get to put in! Amazing that it runs at all, in fact. Well done!
Cosmologicon: Our lowest spec test machine was a Core 2 Duo 2.0GHz with Intel GMA 950. If you're lower specced than that you may see problems. The update loop will remain responsive until the game falls over completely. What hardware are you on? Do try and play it on a faster computer if you get a chance, we reckon its well worthwhile.
holy crap guys, I love it! Plays well on my laptop (just 1.5ghz/Intel gma 900) so nice work! Somehow the visuals, sound design and story enhance one another, they are greater than the sum of their parts. The environments really work for me too, for some reason I love to run on the dining room table :)

One question I do have is about the control scheme...was this a deliberate stylistic choice or more a function of expediency and time needed to put in something like wasd/mouse?
Sorry guys but I ran into a problem in the secret staircase. Going down the stairs slowed things down heaps (I noticed it in other cramped places where perhaps excessive collision detection was going on) ... I ended up jumping down the middle to get to the bottom but then when I tried to come back up the game slowed and then froze on the first (or second, I'm not sure) turn of the staircase. I've tried a bunch of stuff but I'm going to have to reboot to get out of the game :(

I guess is is payback for my game's "story" screen not accepting the space bar to exit :)
georgek: One of the goals we set ourselves was to make sure that anyone could figure out how to play the game without needing any instructions. That ruled out the WASD keys (obvious to seasoned gamers, completely unintuitive for anyone else) and any kind of keyboard+mouse combination (too easy to get confused by only finding half of it). That's also why there's no way to interact with anything in the environment except by walking up to it, no inventory, etc. We did our level best to make sure the camera usually puts itself in useful places, so hopefully the lack of direct camera control will be bearable.

richard: What spec is the computer you're running this on? Collision detection was rarely the bottleneck for us, so I guess you either have a slower computer or a much more snazzy graphics card ;) I'll look into whether there are any fixes you might be able to use to alleviate the problem.
Sorry, having looked into it, its clearly a problem with the world geometry itself rather than a performance issue, resulting from a fairly late change to the game's physics which we didn't have time to test out quite well enough. I'm never quite sure what it's legit to publish after the end of the coding period, but you can fix the issue by changing a single character in the source ... should I post the fix?
awesome game! :)
It locks up my computer so please upload a fix :)
Once Chard wakes up, I'll get him to upload a new version, since he's the one who understands the packaging scripts. In the meantime, if you want to fix the bug for yourself, change the value of COLLISION_SCALE in lib/constants.py from 0.4375 to 0.44 (or, if you really only want to change one character, to 0.4475).
I'm afraid that changing the 3 to a 4 requires flipping three bits, and I draw the line at two. Can we instead change it to a 5?
Cosmologicon: you can, but be aware that it may adversely affect your playing experience.
Oops, that one was my bad. With about 5 minutes to go, I was trying various things to fix a bug with pushable blocks, and seem to have introduced a stupid bug by leaving in one of my unnecessary changes. Silly old me.
Cosmologican: as far as your choppy graphics go, I found that when I had openGL not installed properly (when I thought that it was.) on my linux machine I had this very same problem. - I'm not talking about pyopengl but the proper stuff underlying it. Sorry I'm extremely light on the details here, but it may help you on your google search.

This was an issue I saw when playing previous pyweek entries that used pyglet or similar and annoyed me no end, until I realised it was something I could fix. 
This is very much a game which will tax a weaker 3d card (although it's more about raw polygon-pushing power than fancy features). As Adam said, we tested it on my GMA 950, and it runs acceptably, but not perfectly. If your card is lower in spec than that (e.g. more than ~2 year old integrated graphics, or a netbook/bottom-end laptop), you may have issues.

However, if you do have a decent card, but your GL setup is a bit dodgy, that may well be responsible for any performance issues you might encounter. Linux GL drivers are still notoriously flaky, even though they've improved considerably in the last few years.
Yeah, it's that I'm running on a 1.6GHz Intel Atom netbook. I think my OpenGL is fine; I've run a few other Pyglet/OpenGL games with no problems. I'll definitely play this game on a more powerful computer at some point, but it might not be until after judging closes. Worst case, I'll do like I did with Wound Up, and come back in a year or two when I've got a faster computer. :-)

It's not something I expected you to fix or anything. I just wanted to let you know.
Just wanted to add that the game seems to run fine on linux with an AMD Sempron 3000+ and Nvidia 7200 (the stock dual-monitor card here at work), using the binary drivers.  I'm not sure I agree with the motivation behind the lack of separate camera controls, as we now live in the age of World of Warcraft where even normal people can learn to move with WASD and control the camera with a mouse.  It would certainly make a lot of these blinds leaps much easier.  Still trying to align the jump to get the feather that's over the piano...
Another performance data point -- it's running acceptably (although not terrifically) using MacOSX 10.4.10 on a dual 1.25GHz PPC with a Radeon 9000 Pro (after I fixed it to byteswap arrays after loading them).
Woah... I can honestly say this is the best Pyweek entry I've ever played. I really like the ambient, very Myst-like. The only thing that bothered me was the camera, which tended to move when I had to do a difficult jump. It took some time to get used to.

Too bad I can't vote this time :)
So far I've been able to get into a position where I can jump without the camera angle being a problem... but maybe I haven't got to any of the really difficult jumps yet...

My main complaint about the camera is that it's difficult to position yourself in the corner of a room and then turn around to get a good look at the whole room. Or just stand in one place and look around. It would be nice to have the option of separate move/turn controls for those who would like it.
Implementing camera movement in a game like this is very tricky, and I think they did a very good job. I had some small camera issues naturally, but this much is present in commercial games as well. And the game design makes sure that the camera issues are not gameplay issues — this is not a platform game and not an action game.
Yes, they've certainly done very well - the camera never gets stuck or goes anywhere wildly inappropriate, which is quite an achievement. And you're right that the gameplay doesn't require accurate camera control on the whole. It's a little bit frustrating sometimes not being able to just turn around and look at something, that's all. Not a big problem.
I'm going to have to disagree on the camera/gameplay thing.  The piano jump was much more difficult than it should have been because the camera ended up in the wrong place.  I had to run back and forth along the wall to get it positioned, and it took many tries and a lot of guessing to get my guy lined up so he'd land on top of the piano.  Also the direction the guy would run kept changing whenever the camera would move.  In "normal" 3rd person games the forward key moves you forward from the perspective of your avatar, in this game it's from the perspective of the ever-shifting camera.  This means as you're running along (or pushing a box) you'd have to change which arrow keys you pressed as the camera moved around.  Several times this caused me to fall or otherwise mis-steer the character when all I wanted to do was keep going the same direction.
the jumps over the libraries are tricky I would say.