Bug quest

[gangelop]

I have added a small bug quest which consists of two tiles: s1e1 and s2e1. This little quest is supposed to be started by going South from e1. This means that the player should not be able to enter the bug quest tiles from any other surrounding tiles except e1. For this purpose, I have added restrictions in the leave methods of all surrounding tiles. For the sides that haven't been written yet, I added simple placeholder tiles with the required restriction so that future hackers will know to include it. I've been testing and fixing it for a couple of days so hopefully there won't be any unintentional bugs. I hope you like it. :)

[takluyver]

Thanks, I'll have a more careful look later.

I'd like to think of a better way than adding placeholder tiles - they'll behave as part of the game, but without leading to anything interesting. Maybe we could use some way of keeping notes of what's in a square, and notes to future authors. A Google spreadsheet might be one way of doing it, or perhaps some interface that will load tiles and display some information about them.

On 21 April 2013 19:18, George Angelopoulos notifications@github.comwrote:

I have added a small bug quest which consists of two tiles: s1e1 and s2e1. This little quest is supposed to be started by going South from e1. This means that the player should not be able to enter the bug quest tiles from any other surrounding tiles except e1. For this purpose, I have added restrictions in the leave methods of all surrounding tiles. For the sides that haven't been written yet, I added simple placeholder tiles with the required restriction so that future hackers will know to include it. I've been testing and fixing it for a couple of days so hopefully there

won't be any unintentional bugs. I hope you like it. :)

You can merge this Pull Request by running

git pull https://github.com/lathan/weatbag bug_quest

Or view, comment on, or merge it at:

https://github.com/takluyver/weatbag/pull/18 Commit Summary

• Fixed some grammatical and spelling errors.
• Another minor grammar fix.
• added south leave text for e1
• Added first bug tile.
• Fixed leave bug in s1e1 and modified output text.
• Added leave text if not going after the bug.
• Fixed bug I had made on leave method for e1.
• added a pause after leave text
• wrong indentation on previous commit
• Added the final bug tile. ToDo: leave restrictions
• leave restrictions for s2e1
• leave restrictions for s2e1
• leave restriction for s1
• leave restriction for s2 and indentation style fix
• Added extra commands for interacting with bug.
• fixed bug_quest exit message.
• Added check for "bugs must be crushed" message.
• added some comments
• Changed They way I check for bug presence.
• Made a sexist comment more PC.
• Added a comment
• Revert "Made a sexist comment more PC."
• Made a sexist comment more PC.
• Added placeholder files s1e2, s2e2, s3e1 with
• nothing important

File Changes

• M weatbag/tiles/e1.pyhttps://github.com/takluyver/weatbag/pull/18/files#diff-0(9)
• M weatbag/tiles/s1.pyhttps://github.com/takluyver/weatbag/pull/18/files#diff-1(14)
• A weatbag/tiles/s1e1.pyhttps://github.com/takluyver/weatbag/pull/18/files#diff-2(49)
• A weatbag/tiles/s1e2.pyhttps://github.com/takluyver/weatbag/pull/18/files#diff-3(22)
• M weatbag/tiles/s2.pyhttps://github.com/takluyver/weatbag/pull/18/files#diff-4(31)
• A weatbag/tiles/s2e1.pyhttps://github.com/takluyver/weatbag/pull/18/files#diff-5(34)
• A weatbag/tiles/s2e2.pyhttps://github.com/takluyver/weatbag/pull/18/files#diff-6(22)
• A weatbag/tiles/s3e1.pyhttps://github.com/takluyver/weatbag/pull/18/files#diff-7(22)
• M weatbag/tiles/w1.pyhttps://github.com/takluyver/weatbag/pull/18/files#diff-8(2)

Patch Links:

• https://github.com/takluyver/weatbag/pull/18.patch
• https://github.com/takluyver/weatbag/pull/18.diff

[gangelop]

Yes, I agree that placeholder files are not the most elegant solution and a big hacky. Still I chose placeholders over maybe writing yet another game-engine feature. Here's another proposition:

• Have a comprehensive description of what each tile contains and requires, in comments in the beginning of the tile file.
• Add a note in the Tile API docs reminding devs to be mindful of neighboring tiles.

This has some advantages: It's much more flexible than any strict rule. It's all in the code (no requirements for external spreadsheets). And finally, it's something that everyone should be doing anyway, but now it's made explicit.

[takluyver]

That would work, but I'm a bit concerned that requiring authors to find, open and check 4 (or 8) surrounding tile files manually makes adding a new tile rather less fun.

Another option we could look at is having the notes in string variables in a file, perhaps a one-word description like 'beach' or 'forest', and a longer set of notes for other authors. Then a separate tool could scan all the files, or the files for tiles adjacent to a specified location, and show the user any notes. That tool could be console based, a spreadsheet generator, a simple GUI or a web interface.

[gangelop]

I thought about this all day and I really think it's a bad idea. Tiles are not islands. Surrounding tiles are important and there is (and can be) much more to a tile than what the terrain is. I actually think that trying to make a tile that fits nicely with the descriptions of the surrounding tiles is the most fun part and the largest part of the work. Ignore my content for a moment and take for example s2 and s3. Wouldn't it be completely crude and ugly if I wrote s3e1 and my only consideration was what the terrain should be? It ruins the whole experience of an otherwise exciting and nicely written encounter. So unless you make some monstrously massive API feature to take into account all the nuances of the descriptions, I don't see how trying to automate this can work.

[takluyver]

Sorry, I'm jumping ahead of myself. I'm not suggesting you should just go on the one-word description.

I'm trying to imagine what I'd want an interface to look like. I'd quite like a visual overview of the 2D map, which is why I keep coming back to spreadsheets (though I don't know how a future third dimension could fit in). I imagine that the one-word descriptions would go in the cells, so that you could see at a glance what was where. Then there's a longer description attached to them that you can reveal somehow.

Perhaps a visual example would make it clearer. I'm thinking of something like this:

Putting long descriptions in each cell would make each cell quite big, and it would be hard to get a big picture of the what is where in the world.

A google spreadsheet seems like an easy option, but there's also interest in having a world map that the player can look at inside the game, and only see squares that they've already explored (see pull request #16). Ideally we could use much of the same code for the god map and the player map.

Another option would be single character symbols, like dwarf fortress does. Colour and unicode symbols are tricky to do in a cross-platform way, though.

[takluyver]

If you want to drop the placeholder tiles, and tidy up those input() calls, I think the rest of this looks OK to merge. We can carry discussing maps and notes in a separate issue.

[gangelop]

I'll drop the tiles and add a comment on the top of s1e1 and s2e1about the entry restrictions.

[takluyver]

OK, the blank input() can stand for now then. If players complain about it, we might change it later, but hopefully they'll work it out.

It looks like waiting for the user to hit any key is possible, but a bit fiddly to do in a cross platform way. Plus it assumes it will always be in a terminal, which might not be true.

[takluyver]

Thanks, merging. I'll fix the spelling in the comment.

[takluyver]

See #20 for further discussion about world maps.