In this post:
- I throw yet more shade at the tutorial. I'm starting to feel a little bad about doing this, but evidently not bad enough to retract the shade, or particularly feel like stopping.
- I throw some more fancy techniques at the code, to improve extensibility.
- I start adapting more tutorial code to my altered codebase, and gloss over a bunch of bug fixes.
- I have to work around my design a little, because certain types of changes are less obvious in the context of my code.
- Ultimately, I get about halfway through this part of the tutorial.
- There's no "Next week" blurb? I wonder what that could be about...
Okay, part eleven of thirteen. Let's do this. This tutorial starts off reworking the map and adding more components, which means adding more parameter to the entity initializer, and, um...
If you have a procedure with ten parameters, you probably missed some.
—Alan J. Perlis
So, before we get into the meat of the tutorial, let's make some changes I'd wanted to do before. The basic idea is to stop accessing components as attributes.
So, I converted it to using a dictionary of components, instead of fixed attributes. Then, I made a chained method to stick components on an entity. This gets the arguments off the initializer, and happens to be somewhat cleaner for setting components in general, because it has the logic that must Always Fire in it.
To really take advantage of this, I next need to rev the serialization functions, so I can just dump the components dict directly. The main concern with revving is getting the test code updated... except I'll need to generate a new test file anyway to get stairs, so I can cheat. Except, cheating is effort, so I'll just rev the functions legitimately, then get to work on the tutorial. I can probably get rid of the old dumpers, but for now, I'll focus on following the tutorial.
Let's see, make a Stairs component, write serializer functions for it... Skip over the changes to Entity because I just future-proofed it... Basically follow along with what the tutorial says, though in a slightly different order, because I'm sick and tired of writing usage before definition, because auto-complete can't possibly work when you do that.
Hm. I'm at the new floor creation function, and it feels slightly suspicious that it's duplicating the logic from the "new game" code. Oh well, I'll leave that for later.
Oh no, the function whose organization I've been down on now has access to a variable that my rewritten version does not. Have I been owned? Let's see. It's actually kind of hard for me to tell what is and isn't going on here.
Okay, I appear to be owned in several ways. Let's see about fixing this up. The two issues I'm currently aware of are, message spam from trying to go down the stairs, and I really do need the conn.clear(). The former was easy, I just had an else-block at the wrong level of indentation. For the latter, I want to try leveraging the Event "system". For the former, for now I'm just putting in a quick hack of my own, and adding a new temporary flag attribute to the Game object, to tell it to clear the screen at the start of rendering.
The way is now clear to move on to the second half of this part, but I'm pretty sleepy, so I'll have to put it off until later.