Screenshot of the final version

People and Planes

Once upon a time, there was this green man who enjoyed Pyweeks. Unfortunately, this time, he was plagued with unexpected problems and at the last day, he realized what he had wouldn't work. So, looking that he had only 8 hours left for the deadline, he decided to go out for a walk instead of finishing his entry. He climbed a giant ladder and sat on a cloud. From the top of the cloud, he saw many little colored people waving to the air. From the view above, he also saw several colored planes flying around. It was very obvious that the little colored people wanted to get in their respective colored planes. And so he remembered he had a piece of string from Pyweek, so stuck his hand on the cloud and let one end of the string drop so the little colored people could grab the string to get on their planes. And, so, his quest began to put the little colored people in the little colored planes...

Please read README.txt for instructions, but all you need to know is that you move with arrow keys and have to put colored people in planes of the same color. Sorry for the lack of polish/sound/intro/ingame-instructions.


Sort the pretty colors!
Presented by saluk

Give this entry an award


Ratings (show detail)

Overall: 3.2
Fun: 3.0
Production: 3
Innovation: 3.5

3% respondents marked the game as not working.
Respondents: 27


File Size Uploader Date
Windows py2exe'd of the final version. Big file. :/
5.3 MB Tee 2008/09/14 01:02
Screenshot of the final version
53.9 KB Tee 2008/09/14 00:17
A version of the final entry without pyglet
53.4 KB Tee 2008/09/13 23:56
Final entry, done in 8h :)
783.8 KB Tee 2008/09/13 23:55

Diary Entries

People and Planes: Reply to comments

Wow. I'm quite happy. I wasn't expecting such a high rating (at least for this game). Thanks to everyone who played and voted on my game. :)

Here's a reply to the main points of the comments (not going to go through one by one this time):
  • String physics: Unfortunately, I know nothing of rope physics. That string was the best I could do in roughly more than one hour. I had a cool looking string using Box2D, but, like I said in a previous post, I ended up not using it. One comment liked the physics, thanks. :)

  • Plane hitting the cloud: Actually, I thought that was a nice challenge to the game. You not only have to put people in planes but also dodge the planes, thought that would be an interesting challenge, turned out a few people didn't like it much. I still like that challenge.

  • Lack of sounds, music and polish: Yeah, sorry about that. Would have put them in if I had the time. Although I am guilty of having no sound/music in 4 of my 5 Pyweek entries...

  • Colored people appearing without warning and no indication of stun time: Hmm, didn't think about that, actually. To the person who wrote this comment, I guess I need to have people like you around as playtesters. :) To be honest the game was very little playtested. I'm quite happy you said you'd keep this game on hand when you need a few minutes diversion from work. :)

  • Last level is hard: You're absolutely right. I only had time to test it after the deadline and I too had a very hard time with the last level, but I managed to beat it with some luck and effort.

  • Terrorists entering the planes: (original comment: "This is totally irresponsible. You're letting the little coloured people get on the little coloured planes without having to pass through little coloured metal detectors and having their little coloured tweezers confiscated. You're putting the world at terrible risk!") Uh oh. Should I discriminate them by color?

(There was one DNW due to lack of pyglet, which is odd, because the main package had pyglet in it.)

Thanks for all the comments and feedback! Overall, I'm happy with the comments and the ratings. I don't think I'm making an updated version but learning what I could have done better certainly helps me make better Pyweek games in the future. :) Congratulations to the winners, not only both winners had awesome games but also there were a lot of other awesome games. In fact, congratulations to everyone who finished it. Thanks to Richard once more for hosting it.

I have to admit even though I wasted 6 days on a totally different game that didn't work, I learned a lot this time and this was a great Pyweek (not to mention I surprised myself at how fast I made this game, considering I've tried a few LD48s and never managed to finish them).

See you next Pyweek. :)

Add a comment

Postmortem and some lessons learned

This a long post, but maybe you'll find it interesting to read it if you have some spare time. (Lessons are bolded in case you just want to skim through.)

My performance in this particular Pyweek was probably one of the worst. I had no problems with the theme, but I slammed my face into several walls. It turned out ok in the end, but I still wish I had made a decent game. The neat thing about Pyweek is that every Pyweek there's always something new to learn. This time, time wasn't much of a constraint, I blame my mistakes more. So I'd like to talk a bit about my week of Pyweek; despite the failure, it was actually quite unusual.

