Levels

Client Development Codr's Client
1

I wanted to create a thread for discussing levels in general. Obviously when developing a new client, things can be done any way we want them to be. This opens various possibilities for making levels easier to manage.

I guess I’m just going to leave some questions here for anyone to answer.

  1. What did you find cumbersome about working with levels in Graal?
  2. Would a smaller tile size be preferable?
  3. Would a larger level size be preferable?
  4. Is editing a level file in a text editor important to you?

Please throw in any other comments, suggestions, ideas, or wants as well. The goal here is to come up with a design plan that will best suit the needs we’ve all had while working with Graal.

2

Graals editor was complete trash. Should either use something like Tiled or Fantasy Tales Onlines editor.
I like 16x16 personally, but 32 is good.
Definitely good, imo. I was used to working with 128x128 and it’s pretty good, but very hard to get used to coming from Graal, initially.
Meh. Only if I was going to make a third party editor or if I was a masochist.

Layers is a must have, also.

I have more thoughts on this, but it’s more geared to level editing/editor issues with the Graal editor and not a level specific thing.

3

Since the Graal levels are editable text they’re much more approachable for things like custom editors or generators.

With levels, account data, and server flags text editable it’s easy to make scripts that could for example generate a weekly server that uses player progress and server flags to customize the world. I was too lazy to do anything with it, but I feel it would be a good project to push a new client.

Sent from my iPhone using Tapatalk

4

Text editable levels and most importantly the NPCs inside them is important to me since I’ve done many changes through folders with find and replace when I was working on my server. It would have been very cumbersome otherwise.

16x16 is a perfect tile size.

I agree with the layers, they’re a must.

Levels could be bigger but if we could link them like we can in the Graal editor and edit them as a big gmap level I’d rather use 64x64 levels I guess. I don’t know… haven’t worked with different level sizes really.

5

Layers are definitely happening, which was planned from the start. Including transparency and possibly even animated tilesets. Animated ones may have restrictions, though, as a very large animated image (tileset) will probably have significant overhead, depending on the number of frames per second.

Mass editing via find and replace is a very significant point toward human-readable level data. Definitely not something I was thinking of. Aside from some mostly insignificant efficiency, I don’t see any reason not to make them plain text.

[QUOTE=Chicken;n188757]I was used to working with 128x128 and it’s pretty good[/QUOTE]
128x128 TILES? [ATTACH=JSON]{“data-align”:“none”,“data-size”:“full”,“data-attachmentid”:188762}[/ATTACH]

Ok, so unless more conversation comes along to convince me otherwise, I’ll go with Graal-style everything, but with better layering support. That’s what I was leaning toward already anyway. One thing that will need to be better is level transitioning and multiple level visibility, particularly with NPCs. Graal feels like it was hacked together in that aspect. I’ll be ensuring this engine does map level connections as seamlessly as possible.

As for editors… I haven’t decided yet if I’m going to make something external or do it within the client. I prefer an external editor, but if I’m EVER going to make this work on other operating systems, that isn’t the route to go. Plus, from what I’ve seen of my UI work so far, it works so well that it can be made to not feel much different than working in Windows. That wasn’t the case with Graal’s 20 FPS.

6

Oh, colour shifting is useful for tiles also. Helps to add some variety to levels, without adding in new tiles. Change the hue of a cave tile to a red and it’s like your in a lava tube, blue and you’re underwater.

Customizing what you want as a blocking tile, non blocking and other tile states (e.g shallow water, bush) per tileset. Removes the restrictions on the tileset image layout.

7

[QUOTE=Chicken;n188763]Oh, colour shifting is useful for tiles also. Helps to add some variety to levels, without adding in new tiles. Change the hue of a cave tile to a red and it’s like your in a lava tube, blue and you’re underwater.[/quote]
That’ll just be a part of color effects that can be applied to basically anything rendered, by using modern technology, unlike Graal’s DirectX 7.

I have no plans to hard-code that like Graal did. That just makes no sense for a client that’s trying to be dynamic.

8

make it so i can play the level as im creating it

9

[QUOTE=hosler;n188765]make it so i can play the level as im creating it[/QUOTE]
That’s certainly a possibility, but what is there to gain from that?

10

it’s more fun

11

/facepalm Thanks hosler.

12

Codr dont forget that games should be fun

Sent from my SM-N920R7 using Tapatalk

13

I’m not making a game.

14

[QUOTE=Chicken;n186287]A select entire grouping or select individual tile from grouping feature would also be nice. It would in effect be a hybrid between the second and third idea. You could place a group of tiles in one go (so you have house_chair and it places a chair) or you could select the individual tiles from within said grouping to place down.[/QUOTE]

Graal’s group thing but better. Something Chicken suggested for Evora’s tile editor. I don’t know how useful it would be with well laid out tilesets or for a completely customized world someone would have made for themself. But in the case of some tileset going mainstream with groupings associated I think it would be an enjoyable feature.

