[madamelic]

<not asking in a mean way>

Not enmeshed in game development and have only done it very lightly: what takes a game like this 1.5 - 2 years to finish?

Like at a minimum, it's art, sound, graphics, and programming. If they are re-using assets, that's one of them ~done. So what's taking them 2 years?

My background is in SaaS type stuff and if I went to who hired me and said it would take 2 years to build out a non-cutting edge product I am pretty sure I'd get fired. So can any game devs briefly/not-briefly explain why game dev like this takes so long? I am just curious to understand the dev cycle.

I'd assume that with investment, he'd have at least one person per team so all of these can largely be intertwined with each other but largely running at the same time.

</not asking in a mean way>

[melozo]

I think you’re underrating the sheer amount of iteration that occurs. SaaS has requirements and then implementation- it’s a product that has a target it hits. Yes, churn happens, but the point is you’re working to a specific goal.

Games and any creative work isn’t like that. There’s constant iteration as new ideas come up or developers learn in play testing that certain parts of the game work better than others, and so they realign things continually and keep refining. I’m not a game dev btw, but blogs from devs show a continual cycle of refinement and feature creep.

[probably_wrong]

The best answer to that question is the development blog they made for the first game:

https://blog.thimbleweedpark.com/archives.html

At a quick glance: four months for the engine (which they wrote from scratch [1]) and, based on the budget [2], roughly nine months for crowdsourcing and pre-production (setting the overall story and puzzles, deciding on the look of the game, building small proofs-of-concept), seven months for production, three months for testing and bugfixing, and two months for release (which they overshot by three months).

[1] https://blog.thimbleweedpark.com/roadmap1.html

[2] https://blog.thimbleweedpark.com/budget1.html

[pygy_]

I'll add that, unlike what your parent wrote, asset reuse will be minimal, in adventure games, one of the reward for solving puzzles is unlocking access to new locations and thus new art.

In this case, they may reuse some of the sprites for the main characters (default animations). Most of the animations are custom and can't be reused.

Likewise for the voice acting (I'd expect them to start from scratch here, the mood of the games may be a bit different).

[RobM71]

It's just like when during development the client/the users realize the system can do more and better, so the specs are changed because it makes a lot of sense to do that. Game dev is always like that: you won't realize what works and what doesn't until you can actually playtest the game... then you'll think of fixes and you'll have to go back implementing them.

[lentil_soup]

It's just a lot of work.

You need to build the engine/tech, need to support various platforms including building a rendering pipeline (so Vulkan, DirectX and Metal). You need to support animation (probably just 2D?), audio (including various effects and params), different types of input, a UI system, etc. To author the assets you need editors of some form for building the scenes, for cinematics, for the narrative, for the animations, a lot of these will be custom. Then to get the assets in the game you need a pipeline that coverts everything into platform specific formats. And all of this has to be performant, targeting 60fps ideally and cross platform.

That's just the tech side. Then you need all the other disciplines to be in sync. Can't start on animations until you have characters, can't start on those until you have concepts but can't have those until you have a narrative. And these will go via a lot of iterations as you try things out and figure out what works.

Then there's testing, the possibilities from a user perspective are really broad so the bug surface is massive. For a simple app the user is quite limited so it's simpler to enforce rules and unit tests. With a game a user can do a lot across many platforms and the issues can be on the low level graphics driver or just logic puzzle errors.

Then you have certification, platform holders have a book of tests they do to your game so you don't brick the console. Things like, does you game handle unplugging the console while you're saving to disk?

I can imagine they'll reuse a ton of tech from previous games, but there's always new things you need to do. Two years is actually pretty fast for the industry.

[tetha]

In my experience, business software has narrow and predictable use cases. Note taking: You need to add, delete and update notes and the real meat of the product is usually in the note organization. Even SAP has use cases simple in nature: Account for milk cartons sold. The use cases just grow complex once you work in 30 countries or more. "Pay the right taxes on milk cartons sold" becomes tricky.

However, this is parallelizable: You can work on all 30 countries at once and ship when ready. You can work on taking and organizing notes in parallel. You can work on scaling in parallel. You can streamline UX in parallel while introducing tagging, or trees, or groups, or anything.

A game, and especially a narrative game, has an intrinsic linear component, the plot. You can work on a certain amount in parallel, sure: Once the rough shape of the plot is laid out, you can start working on assets, necessary engine features, sounds, dialog in parallel.

But you still have a strong need that a player or play tester has a good progression from act one to act two to act three, and a good progression from puzzle one to puzzle two to puzzle three. This takes a lot of very slow iteration.

This involves human testing by nature. You get a playtest every few months, if you have the money. You can easily throw more CI hardware to run your integration tests more often for more countries. Playtesters, especially those who don't know the game, are very, very limited.

Then you also want characters and settings to be consistent across the plot. If done well, this takes a lot of adjustments and refinement both back and forth. Sometimes the setting of Act three requires a character to have a certain trait, and that trait should be developed, so you now go back to Acts one and two to see if you can build up the character -- without knocking down the entire house of cards already in place.

And once you get to polish and atmosphere, it becomes even harder and more time consuming, because then you need new playtesters even more.

From a past job and working on some features, I spent a day or two presenting like 6-8 different options, and then spent half a day in different testing groups to figure out which procedural generation option "feels the best" for what the game designer wants. With a better spec, that could've been an hour. This made players more excited. Probably.

[dbalatero]

Don't really have the context, but I'd trust the expert that it will get done on the schedule they want. I'd say people on the outside of things often ask these kinds of questions due to lacking any context on production schedules. See: the last time your PM said "can't we just..."

He's also a small shop and perhaps they intentionally move slower. I suspect he doesn't need to urgently get paid for this.

Story writing is probably non linear in time it takes, and I imagine there's a fair amount of waterfall. E.g you can't schedule voice actors until the story and dialogue is done. Oh wait, the voice actors have other commitments so they'll be by in 3 months. Etc.