In the beginning, I had no idea what I was going to do. So I planned a simple platformer with string swinging and climbing and more stringy actions and decided to do it. I needed some rope/string physics, so, knowing that it would take too long for me to do that by hand, I picked Box2D. It was fairly smooth to use it and in the beginning things were well. Eventually, I was able to make a reasonably decent string that got longer or shorter. But then I realized I wasted too much time just tweaking the string, and decided to go with a different idea I had while playing with the string.

So far, things were okay. I had an interesting theme planned out to cover the mechanic. The basic mechanic was that you controlled an invisible ball with eyes that was attached below the string, and the physics made it feel like you were a string ghost, which felt really nice and cool. But I wasted a few days on it before realizing two lessons.

1. Be precise on your design, especially if your game isn't tried-and-true. My game involved shoving things away with white string and destroying things with black string, but I didn't realize how badly they could interfere with each other, considering they were parts of the same string. The problem in my design was that I didn't realize that it would be hard for the player to do what he wants, which brings me to lesson 2.

2. If you are unsure about how an element behaves with another element, be sure about it before putting those two elements together in the game. So after I realized my string was so hard to control, I decided to tweak it. And tweak it more. And so I spent a lot of time tweaking it to see if I could make the string easier to control. Putting joints there, removing joints here, adjusting parameters, etc. Eventually I had something I was somewhat satisfied with, but I had wasted a lot of time.

Also, having an interesting theme somewhat blinded my view of the mechanics. I had this really interesting, artsy idea where the string would represent life and white string and black string would represent good and evil respectively, there were several cool features about it, and I kept insisting on it, even with the mechanics not working out well. A possible third lesson here is to make clear view of your mechanics, try to see if they work well without what's on top of it (theme, rules independent of the mechanics, graphics, etc).

At that point, it was already Friday. I realized things just wouldn't work when I stumbled into more incompatibilities between design and physics. So at that point I decided to scrap my theme, but I liked the idea of that ghost-like string, it looked even nicer when it was glowing, and I didn't want to waste it, so I kept it. That was another mistake, sometimes you just have to scrap everything and start over (that's a hard one to learn and even harder to identify when you have to do that).

The third idea was very simple: there would be several enemies with black and white "weak points", and if you touched them with the same color, they would get stuck to your string. Also, if you made a weak point touch another weak point of the same color, they would stick together. The goal was to destroy enemies by "sticking" all the weak points to something. That sounded pretty cool, but there was a technical problem. It's a technical lesson, but, anyway, joints might not be as tight as you want. The thing was that, to make things easier, the weak points were different bodies from the enemies themselves, with joints attached. The problem was that they either kept distancing themselves from the enemies, or when one enemy was attached to another, they kept distancing from each other (this depended on how I tweaked the masses). I managed to have something reasonable except for fast or wacky movements, but there were two more problems.

First, the game felt like a Frankenstein. Nothing connected. There was the ghost string, there were the enemies, but there was no reason for them to be together. It just didn't feel good, next time I should keep in mind that every element of a game should be well connected. Second, the tipping point that made me give up was that my game not only crashed, but also crashed the computer, for the second time. Sure, it was only twice, and there were other programs running which could also be the culprit, but I just didn't want to risk handing out a game that might crash someone's computer.

Anyway, at that point I had only eight hours left, and I felt like I should give up. But I really wanted to submit a game, and those eight hours were mostly clear, so I picked an idea I had before, scrapped everything and decided to do it. I made a really simple and rough approximation to a string, drew some planes, drew some people, added the code, and finished a simple game. I never managed to finish a Ludum Dare, but, ironically, I managed to finish an eight hour game in Pyweek. I felt kinda glad, but I still feel bad for wasting an entire week. The good thing about it is that it actually made me feel a bit more confident for a LD, and there were a lot of lessons learned. A last interesting lesson is that sometimes you do better with a totally different idea in just a few hours rather than sticking with another idea for a week, although I think it's very hard to identify these situations, but it's good to know that situations like those exist.

It was fun, though. I've never tried to implement four different ideas in one Pyweek. I haven't gotten around to play the games yet, I still have to catch up with my usual postponing of things first, but I will when I find the time, there seem to be a lot of fun games. Sorry for the long post, but if you're still reading, thanks for reading. :)

1 comment

After scrapping three different ideas...

So, earlier today I've scrapped my third idea, because it was getting very messy and the design wasn't good, but I've managed to make a simple, untested game without polish or sound or intro in eight hours. I'm happy that I managed to submit something, even though I wasted the entire week on ideas that didn't work. :) There's even a little story to my game on my entry page. Unfortunately, I didn't have time to properly test it, so sorry if it's unbalanced (too hard or too easy). Let me know if you manage to win and how hard it is. :)

