Topic: [suggestions] level editor functionalities

we already have a discussion about rotating bricks and about a graphic interface for selecting bricks/groups, so i'd like to add some other suggestions:
options to select brickset and background from the ones available
options to reload brickset and background without reloading the whole level

https://image.ibb.co/kuSYrm/SD_sml.pnghttps://image.ibb.co/kHq8P6/SeD_sml.pnghttps://image.ibb.co/cJf8P6/LTot_W_sml.png

Re: [suggestions] level editor functionalities

good idea KZR. smile

Re: [suggestions] level editor functionalities

changing the brickset during gameplay would either screw up the level or crash the game altogether. To see why, pick an existing level and, using a text editor, replace the brickset by a completely different one, made by a different author.

on the other hand, changing the background during gameplay is indeed possible. A script command like change_background is also planned.

Re: [suggestions] level editor functionalities

However, if there was a way to edit the level abstractly,
without (or before) imposing a brickset on it right away,
then changing bricksets would be much easier.

-- svgmovement

Re: [suggestions] level editor functionalities

svgmovement wrote:

However, if there was a way to edit the level abstractly,
without (or before) imposing a brickset on it right away,
then changing bricksets would be much easier.

exactly. unlike backgrounds, selecting a brickset is only really possible when there are no bricks.

i guess this is all part of a broader suggestion, which is: when one is going to create a new level, use a graphical interface to select options like brickset, background, level name, and so on, so that you don't have to type the header of a .lev file. isn't it?

Re: [suggestions] level editor functionalities

well, if bricksets followed a template, it would be easy to re-skin a level at any time. And i totally agree with the UI thing, starting a new level should be a lot more painless to newbies and veterans alike.

Last edited by KZR (2013-03-08 17:42:12)

https://image.ibb.co/kuSYrm/SD_sml.pnghttps://image.ibb.co/kHq8P6/SeD_sml.pnghttps://image.ibb.co/cJf8P6/LTot_W_sml.png

Re: [suggestions] level editor functionalities

Back before 1991 there where a very big issue among musicians when sending tracks to one another: There where no standardized preset bank. This ment that you had to slip with a note telling what sound each channel was playing. Roland among other companies got together and deviced a standard to solve this issue: General MIDI. What we need is to have a similar structure to make brick sets interchangeable between levels.

Re: [suggestions] level editor functionalities

jobromedia wrote:

Roland among other companies got together and deviced a standard to solve this issue: General MIDI. What we need is to have a similar structure to make brick sets interchangeable between levels.

The problem is that not all levels will use the same bricks. Music Stadium will not
use palm trees, just like Waterworks will not use the hot lava of Magma Mines.

General MIDI captures many common instruments, but it doesn't catch all. On one hand,
forcing levels to a standard would effectively remove level-specific bricks. An
all-encompassing standard, on the other hand, would just be too cumbersome
to use and maintain. hmm

Also, I am working on a brickset for Sunshine Paradise, and I am writing the
brickset file by hand. (I can more personally control how the brickset
functions that way. smile ) I would hate to have to go online to a lookup
table of standard brick IDs every time I wanted to add a new brick. sad

-- svgmovement

Re: [suggestions] level editor functionalities

Well it's the same anyways. All we need to do is to come up with a predefined list where all object ID's resides.

When programming Basic back in the days I always set up variables holding line numbers where certain functions should be designed.

We need to think similar. General MIDI has the following instrument groups defined for instance:

Keyboard: 0 - 7
Tonal percussion: 8 - 15
Organs: 16 - 23
Guitars: 24 - 31
Basses: 32 - 39
...

We need to define similar groupings:

Flatland: 0 - 99
Small slope up: 100 - 199
Medium slope up: 200 - 299
Steep slope up: 300 - 399
Small slope down: 400 - 499
Medium slope down: 500 - 599
Steep slope down: 600 - 699
...
Trees: 1000 - 1199
City signs: 12000 - 1399
...

Fact is: I think we should add support to include extra bricks in a similar way that you do in C / C++:

#include "brick.brk"

Re: [suggestions] level editor functionalities

jobromedia wrote:

#include "brick.brk"

Do keep in mind, adding functionality like that would break many levels.  Why?  Simply because brick 0 could be one of two bricks.  Perhaps what would be the best option for you would be to fully define the two brick sets, then simply multiply the brick numbers in one of the files by 10000 or so and put the files together.  In fact, because open surge bricks have a defined file structure it wouldn't be too hard to write a program that could potentially combine two brick sets very easily.

As for an all encompassing brick standard, that is not something that can be implemented by the engine.  If anything, this would have to be implemented by the community willingly rather than forcefully.  After all, a template may encourage creativity but it can also stifle it, especially in level design where there end up being all sorts of weird bricks for each and every level.

If I knew then what I know now I'd tell you that the story's true.  Cause whatever you do, it comes back to you.  -Slaughter, Burning Bridges

Re: [suggestions] level editor functionalities

Yes it would break the level standard if we would have brick 0 in both files. Just as in Delphi having two instances of MyProcedure() would make a big problem. And... If we're to keep a nice standard then this is a perfect solution. Why? Many objects resides in separate image files already. From my pov it's just a matter of separating the bricks into separate text files. Will make it much easier to find and correct problems along the line as they pop up.

OS can locate files in separate folders?

So name the folder mybrickset.brk then. Then let Oper Surge load all the files in the folder. How to separate ID conflicts? Add a command ID_OFFSET, which will load the bricks and reset the ID's to ID_OFFSET + ID. Then all we need to do is to define a variable per file to hold the ID offset.

Re: [suggestions] level editor functionalities

This seems overcomplicated. sad

jobromedia wrote:

If we're to keep a nice standard then this is a perfect solution. Why? Many objects resides in separate image files already.From my pov it's just a matter of separating the bricks into separate text files. Will make it much easier to find and correct problems along the line as they pop up.

I'm not sure how brick file separation would help finding and correcting problems. While
grouping sets of bricks would be easier, finding problems would basically be finding the
right brick and changing a parameter or two.

OS can locate files in separate folders?

So name the folder mybrickset.brk then. Then let Oper Surge load all the files in the folder. How to separate ID conflicts? Add a command ID_OFFSET, which will load the bricks and reset the ID's to ID_OFFSET + ID. Then all we need to do is to define a variable per file to hold the ID offset.

Telling a .brk directory from a .brk file is rather easy. The ID_OFFSET, however, has some
hidden drawbacks.

If you add ID_OFFSETs to applicable bricks, then they will show up with modified offsets in the
level editor. Then, bricksets with different include arrangements will actually show up with
different IDs per brick in the level definition.

One could compensate by defining bricks in the level file with
an "ID_OFFSET, ID_OFFSET, ID" format, or store the
ID_OFFSETs with each brick type and display those in the
level editor. Either way, the ID_OFFSET seems to overcomplicate
things.

-- svgmovement

13

Re: [suggestions] level editor functionalities

let's not complicate things. If we make bricksets by template, they can be changed while retaining the level shape. It doesn't mean someone has to use all the bricks. It means that if we do each brickset with only the bricks that are needed, we'll take away some freedom from the players that want to build their own levels with the default bricksets, and we'll make things even harder for those wanting to modify the bricksets.

The way PNG is compressed won't make a brickset too memory-hungry, and no one is required to use or modify all the bricks in the template to make the levels included in the game. But following a template is a must if we want the bricksets to be easily changed without completely screwing up the level.

Therefore, if we put all the solids in bricks 0-999 , the passables in 1000-1999 and so on, there won't be any problems when making changes, as long as the shape of the solids is not changed.

Last edited by KZR (2013-03-14 16:52:21)

https://image.ibb.co/kuSYrm/SD_sml.pnghttps://image.ibb.co/kHq8P6/SeD_sml.pnghttps://image.ibb.co/cJf8P6/LTot_W_sml.png