A generous friend (Michael Foord) has compiled the cython files for me under Windows so I've uploaded a new version with those files bundled. Hopefully cython's internal machinery will be happy to use them:

Download: endless-path-7

I'd be interested to know whether this works for you if you are on Windows and do not have cython installed.

Thanks, Michael!

Firstly I would like to apologise for how difficult it is to play our "game". This is totally my fault - I had intended to tweak the physics code a bit more towards the end of the challenge, but I haven't been able to do any testing for the last couple of days as I was away from my pc and my laptop can't run the game for some reason.

However! I do have some advice on how to stay balanced, and I think that compared to riding a real unicycle, it's not so wibbly wobbly after all :P

Here's how you can avoid falling over:

Redefine the laws of physics.
Since the default values for most of the constants are a bit iffy, you may you want to adjust them yourself before playing. The values are all stored in constants.py. I recommend decreasing g - so the unicycle is slower to respond to changes in how much you lean backwards and forwards - and increasing the mass of the unicycle (this makes your overall acceleration influence the wobbliness more).

Try not to tilt too much, and pay attention to your acceleration
If you lean over too much, the orientation of the unicycle will change very quickly, making it very easy to fall off. Your acceleration also affects the orientation of the unicycle, so it's possible to stay balanced without jerking the mouse about too much.

There is a very simple algorithm I was taught when I learned unicycle for real - if you're tilting too far forwards, pedal harder; if you're tilting too far backwards, lean forwards. This works suprisingly well, and using this technique I was able to stay on my virtual unicycle a lot easier too.


I hope this helps, and that you like our game, even though it's nowhere near as complete as we would have liked. If you have feedback of any kind, please leave a comment.

See you next pyweek! :)

For me that is.  Actually I think it's going to do pretty well overall as well, so I'm really pleased with what we built.  I uploaded the final version last night, but didn't have the energy to post about it until this morning.

Here's a screen shot from the 3rd level (there are 4 levels total):



As is always the case, there wasn't enough time at the end to tweak gameplay ond tune the levels to find the right difficulty.  If you don't die (which isn't too hard once you get the hang of it) you can beat all four levels in about 10 minutes (that includes loading times, which are longer than we'd like). 

I have to apologize about the size of the download; our single artist was extremely productive and despite having four programmers we just couldn't keep up and get all of the assets included in the game, but I didn't have time to trim the data down and only include what was actually used.  This may not have actually saved a lot of space though, as a quick survey estimates I maybe could have trimmed 6MB (total package is ~30MB)

I'm a little sad we weren't able to get all those great art and sound assets in, and a little annoyed at the brutal looking hud (Shields and timer) which totally clash and detract from the overall beauty of the visuals: A nice shield charge bar (or equivalent indicator around the ship) would have helped a great deal.  Some alpha on the timer (ala the FPS counter) would integrate it better, but in the final hours I decided getting the storyboards in for each level was more important.  I hope that was the right choice.

I'm a little nervous how it will perform on some slower machines, since I didn't get a chance to test it on one, and we didn't get to do any optimization.

Also (random note) it seems to crash occasionally on me, or start up and you won't see the graphics update.  I'm not sure why, most of the time it's fine, so if you see that just restart the thing and it should clear up the issue.

 I hope you enjoy it!

Finally I got my hands on iMovie and uploaded a properly cut little gameplay video:

• http://www.youtube.com/watch?v=SA8bCP7VWgA

After a developing time of only 50 hours, we ended the game. It's a basic point and shoot game, but the time wans't our side.

Download the Windows Version

Another Pyweek over and plenty of games to play. Congratulations to everyone who finished. :)

Time for my usual postmortem. Beware, this is a huge post - this is basically all the diary entries I was supposed to write combined. It's probably a good idea to play The Strange Sine Orbs before you read this so you get the context, too, but it's not necessary.


Like I wrote in my previous post, I was away until Tuesday morning and that was when I got to know the theme. I usually end up spending too much time trying to find a good idea seed, and this Pyweek was no exception. In fact, it was probably the Pyweek in which I felt the worst creative block (possibly due to the theme). I only settled on something on Wednesday evening, but, actually, I didn't like the idea much.

My original idea was to make a game where a character is controlled by the mouse and another character is elastically attached to the first one, and the player would have to navigate some skill/puzzle levels. I had a few puzzles in mind using this simple mechanic - I think you can work out some nice levels if you add bouncing walls and such. 

