April 2011 challenge: “Nine Times”

Nines Time - Images moved to another domain and blog posts

Posted by bdilly on 2012/05/20 21:50


I had to move images to another domain, so I'm re-posting them here. Images from previous entries will be broken from now.

Also, I and João have blogged about our participation on pyweek (we forgot to mention it here):

Game screenshots:

Game screenshotGame screenshot 2

Sketch images:

Splash sketchMain Screen sketchVictory sketchFail screen sketch

Add a comment

Pluto the 9th Planet - Pluto the 9th Planet - Postmortem & Walkthrough

Posted by ilseppia on 2011/05/03 15:04

Well, this was our first pyweek as a team, and we are pretty happy of the game we built-up, even if it still needs lot of improvements.
Most of them are from the code point of view... some levels were quickly written down without a strong idea on the paper and this is the result. Fortunately our artist made amazing artwork and the game looks very nice. And thanks to our musician the game has great background tune. We'll add for sure some sound effects in the future.

Happy to read all your comments. Here the replies:
Regarding the long loading time you raised, at the moment original files are quite big and there are some "blank frames". The game is loading all of them and scaling images at startup... probaibly we can have some improvement by resizing the original images and removing blank frames.

At the moment I'm not clear with the "freeze" between the story and the game start, according to me the game should not do anything particular at that stage. As stated by someone of you, maybe the game have some memory leaks... maybe it is something related to the image blitting or frame management... I'm not very experienced so I'll review the code and I'll compare it with yours to understand what is wrong.

For all the people that found the game frustrating, not winnable or with unclear targets... I'm sorry, our first error was to think that a minigame-based game would be easy to code... obviously we were totally wrong, we had to fight with 9 simple but different small games. As result, most of them are buggy. And the worst consequence of this point is that our "Fun" rating has been dropped down.
Personally speaking "Fun" was our primary goal... we learned the lesson.

Here some hints to walk through the game bugs...
Mercury: just press Z and M keys alternately ro run. I hope nobody had problems with this game.
Venus: move with arrow keys and collect asteroids to beat Venus' weigth. If timer reach 1 minute, you lose. Note: I was unsure about limiting movements to the screen border... at the end I choose to let people get lost outside from the screen... don't know if I'll confirm this choice in the next release
Earth: my favorite level, moving your mouse (no clicks are needed) you have to drag seeds on your surfaces and asteroids on earth's one. win condition is you>=90% AND earth<=10%. Lose condition are you=0% OR earth=100% OR timer reach 1 minute. Hope lot of people noticed what happens when you click on the moon ;)
Mars: press the keys showed in the sequence on the bottom left of the screen. If you miss a key or you do not press any key for a while, you lose a life. If you hit 5 keys in a sequence, Mars lose a life. Maybe we'll change this gameplay removing key sequences... don't know at the moment.
Jupiter: unfinished level... Original idea was to keep pressed mouse key to blow yourself (but without exploding) and then compare your size with Jupiter's one. Then I hadn't time to code so as workaround the only way to beat this game is to click, after the "blowing" phase, on that crater of Jupiter that looks like a cork. You should see him deflating (but animation doesn't work). As result you are bigger than him and you win. We'll see what to do with this level.
Saturn: I had problems in coding also the original idea for this level. As workaround, at this moment you have only to follow Saturn's instructions and <strike>type</strike> find his RING... This quick solution has been choosen in order to not waste all the animations of Saturn made without the rings. Unfortunately the font we used in the game is all uppercase, so the RING word is not enhanced as wanted :(. We'll change the font for sure.
Uranus: move your mouse and find uranus, then click. Do it 3 times. Unfortunately the frame management need some improvements, so some animations like Uranus' catch are wasted. And please do not move the mouse too fast otherwise you'll cheat :)
Neptune: Lot of bugs here... once you collect a snowflake (no click is needed) you should shake your mouse until a snowball is made (and Pluto should automatically raise the arm aiming to Neptune to confirm this). Now you should drag the snowball on your picture and pluto should shoot to neptune. You should do this 3 times. As you see I used a lot of "should". Maybe you can succeed avoiding any collision with asteroids and further snowflakes... but I can't assure you.
Sun: We planned a final boss level against the Sun, but it has not been coded at all, I had't enough time... there are just some images of sun in the data folder.

So... probabily for a while we will not have time to work on the game and fix all the bugs, but would be nice to complete it e.g. for next pyggy competition.
For people interested, we'll let you know if new release of the game will be available.

Thanks to all.
Thanks for your games.

1 comment

Squares city - Postmortem

Posted by petraszd on 2011/05/02 23:11

I have written blog post and I am riposting it here:


So, PyWeek #12 (http://www.pyweek.org) has ended and this is going to be some standard lessons learned kind of blog post.

First of all I am sorry for my poor English.

