Some comments
This has been a really fun Pyweek! Thanks to Richard and congratulations to the winners!From what I see, most comments had to do with the following:
- The forest is too hard Too bad... We wanted the game to be longer, and successively harder, but we had to cut some parts from the middle, due to lack of time. I suppose the contrast between the easy puzzles from the beginning and the final puzzle put some people off. Sorry!
- Hey, in the forest if you go west and go east you not return to the starting point !!! Thats off the rules !!! Hehe! We stole it from Dunnet. It their fault! ;)
- How are you supposed to use the gateopener? "Give gateopener" or "drop gateopener". We didn't realize that "use gateopener" would be logical. Sorry, again.
- The fun was spoiled for the dumb input interpreter. Need to accept more variations It does actually accept variations. We are not too experienced with this kind of games, and the standard commands that they accept. The parser is pretty flexible if you have time to implement more aliases. We'll try to think it through better in the future, though.
- I looked in the code for hints Woo! You managed to find your way through that mess? Kudos to you!
- A baguette? What the hell? (a.k.a. fixing the ladder) But there was a bakery! Sorry :)
Thank you all and see you in six months!
(log in to comment)
Comments
Refactoring might be better. Hm... Maybe we'll wait with the new engine for future games instead (text based adventures were fun!). Ah, well. We'll post here and on pygame.org when the new version is out!
Regarding the rudeness, there should be some way to discourage posts like the above. Perhaps making the votes non-anonymous could work? In my opinion, it shouldn't really hurt the voting process.
I was wondering if png would compress more (png is worse than jpg with photographs, but with the effect it looks like there are a lot of areas of colors in common), so I did a quick test with one of your images and it was larger. So you should probably use a more compressed jpg like claxo said.
Some comments will be rude, I think the best to do is to realize they're not useful and just ignore them. Maybe making votes non-anonymous could work, I don't know, I'm a bit indifferent to that, it does make people more careful on what they're going to write. The only disadvantage I see with that is that people might rate others games lowers based on comments on previous Pyweeks, maybe even in a not so conscious way.
(I thought it was funny using the baguette. I put the first three, then I realized I needed one more, so I tried the baguette and it worked. Things like this are actually not so uncommon in interactive fiction or adventure games if they lean towards the humorous side. In fact, I don't know of a humorous adventure game (like Monkey Island, Sam and Max, etc) that doesn't use an item in an unusual way. Perhaps you could have said that the baguette is so stale that it's as hard as a rock, that would have probably helped.)
Interactive fiction games should have more playtesters than other games (more playtesters, not necessarily more tested), because it's hard to predict what someone will try. Of course, in a competition that's hard, but maybe that's something you might want to remember.
I like the comic. :)
http://xkcd.com/481/
Although I consider the comments around here much, much nicer than what's out there. Even those you said were rude I don't consider them so rude.
Certainly such a virus will be useful !
You are right, Tee, that in the wild you can expect much more harh opinions. One must enter in 'review mode' before reading opinions over one's work: take usefull facts, rejoice with kudos, disregard noise and pass over empty, negative stings.
Anonymous votes are better, in my opinion. Less post-judge bickering, no resentements.
It's way too much to ask, but I wish that reviewers would skip games they know they wouldn't like due to genre alone. It's genre discrimination I tell you.
I also love when people complain about theme for games that fit pretty well. They did that to me last time with my robot fighting game - they were all "I really don't see how a robot fighting game fits the theme of robots".
But yeah, I'm one of the many who quit at the forest maze. I never liked those sorts of mazes in these games. And the walkthrough didn't really help either. How do I get out of the maze? I want to see the end!
- Provide "x" as an abbreviation for "examine".
- Provide more phrasings for repairing the ladder. "Use" is actually quite a rare verb to find in a text adventure. Players are more likely to try things like "repair ladder", "fix ladder", "mend ladder" (and all of those with "using something" appended), "attach something to ladder", "put something in/on ladder", etc. If you are going to require "use" for anything, it would be a good idea to mention the existence of this verb somewhere in the instructions.
- The first few times through, I completely missed the fact that I could go north from the garden outside my house. Most locations clearly indicate the possible exit directions, but "north" is only mentioned obliquely here. Together with the picture it didn't suggest going that way.
- If you are carrying the gas when you encounter the camel-walrus for the first time, things happen in a confusing order -- the reaction of the camel-walrus occurs before you get a description of the location or mention of the existence of the gate and gateopener.
- Get rid of the maze. Mazes in adventure games are nowadays almost universally reviled as a thoroughly worn-out idea. Unless a maze has some ingenious new twist, which yours doesn't, players will hate it.
- At the ravine, if it's possible to "climb down", then just a plain "d" should really do the same thing -- especially given that "u" is sufficient for climbing trees. Until I saw the walkthrough, I didn't know that it was possible to go down at the ravine.
gcewing has some excellent points. Don't forget "get". I also didn't know it was possible to go down the ravine until I looked at the code after I finished to see if I had missed anything, and I also tried "d" at first.
claxo on 2008/09/28 20:56:
Compression:After seeing the comment about compression, I tryied a quick test: load bakeryinside.jpg , and saved to .jpg changing the image quality.
Initial size was 601 KB , final size 110 KB, 'eye quality' good. So, certainly there is room for improvement on package size.
For photo derived ( ie no big solid color areas, no thin lines) .jpg is usually the right type of file to use for high compresion and reasonable quality; you just need to play with the quality options to get the right balance.
Obviusly you must compress only in the package stage, to preserve good quality art while developing.
Not to say that your team must have done that for the compo (deadline comes too fast !!), but surely worth for a postcompo release.
Post compo:
If I may tell, full rewrites usually dont ever come. To the point refactors have much high likelihood of success. Not so much a mess the current code, at least if you limit yourselves to flexibilize the parser and be more kind in the forest.
Rudeness:
Even accounting for low social skills and posible not english fluency, yes, there are a few comments in bad tone, (in your entry ratings and in others ). It is good that you comment on these, so that people can see how it will be perceived, but dont let the issue lose your mood. In a group of 100 people it is nearly guaranted some prick.