Design and documentation journal for my interactive fiction (text games); also reviews and other miscellaneous stuff.

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!  

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)

7 comments:

  1. Sounds very cool, now quit teasing and give us a look at it! - Dustin N.

    ReplyDelete
  2. Ack. This wasn't supposed to publish until Monday, when hopefully I'd have screenshots and maybe a pre-alpha test for folks.

    Hold tight - I'll append a couple.

    ReplyDelete
  3. Looking good! A few specific thoughts:

    The bugs you describe definitely sound odd; I don't think I've seen anything like them. I have no ideas about the layers issue, but the problem with coordinates could be some kind of memory bug in the IDE interpreter: the coordinates are stored as lists which would make them more susceptible to issues in dynamic memory.

    Regarding the slow drawing for the sky: are the sunsets implemented using an image (or images)? If so, it may be that the images are extremely large, which could slow things down. Given the lack of details in the sky (assuming features like clouds are sprites), you might be able to get away with up-scaling a smaller image. In most Glk libraries, this will mostly result in a softening of the appearance, and will probably look just fine. (Whether it's faster or not might depend on the Glk implementation. I don't have a sense for how that would play out.)

    (Drawing lots of rectangles is also slow, so if you're implementing the sky gradient using pixel-width rectangles, that could get pokey real quick, especially if you're calculating RGB values for each on the fly...)

    When you talk about darkening the filters for night, do you mean regenerating the sprites in Photoshop? Because another option would be to use a set of semi-transparent PNG overlays of different opacities to darken the landscape as a whole. You can use a very small image (e.g. 10px by 10px) and stretch it to cover the whole window; it will look just fine. To keep the stars sparkling, put them on top of the overlay instead of under it.

    I'd vote for a single color scheme for the status bar--you have plenty of seasonal changes going on already, and having a consistent color to provide contrast would probably be a good thing.

    In any case, it's really coming together. Congrats on getting over that last hump!

    ReplyDelete
  4. Wow! This looks beatiful, especially the winter screenshot.

    I must say I'm intrigued by your game and have been following your posts on and off for a couple of months now. One thing that would be great is adding an 'about' page for this blog, explaining the background and the game concept for new readers.

    Cheers!

    ReplyDelete
  5. Erik:
    The sky base is rectangle primitive; the gradients and shades are semi-transparent .pngs. I hadn't thought about stretching to that extent, though - that's a great idea. I've got 25% opacity at the moment; I was thinking of just adding another sprite with the same image and turning on one, both, or neither depending on the circumstances.
    Thanks for the advice.

    Fredrik - yeah, an about page is a great idea. Thanks for reading!

    ReplyDelete
  6. Really impressive, I can't wait to see how this plays out during a game! Thanks for sharing!

    ReplyDelete
  7. Wow. Just wow.

    I've been following development here on and off for a few months, and I must admit I never thought anybody would be capable of pulling something like this off in IF, let alone make it look good.

    Try to keep it away from gaming websites like rockpapershotgun until it's ready - I reckon they'd be desperate to get their hands on this!

    ReplyDelete