This was my second pyweek entry. First one was kind of weak. But this time I have made better one. It managed to get second place at solos. Oh, and now it even has a clone. How cool is that?

So, link to my entry:


And lessons learned:

RTBR (Read the bloody recommendations)

I really should have read the recommendations. But wait. I have read it. Twice... But. But I paid almost none atention to it. That is bad thing. I think this blog post would have been shorter if not my ignorance.

Include dependencies Yourself

It is one from recommendations. But I have managed to miss it. I could have included pyglet and cocos2d libs into my game. Ok, there is some small pyglet's c dependency (AvBin), but cocos2d has no C code and should have been included into game's source. I think this mistake of mine haved caused some errors for peaple who have tried to run (without positive results) my game.

Communicate with others

I spend around half an hour in IRC communicating with other entrants and that is it. If I would have spent more time chating with others they could have save my game from problems running it by pointing such simple things as: "Your game do not work on my machine because Your have left THAT mistake". And more people than would have played (and hopefully liked) my game.

Proofreading is Your friend

"Squares citry". Mhuhahahahahaha. Citry. I managed to leave spelling mistake in my game's main screen. There is like 10 words in my game and I still managed to leave one spelling mistake... In the main screen. One proof reading pass (10 words -- it should not take long). One bloody reading pass.

And the goodies part:

Try to reach playable state as soon as possible

You probably have nice idea (half borrowed). Your imagination is really powerfull. You can play Your game with it and Your game rules. You definitely are going to win. There is one "but" of course. You have not written one line of code...

My point is that You should reach state of Your first prototype where You can actually see Your gameplay. And it is going to suck donkey balls. But situation will not be as bad as it sounds now, because from there You will make it good or at least not as annoying. But You will need time.

So, You should be fast. I mean really fast. It is game competition and it has very restrictive time limit (one week). Use anything You can think of to reach that limit. Screw good practice. Copy and pasting programming? Good! No unit or other kind of auto tests? Good! Strange class structure? Good! I mean as strange as Dali's paintings? Still good! All anti-patterns You can think and find at http://c2.com/cgi/wiki?AntiPatternsCatalog? Good!

Use anything to have main portion of gameplay ready within shortest amount of time possible.

Do not get me wrong. Do not write bad code just to write bad code. But if writting bad code helps You -- than go for it. During these kind of competitions You need to produce as many features as You can and bad practices are really good for that. Seariuosly.

Than tweak Your gameplay as much as You can

Now You can sort off play Your game. As I said it sucks. But that good -- You have enough time to fix it. But You code sucks. So what? You still need to remove half off it (Your gameplay sucks. Remmerber?).

Spend a lot of time tweaking various aspects of Your gameplay. Refactor some of Your code as You go along. Just do not try to refactoring all of it -- just parts that stops You from easy way of changing small bits of Your gameplay.

Know Your limitations

At start I was thinking of some complex stuff I am going to do. Some complex art I am going to produce. But than I have understood -- I am alone into this one. I can draw all week or I can code all week. I just can not do both. So simple graphics to go.

Some peaple like to say: try to make imposible -- this is the only way to make something decent. I do not think so. You have one week. One week. One week! Forget Your utopia. Just try to make something with start, with end and something that You can call "It is game". First rule: You need to finish within one week. Second rule... Wait... To make playable game within one week is very hard so no more rules. Just make something with start and with end. With too ends (win and lose) if You can.

Have fun

Have fun. Have fun. Have fun. Have fun. Have fun. Have fun. Life is short. Have fun. There is no way I could finish my entry without thinking that I am world class hacker while making some stupid rectangles to collide. So, have fun.


Fractured Soul - Fractured Soul: response to feedback

Posted by Cosmologicon on 2011/04/27 04:44

Thanks to everyone who took the time to judge! 24 is a good number of responses, and we got a lot of really well considered feedback. This is helpful since we're contemplating another version of Fractured Soul. I'll try to respond to the major points. If you think you gave a good comment that I'm overlooking, please say so! First, there were many very kind comments:

I can see that a lot of work was put into it, great work.
I can't figure out it came out from a "random-people" team who never worked together. Very very good job.
Superb entry, especially the puzzle design.
Very nice platformer puzzle game.
A thoroughly enjoyable game.
A really great game.
love the game mechanics. Nice game
Had tons of fun playing this!
The sounds were quite fitting. The background music is a good match too.
This is great! Well done!
Very well made game.
The graphics and visual effects of sprite during the jumps were amazing. background sound was good too.
Great puzzles that made me think.

Thank you! It's definitely helpful to know what we got right. The judges mostly agree that our game idea, sound/music, level design, and overall implementation (nuts and bolts) were good.

Now on to the suggestions for improvement....

Walk cycle is broken
Would benefit from a bit more variety in the scenery
Bland environment
The disparity between the detail on the character sprite/statues compared to everything else was noticable
I found the interludes unimaginative
Some of the humour was a bit... lame

