How a timeline changes
So here's a funny image:
What's funny is that the development turnaround actually turned into this:
Which is a lot longer than 4 weeks! So why the huge leap?
A mixture of things, but at the core of it was a need to have just a bit longer to get some more content in - I ended up pushing the deadline some 3 times, each with pretty much the same reason:
- I needed more time to actually put in levels, mechanics & pieces into the game
- Freya needed more time to write, and we gained time to add in the Unlockable stories
- & more time for testing/marketing assets/the little things
By the time of the itch release is when I truly realised that this wasn't a 4 week game, nor an 8 week project. This could've used around an extra month - I say that because I absolutely crunched on this thing, 8am-8pm most days of the week (purely driven by high-octane "oh this is cool to make my own game" energy, satisfying that long-time hunger to do this kind of passion project)
What I thought it'd be
So: what were the major reasons for the time difference?
After finishing the gamejam, I reckoned that taking it, redoing the foundations, & setting it up in such a way as to make working in the project quick 'n easy (e.g. you can play from any scene and it works) would set me up for a very quick turnaround.
The 2nd step was figuring out the interweaving of my turnaround, with a musician & writer taking on the music 'n wordy words. By offloading "half" the game (note: like 2/4, will explain later), I could absolutely focus on the development, getting something fun when we all come together by the end of those 4 weeks.
Now there are a few major hurdles that made the 4 weeks absolutely undoable:
- I'm one man, and it's not "just" development I was signing up for, it was:
- Coding (& the Middleware layer, & project maintenance)
- Art (& Concepting, & Lighting)
- Level Design
- Project Management
- Where doing a writer search is a lot more time-consuming than you'd think - it isn't just asking folks, or reading portfolios; It's keeping a callbook table, a tally of yeses/nos; and it's reading a portfolio with context of whether they'd fit the story you want.
- This game is far larger than 4 weeks of development. What I mean by this, is that saying "ok 9 mechanics, 10 levels each, a tutorial" isn't easy, nor is saying "we need to make ~90 levels" to quanitify it as a target. Making 9 mechanics of puzzles actually entails:
- what's the mechanic?
- how do you teach it?
- how do you introduce it's quirks?
- how do you make levels that "twist the knife" (in my parlance, i.e. how do you make levels that combine previous ones to add that extra "oooooh you sneaky sod" kind of talk when you first 'get a level)
- And finally, it's making the difficulty curve of that group work.
So yeah, in hindsight - 4 weeks was, at maximum output, an alpha or early beta version of the game (which it absolutely was)
What it became
Now, how did the final turnaround look?
Let's look at that image from earlier, but with some more notes:
As said earlier, the driving force behind the deadline changes was for everyone involved to get more time to do stuff - in my case, it was a sheer cliff of "if I don't have an extra week, like half the game won't exist"... and then that 2 more times.
Each extra week felt like a god-send with the amount of extra time I had to use. And I think that, whilst it's a negative to have had such a tight deadline in the first place, it's a good outlook where each extension would reward so much to the game.
Smart move: don't announce until you can release
Luckily, in my case I chose not to announce a release date until the week prior to it - where the build was in a release candidate state where "if you were forced to, you would pretty happy with the state of it", and one more week of fixes/changes would've all helped in their own little ways.
Now for how I used that time: a big takeaway from this project was an emphasis on pure momentum - following the gamejam, I had my little nugget of an idea that worked. Now, it was a case of taking that forwards in every possible dimension.
Because of the energy coming off the jam, I already had that driving force to get immediately stuck into planning, design, a mini-postmortem, & so on. Taking that a step further, each week accidentally became it's own sprint:
- Where should the game be in relation to the final goals?
- How do I get there?
- What should be in the friday build?
- What else can I fit in? To split up the work from being just one discipline
So in essence, mondays/tuesdays would kickoff a major tech change, the rest of the week was iteration. By friday I'd have a build, then get some feedback from the team & my (very patient) friends.
Where, as someone who groans at doing a single task for more than a couple days, having the ability to flit between major tasks helped keep my interest up; and to tie it back around - my momentum. Every, single, day, had new stuff going in, and a new (bite-sized) challenge to face.
Take that across 5 weeks, and then suddenly I realised it was all together and ready to be released.
So going into this, I already thought that 4 weeks would be "long", it was my "take 1 week, double it, add on extra". I was already going into this project with an extension in mind, as I've done a fair bit of development time at work.
A Jam game is a vertical slice, not a full project
But I think what I didn't do was say "ok but how long will it actually take to do each of these smaller steps?", I had my vertical slice of gameplay from the jam; but not a vertical slice of development time for the game. I was thinking in terms of the jam rush, not across a 2 month marathon.
In my case I had a pretty well-defined end goal, which left me with a strong target of how close I was to finishing - yes it was a lot, but every node mechanic coded, each tutorial had a definite feel of being close to finishing. (Versus "oh maybe like 7 mechanics would be good" and finding out you need 2 more, I had defined "no, 9 new mechanics, 10 levels each, 1-3 tutorial steps per" in the opening salvo of planning the project)
A gist of how long some chunks took
As some rules of thumb, I found the following "big blocks" took so long:
|Codebase refactor||1 week||The jam was in a decent state, and getting ready for the big project was easier than it could've been because I knew what I wanted to support|
|Hiring a writer||2 weeks||Will write up about this at some point, in short: send out a call, get responses, review, send out follow-ups for a paid writing test, review, pick your writer, then do a video planning session.|
|A group of levels||1 1/2 weeks each (overlapping)||The tutorials, level designs, story integration, testing for each group of levels. Where you can easily overlap these - it's easier to draft up a bunch of levels at once, and you can test one whilst making another|
|Main scene 3D background||~1 week on/off throughout development||Iin my case I wasn't doing textures, just lighting, hence it was quick to make. And it just takes time to figure out what kind of look you want.|
|Game Tutorial||4 days||With a few more for testing & editing it - it's your tutorial for the game, it needs to be slow, instructive, and clear.|
Keeping momentum & general progress
The trick I found was to keep overlapping parts of your development; each day I made some progress in 2 or 3 "disciplines": code, design, art, bug fixes, editor tools.
Where each week/couple days had a main focus, like "ok this week is the Fuse Node", "this week is getting the menu art & functionality done", etc.
By having a main goal finished, with other parts of the game being nudged forwards, it felt like the game was just coming together naturally? This lead to the last week being relatively stress-free (compared to some deadline weeks I've experienced), because most parts of the game were done to a decent extent. What was left was bug fixes, some final QA, and adding useful extras.
So yeah, turns out making games is hard; and every, single, time, there's something that trips you up. Anyway TL; DR:
- After prototyping, figure out a rough estimate of how long a task will be, then plan with that, don't estimate off your early versions where you were skipping steps/rushing something.
- With that estimate, re-evaluate your Release Candidate goals, how long is it actually?
- If you can, make your opening weeks foundational - try and set the groundwork such that it's easier to add/iterate features, and easy to work in your project (tools, ease-of-play, etc.). 3 weeks later as everything is changing you'll be thankful
- If you're solo, or a small team, maybe consider doing "Big goal, 3 small goals" per week, or something like that. Keep every discipline of a game nudging forwards. By the end of a cycle, hopefully this means no one part of the game was left behind.
- Keep an extremely diligent task-list - I use my task kanban board as a general ground for tasks, notes, documents, questions. That way everything I need to know is in one place.
Get A Forgetful Loop
Leave a comment
Log in with itch.io to leave a comment.