Closed DivFord closed 9 years ago
I've looked at the changes you made and condensed them down to reduce code repetition.
Sorry, I don't understand your reasoning behind needing fixed sized patterns. I don't think there's a relationship between the size of pattern and the tool required to overcome it. Of course there will need to be a pattern that fits it, but that can be accommodated for in the active_levels.xml file.
I agree though that the tools required to overcome the pattern will need to encoded someway in the pattern name.
Yeah, my code was pretty clunky. Glad you've found a way to fix that.
I don't think I explained myself very well, so I'm going to hit you with a wall of text… Sorry.
This isn't a tool problem, it's a design problem. The tool can accommodate any size pattern, which is neat. However, any time we use a placeholder in a level, we need to be sure that a pattern exists that will fit into that placeholder. The tool allows me to make levels with 3x6, 7x4 and 1x2 placeholders, and to make 2x5 and 3x3 patterns, but when we try to run it, none of those pieces fit together.
Essentially, we have a huge possibility space, and I would like to limit it to something more manageable. To use a exaggeratedly narrow example, if we were to say that all patterns had to be 3x3, we would lose flexibility, but would guarantee that when we put a 3x3 placeholder in a level, a 3x3 pattern will exist to fill it. Obviously that's more limiting than we actually want, hence my compromise of 17 different patterns. I'm not particularly attached to those 17, it's just that we have to draw the line somewhere.
We don't actually need to change any code to accommodate the rules I'm suggesting, which I think is your objection. My point was that it might be easier to solve the required-tools problem if we did. At the moment, pattern groups are named things like "PR_w3h4_e2x2". If we wanted to add the required tools onto that name (I'm assuming a binary enum or a group of character codes), it would get almost unmanageably long. However, if we do limit our possibility space, it's possible to write "PR_w3h4_e2x2" simply as "O4".
Lastly, I think it helps to have some rules about the purpose of the pattern. A 3x4 pattern can be anything, but if you call for an obstacle pattern, you know that its function is to block progress. I feel like naming things based on function rather than shape makes level design easier.
EDIT: Have you tested your changes? I'm getting things in the wrong places and on top of each other. Also the error messages suggest you've reversed the individual char codes (it's complaining about cP and dB, which are presumably crates and dirt blocks written backwards).
Okay, I see what you're saying. That would certainly make it a lot easier to think about the levels.
Aww crap. Okay I'll have a look and implement a fix. EDIT: this is now fixed.
It's no longer throwing error messages with the reversed pattern, but it isn't actually placing it either. The test level is set up with a PR, then a PL, and the PL just isn't happening.
Ah yes, you're right. I didn't spot that. I'll get it fixed. EDIT: This should now be fixed.
It's definitely fixed now. Hooray!
I've been playing around with the pattern system Matt implemented, and it seems to cover most of what I wrote in the design doc.
I added in a feature to print patterns in reverse. Now, rather than search for a "PL" group of patterns, it uses the "PR" group flipped horizontally.
The things that are still missing:
I think we probably should add those features. Lock and keys give us a lot more design space for making puzzles, and we pretty much have to check for tools if we follow the plan and pick up tools in each world.
Any thoughts on how we should implement them?
With regards to the tool check, I think we probably need to include it in the group name. I like the way the current system can detect any size of pattern, but since every pattern-hole we put in a level has to have a pattern that fits it, we'll need to stick to predefined dimensions of patterns anyway. Long story short, I like the system we have, but I think the one in the design may work better.
There. I have rambled. Please ramble back at me.