Planning is slowly coming to a close now that I’m down to API specification. Slower than I’d hoped. But I’m still managing to solve important problems so I don’t feel too terrible about the rate of progress.
Programming strategies are a funny thing. For any given established design technique it’s not very hard to find a counter argument against it. Which isn’t really surprising, when you get down to it there’s no single perfect piece of code for any sufficiently complex problem. The best you can do is optimize for the specific angles that are most important for your project. Losing sight of that is the danger of doing extensive planning like I’m doing right now.
And I fell into it this week. I got too worried about what the right way to split up a task into objects was (dang ol’ Law of Demeter got stuck in my head). Spun my wheels in the dirt for a few days. Eventually managed to let it go, realizing that if this part of the code needed better modularity later it wouldn’t be hard to add it after the fact since the part that other things touched was sufficiently contained. I feel like a code hypochondriac most days, worrying about potential problems that will likely never materialize. Which then leads me to overcompensating the other direction of embracing under-planning and ending up with an actual mess. Fortunately I only spent a couple days on these worries, and I managed to stop before it became an actual problem.
————————
Other dumb problems I worried about this week:
1. Enumerators in Python suck, or languages with flexible namespaces have ruined me
This is a problem I’ve hit my head against pretty much constantly. And I still don’t have a comfortable method to deal with it. There’s basically two common methods for enumerators in Python. You can use magic strings which then requires extensive documentation for what the available options even are (yuck). Or you can use an object with properties representing the available constants (which is essentially the method that got incorporated into Python3).
What I don’t like about the latter method is that it feels incredibly overbearing to have to import the enumerator object (in my particular case I want to use enums for setting the mode of something. ie, additive or subtractive or alpha blending). Like I just want to casually manipulate this sprite object somewhere and now I have to import something just to tell it to be left aligned? To say nothing of the fact that it basically requires documentation to figure out that a method wants that specific type of enumerator in a language without strong typing (after finding out 3 has argument annotations I’m probably going to take the speed hit and finally switch to it. When you start working with a big enough codebase for long enough, no typing leads to a lot of incredibly long argument names for the sake of clarity).
The closest I’ve come to what I want is to make an enumerator object of sorts that just has a bunch of methods for setting it: SetAdditive(), SetSubtractive(), etc. It’s ok I guess? I feel a little weird about it. Maybe it’s okay.
2. Size and scale are different things.
Because telling an SFML sprite to hit a target size is done by giving it a scale parameter, I ended up mixing up the concept of size and scale into the same component of a scene node. Specifically the properties of “match the size given by our parent sprite” and “make this sprite’s base size match this target size regardless of its loaded size” ended up getting put into the scale component. This is an awful idea because you don’t want to have child scene nodes inherit this particular scaling. Eventually I realized my mistake: a size component handles these things, and then the scale component scales it up, and finally the low level sprite is given a scale to match the resulting size of the two.