I for one agree with all of the above. The graphics and the writing were the two major content-related issues I had with the game, and I wrote about them in the postmortem.

Act I "tutorial" felt a little longwinded
Fair enough. We'll see about cutting it down. Maybe spread it out so that the tutorial doesn't all appear at the beginning.

Disturbing camera
The camera jumped around a lot
I expected to get a lot more negative comments about this. I also think the camera is disturbing, and at the same time we wanted you to see what a button does when you push it. We've gotten some suggestions about how to get both, still not sure what's best.

I'm a bit puzzled by this. Did you not realize you can walk around the lobby levels by going just underneath the portals? Maybe a different tileset would make this clearer.

I think most puzzles would be equivalent if you could just drop a statue and wouldn't have to start from the gate again.
an undo button would be nice
We'll consider starting where you drop a statue, and hopefully address the repetitiveness one way or the other. But for now I'll just say, there are subtle issues involved that you probably wouldn't think of until you've tried it. There are challenges that only work if you respawn at the start. For instance Ascension could be beaten with four statues if you spawned next to the last statue you placed; many other levels are the same way. As for an undo button, none of the mechanics that made it into the game would be broken by adding that feature, but there are other mechanics I hope to add that would.

Jumping feels a bit odd, probably due to the tile system
lack of solid platforming physics (for example you want to move a little and fall into a pit instead).
The sprite was difficult to control when jumping around the blocks, margin of errors was too little.
The grid-aligned physics helped most of the time, but sometimes got in the way and made the game feel glitchy.
We'll see what we can do. The whole point of the grid-aligned physics is to remove the margin of error with placement. Either you can make a jump easily or not at all. There should be (almost) no jumps in the game that require any skill. Probably the best thing for making it easier to control is getting some playtesters to try out a variety of settings.

cool idea, but needs work
the game is boring when you do the same level for 8th time.
not very fun
Just little platform game without goal.
Thanks for the feedback, not sure what we could do about it. We're definitely open to suggestions you might have as to how to improve the fun or goal!

similar to Braid to which it compares unfavorably
Okay, I'm sorry we couldn't make a game as good as Braid for pyweek. ;)

Thanks again to all the judges, and to richard! See you next time!


Art Attack - Art Attack - Future plans

Posted by mauve on 2011/04/25 13:30

I'm very pleased with the comments Art Attack received in the judging. I knew about a lot of the issues of balance, though I only had limited time to do play testing during Pyweek.

Multiplayer games tend to evolve in response to users' feedback. I'd like Art Attack to really deliver on its promise, not just for the Pyggys, but because it's a game I enjoy playing. I wanted to have pushed the next version by now, but rating 56 games has consumed a lot of my time since the competition ended.

My target is to deliver one new version each week, so long as there are improvements that can be made and so long as there are people wanting to play. The tracker for the project is


and I'm happy to accept any issues/feedback, or better yet Windows or Mac builds, or patches.

I don't know yet whether I'll be able to meet this target or how close I'll get, so if you want to offer encouragement or just play a game sometime, I'd appreciate that. I'll usually be found idling in the #pyweek IRC channel on Freenode.

1 comment

Shattered Silence - PyWeek12 SS3/NP PostMortem...ish

Posted by Falun on 2011/04/25 09:15

Note: Please forgive typos and things that only sort of make sense -- this was written on a plane while being pretty seriously sleep deprived

I kind of want this to be one but I simply haven't had the energy/motivation needed to write it after talking most of these things over with my team.  I'll try to hit the high points though.

General thoughts on PyWeek12:
First and foremost, to all the entrants: Good Job!  The quality of the games this time around seemed pretty phenomenal.  I'm not sure why but it just felt as if everything was noticeably better put together than in the previous two competitions I participated in.

My goal for this submission was to demonstrate that our team could be creative -- previously we'd basically done clones of classic games.  While this meant gameplay was a known good it required no real thought outside of a new plot to frame the same old thing.  This time around we experimented with (somewhat) strange plot, new gameplay mechanics, and (I thought) worked the theme in in a pretty neat manner.

Overall I'm super happy with our performance and our component scores fell as expected: Production > Innovation > Fun.  I am a bit surprised we did so poorly relative to previous entries with Production as this felt like it was the most polished of any of our submissions thus far.  So it goes.

We generally divide PyWeek into two phases.  Phase one is pre-competition and involves a lot of brainstorming about what possible games would be for each theme.  In the past we've started with "NES-style platformers styled after Wibbly Wobbly" or "Steampunkish SNES-Zelda centered around Caught."  This time we started with the theme and came up with a gameplay mechanic that fit the story we wanted to tell.  This was a reasonable success and our "innovation" ranking reflected that relative to previous submissions.

