This week, pretty much my sole focus has been dealing with the big icon issue, which was looming as a big problem over 510's new lighting features--and it had been bugging a lot of users well before that.

As I mentioned in last week's post, the new method of handling big icons is to divide the map up into chunks in visual space (only counting the default client.dir=NORTH), and keep track of which objects are in view of it. Those of you who've been waiting on a solution can thank Ter13 for proposing the rough concept.

Where it stands right now, I'm both ahead of and behind the game. Ahead, because I got big turfs handled, which is something I really wanted to do sooner rather than later but had been planning to put off. Also, the webclient supports this new setup for objs and mobs, but not yet for turfs, and it wasn't my intention to handle the webclient that early at all; the obj and mob code simply fell out of what I was working on. And I'm behind because I wanted to put out a release yesterday, but I discovered in further testing that something was very wrong, and I had to hunt down that bug. Plus at this point, I'd prefer to make the webclient handle turfs too.

So while my goal was to get out a release this week, the real time to do that was yesterday--and since I found a bug that had to be fixed, that pushed it back. I could do a release with where things stand today, but because of the high-impact nature of this change, I can't in good conscience put it out on a Friday. Yes I know we're still in beta here, but I have too many bad experiences with Friday releases.

For those interested in what happens under the hood with how maps are sent to players, here's a quick overview. In the old way, turf maps were always sent as a big block--minus a chunk for the old block, if a full refresh wasn't called for. (Before version 505, changing any turf appearance or area in bounds caused a full refresh!) The turf field is padded a bit, so players can move around a little before an update. Also, turfs in an extended radius were checked for anything that had big/giant extents, and were added to a list of special turfs; the new system gets rid of that, and only sends huge turfs in view (or ones that hold any big/out-of-bounds movables in view). Movables were sent by looping through all turfs in view range (with a little padding), plus all special turfs, and sending them all to the client. That too has been changed, since now it's feasible to simply loop through all chunks in view and grab the movables from there.

One of the cool things that I discovered as part of this process, by which I mean something I discovered when tracking that bug yesterday, is that it's feasible for the client to display objects on another Z level if it's told to. And my chunk setup kind of dovetails with that as well, for turfs, or it can later on. Why is this important? Because one of my longstanding wish-list items is to eventually have a way to link up Z levels so that seamless transitions can be made from one map to another, making it easier to create an expansive RPG or action game. That's nowhere near on the horizon yet, but I like that we've moved more in a direction where it could be feasible someday.

Other development items remain on my list, but I went over all those last week. I hope to get to a bunch more things once 510.1328 is out.

Easter is coming up in three weeks. For a lot of people, that means a break from school. Make the most of it and get ready to do some serious game developing (or playing)! But until that happens, it's time to get your green on and play Irish folk music in the hopes of luring out a leprechaun with the promise of beer and cereal marshmallows. (I think that's how it works.) If you find a pot of gold at the end of the rainbow, or loose change in your couch, hopefully you'll send a little our way.