Inventor of The Rotation

Over the past 2 years, I accidentally discovered a great method of solo game development. It started when I originally shelved this project for being too much for one developer. It was just another uncompleted game in a series of uncompleted games. I was in a slump. 

From there, I demanded of myself to complete a game at all costs. Make completing the game be the one and only goal. But life was busy, I had no team, and had limited art skills. So I had to change the definition of “game” in my head. I limited myself to 48 hours of dev time and said that “whatever you have after that is what the game will be!”. I didn’t do it consecutively, so I could spend 48 hours over a whole week, but I monitored it closely. Because I wanted to publish it on my itch page, I also paid close attention to the player experience. Would I be able to confidently let players download this and play it on their own machines? Would the core game loop be fun and evident?

This resulted in Tower of the Flying Samurai, which you can find here. It’s not successful, but it lead to some awareness and opportunities. It also greatly reinvigorated my passion for game development.

So what next? Well, more games! And then more games. And pretty soon, I had 6 completed projects under my belt. It felt great. I had an anti-slump.

Then, after months of being published, one of the aforementioned projects, Breaktory, took off. And so, for the first time, I revisited it. Coming back to my old code was a freezing splash of water on the face! Who coded this!? Who designed that!? Why did I do this? Why not cut that?

Mistakes were easy to see. Code was a lot easier to refactor. Features were easier to add, as customer feedback had built up enough. Basically, time passing allowed a lot of things to change. This first revisit was the birth of this Rotation Method, though I didn’t know it at the time.

Once I was done adding more content and polish to Breaktory, I moved on to an ancient game of mine, Blip 6. Did a much more quick but effective polish pass on it. Then I started a new project for the 7DFPS jam. Then I resurrected an old Android game project. And I kept on doing this “new project, old project, refactor, revisit” kind of approach to development when I realized something:

• It was really working well
• I had never been more productive
• I was in no way crunching or approaching burnout
• It was solving a lot of problems I had always encountered

So yeah. That’s basically it.

The Rotation Method

The Rotation elevator pitch is:

Rotate through multiple projects to keep a fresh perspective on art, code, and design as well as continuing to create and refresh deliverable content while generating interest in you and your projects

That’s a mouthful, but really, we’re all about using that most useful thing of all: Time. Having time pass, then coming back to an old project is some kind of magic objectiveness that is priceless. Whether it be playing old builds or sifting through code, you’re going to see balance issues, bad decisions, easy refactors, and a ton of other things with the hindsight of past time. 

But you can’t just wait 3 months, then come back to a project.

OR CAN YOU!?

Like most devs, you’ve probably got a few unfinished or abandoned projects. Experiments that failed halfway through, games that became too complex, or prototypes you just lost interest in. I bet you a one dollar fish that if you search one of those projects out today, yes now, open it and start to play it, you’re going to be reminded of something great about it. 

And you’re also going to hate some things about it. 

This is the fresh perspective that revisiting projects grants you.

Now if you could always have that fresh perspective on your projects, wouldn’t it be great?

That’s what this method of development grants you. With a catalog of 3+ games, you can always be revisiting old projects with a fresh mind. 

If you have multiple projects already

1. Set an achievable milestone
   1. For me, it was “Make a complete, visually striking game in 48 hours”
   2. It could be “Complete this abandoned project in a week” or even more specific like “Upgrade the Input system of X Published project”
   3. The milestone should always be public facing, so people can download and play it. This makes it so when you switch to a new game’s development, people can still download, play, and give valuable feedback
2. Reach that milestone
   1. Really hold yourself to it
3. Take a break
   1. You just completed a milestone or published a game. It’s necessary to take a break!
   2. I recommend a full week
4. Evaluate previous projects
   1. Start with playing your games
   2. Check on community
      1. Is there a community beginning to grow? Lots of comments, Youtube views, or more downloads than usual? Hone in on that growth!
   3. What needs updating? 
   4. Does a specific game get featured somewhere? Did a streamer show interest in the game?
   5. Are colleagues reaching out about a certain game over others with specific requests?
   6. (This all might sound really specific, and that’s because they are examples of things that have happened to me and my derpy games!)