Phase two is the post-selection development and, honestly, not much went smoothly with it this pyweek.  Morale was lagging from day one, we never had a unified mindset about the game mechanics, three of our content people were not available for significant portions of the week.  On the plus side that means there was a lot to learn?

So... about those lessons?
Morale is key for us maybe as much as (or more so?) than having a solid game concept at day 1.  I was having a minor nervous breakdown for the first two or three days of the competition which caused me to miss the most important phase of my development -- weekend #1.  After that I was constantly behind schedule and generally less productive than I should have been until Friday of the competition (which for the most part was too late to make matter).

Fixception and I were the main drivers behind the concept for Shattered Silence and spent a good amount of time during phase 1 and the first couple of days of phase 2 trying to make sure our lead dev (Blake) had a good understanding of it.  We were successful to some degree but changes were made to adapt it to what Blake was familiar with and a non-trivial amount of the mechanics just didn't make it into the game.  In that regard the theme was a bit of an omen -- about 1/9th of what we wanted actually made it in.  To top those problems we really didn't do a good job selling the concept to our asset team which made it difficult for them to come up with content (music and pixel art specifically).  For a game to be developed in a week and do well it should have, if not buy in, at least team-wide understanding of the concept and basic gameplay.

This last bit isn't so much a new lesson but one we continuously learn: as a rule we will underestimate the difficulty of something important.  For SS1 (Shoul Shenanigans) it was (non-pixel) art, in SS2 (Shackled Stones) it was level content, turn around on enemies, and map scripting integration.  For SS3 we hit a bottleneck with level creation again as well as game mechanics and necessity of things like pathfinding.

My take away from this is confusion -- maybe we should try again but with more unity behind an original idea, maybe if we're going to do our own games we should be more "realistic" (but then the creative process is a bit less fun, for me at least), maybe we've reached a bottleneck on our current development style (I suspect this, if nothing else, to be the case).

Going forward:
While I'm not sure about it yet I suspect I won't be working with the NP team for PyWeek13 -- I'm getting a little bit burned out doing work so far removed from the actual game portions of the projects.  Most of those on the team are long time friends of mine and Blake is a fantastic developer so I hate to leave them hanging... but the difference in drive during a PyWeek run between Blake and I is 1) intimidating 2) makes me super hesitant to take a role I think I would find interesting. For the most part I don't expect this to make much difference on the NP team -- Blake is one of those types that can do everything from Art to Dev to Music if he needs to and I'm no better as a second dev than ikanread so shuffling people around should mean for only a minor distraction, if any at all.

I've also been super encouraged by the feedback we got.  Specifically whoever said "Wonderful intro. Fantastic immersive story. A bit lacking in the gameplay department. I don't know if I would call this game 'fun.' But it is a beautiful work of art." makes me really happy, thank you =)  There were enough things of this sort I want to see Shattered Silence built as the game it is in my head so I'll probably start development for it as a long term project outside of PyWeek (probably in C++ or C#)

 - Based on performance vs my personal goals for PW12 I think this was our best submission yet
 - I thoroughly enjoyed the theme and our concept and will likely start development on it as a new project and build out the other 88% of the game
 - I suspect I'm burned out on the team thing, depending on how the second edition (SS3mkii) is going I may not be in PW13 at all.
 - This turned out a little more post-mortemy than I thought it would be.  If you've made it this far you deserve a cookie.


Improbable Rocket-Propelled Dinosaur Scientist - IRPDS: Postmortem and reply to comments

Posted by Tee on 2011/04/24 17:22

Hey everyone,

Thanks for all the feedback and congratulations to both "supers". :) Thanks to Richard for hosting this Pyweek once again.

I'd like to reply to a few of the comments (parts of it, at least) and then write a little postmortem.

Before, I'd like to say that whoever are writing verbose and thoughtful comments are awesome. I really try to make an effort to do that, but I find it very hard, not only because of lack of time, but because I often don't know what to say. This Pyweek I only managed to rate a little more than half of the games due to lack of time, often giving comments without much substance because I couldn't think of anything, and it really impresses me how they write well. If you are one of those, a special kudos to you. I should really learn how to do it.

Second, I'm wondering if anyone played the game without text due to some bug. Text was quite important in the game. If you have, please let me know.

For the sake of not making this post too long, I'll reply only to parts of comments that mention some specifics about my game. Thank you very much for all of you who complimented on my game, even though they're not mentioned below.

Reply to comments

"It works, but for some reason, it crashed suddenly while playing. Also, when starting over, the music sometimes doesn't stop itself before playing again, so you hear the same song twice at the same time."
"And it segfaulted a lot until I changed the fonts."
"Just needed some extending and fixing of crashes."

Odd. Does anyone have any clue to why these happen so I can avoid them next time? These crashes don't happen to me, I could use some help. (The music bug is indeed a programming bug - I forgot to stop it at restart.)

