Well, what I've done - on this one and on a lot of my previous games - is kind of a technical exercise, both in the coding and design. I haven't had much pressure to ship as an indie, so I'm doing a lot of boundary-pushing. This is turning into a kind of a reflective post, which is good, since I need to write about it too.
In this case the thought was: build up the core features for a really big, simulation-driven game, that could also be made accessible. The game itself could change, the core idea was just to try having a lot of things going on and see what I could make out of them, which in part was driven by the idea that a big, simulation-driven game is usually a good, playable game too. The only instances I can think of this kind of game actually failing to be fun for some audience are where the developers shipped the game before the design was ready or things were polished - e.g. the numerous games shipped as buggy messes with non-working features: Darklands
, or Battlecruiser 3000
, to name some famous fails from the 90s. Dwarf Fortress
only fails to be fun for people because it's ignored accessibility - it's just a few steps above playing a game in a debugger. In any other respect it's a massive hit. Spore
is a good example of the worst case if the game is polished and most things work as advertised; the result ended up being a kind of minigame collection, but most people were able to find a few hours of fun in it, even though it did not come together in a cohesive, focused way.
And after six months, like those half-finished games, Magnate is sort of playable, and even sort of fun, in a few spots, but it's obvious how much work is still left - an amount that - if I'm going to make the best
game out of this - is in the man-year range, because it's the kind of game that responds well to feature accumulation. It's clear that things will have to get cut
to make Magnate work, but even more things will have to get added
, too. And that's the problem with making the game big.
So I've let myself keep the design very loose and tied to the abstract, because all this time, the technical challenges have been the top thing on my mind. And in trying for that I've found out that having this kind of design doesn't give me the leverage I thought it would. It's code, it's simulation, things are procedural and such, but it's code that is built like content, and thus - unlike the engine bits - it's not once-and-done, and the iteration times are huge when dealing with code, so it takes a really long time to get it right across the entire game. It could be another six months before I have it firmly steered in the "fun" direction.
So I see myself doing one of these things for future work on Magnate:
- Work on it gradually in between other projects, so that I can iterate on the "big game," however long it takes.
- Strip it down, and make multiple games with different focuses.
- Get a budget and a team to work on it. Within a team, many more ideas are formed than can be implemented, so design becomes more of a filtering process. Development also bottlenecks less, up to a certain team size - 5 or so would be fine.
I'm more interested in game-business experiments than game-design ones right now, so this is the right time for a break. Right now I'm starting on a little minigolf game with a map editor. I'll have a playable build done sometime tomorrow or the next day, and I'll have a first-pass, ready-to-sell product in 1-3 weeks. So I will change gears and be able to see progress in product-to-product iteration in future months, instead of feature-to-feature iteration. Then we'll see where I'm at.