But I didn't really like this idea. The core of the idea was a bit too "boring" (in the sense that, not that it wouldn't be fun, but I like to experiment with different things). The elasticity was the only part related to the theme, which I thought was a bit vague. I was relying too much on the level design, but there was still a lot of work to do on levels and I would only be able to implement core stuff and a few sloppy levels at most. So, Friday night, I decided to stop implementing it, go to sleep, and wake up very early in the next morning with a fresh mind to see if I could come up with something else easy to implement, even if it's just a bad game to submit. I had the whole Saturday free for Pyweek, so I figured I could work something out. I had my hopes down to the point of thinking I would have nothing to submit, but I've been frustrated more than a few times before in Pyweek and I knew I just had to keep trying, even if just for the sake of trying.


Saturday morning, woke up very early, had breakfast and started thinking of ideas. I spent around one hour and a half trying to come up with "one day" ideas until I had a seed of the idea for The Strange Sine Orbs. At first, it was just the following mechanic concept: "objects that either go straight or in a sine wave, and that's the only control the player has". (Actually, that mechanic came from the idea of forcing cars to wobble and causing them to crash in Burnout style, but I decided that would be way too complicated, especially for a one day game.) That mechanic is pretty easy to implement, so, since by then I was very tired of thinking, I decided to go with it and see what happens. This was something that pleased me much more than the previous idea, because it's something more unusual that I could experiment with and toy around with.

At first, I didn't have much faith in this idea. I had it implemented and had some (white rectangle) baddies moving in the opposite direction and tried to make my bullets hit them. It was awful. There was absolutely no control. I couldn't hit the baddies because it was hard to know where the bullet would go. I was already invested in the idea even though I was almost sure it wouldn't come out good, so I decided to figure out a way to give control to the player. Given some time to think, I went with the three following ideas:

• Path prediction. At first I felt this would take away the challenge of the player trying to predict his movement, but this turned out to be good, since the sine wave with accelerating amplitude was too hard to predict anyway, and the game is still quite challenging with the prediction.  
• Stationary objects. With the path prediction, you know for sure you're hitting that object.
• Quick decceleration, so you can "aim" easier from the wobble mode to the straight mode. 

These three things worked out surprisingly well (it actually took quite some time to tweak everything well enough to make them click - for quite a while I thought I was being crazy trying to put in things that didn't fit well). With stationary objects came the idea that the orb had to grab some "charges" before it reached to right side of the screen, and you had to destroy the baddies that moved to the left. Sort of like a battle between two unseen opponents. (I'd write a bit more about the design, but this post is already too long.)

One of the hardest parts was to figure out some "theme" to go on top of the mechanic. I had the mechanic, but finding an excuse for it was hard. I ended up not having much of a "theme"; I decided to just draw whatever popped in my mind and go with it. I think it turned out ok, though I know I will get a low Production score because of it. That's ok, given the time I had for it.

I'm not sure about the balancing, though. I didn't have much time to get someone else to playtest it, so I decided to submit it the way it was (playtested only by me). It might be a bit harder than I think because I was already used to the controls when I tested it, but I hope not. But I felt it wasn't hard to win, so that should balance it out.

I like the fact that some interesting strategies emerged. For example, if you let the enemy pass, you can have it wobble to the end so you can get it back at the beginning and try to block it again. Aiming at the enemy from wobble mode to straight mode is also a neat strategy. I also like that a clear distinction between attack and defense emerged: attack would be wobble a lot and try to get a lot of charges; defense would be to aim at the enemies by adjusting the position with small wobbles.

Taking everything into account, I'm quite satisfied with my performance in this Pyweek. This turned out to be an interesting one for me. In the end, I think my persistence paid off. The gameplay is a bit unusual and the game felt fun at least for me. The only thing I worry about is that the sloppy graphics and the initial apparent complexity/strangeness will scare some people off. I suppose I don't know how it feels to play the final version of the game for the first time.


Lessons learned:

