Quote:
Basically, yes. But I would only save the "objects", so that something might include thing like:
using { "water\"
include "well.mob" as center_well}
sun_position { lat 50.045 time 14:43}
The first would pull in the script for a generic well, which you could then alter using:
object {center_well rotate <30,0,0>}.
ummm... that's exactly what I said earlier. Since you didn't notice, in the example I showed, it had sunlight coming through the opening, and the direction each item is facing. The time is also a weird idea for the client to deal with in regards to celestial bodies, since it would be easier for the server to just figure that out in order to deal better with different worlds. Some might have two or three suns or moons travelling at different speeds. Ambiant city light at different times would also be better server side. Those are things that can just be looked up in an array or hash table quite quickly.
Quote:
Since the point is to allow certain specific things, like lighting, to be dynamic, you need to be able to re-do the image as needed. Some things, like adding rain or snow, could be done with OpenGL, after the main image exists, since the effect would be overlayed onto the image, not animated. However, some tweaks to the surfaces (specifically their reflection, etc.) might be used to make everything look "wet".
Its not full animation, you can't rotate it to look at it from some other angle, etc. But you *will* notice, if you set it to allow it, that the light angles and shadows change over time as the sun moves, or similar stuff.
Adding rain or snow into the image after with OpenGL instead of just having the rederer do that would require one of those suboptimal hack jobs you were mentioning earlier.
Also once you start doing things like rotating an item, or moving the light source, you might as well just rerender the whole image, since that will change shadows and reflections on any decently populated room, and on slow computers, it can just re-request an update when it's done rendering (or after a 30 second delay if there is no change). Better updating would also allow for things like a ring of mushrooms appearing at midnight for an hour, or a door that disappears if the light is too bright to be dealt with easier. And with the compressed code, it wouldn't require much bandwidth at all.
And for everything after that point (since I'm not going to copy and paste the rest of the post, you are just repeating everything that I had said, aside from me forgetting to explain the "cave4" bit as being a full room with a height bitmap and a few standard terrain features that is stored by the client. Reusability is a key factor in making a program smaller and more efficient.
Also, beware of obscurement in anything you do... it's a double edged sword. Not only will you be protecting your data from people who want to crack it better, but you will make it much harder to read for when you or someone else has to go fix something.
Aside from tossing this into a script to pass the data over to yet another program, I'm still confused how this would be done in almost any client other than MUSHclient. It would be far simpler to just make your own client and have all of this embedded into it, especially if someone decides to move rooms before an image is fully rendered, and the client will have to figure out what to do with that unfinished process. The main advantage I can see about using a proprietary client instead of a mud client is that it would be easier to deal with adding unique items or doing updates, since it could download new patches at connection, or backgrounded throughout the runtime. |
![[Previous page]](/images/thin_prev.gif){kind=small}
1
2 3
![[Next page]](/images/thin_next.gif){kind=small}
![[Go to top]](/images/gototop.gif){kind=small}
top