Monday 4 October 2010

Gui programming

One thing that makes development of Brick Atelier (former Stile) hard is not only the low level gui programming but the fact that the way I programmed the "engine" was really not that clever. It's not impossible to fix the problems, but I found out it takes some work.

For example I had defined consts for zoomed pixel size and of course used them everywhere. Now I want to be able to adjust the pixel size (it's the way to make the app window smaller or bigger for different resolutions) with an option. Replacing consts with a getter for external classes is not that hard, but it's also quite risky code, because of initialization order stuff. So I need to pass the pixel size to both brush classes (which could be combined by the way), but they are allocated in Drawing_Tool class and that class could be refactored out. So making changes like this may sometimes require a lot more work than just simple replacing stuff.

This constantly reminds me about the importance of planning. When I start the next project, whatever it is, I'm going to plan it well.

2 comments:

Jotaf said...

Well, I don't think it means you need more planning, which has a high development cost, but more flexible code, which means that you consider all code "temporary" and you're not afraid to rewrite things as the need arises. Cases similar to the one you describe can always be solved in a matter of minutes with Search&Replace, and any more complex cases are so specific that you'd need to review the relevant code even if you planned ahead anyway (because conditions always vary). IMO you have to see code as evolving logic and embrace the fact that it has to be changed. You always need planning but at some point, more time invested in planning doesn't translate into more benefits.

Jotaf said...

I also just read your earlier posts (was away from the internets for some time).

About the GUI libraries: most are borderline insane, and you need to learn all kinds of nonsense to get them to do what you want. Good old times of VB, when any kid could make a complex interface! If I had to use one today, I'd allocate several days to evaluate all options carefully. Home brewed is probably not that bad.

About the food clock: you could automatically calculate how much food is required to kill a creature (creature HP / player damage = turns to kill it; multiply by food consumption per turn plus some small value to account for maneuvering around the creature), then just sum the food required to kill all creatures in a level plus a constant to account for moving around the level. Then challenging levels will have plenty of food, while more sparse and easy ones will have less. Also, weak players will have more food, strong ones that easily crush opponents will not. I don't have a food clock in my RL but this could be useful for some combat consumable items...