I'm going through a bit of a slump at the moment. One of those "all my ideas are terrible, and I'll never be able to implement them, and even if I do, it'll be *boring*" slumps. They happen regularly, and I've learned to wait them out, resisting the urge to, say, chuck all my code and start from scratch, or chuck all my code and design a new game, or chuck all my code and give up game design FOREVER in despair.
Most of the slumps go away relatively quickly, so I'm taking the opportunity to step back a little. (Fixing bugs is making my fingers itch to chuck all my code, or at least major parts of it, and that's never a decision to make during a slump.) So I'm spending my spare time reading, and occasionally doing something radical like going outside.
The nice thing is that these slumps are almost always followed by periods of drive and innovation, so I'm hoping that happens this time, too.
Wednesday, May 25, 2011
Thursday, May 5, 2011
Better Design Practice: Scene Start/End Conditions in Inform 7
One of the things that's really been hammered home to me lately is that is a terrible, terrible idea to have single-fire scene starters. There are numerous, hideous ways they can go wrong, unless the game starts and stays very simple and constant in design, and rooting out the bugs can be incredibly irritating.
Consider the difference between Scene A, which starts when the time of day is 9:01 pm and ends when the time of day is 10:00 pm, and Scene B, which starts when the time of day is after 9:00 pm and the time of day is before 10:01 pm.
Under normal circumstances, where there's no time breaks, no bugs, no testing circumstances, etc., these will function identically. But if you want to start testing at 9:15 pm to make sure the end game is running smoothly, Scene A won't fire. You could start testing at 9:00 pm, of course - assuming there's no other scenes using similar start conditions that would be interrupted. If you've got a multi-scene end-game, you could very well need to start dozens or hundreds of turns earlier.
You can, of course, always set up a testing string of commands or a skein to get you to the necessary point, but it's really nice to have the additional flexibility of just jumping in.
I'm going through now and trying to make sure that scenes rigorously begin not only during the first turn they apply, but every turn they apply. (The language in Inform is a bit misleading - I anticipated there might be an issue with "starting" a scene every turn, especially if there are conditions that fire when it begins. I think it might be better to talk about when scenes are acted out, or continue, or go on, or happen - some verb that doesn't imply simple on/off conditions.)
Consider the difference between Scene A, which starts when the time of day is 9:01 pm and ends when the time of day is 10:00 pm, and Scene B, which starts when the time of day is after 9:00 pm and the time of day is before 10:01 pm.
Under normal circumstances, where there's no time breaks, no bugs, no testing circumstances, etc., these will function identically. But if you want to start testing at 9:15 pm to make sure the end game is running smoothly, Scene A won't fire. You could start testing at 9:00 pm, of course - assuming there's no other scenes using similar start conditions that would be interrupted. If you've got a multi-scene end-game, you could very well need to start dozens or hundreds of turns earlier.
You can, of course, always set up a testing string of commands or a skein to get you to the necessary point, but it's really nice to have the additional flexibility of just jumping in.
I'm going through now and trying to make sure that scenes rigorously begin not only during the first turn they apply, but every turn they apply. (The language in Inform is a bit misleading - I anticipated there might be an issue with "starting" a scene every turn, especially if there are conditions that fire when it begins. I think it might be better to talk about when scenes are acted out, or continue, or go on, or happen - some verb that doesn't imply simple on/off conditions.)
Monday, May 2, 2011
I will pet it and keep it and call it George
It's terribly gauche to be too proud of one's own work. "This old thing?" I say, holding up my new, kickass, sparkly graphics frame. "Why, this is just something I knocked together in a few spare weekends. It's nothing, really."
But hot damn if the thing doesn't mostly work, and it looks *good*. I'm not even going to put in a disclaimer here, like "it looks good to me" or "it looks good for IF graphics". Puppy looks good. Good at night, good during the day, downright tear-jerking when the sunset peaks, stunning in fall. I was desperately worried about winter - the scaling affects the snow more than leaves, and it was so labor intensive that I got a little sloppy here and there, and each individual sprite isn't that good - but in aggregate? It looks good.
That said, it needs more work.
Most seriously, I'm experiencing a rare-but-not-rare-enough bug in the Inform testing platform where layers will get shuffled or not activated. It happens maybe once every 25-50 compiles, and seems to be unaffected by my attempts to implement refresh commands (ie turning all the layers off/on, or changing the layers in game and then redrawing does not seem to have an effect). There's a related, rarer (?) bug that ignores either the coordinates for the origin of certain sprites, or the order to have them centrally centered (rather than centering based on the upper left corner). The only recourse under these circumstances seems to be to exit; even restarting doesn't affect the issue. I'm pretty sure it's an internal problem and not my code, because it's so unpredictable and there's literally nothing about recentering or moving sprites around in the game at this time.
I haven't experienced the bug in any of the interpreter runs, but I've only done a few of those. I'm trying to nail down specifics for a bug report, but reproducibility is a problem, so gathering data is slow.
Problems that are related to my code:
- The game is definitely a titch boggy during sunrise/sunset; just enough that I know something special is happening under the hood. (Most turns don't run graphics rules; usually it's an hourly thing, but sunrise/set requires updates each turn). The bog seems to be related to redrawing, but not to number of sprites - that is, the cost of changing the sky color when there's no sprites is only a tiny bit quicker than doing it when there's 50-odd. The downside is that it means it's largely out of my hands, assuming I want to do turnly updates. The upside means that I don't have to feel guilty about the tree sprites.
- Tree sprites are a little sparser than I wanted originally, and I may add more. Or may not. I'm not completely pleased about the placement of all the sprites; it's a bit off.
- Many of the tree sprites have little piles of leaves around their base during the fall. This looks weird on the trees in the far background, and often doesn't work with the contours of the hills. I need to go back in and take them out. Thankfully, I have all the layered originals, so it's just a little boring rather than downright impossible.
- The times when the ground is bare (no grass or snow) don't look quite right. I'm not sure why, which makes it hard to fix. It's not awful, but it's not great, especially in early winter.
- I desperately need to darken the filters more during the night, and possibly during rainstorms as well. The worst offenders are the spring sprites - the cherry blossoms practically glow against the sky, and not in a good way.
- Changes in seasonal appearance are not entirely hooked into the seasons yet; only brute force makes the graphical changes right now, so I'm sure there will be many amusing adventures as I iron out that issue.
- Sun and moon are not operable; I plan to put them on arcs, and I'd like to feel a little better about the layout before deciding exact paths.
- I need testing commands for weather. And month/day.
- A few of the more complicated conditions, like the sky gradients and precipitation, need work and/or implementation.
- None of the unimportant layers, like lightning, have any implementation beyond tentative placement.
- There's an acceptable neutral color scheme right now for status bar, inventory window, and map window. It's sort of taupe with chocolate, and was not intended to be a long term choice. I've grown used to it, but I'm contemplating tying that in seasonally. Winter/fall colors schemes are easy enough - gray/blue and earth tones are nondistracting and completely acceptable neutrals. Spring/summer is tougher; green can be a little distracting, and it's hard to get tones right, and I need to not go too tropical or bright. (Eyestrain: I do not want it.) More neutral versions of summer/spring colors tend to go autumn/wintery: hyacinth is great, but by the time I don't feel like the status bar is shrieking at me, we have a nice eggplant/plum color. Dark turquoise/cream, maybe? I dunno. There might be a chameleon neutral set that would look "seasonal" when put up against the tones from the top window. Fortunately, I love excuses to visit Kuler, and see what appeals.
Update:
Screenshots. Whoo!
But hot damn if the thing doesn't mostly work, and it looks *good*. I'm not even going to put in a disclaimer here, like "it looks good to me" or "it looks good for IF graphics". Puppy looks good. Good at night, good during the day, downright tear-jerking when the sunset peaks, stunning in fall. I was desperately worried about winter - the scaling affects the snow more than leaves, and it was so labor intensive that I got a little sloppy here and there, and each individual sprite isn't that good - but in aggregate? It looks good.
That said, it needs more work.
Most seriously, I'm experiencing a rare-but-not-rare-enough bug in the Inform testing platform where layers will get shuffled or not activated. It happens maybe once every 25-50 compiles, and seems to be unaffected by my attempts to implement refresh commands (ie turning all the layers off/on, or changing the layers in game and then redrawing does not seem to have an effect). There's a related, rarer (?) bug that ignores either the coordinates for the origin of certain sprites, or the order to have them centrally centered (rather than centering based on the upper left corner). The only recourse under these circumstances seems to be to exit; even restarting doesn't affect the issue. I'm pretty sure it's an internal problem and not my code, because it's so unpredictable and there's literally nothing about recentering or moving sprites around in the game at this time.
I haven't experienced the bug in any of the interpreter runs, but I've only done a few of those. I'm trying to nail down specifics for a bug report, but reproducibility is a problem, so gathering data is slow.
Problems that are related to my code:
- The game is definitely a titch boggy during sunrise/sunset; just enough that I know something special is happening under the hood. (Most turns don't run graphics rules; usually it's an hourly thing, but sunrise/set requires updates each turn). The bog seems to be related to redrawing, but not to number of sprites - that is, the cost of changing the sky color when there's no sprites is only a tiny bit quicker than doing it when there's 50-odd. The downside is that it means it's largely out of my hands, assuming I want to do turnly updates. The upside means that I don't have to feel guilty about the tree sprites.
- Tree sprites are a little sparser than I wanted originally, and I may add more. Or may not. I'm not completely pleased about the placement of all the sprites; it's a bit off.
- Many of the tree sprites have little piles of leaves around their base during the fall. This looks weird on the trees in the far background, and often doesn't work with the contours of the hills. I need to go back in and take them out. Thankfully, I have all the layered originals, so it's just a little boring rather than downright impossible.
- The times when the ground is bare (no grass or snow) don't look quite right. I'm not sure why, which makes it hard to fix. It's not awful, but it's not great, especially in early winter.
- I desperately need to darken the filters more during the night, and possibly during rainstorms as well. The worst offenders are the spring sprites - the cherry blossoms practically glow against the sky, and not in a good way.
- Changes in seasonal appearance are not entirely hooked into the seasons yet; only brute force makes the graphical changes right now, so I'm sure there will be many amusing adventures as I iron out that issue.
- Sun and moon are not operable; I plan to put them on arcs, and I'd like to feel a little better about the layout before deciding exact paths.
- I need testing commands for weather. And month/day.
- A few of the more complicated conditions, like the sky gradients and precipitation, need work and/or implementation.
- None of the unimportant layers, like lightning, have any implementation beyond tentative placement.
- There's an acceptable neutral color scheme right now for status bar, inventory window, and map window. It's sort of taupe with chocolate, and was not intended to be a long term choice. I've grown used to it, but I'm contemplating tying that in seasonally. Winter/fall colors schemes are easy enough - gray/blue and earth tones are nondistracting and completely acceptable neutrals. Spring/summer is tougher; green can be a little distracting, and it's hard to get tones right, and I need to not go too tropical or bright. (Eyestrain: I do not want it.) More neutral versions of summer/spring colors tend to go autumn/wintery: hyacinth is great, but by the time I don't feel like the status bar is shrieking at me, we have a nice eggplant/plum color. Dark turquoise/cream, maybe? I dunno. There might be a chameleon neutral set that would look "seasonal" when put up against the tones from the top window. Fortunately, I love excuses to visit Kuler, and see what appeals.
Update:
Screenshots. Whoo!
 |
| Winter; heavy snow, day. |
 |
| The end of dawn; summer |
 |
| Early fall sunset |
 |
| Mid-fall; very fond of the sky-color picked here. |
 |
| Mid-spring night (with glowing foliage visible in background) |
Subscribe to:
Posts (Atom)