15

Editors are really beyond the scope of the discussion here. This is about the technical aspects of levels.

For example, something I’m now thinking through is the idea of multiple tilesets, individual tile replacement on an existing tileset, and how to support layers in general.

16

[QUOTE=Codr;n188756]

[*]What did you find cumbersome about working with levels in Graal?
[/QUOTE]

Lack of transparency support without using dedicated NPCs
Lack of layer support to create overhead images without using dedicated NPCs
Very inefficient support for light effects, so I completely disregarded them in favour of performance
Lack of support for particle effects (unless you like 1FPS light shows) and shaders.
Editing large maps sometimes was annoying to navigate, it feels like it was completely out of the scope of the editor, and was tacked on as a last minute addition. I feel like it should have had some sort of button to press on your keyboard so you could click on an area to navigate to. Maybe a small overlay downscaled to <25% of the size of the map. I dunno if that makes any sense. Perhaps another way to put it would be that it imitates the map in Graal when you press M, and then you could click on a spot on the map to focus on it.
I think this is probably a bit beyond the realm of my knowledge, but file being the container for the scripts and the filesize limit imposed on them was a massive problem for a lot of people trying to do a lot more advanced scripting. Sure, this inspired a lot of creative solutions, but I think people could probably use some more wiggle room.
Another thing I might point out is that there were “predefined” tiles that you could use. I think maybe having that as a bunch of elements laid out to select, rather than them being sequestered to a list that you need to navigate, would be much more useful.

[QUOTE=Codr;n188756]

[*]Would a smaller tile size be preferable?
[/QUOTE]

16^2 px tiles are already generally considered “sub” tiles by size, considering the character is roughly two tiles wide and less than three tiles tall. I think the tile size is more than adequate, but that’s my opinion.

[QUOTE=Codr;n188756]

[*]Would a larger level size be preferable?
[/QUOTE]

Personally I think it’s fine. However, bigmap support should be integrated and easy to implement without external programs and text editors.

[QUOTE=Codr;n188756]

[*]Is editing a level file in a text editor important to you?
[/QUOTE]

I think the biggest flaw with the editor is that sometimes you could softlock your level and require the use of a text editor to remove the problematic NPC. It would be nice to retain that functionality, however, maybe there is a way to completely avoid having that problem in the first place.

Some of my favourite features in the editor was the drag and drop shortcuts. Like, right clicking with a “carried” tile or pattern would fill a targeted tile and all of its immediate siblings with the pattern/tile. Duplicating with right click was also pretty handy. Perhaps a feature similar to this one would also be very handy, but I can understand if that’s a bit harder to implement on a tile based program. I also loved how you could jump in and out of testing without being bothered to save the file, and it was also surprisingly easy to edit maps when you were online. The workflow in the editor is very underrated.

Looking around, I think Gonstruct probably solves a lot of problems I’ve mentioned. I dunno, I haven’t used it before, and I’m only really basing my problems on the editor intended for the _222 client.

edit: oh you’re not talking about Editors. Uh… ignore this I guess.

17

[QUOTE=Yggdrasil;n188779]
edit: oh you’re not talking about Editors. Uh… ignore this I guess.
[/QUOTE]

Well, a lot of what you talked about can be described by Graal’s poor engine, which is what the topic is, basically.

[quote]Lack of transparency support without using dedicated NPCs
Lack of layer support to create overhead images without using dedicated NPCs
Very inefficient support for light effects, so I completely disregarded them in favour of performance
Lack of support for particle effects (unless you like 1FPS light shows) and shaders.[/quote]
All of this will be properly supported. The current plan is to support 8 layers, including the base layer. The top 7 will support alpha blending (transparency). Lighting effects are just alpha blending, I believe, which will be supported on any drawn images. Particles were actually introduced in later Graal versions, but there will definitely be engine support for them.

Quoting this just because I said this earlier for maps in general. I completely agree. I’ll do it right.

Wasn’t this 64 KB? Lol… I think we’ve advanced far beyond that in bandwidth these days, at least in non-isolated areas of developed countries. This limitation won’t exist, at least not anywhere near such a low value.

I agree with basically everything you said about editors, but that’s definitely for later.

18

Does anyone have any better ideas for creating a unified area out of levels? Maps, basically. Feel free to comment on the option you like best if not.

The options I came up with were:

  • Using an external file, equivalent to the map .txt files used by non-gmap Graal maps. To me, this feels clunky somehow.
  • Specifying the adjacent levels in each level itself. This would be more complex on my end, but is doable.
  • Defining the map layout via script directly. This would be kind of ugly, but there’s no reason it couldn’t be done.
19

Couldn’t it just have like a grid in an editor and place the levels in that grid?

20

[QUOTE=2ndwolf;n188805]Couldn’t it just have like a grid in an editor and place the levels in that grid?[/QUOTE]
That’s basically just a UI representation of any option that’s chosen. What happens when you save?