Moomalade

Since we’re starting some new projects soon, I’ve had a chance to work on framework code in anticipation of full production. This is always great fun as you get to have a stab at solving existing problems elegantly since you have the largest solution space. I like trying to find elegant solutions however during production the most elegant solution that’s “right for the code in the long run” might not actually be right for the production.

During the course of production many problems get solved. There is only a fixed space of solutions for each problem, and as the project matures more constraints are placed on that solution space. Certain solutions will become impractical or impossible, and the relative cost of different solutions will increase. For example, after the production reaches alpha, if you weigh a solution that requires refactoring a large amount of code, touching several key systems and changing an asset format against a solution that fixes the problem in hand with no extra baggage, you will likely take the pragmatic approach (or agile, or any other sensible philosophy) and tag the first solution as undesirable relative to the simpler second solution.

At the start of the project however the same cannot be said, especially if the key systems haven’t been written and there are no fixed asset formats, which makes the solution space much more flexible. This means that right now I have the best chance to find elegant solutions to problems we might encounter or have encountered in the past. I really care about nice, clean elegant solutions to problems. Of course there is always limited time so not all solutions are open and not all problems are worth tackling, such is life. So this time I’m trying to iterate on how we get data into the game, and how we structure the game framework. Incidentally, data storage and loading sparked a thread on the GD Algorithms mailing list called ‘Data base choices’ recently.