• As always, be persistent. Learn how to deal with your frustrations. It may not work, but there's a chance you'll surprise yourself, and that chance is worth it.
• This is the third time I waste the rest of the week pursuing complicated objectives, then stop Friday and do a game in a day (others were Pyweek 7 and 8). I guess that if you aim for an idea that you can implement in a day, it'll be much easier. Maybe you should pretend this is Pyday and not Pyweek and start from there, so your goals are kept simple, and, more importantly, you stick with an idea that you're sure it's easy and quick to implement. A lot of problems come from thinking you can implement something and then finding out that it's not as easy as it sounds. Making a game in a day forces you to think: can I really implement this in less than a day? (On the other hand, I have to admit that sometimes aiming high and then failing hard is also quite thrilling. That's why I will probably never learn from this lesson. :P)
• If you're trying to design something unusual, design iteratively. Design, implement, play, repeat. This way you can see what's not working right and tweak it. In my case, it was the lack of control for the wobbly mechanic. I ended up adding control features and then iteratively fine-tuning it into a reasonable game.

Anyway, as usual, I enjoy feedback a lot and you don't need to wait until you rate the games to comment. :) Please comment if you managed to use some strategy different from the ones I mentioned. If anyone wants to discuss the design of the game, I'd be happy to. If you didn't like the game, I'd be also interested to hear - since I was the only playtester, I have no idea if it's fun for others.

Well, sorry for the huge post, and thanks for reading all this and thanks for playing my game if you already did. Thanks to Richard for hosting yet another Pyweek. I'm looking forward to play your games. :)

After a week of hammering out this beast, it's time to find out its value. So many sacrifices were made along the way, but they were necessary to meet the deadline. I hope that which was left was worth the effort.

Panda3D is certainly one of the least used engines in PyWeek. And with a large SDK that entrants had to download before, it is understandable that it's been seen to be a suboptimal choice for this challenge. However, thanks to the 1.7.0 release last January, all that has changed. Now others can install a very small runtime distribution of Panda3D and games can be packed in a highly optimised executable. I do hope this entry will demonstrate to other PyWeek competitors that Panda3D really isn't as bad a choice as it may have appeared to be in the past.

As for the prototype itself, I must say I was surprised when "Wibbly-Wobbly" won the vote. And yet initially I knew it would score highly due to sounding like a nice little challenge. I actually expected Eleventh to win due to its broad nature, but that didn't happen.

As with PyWeek 9, I wanted to build a puzzle-filled adventure prototype with a child as the main character (as children are unfortunately rarely the main characters of games outside the genre of "children's games"), but I knew (from experience of failure to go solo last time) that I would need help. Sure, my experience with Panda3D and software engineering in general had grown quite a great deal since last August, but still I felt a teammate would be the best approach. I asked my good friend, rdb, if he wanted to partner up with me, and he eagerly agreed. And after a week of design discussion and preparation, the challenge began.

Starting the minute of 00:00:00 UTC, I began building the framework for our prototype; lower level stuff like engine configuration, camera control, class flow... the little necessary things. After that, it was all about building game logic. It was a good thing I sought out partnership with a skilled and knowledgeable guy like rdb as there were points during development that simply lost me. And rdb being a good friend of mine made the partnership more enjoyable as well.

Being the mad symbolist I am, I revelled in weaving symbolism throughout this prototype. Everything from the relative direction of the entryway to the number of statues and the relative direction of the control panel is symbolic to me. Even the title is embedded with symbolism.

Well, seven days later, we came up with a single room and a single theme-related puzzle. We realised too late that it was too easy a puzzle, but we hadn't time to improve it. I built the underlying mechanics of a tile sliding puzzle as well, but we didn't have time to finish that either. Ah well. I hope this will be enough to impress the other competitors.

All in all, a rather satisfying experience. And I finished a prototype. I feel accomplished. And I couldn't have done it so well (if at all) without my friend and partner rdb. I have many thanks for him.

~ Xidram

The final version of the game has been uploaded. After a bit of research into the many different versions of the files, I managed to find a combo that works really well (it lacks sound though). After a bit of packaging and ReREADMEing, I can present to you:

Wibbly-Wobbly: the Canine Screwdriver

The aim of the game is to finish levels by reaching a particular area of the screen. The area, of course
is invisible, and so are the switches that modify the map in order to make it possible to reach. Luckily there's an omnipotent somebody there to tell you, Wibbly-Wobbly, what to do, God.

For some reason however, God doesn't seem to speak screwdriverish. God uses some weird language that doesn't seem to make sense... Or does it?

Turns out it does (every single word of it)! You "can" finish the game without learning a word of God's language, but it will take a LOT of time, I hope.

Controls:

Arrows: Movement
Space: Skip cutscene
Escape: Skip cutscene or lose level

The game contains 3 levels 4 cut scenes and an easter egg.

"Enjoy"

I have tracked down the performance problems with my game to Pyglet's use of VBOs. It turns out these are dreadfully slow on my machine - a Radeon HD 4850 on Ubuntu Jaunty - and disabling them globally makes the game run much faster. I have thus added a commandline switch (--novbo) to my game to disable VBOs. If my game is giving performance problems, try this first; if it turns out you are still having performance problems, you may be fill-rate bound, in which case you can try reducing the window size (-d option).

I don't have access to enough machines to know whether VBOs are best to default to on or off. I would be very grateful if you could let me know whether it runs faster with VBOs on or off, and on what OS and hardware (the -r option shows framerate).

This also explains why so many pyglet games run like a slideshow for me. I thought they were just buggy.

Just *slightly* past the deadline (13 hours or so).  The point is, it's here now, right? :-)


Why is the palm-tree in the road?  It's a triffid.  Or a bug.  I only just noticed it.