It turned out fairly small. The zipped source file is 53kb for the pygletless version, it's even lighter than the screenshot. With pyglet that's 783kb. I hope you enjoy it. :)

Add a comment

Second detour

Anyone who has been following my posts know that I haven't been doing very well with my entry, so this morning I had a new idea that uses some of what I've already implemented and I scrapped the rest. This is the second time I'm changing ideas, and I don't think I've ever changed ideas so late in Pyweek. Anyway, this new idea isn't too complex to implement, though unfortunately it's not simple enough to have that "beauty of simplicity", and hopefully I'll deliver something in time. I've already coded some of it this afternoon and will continue until I finish.

This is probably one of my worst performances in Pyweek, but I think I can at least submit something that's probably not too fun, but it's slightly innovative in the sense that it's probably not a type of game you play very often. I haven't given up yet.

Add a comment

Progress (or lack thereof)

I haven't been doing so well with my game, I've been hitting wall after wall. That style that I said that fits perfectly with my game, turns out, I can't make it fit so well. I had made before some design decisions that I thought would work, but in practice, I've realized they don't. I've learned that you have to be careful with envisioning games that are a bit more experimental, because this or that mechanic you think would be cool might not work so well in practice. And I just can't figure out the art for this game, you might have to play an ugly game.

Oh well. I'm going to look for workarounds and see what I can do. I'm just not sure I can make it fun.

1 comment

New idea

I'm really excited about this new game mechanic that came to my mind. I've found a theme that fits perfectly with it. I'm not going into details just yet, I'm just going to say I'm very happy with it and I really hope I can finish it in time the way I want. I've just finished establishing the design, and I realized there are a lot of things to do, and I've already wasted half the week, so wish me luck. :)

The current title of the game is Trace (subject to change, of course).

1 comment


I've been having some problems with my progress. All I've done so far is a string, but I'm starting to lose confidence in my original idea, especially because I'm not sure if I can make it in time. On the other hand, while playing around with my string, I've had this a bit more experimental idea that could be interesting, but I'm not too sure if it can be fun. But I think it should be faster to implement than the first idea.

So, I'm torn between two choices:

a) stick with a more tried-and-true platformer-type game that I might not finish in time, but should definitely be fun; or
b) go for another idea which is a bit more experimental, with some potential for disaster, but could possibly be fun, probably not as fun as a), and also I think is faster to do?

I did say in another post that I would try to focus on fun over innovation (a), but b) would sort of be the opposite. It's actually a pretty cool idea which I won't say just yet, but I'm not so sure about the fun in it. Currently, I'm leaning towards b), especially because I'm worried I might not finish a) in time. I'm going to bed now, so maybe tomorrow I'll have a clearer thought of what I want.

Thoughts, anyone?


I might have a name

Progress is slow, but I might have a simple name for the game, subject to change: Gnome Caves. It's a platformer game about one or maybe more gnomes in caves. More than that, I still haven't decided, but currently I'm trying to figure out whether I can do what I want with strings.

Add a comment

Fun vs innovation

I'm starting now and I might have an idea. It's not too innovative, it's basically a one-screen platformer game involving strings and climbing, possibly similar to what other people are making, but it seems to have some potential for fun. Previous pyweeks I always tried to focus on innovation before I started the game, now I'll try something different: start the game first with a solid base, and then think of neat (possibly innovative) features I can put in it. I already have one pretty neat feature I like about this idea, but since I'm not too sure about it, I'll tell it later. :)

What I really mean is, this time I'll be focusing on the "fun" aspect, instead of the last times when I mostly tried to be innovative. I hope it works.

Add a comment