Caleb Valenzuela
Member
I noticed a lot of forum members who want to pursue the very interesting and slightly discouraging hobby of method development, but end up making a method that already exists, or is just another variant of a method. Method development can be confusing and overwhelming without a guide, which is what this thread is for!
Phase 1: Objectives and Planning
This is the phase where you ask yourself stuff like: “What puzzle/event am i going to make a method for?” “Do I want it to be competitive? Fun? Efficient?” Basically the prerequisite questions. For example, when I created the CVOB method, my goal was to reduce the amount of blind spots on the 4x4 while maintaining decent ergonomics. Once you know your objectives and commit to it, it’s time to move onto Phase 2. Research is crucial here since you can find plenty of ideas from already-existing method.
Phase 2: Design
This is one of the fun (and sometimes disappointing) parts. This is where you start brainstorming ideas and organizing steps in accordance to your objectives. For CVOB, I went through a lot of trial and error in creating something that aligned with what i wanted, so don’t be discouraged! It’s also helpful to have knowledge with alg sets (stuff like CLL, 2GLL, ZBLL, etc), methods (eg. APB, CEOR, Mehta), and basic concepts for the practicality of a solve like ergonomics, movecount, alg count, etc. The more you knowledge you have over the puzzle, the better. Think of many continuations for the first step, then deduce which continuation is best for your method. It’s also helpful to know how to generate algorithms, so i suggest the Trangium Batch Solver Guide @CrossPetrus made. Make sure you aren’t just recreating an already existing method, too. The Speedsolving.com Wiki has a bunch of methods that you can scroll through.
Phase 3: Review
Review the method you made. Is it heavily algorithmic? Is it intuitive? Does it have good ergonomics? Is the recognition for each step good or bad? Compare it to other methods and see what makes your method stand out from the others.
This is where you have to think critically about each step. Sometimes, you’ll miss important flaws in your method, so it’s important to ask for feedback. Speedsolving.com (yes, this forum) is a great place to ask for feedback. The “New Method/Subset/Concept Idea Thread” has hundreds of pages of other methods. The Straughan Discord server is also a good place to ask for feedback. Don’t be discouraged if your method doesn’t end up as good as you thought. After all, nobody is perfect.
Phase 4: Development
This is the second to the last step of the process. This is where you generate algs, polish up your method, find good solutions for intuitive steps, finalize movecounts, find the best algorithms, etc. CubeExplorer is good for generating algs for specific cases, while Batch Solver is good for generating batches of algorithms, hence the name Batch Solver. The development stage is basically practicing your own method and preparing it for documentation.
Phase 5: Documentation
It’s time to present your method to the community! It’s important to be honest about the pros and cons of your method. List the advantages and disadvantages. Don’t give your method an overly positive image, but also don’t give your method a negative image as well. Provide evidence that your method is viable. Be clear about movecount, alg count, and what you were aiming for when developing your method. Provide example solves, videos, present the method on youtube, cubing forums, discord, etc. Make clear “Beginner -> Intermediate -> Advanced” tutorials/phases for your method. Honesty is key when presenting a method. You could think about it like this:
“Present what you cooked, but don’t make it look like a 5-star Michelin meal when it’s not, but also don’t make it look like a came out of a dumpster.”
In other words, don’t “glaze” it
Phase 6: Maintenance
Update algs, upload new videos, example solves, present new steps/substeps, optional alg sets, etc. If people critique your method, try listening instead of arguing. Clarify instead of making claims without proof.
Method development isn’t easy, but i hope this was able to give you a guideline on how to create your own super duper unique method.
Links:
Phase 1: Objectives and Planning
This is the phase where you ask yourself stuff like: “What puzzle/event am i going to make a method for?” “Do I want it to be competitive? Fun? Efficient?” Basically the prerequisite questions. For example, when I created the CVOB method, my goal was to reduce the amount of blind spots on the 4x4 while maintaining decent ergonomics. Once you know your objectives and commit to it, it’s time to move onto Phase 2. Research is crucial here since you can find plenty of ideas from already-existing method.
Phase 2: Design
This is one of the fun (and sometimes disappointing) parts. This is where you start brainstorming ideas and organizing steps in accordance to your objectives. For CVOB, I went through a lot of trial and error in creating something that aligned with what i wanted, so don’t be discouraged! It’s also helpful to have knowledge with alg sets (stuff like CLL, 2GLL, ZBLL, etc), methods (eg. APB, CEOR, Mehta), and basic concepts for the practicality of a solve like ergonomics, movecount, alg count, etc. The more you knowledge you have over the puzzle, the better. Think of many continuations for the first step, then deduce which continuation is best for your method. It’s also helpful to know how to generate algorithms, so i suggest the Trangium Batch Solver Guide @CrossPetrus made. Make sure you aren’t just recreating an already existing method, too. The Speedsolving.com Wiki has a bunch of methods that you can scroll through.
Phase 3: Review
Review the method you made. Is it heavily algorithmic? Is it intuitive? Does it have good ergonomics? Is the recognition for each step good or bad? Compare it to other methods and see what makes your method stand out from the others.
This is where you have to think critically about each step. Sometimes, you’ll miss important flaws in your method, so it’s important to ask for feedback. Speedsolving.com (yes, this forum) is a great place to ask for feedback. The “New Method/Subset/Concept Idea Thread” has hundreds of pages of other methods. The Straughan Discord server is also a good place to ask for feedback. Don’t be discouraged if your method doesn’t end up as good as you thought. After all, nobody is perfect.
Phase 4: Development
This is the second to the last step of the process. This is where you generate algs, polish up your method, find good solutions for intuitive steps, finalize movecounts, find the best algorithms, etc. CubeExplorer is good for generating algs for specific cases, while Batch Solver is good for generating batches of algorithms, hence the name Batch Solver. The development stage is basically practicing your own method and preparing it for documentation.
Phase 5: Documentation
It’s time to present your method to the community! It’s important to be honest about the pros and cons of your method. List the advantages and disadvantages. Don’t give your method an overly positive image, but also don’t give your method a negative image as well. Provide evidence that your method is viable. Be clear about movecount, alg count, and what you were aiming for when developing your method. Provide example solves, videos, present the method on youtube, cubing forums, discord, etc. Make clear “Beginner -> Intermediate -> Advanced” tutorials/phases for your method. Honesty is key when presenting a method. You could think about it like this:
“Present what you cooked, but don’t make it look like a 5-star Michelin meal when it’s not, but also don’t make it look like a came out of a dumpster.”
In other words, don’t “glaze” it
Phase 6: Maintenance
Update algs, upload new videos, example solves, present new steps/substeps, optional alg sets, etc. If people critique your method, try listening instead of arguing. Clarify instead of making claims without proof.
Method development isn’t easy, but i hope this was able to give you a guideline on how to create your own super duper unique method.
Links:
