Level editing comments
JohnR
up, but the levels I create get huge very quickly when all of the
editing history is saved in the file. And I'm just copying and
dragging the same few platforms and items around (but I suppose each
copy creates a new unique platform or item ID, along with the new
position).
What are some recommendations for keeping level file sizes small? And
then the history is duplicated in two places (resources/levels and
server/history) once the level is saved by the client.
Is there an easy way to strip out the history and just keep the "good
stuff" ?
I don't know how this currently works, but would it make any sense to
compress the history before sending it to the client? It's probably
not easy, so maybe that's a future optimization.
Another question I have is the level size limits. Based on the
BitLevel.py code, is the level size 1024x768? I've reached that grey
border area around the edge. I'm not sure what happens if you try to
put things beyond that border... Would it make sense to allow people
to specify a level size and a default background color, or are all
levels intended to fit within that size, without the player ever
seeing that grey border region?
Thanks,
-John
Chris McCormick
On Tue, Mar 08, 2011 at 09:41:38PM -0800, JohnR wrote:
> It seems like the build-in levels are so small when they are zipped
> up, but the levels I create get huge very quickly when all of the
> editing history is saved in the file. And I'm just copying and
> dragging the same few platforms and items around (but I suppose each
> copy creates a new unique platform or item ID, along with the new
> position).
>
> What are some recommendations for keeping level file sizes small? And
> then the history is duplicated in two places (resources/levels and
> server/history) once the level is saved by the client.
>
> Is there an easy way to strip out the history and just keep the "good
> stuff" ?
>
>
> I don't know how this currently works, but would it make any sense to
> compress the history before sending it to the client? It's probably
> not easy, so maybe that's a future optimization.
Good questions.
The server side works 100% on a historical basis as no actual levels are sent
or stored on the server, just the changes, so that side has to retain the full
history.
I guess it would be sensible to start looking at stripping out old history from
the client side store at some point, although I do kind of like the idea of
multiple redundancy of the level histories. It's neccessary for the client to
at least know how much of the level it has downloaded from the server and I'm
currently doing that by measuring history size but I suppose it could be done
differently.
When it comes time to implement an undo function I would like to have the
history handy.
What kind of file sizes are we talking about being too big? I guess I would
consider 1 or 2 megabytes per client-side-level to be reasonable. Or whatever
really, I mean people have terabyte harddrives now right?
> Another question I have is the level size limits. Based on the
> BitLevel.py code, is the level size 1024x768? I've reached that grey
> border area around the edge. I'm not sure what happens if you try to
> put things beyond that border... Would it make sense to allow people
> to specify a level size and a default background color, or are all
> levels intended to fit within that size, without the player ever
> seeing that grey border region?
Like the short messages thing I kind of like the idea of the level size being
that small, so that people will make portals between lots of interconnecting
levels. I like the idea of little self contained worlds all linked together
rather than huge monolithic worlds that take ages to build.
I am totally open to having customiseable level sizes later though. I can add
that one to the TODO list.
Chris.
-------------------
http://mccormick.cx
JohnR
the sizes aren't that big. A few MB zipped, so it could be worse.