Skip to content

July 20th, 2014

July 20th, 2014 published on

Well it finally happened this week. Sew came up to me and told me that he couldn’t really start on that much final art until there’s a finalized plan for the game. This was inevitable. Several months ago or so when I decided whether to do the UI/Display overhaul first or prioritize finalizing the game design I chose the UI, despite my gut feeling otherwise. I suppose that’s this year’s big mistake.

It’s a better mistake than last year, though. It taught me the valuable lesson that while development UI doesn’t need to be pretty, it does to be functional and expose needed information properly to players. Putting it off alongside prettiness can lead to false results. The changes will also make it easier to do certain design changes that I would have avoided before due to development costs. So it’s not a total loss.

Regardless, I immediately put the remaining UI work on the back burner (though I may try to work on it once a week so I don’t lose my place) and set to converting the existing game to use the new display system. The work needed to convert the existing map engine has been worse than expected. While I fully expected updating all the systems that depended on it to be a pain, I didn’t expect this much resistance from the engine itself. So it seems like it’s going to be a 2-3 week job instead of 1 week. It’s quite frustrating when all I really want to do is get back to work on the game itself.

So the game itself. Why is the basic game not finalized after nearly 3 years of work? Basically, it’s costly to iterate on a complex game.

The initial goal here was to build a system that could support the basic idea of the game we wanted to make and to then tweak it to make it better. Along the way I deliberately overbuilt portions of it to be able to handle common RPG mechanics that we might or might not need. At the same time I underbuilt other portions of it since time was at a premium. This system probably took about 1.5-2 years of production to become stable enough to really build sample content for and to test thoroughly.

Under the lofty ideals of iteration as king we should have then proceeded to rapidly tweak the game into a better state. But even with a solid foundation in place, I found the larger changes I wanted to make taking months to add because the original system was in no way built for them. In a game with a small central concept you can with rebuild the central mechanic again and again with relative ease. Say you wanted to make the perfect player movement in a platformer. Player movement isn’t an expensive thing to build over and over again, especially if what it interacts with doesn’t exist yet. This, as it turns out, isn’t so much the case when you’re already hauling around the rest of the game on your back. This is largely on me for building the entire game before iterating, but it’s also on our genre for relying on interactions between many things for the “game” to really start to exist.

I think I adapted to this fairly well. After the first changes being very high cost, I built newer versions of the map system in a direction where I could experiment with lots of things for a fairly low cost. It’s very unlikely that I’m going to shift from that fundamental system now, but I also haven’t completely figured out what really works with it yet. The battle system meanwhile was overbuilt to begin with and has been cheaper to iterate on.

There’s something Sew has asked me again and again the last year or so: “what is the game any more?”. The more I’ve tweaked the game in an increasingly complicated and mangled direction, the more I’ve lost him. There’s a method to the madness, and for every failure along the way I’m getting closer to what I’m looking for. You’ll just have to trust me on that.

I’ve done two approaches to making games in my life. The first one is creating a design doc and then building just that and fixing it in post. Very efficient for simultaneous team work, though it can lead you right off a cliff if you were wrong. The second one is building a core idea that you’re happy with and then continuing to build more and more around it until you run out of ideas. Not a technique I’ve had the opportunity to use much since it’s hard for teams, but it was probably the funnest to work with and led to the most reliable results. I had hoped to use the second technique for this game, but finding that first step has been a doozy.