Improbable Rocket-Propelled Dinosaur Scientist
The Improbability Device has gone through a massive failure, and it's up to a scientist to get to the lab and fix it. Unfortunately, the device has turned the world upside down and the scientist into a dinosaur. Furthermore, probability atoms have been spilled that alter probabilities of things happening. Fortunately, the scientist has a rocket to avoid all those upside-down traffic jams.
Created in a rush in one day, so things may be a little shaky and incomplete. Requires pyglet.
Created in a rush in one day, so things may be a little shaky and incomplete. Requires pyglet.
Awards
Scores
Ratings (show detail)
Overall: 3.3
Fun: 3.1
Production: 3.2
Innovation: 3.6
Respondents: 25
Files
File | Uploader | Date |
---|---|---|
IRPDS-0.1-without-pyglet.zip
— final
Improbable Rocket-Propelled Dinosaur Scientist, without pyglet |
Tee | 2011/04/10 00:07 |
IRPDS-0.1.zip
— final
Improbable Rocket-Propelled Dinosaur Scientist, with pyglet |
Tee | 2011/04/10 00:06 |
IRPDS-ss.png
In-game screenshot |
Tee | 2011/04/09 23:42 |
Diary Entries
Improbable Rocket-Propelled Dinosaur Scientist
This is probably one of the best game titles I have come up with in Pyweek.
This Pyweek I had an interesting idea right from the beginning but I had very little time. I was forced to rush everything in at the last day. There are many things missing from the original concept, as usual.
The concept comes from "nine times out of X". There's a story about a scientist who works on the Improbability Device and becomes a dinosaur after a massive failure and then has to rocket towards the device to fix it. On the way to the machine, improbable events may happen, but unfortunately I had time to implement only a few. The dinosaur scientist can alter the probability of these events by picking up atoms that were released from the failure of the device.
Only after I finished the game I realized there was a flaw in the design: there's some chance that the player makes things too improbable to happen, so nothing ends up happening in the game, which means the player might get bored. I tried to fix it at the last minute, but I couldn't do much besides tweak a few parameters, and I'm not sure that helped much.
I started this day thinking I might not be able to finish something, and I still had that feeling in the middle of the day, but there it is to prove myself wrong. The game could use a lot of work, but at least it's playable. I hope you enjoy the game. As usual, feedback is very much appreciated. :)
This Pyweek I had an interesting idea right from the beginning but I had very little time. I was forced to rush everything in at the last day. There are many things missing from the original concept, as usual.
The concept comes from "nine times out of X". There's a story about a scientist who works on the Improbability Device and becomes a dinosaur after a massive failure and then has to rocket towards the device to fix it. On the way to the machine, improbable events may happen, but unfortunately I had time to implement only a few. The dinosaur scientist can alter the probability of these events by picking up atoms that were released from the failure of the device.
Only after I finished the game I realized there was a flaw in the design: there's some chance that the player makes things too improbable to happen, so nothing ends up happening in the game, which means the player might get bored. I tried to fix it at the last minute, but I couldn't do much besides tweak a few parameters, and I'm not sure that helped much.
I started this day thinking I might not be able to finish something, and I still had that feeling in the middle of the day, but there it is to prove myself wrong. The game could use a lot of work, but at least it's playable. I hope you enjoy the game. As usual, feedback is very much appreciated. :)
IRPDS: Postmortem and reply to comments
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."
Definitely.
"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. :)
Postmortem
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!