This zeroth entry in the Game Sprint series details the upcoming game development project I'll be working on for the next year.

Game Sprints are a commitment to design, build, and release a game on itch.io every two weeks for the next year. Having just completed Raycast a few months ago, I've started thinking about larger solo projects. Though I'm capable and confident directing and designing games with a team, building something both larger in scope (though now with a premade engine) and by myself is a big leap.

To avoid amassing mountains of technical debt and an almost inevitable hiatus, I'll be honing my solo game designer skills with smaller, defined projects first. But how can I ensure those projects happen?

1. With specific, rigid deadlines

To paraphrase Ben Franklin, in game development nothing can be said to be certain, except scope creep and delays.

If nothing else, the purpose of the Game Sprint games is to build habits that stop me from making poor planning decisions when it comes time for a larger project. I, like most developers I know, am incredible at finding endless things to improve. But knowing what and where to prioritize is the most essential planning skill — one that doesn't happen if deadlines can always be pushed.

By setting a hard deadline of one game every two weeks, I'm not saying I'll force myself to go through continuous crunch to get the perfect game released every fortnight. Instead, I'm forcing myself to learn what to prioritize and deliver whatever I have at the end of each Sprint, regardless of its state — aside from gamebreaking bugs.

That means I'll be building new and better workflows every two weeks and won't get stuck when things aren't as smooth.

2. By finding the perfect Sprint length

When I first came up with this project, I wanted to build a game a week. I had just started using Godot, the engine I'll be working in for this project, and found I was able to build my first game in the engine with little issue in just a few days.

Though I'm now capable of building games like Bubble Fall in a few hours, I plan to build games with more depth that will necessitate minimum timelines of at least a few days. Having looked around the internet to find others who attempted similar projects, none were able to maintain a game each week for more than a few months despite committing to a year, and few were even able to maintain a game a month.

I'm confident that two weeks is a reasonable timeline for myself, but I won't hesitate to modify that timeline if it starts to get in the way of making this a habit.

I want to build a plan I can stick to, and two weeks feels right for me. If you're thinking about trying Game Sprints for yourself, I encourage you to build a small game at a comfortable pace. When you finish, double the time it took you to make your game to find your Sprint length.

3. By avoiding crunch at all costs

This was and is still a big fear for me. I want to deliver 26 fun and engaging games, but I can't let my desire to make good games lead to burnout.

The purpose of this project is not to build games that go viral or make money, but instead to build my skills and confidence before I embark on larger projects.

To facilitate this, I'm using my preferred planning method, Github projects, to plan each Sprint and setting a proportionate amount of work for each day I'm able to work on the game. When I finish my tasks, I'll stop work on the game for the day.

4. By baking in accountability

...and you're it! At least in part.

A strong and clear commitment to delivering a game every two weeks means that you, and everyone I've talked to about this project, can expect a new game and devlog every other Sunday.

If you're looking to start a Game Sprint and want to stay accountable to someone, don't hesitate to reach out at hi[at]jocelynbaker.ca. I'd love to hear what you're working on!

Thank you for reading about my Game Sprints project. Come back in two weeks to hear about my first Game Sprint game, Trivial!