"Although quite short"
"a bit too long"
"the flight itself is extremely long given that there are only two different things that seem to happen."

Not so sure if it's short or long, but I think I understand what you mean. I think all three are right. The game does take little time (only 160 seconds, to be precise), but it feels long because the events that happen are the same over and over.

"Just needs more random events that can occur."
"it's too bad you didn't have enough time to add more events"
"Unfortunately it seems like all of the planned events hadn't been completed so the game was lacking substance."


"Could you have an event where good things, like yummy cakes and pies appear, that you WANT to hit? Maybe randomly change the direction of travel from horizontal to vertical?"

Yes. These are great ideas, by the way, thanks. I'll write the events I had planned further below, on my postmortem.

"This is madness."

Madness? THIS IS PYWEEK! (Too obvious? Sorry. :) )

"the balance was a bit off"
"I'm finding it impossibly hard, though. The difficulty needs to start off much lower and ramp up."
"I didn't get very far, but that's mostly because I suck at dodging things."
"I didn't find the flying pigs to be that hard"
"Actually as it stands, the pigs and the traffic jams are at about the right level (does this depend on the probability you're at though?) - you *can* get through the pigs."

I seem to hear comments like these first three pretty much every Pyweek. :) I should make a goal to have playtesters next one. However, I'm happy to hear that some people didn't find it so hard. Like I wrote in a previous post, I think it's because it strongly depends on how you play the game. By the way, to answer the last one, the difficulty of the events don't depend on the probability; the probability only affects whether they happen or not.

"Also a problem is that there's no time to take your eyes off the action to see when the event has changed and what it's changed to. Might be better if there were a sound indicating an event change, and the text appeared overlaid on the playing area."

Couldn't agree more. I noticed that problem during playtesting and I tried to fix it by coloring the numbers that trigger the event as green. It helped a little and I knew it needed something more, but by then I had no time left.

"And show some indication of the player's health (if there is one already, I couldn't find it)."
"I would also have liked more feedback when I lost a life."

There is one, lower left, above the number. I guess it was too small, sorry. There definitely could have been an effect for when you're hurt, but I had no time for polish.

"Did not follow the theme of the challenge"

Even though the words "Nine times" were on screen at all times? Unless the text wasn't showing up in your case, I really don't know how to make it more obvious.

"As you've said, it needs more events to be implemented; once you start picking up the atoms, the gameplay becomes less interesting."

That, I believe, is a problem with the core idea. The original plan was actually to have "opposite" events occur when you probabilitize them out, not completely remove them. For example, if pigs didn't fly, you'd still see them wandering around at the top of the screen, possibly a few of them would still fall. That way, the game would remain interesting even if you're extremely good at picking up atoms.

"If you're going to develop this game more, here's an idea: stick some floating obstacles in the sky (unlikely things, of course.) This will force the player to pick up atoms that they don't want to."

That's an interesting suggestion and I did think of this initially, but I worry that this might make the game even harder. Maybe there's a better solution to make atom picking more difficult. Thanks for the idea, though.

"I know you said that collecting the probability particles affects gameplay, but it wasn't clear to me how that was happening."
"The mechanics of what was happening in the game were difficult for me to understand at first. I thought I was trying to affect the probabilities of specific major events, but on closer examination it seemed like it was more the frequency of whatever random (I think?) event had been picked?"

To answer the question, no, you are trying to affect the probabilities of the specific major (random) events that are written at the bottom of the screen, not their frequency. I wonder why you felt it was the frequency - that's probably something that needs fixing. Do either of you have any suggestion to make it clearer? These comments, combined with the "font is buggy" comments, make me wonder if you played without text, as I think it's not so obscure with the text, but I may be wrong.

"honestly saying, the visual is a huge deception - from Tee i were expecting the excellence he
reached at Pyweek9, with Quetzal"

I'm not someone who likes to rant much, but I simply can't help it but make this one. Apologies in advance.

To this judge: based on your comment, previous knowledge and a little guesswork, I'm fairly certain who you are, but since I'm only 90% sure and I don't want to disrespect the anonymity of the judges, I'll speak in vague terms.

I understand your disappointment, but was your 1-1-1 rating really fair? According to your comment, you have a strong taste on a retro style, but not all games have to be that way. Although I don't care much about the ratings themselves, it does upset me a little when they're clearly not fair, but what particularly compelled me to rant is that I noticed, by looking at comments to other games and making reasonable guesses, that you also did this to other games, either voting very low or very high based apparently mostly on the style of the game ("i couldn't run this game [...], but the pixel art quality [...] is so far beyond average, that i really bet this game seems Exceptional in everything"? Seriously, how can you rate 5-5-5 to any game solely based on the screenshot?).

Please don't let your personal taste influence the ratings so much, particularly given that you have such strong tastes. Please consider fun, innovation and production separately, and please give the game a few minutes before rating even if you don't like the visuals. I'd really appreciate it if you made a better effort to be more fair for next Pyweek. Assuming I'm not wrong about who you are, I know you like this community and I enjoy your enthusiasm around here, but I think you should be more fair to everyone, even to those that clash with your ideas and style. I know you're disappointed with this whole Pyweek this time because most games didn't suit your style, but if you really like this community, please try to be a little less zealous about your style while rating and be constructive to everyone. Thanks. :)


I usually have more time for Pyweeks, but this Pyweek I had only Sunday and Saturday, one of which I wasted completely, so, not counting "thinking about the idea" which I can do anywhere, I had only one day.

This time, I decided to do something I usually don't do: make up concrete concepts for the five themes before the challenge started. I was lucky to have gotten a theme for which I had a nice idea, playing with the expression "Nine times out of X". That's something that went right, though I suppose it was a little based on luck.

The original concept didn't involve a flying raptor; that idea came along the week. Originally, I was going to do a Canabalt-style game, but I decided it was too much work for only one day considering all the rest I had to implement, so I opted for the much simpler "use your arrow keys to move" scheme. The original concept also involved a robotic-like newscaster telling you the probabilities of events happening.

As I had said before, I had planned more events to the game. These were:
- floor becomes lava: the floor above you becomes lava and lava balls start shooting down Mario-style;
- a train cuts across the screen: a train runs over the bottom part of the screen; I wanted to have one single event that inspired fear so the player would be desperate to "probabilitize" that event out when he sees that message;
- bugs happen: Python exceptions would cover the screen, disrupting the player's visibility;
- the screen turns upside down: self-explanatory; I thought this would be fun as the ground would actually become the ground;
- rockets boost: the player would get a boost to get to the ending faster, though this means obstacles would also be faster;
- dinosaurs shrink: self-explanatory, easier to dodge obstacles;

There aren't that many events (it particularly lacks good events - though one suggested in a comment, flying cakes, was a good one), but at one moment I stopped thinking about them because I knew I wouldn't have time to implement all of them. Maybe with time I would have thought of some crazier, more out-of-the-box events. Also, as I mentioned in my reply to comments, I also planned to always have things happening even when an event didn't happen, like pigs walking when they didn't fly.

Another thing planned but unfortunately cut out was a sense of progression - the way it is now, there's no sense of progression except the progress bar. That is, the game would become harder and new events would show up as you progressed during the game. That was something important that I wish I had time to implement, but I barely had time to implement the small amount of events in the game.

Difficulty was an issue in my game, but those who know my history would guess correctly that that doesn't surprise me. I have a tendency for hard games and that reflects on my games even when I actively try not to make them too hard. I should really make time for finding a playtester next time.

Overall, I'm reasonably satisfied to how the game turned out even though I wish I had time to implement some more events. I like the concept and the execution turned out reasonable, particularly given it was made in a hurry.

Anyway, thanks to everyone for all your feedback and all your games! See you next Pyweek!


City Nine News - City Nine Times: Post-mortem and feedback

Posted by akira44 on 2011/04/24 15:09

Well, there goes PyWeek. As I promised earlier, let's take a look at the lessons learned, mistakes made and all that.

What (I think) I did right:
  • A clear game idea: even though the idea was not a great one, having a precise idea of what you want your game to do ended up being a great time-saver. If I had to take this as a lesson for a future PyWeek, I'd say that during the voting week, each day could be used to come up with a full idea of what to do if a certain theme is chosen. As I said before, I've based my game on a previous one, so every aspect of gameplay was well defined before the start.
  • Planning. planning, planning: I knew I wouldn't have enough time (well, neither of us does) to do everything perfect, so I made a realistic schedule I could stick to. In case you are curious - engine:3 days, art:2 days, music:1 day and fixing stuff:1 day). Leaving the less important tasks to the end allowed me, when things went bad, to cut out on music and use the remaining time to fix bugs.
  • Know your tools: If I may say so, I think the artwork came out good enough. Had I not had my full "studio" (that is, my bedroom) completely ready to go, I would have had to settle for a lot less. For instance, having a graphics tablet and knowing how to use it is the only reason I managed to give the repair guy a blue shirt (it is hand-painted) in less than an hour.
  • No features!: Cutting features as I thought about them was a nice touch. Yes, the game could certainly use improvement, but had I spent time in every single idea I wouldn't have made it on time. In case you wonder, a few of them were:
    • Fix the repair guy so he doesn't wait for you to unblock his path - solving this would have made the AI much more complex than a simple BFS, plus it could have led to situations where neither of you can move. That's also the reason the guy takes sometimes the longest path :P
    • custom "break" animation for the machines: that would have taken too much time. On that same level: giving the repair guy a tool case.
    • pause and score: the levels are not long enough to warrant the time - if you have something to do, just lose and continue. Same thing with score - I have the suspicion no one said "damn, I wish this game had a score..." :P