5. Move on to another new or existing project
   1. Based on your evaluations and also, very importantly, your wants, select a new-old project or start a new-new project, then go back to Step 1
   2. Game Jams are really great things to glom onto for inspiration and motivation

If you are starting from scratch

1. Create a 48 hour game jam project. Complete it.
   1. By “complete it”, I mean put it up on a website where people can pay for it and download it. Itch.io, Android / iOS storefronts, etc. Doesn’t have to be Steam, but get the game up somewhere. Really complete it!
   2. Doesn’t have to be 48 consecutive hours, just spread it out over a week and take it slow. But limit your game’s scope severely, that’s the important thing
2. Create a week-long game jam project. Complete it.
   1. After launching the 48 hour game, take some time to come up with something a bit more complex.
   2. You can increase the complexity of the core game or take another super simple idea and pad it with QoL features like: Leaderboards, Options, Campaign, Unlockables, Mode Variation, etc
3. Create a month-long game jam project. Complete it.
4. Now "Rotate" back to the first project.
   1. It’s been about a month and a half. Revisit that initial game jam and give it that 2nd polish pass all game jam games need
   2. You’ll notice the distance from the project will make it easier to cut, add, and fix both bugs and features
   3. Now you have 3 projects rotating. Go back to the oldest one and decide what you want to fix or add to it
5. After this, it's up to you: Rotate to the 2nd project or start a new one!

Side Effects

1. Builds your portfolio
   1. This is a big “No Duh!” but it really is nice to have a set of completed, playable projects for potential employers or publishers to see
2. Gives time for pitch submissions / publisher communication
   1. This is one of my favorite side effects, as I can get a bit impatient with publishers not responding. If you move on to the next project and goal, it makes waiting for responses much easier 
3. Allows for a Patreon friendly stream of game content
   1. If you are the type, this method of development leads to frequent releases of new content and updates. That is something that works great for Patreon, streaming schedule, or other social media
4. Leads to new opportunities
   1. I have multiple former work colleagues, artists, writers, and even publishers reach out to me about previous games. Sometimes they want to start a new collaboration, sometimes they want to take something I’ve worked on and extend it. It all boils down to opportunity.
5. A growing code and asset base
   1. Of course code reuse is important, but I really never did until I started rapidly developing individual projects. It’s so much more convenient to have a basic sound system that I can copy over to each project at the start, or a camera utils file that covers shaking, zooming, etc.

Possible pitfalls

1. Crunch and burnout
   1. You can’t just make more games! A lot of this method is goal creation and acceptance that not everything in gamedev is perfect
   2. It is crucial to get a feel for strict scoping, like you have never done before. Otherwise, this will just lead to more unfinished projects, and if you get a few actually done, brutal crunch and burnout. 
2. Lack of polish / becoming too accepting
   1. Attention to detail and that extra mile are often what separates an amateurish looking video game from a professional studio’s polished product. I’m pitching this system as a “long run”, so your multiple games will gain polish over time
3. Might not be for you
   1. I’m not sure if this is even a good method me
   2. I’m sharing it because it is working for me in the sense that my games are more frequently being released and updated, and they are getting a bit more attention
   3. It’s also a more laid back method of development, closer to being a hobbyist, while still having some professional applications

Conclusion

I originally thought that this game was unfinishable, but after completing several other projects and rotating back to it, I could easily see how to finish it. Maybe not the ambitiously scoped version I had planned out 2 years ago, but it’s ready and available for the public to download and play, and it’s really fun.

I believe I’ve seen other devs doing the same, and maybe not labeling it. DM if you think you might be. As with any method of development, this won’t be for just everybody, but I do believe it will help with so many common traps, especially for self motivated, but not so organized people.