There's just so many things I need to work on. I started off with a saving datum that writes and reads its own files. But this was just for players. I soon found out that I need to do the same for a lot of things like maps (for instancing) and literal variables (these are datums that work like variables but have a read-only flag which causes the value not to be changeable by the user.)

Furthermore, there are no real player icons yet. I'm gonna reduce it back down to 20x20 icons just to make my life easier. They were going to be 20x32, which looked sorta cool and all, but 20x20 is easier to work with and I don't have to think about so many more pixels.

Shaun (Tairun) should be working with me today on the project. He can do some icons for me. I'll stick with my programming and sort out the objects I made for it (there are well over 20-30 separate parent/template objects that don't include things like turfs).

What I hope to achieve is cameras being able to be restricted to a specific part of the map while also locking onto an atom (such as the player). Currently the camera object is a little odd and only picks up players, but I will change this.

The game runs in a tick_lag of 0.50 (meaning that it has a max FPS of 20). IT seems to look fluid enough with what I need to do. Most players will probably have a latency of well over 50 ping, but I think I can make that exception. I just dno't want the default 1.0 tick_lag, because it just feels so blocky. 0.5 tick_lag makes it feel so much more smooth.

I would have liked to get some sort of framework up for Edreoll so that the client/players send packets to a server rather than be connected to a server itself. If I had taken this ruote, I could reduce the tick_lag even more to give myself a better FPS such as 30 or 40. I think that's a bit much to do right now though, and the reliability of Topic() and Export() can be sketchy. I haven't tested those at all, nor have I been able to accomplish any sort of workability with them.

HOWEVER, should I be able to do it, I can switch the way maps are displayed and rely entirely on a single map layer. Or, I could rely entirely on client.screen which could be great too.

The possibilities of this are endless, but I need some sort of finished product soon or else I'm gnona go crazy. There's jhust so much code to do.

I have learned that using datums and datum methods are a far better example for safer programming than direct editing of variables. Instead the methods themselves assign the variables accordingly.

That's all I got for now. I'll be working on Edreoll a bit more for now. Anyone who's waiting for it -- It's not gone. It's just slow in progress as usual.
In playing with tick_lag, the most noticeable difference is the camera control. Animated icons playing at 10 frames per second look ok, but a screen scrolling at 10 fps looks bad. Also keep in mind that 20 fps will look like crap once you're used to seeing the game at 30 fps, so its probably better to start with a low framerate and increase it later.

If you're using tile-based movement and camera control I wouldn't expect that you'd benefit too much from a framerate over 25. I've been in games of A Miner Adventure (its tick lag is 0.3) that ran perfectly over the internet, so you could probably handle more than 20 fps if you need to.
20 FPS seems to be right where it needs to be actually. The fact that you can still see noticeable chunkiness actually seems to add a bit of retro-appeal to it. If it was too smooth it wouldn't feel right to me. Thanks for the input : P -- also, tick_lag affects animation speeds, so working with a tick_lag of 0.5 is a lot easier with manipulation animations than something lower.