What I did wrong

  • Not enough play-testing: if you played my game, you know it goes from "looks good" to "aaaaarggh, i hate this thing!" too fast (level 3 is annoying, level 4 is a nightmare, only one guy made it to level 10, and that was after altering the difficulty - I wrote about that in a previous entry). Had I played for at least one hour, I'd have spotted this fairly fast - and that only happened because I decided to use the alloted time to add lamps, plants and a carpet, that is, for not sticking to my schedule! I've seen this happen before, but only as an artist, not as a developer, so I'll keep this in mind for my next PyWeek.
  • Not a great idea: Honestly, I don't really know what I was expecting to come out of this. I mean, I didn't even like the original game! I think I went with "this looks manageable" instead of "this looks fun", and while that is not really a problem in an office, for a game that's a bad thing... On a rather ironic note, I was against "Coughlin Brother's Mortuary", but that game would have ended up being at least more original than this :P . There were many good suggestions in the comments of some other diary entries I wrote, and while many of them are good enough to improve the game as it is, they probably can't help the fact that you don't have much power to alter the outcome of the game - all you have to do is follow the orders, and that's it. I'll try to come with something better in the future.

About the comments
Thanks for all of you who took your time to play and rate my game (except the two of you, you know who you are). If I have to be honest, I was bracing myself to much worse comments, but the fact is that (almost) everyone was nice and polite (I was expecting something like "BOOO-RINGGG", but instead I got a nice "The mechanics are quite simple").
A few comments, leaving aside all those "the game is hard/boring" and "the machines break too much":
  • Ok, but what about the theme? You work in a newspaper called "The Nine Times", I thought it was clear enough :P
  • Eventually it's purely a matter of chance whether a particular playthrough of a level is winnable at all: Yeep, that's the real problem. Too bad I didn't notice that earlier :-\
  • A bit repetitive, and frustrating when things keep breaking randomly when your time and coffee is running out. But something perverse about the monotony appealed to me :) : Yeah, I guess making boring games is not precisely the way to go, but I also appreciated that; is kind of an artistic statement if you push it a little (ok, a lot).
  • It's a bit annoying that repair dude wants the whole hallway for himself: Tech response - that's because if the guy moves when there isn't a clear path, then there is a chance that he'll corner you in a hallway, and since he doesn't know what "surrender" means he won't walk back, and you'd end up staring at each other in a hall until the end of time. But yes, a decent AI should be able to solve this, right now is a simple BFS (breadth-first search) algorithm.
  • I have to say it would have been even better with some background music: Damn, you touched a sensitive subject! Yes, not only I wanted to give it some background music, I wanted to make it by myself too! Unfortunately, I had to cut a day from my schedule, and music had to go. As a personal revenge, the note you hear when you lose is 100% home-made with my harmonica :). That reminds me: if you liked the intro music, that tune is "Chased by a cow" by Heifervescent, from their album Hoofed and Dangerous. You can download the album for free from Jamendo.
  • the coffee meter goes down pretty fast: In the original game, it used to go even faster :-\ - but yes, it does, sorry!
  • I had to edit the code and decrease the probability of stuff breaking in order to make some of the later levels winnable. Then I got to a level that didn't seem to have the player on it: Yes, I've just noticed that! The last level file (data/levels/10.txt) has no "x", and thus has no player, sorry for that :-\ - If you wonder how the game looks like when you "win", you can open data/endgame.png and feel blown away by how different it looks from the regular "game over" screen :P - In case you wonder, this entry details how to make the game easier. If I can submit a patch, I'll upload it in a couple days.
I think those are the main points, but if you think I left out either a good or bad lesson from my game feel free to comment. I also want to thank everyone who entered (except the two of you, you know who you are!) for making PyWeek such a fun experience, and I look forward to see you all again in 4 to 6 months.

Good luck!

Add a comment

Interesting Times - Interesting Times - Thanks, Postmortem and Future Plans

Posted by gcewing on 2011/04/24 08:41

Thanks for all the good ratings given to Interesting Times. It did better than I expected, given that I only had time to implement about half the ideas I had for it.

Instead of just the boring stars, I was going to have randomly-generated newspaper headlines popping up as overlays, hopefully with enough amusing combinations to keep the player entertained. I think that would have helped to raise it above the level of being just about running around collecting tokens. Instead of stars with numbers in them, you'd be going after something with meaning.

There are also a few issues with the mechanics. The reporters need to be made a bit more self-sufficient so that they don't need so much micro-management. A particular problem is that there's no coordination between them, so they tend to go after the same news items and bunch together. Eventually they're all on top of each other and travelling around together, so you have to keep manually spreading them out. Making them slightly more intelligent would fix that.

Another thing is that once one side has all the houses around a newsstand subscribed, it's very hard for the other side to fight back. You can be publishing lots of great news, but it doesn't do any good because nobody is taking any notice of it. The only thing you can do is try to starve the opposition of news and wait for them to lose subscribers, which can take a long time, and if you don't have any subscribers yourself you may not have enough cash to last that long.

Probably subscribed houses should take newsstands into account in their neighbourly influence the same as other houses, something they don't currently do. That would give you a toehold to try to win back subscribers by publishing superior news.

Another thing I've been considering is making it possible to buy newsstands, and perhaps build new ones, so that they only sell your newspaper. This would obviously have to be fairly expensive, otherwise you could win just by buying up all the newsstands. But if it's too expensive, it wouldn't be available as a way of fighting back when you're in a tight corner. Some more thought may be required on that one.

Some other ideas that didn't make it:
  • Instead of newspapers being magically transported to newsstands and runners, you have a head office and need to hire vans to distribute them from there.
  • You should have to decide how many copies to allocate to each newsstand and runner.
  • Instead of paying day-to-day, subscribers should pay for some number of copies in advance, perhaps a week.
  • You shouldn't be able to hire and fire employees on a whim. Perhaps a redundancy payment should be required whenever you fire a staff member.
  • Other ways of acquiring news, such as purchasing a subscription to a syndication service. (The downside would be that some of your news would help the opposition as well.)
  • Other sources of income, such as advertising revenue.
  • Maybe there should be some ways for your reporters to attack their counterparts, such as phoning in fake news reports?
  • Music! Every game needs music...
Anyhow, I've certainly got enough ideas to be able to make an improved Pyggy version, although I haven't decided whether to do that yet. What do you think? Would anyone be interested?

Responses to Feedback

never seemed to be able to make much of a profit

Yes, you probably won't end up rolling in dough, but that's not really the object, gaining subscribers is. Money is only useful insofar as it enables you to avoid going bankrupt. If you can keep printing papers and paying your staff, you're doing all right.

For some reason I keep wanting to work Clarke Kent and Superman into the game somehow. :)

Ha! Something to keep in mind when writing the headline generator, perhaps. :-)

My money never seemed to go up or down, and I didn't get the feeling that I was winning OR losing.

As mentioned above, if your money isn't going down then you're doing okay. As for winning/losing, if the playing field is turning blue, you're winning; if it's turning red, you're losing!

I think this game needed a few tutorial levels with dumbed-down rules so that players can get the hang of it one step at a time.

Yeah, a tutorial is another thing I didn't get time for. Not sure how to dumb things down, but the first level is probably small enough that you don't need to worry too much about hiring extra staff or setting runner routes, so those things could be left for later levels.

I couldn't find how to exit the level designer.

Hmmm, this is embarrassing. I just tried it, and found that the level editor menu is being displayed as black on black. :-( It seems that I never used the level editor after I changed the menu text colour from white to black as part of adding a background to the title screen, or I would have noticed that.

If you turn on your Clarke Kent X-ray vision you'll see that there's an "Exit Level Editor" menu option near the bottom of that black screen. Or you can press Ctrl-Q to get back to the main menu.

Very nice graphics

Thanks, but most of the credit for that is due to Danc, who designed the unbearably cute characters in the PlanetCute tile set. I admit responsibility for the cruddy-looking houses, though. :-)

Hope to see you next time :)

Thanks, I'll do my best to be there!

Add a comment

Forever End - Final thoughts on the competition

Posted by ChipX86 on 2011/04/24 06:23

So now that the PyWeek judging is over, I thought I'd give a few final notes on PyWeek and my game.

So PyWeek was definitely a blast. So much fun, and a great opportunity to start learning game development.

Looking bad, I realized there were things I could have done much better:

  • Make it more clear when an effect was an effect. A lot of people rated my game as graphically glitchy, but those weren't glitches they saw. It was the "time is merging together!" effect. Oh well. If I had the time to finish the effect, it would have been very obvious. Frankly, I liked how it ended up, though would definitely go further if I decide to continue the game.
  • Add a tutorial! I planned this but couldn't fit it in.
  • Level design could have been better. I knew this, but again, didn't have the time. If I had a month, this game would have been wayyy different, with more interesting ways to use multiple time periods.
  • Sounds! Animation! I almost had sound, actually, but it felt too much like I was trying to shove existing things in. Next time I'm going to see about getting someone who can spend their time on the sound. As for animation, the main problem was that the main guy didn't animate. I have a few versions of his animation but didn't like any of them and didn't get to fine-tune them in time. Next time, that's a priority.
So room for improvement, but to be honest, I did this for myself. Never written a real game before and wanted to learn what it would take. For a week's worth, I'm thrilled how this turned out, and am looking forward to the next PyWeek, with the opportunity to make use of some of the feedback from this PyWeek.

Add a comment