Dungeon Editor Progress

Talk about creating Grimrock 1 levels and mods here. Warning: forum contains spoilers!
Traxis
Posts: 5
Joined: Mon May 07, 2012 12:10 am

Re: Dungeon Editor Progress

Post by Traxis »

r0ck wrote:you forgot to put doorframes to your ironbars doors :P Ingame it will look really strange without em ^^.
Indeed. Well spotted, i didn't notice that until just now :shock:
User avatar
Isaac
Posts: 3185
Joined: Fri Mar 02, 2012 10:02 pm

Re: Dungeon Editor Progress

Post by Isaac »

krayzkrok wrote:
Isaac wrote:What's the down-side for a left-click menu that only pop's up when the user calls for it?
What I'm talking about is getting instant feedback on tile contents, "mouse over" as hannamarin says. It would be tedious and time-consuming to left/right click every tile that you wanted to check contents for, especially if you were working on a puzzle over a large area. There are several ways of showing mouse-over information somewhere, and it's easy to select click a tile so you can then start working on individual elements, or right click to bring up a context menu, but don't make me click each tile to display that information when I'm just looking around.
When I envision the editor in use, I make the assumption that very few tiles will actually have a stack of items, creatures, and/or puzzle logic on them. If the engine were to auto update a 'viewer panel' that lists the contents for any tile under the cursor... then the engine would have to check every tile under the cursor, and most would be empty; a few would have one or more stacks, and a very few would have a large list of things on that tile. I do not see why the engine shouldn't mark any tile that has multiple items and logic with an obvious icon, and let the user click on the one they wish to view. A dedicated viewer panel would permanently take up UI space, where a pop-up (on demand) menu would allow you to quickly select the item of interest, and could include a link to a 'floating' or dedicated viewer panel as well.
User avatar
gambit37
Posts: 218
Joined: Fri Mar 02, 2012 3:40 pm

Re: Dungeon Editor Progress

Post by gambit37 »

Traxis wrote:
r0ck wrote:you forgot to put doorframes to your ironbars doors :P Ingame it will look really strange without em ^^.
Indeed. Well spotted, i didn't notice that until just now :shock:
Who cares? That wasn't the point of this quick demo, I wasn't going for accuracy. :roll:
User avatar
agris
Posts: 17
Joined: Sat Apr 14, 2012 4:36 am

Re: Dungeon Editor Progress

Post by agris »

Hey petri-
petri wrote: - Consider storing the entire dungeon in a single big dungeon.lua file
What's the advantage / disadvantage of this? From an outsider's perspective (mine), it seems like having a .lua file per dungeon floor would make things easier to debug when shit gets wacky. Also, it might be easier to release episodic content if you include the right hooks, rather than having to redistribute the whole code-base again (and possibly reset existing globals?).

If it's an issue of how to render the preview, couldn't we specify something similar to C's headers using #include level1.lua level2.lua in the dungeon script, so when it compiles we get the right linked content?
User avatar
Thels
Posts: 481
Joined: Wed Apr 25, 2012 8:42 am
Location: The Netherlands
Contact:

Re: Dungeon Editor Progress

Post by Thels »

petri wrote:- Consider storing the entire dungeon in a single big dungeon.lua file
Wouldn't that also cause problems later on, when people would mod more than just the dungeon. Packing them in data files, rather than using a loose .lua feels better in the long run.
User avatar
petri
Posts: 1917
Joined: Thu Mar 01, 2012 4:58 pm
Location: Finland

Re: Dungeon Editor Progress

Post by petri »

agris wrote:
petri wrote: - Consider storing the entire dungeon in a single big dungeon.lua file
What's the advantage / disadvantage of this? From an outsider's perspective (mine), it seems like having a .lua file per dungeon floor would make things easier to debug when shit gets wacky. Also, it might be easier to release episodic content if you include the right hooks, rather than having to redistribute the whole code-base again (and possibly reset existing globals?).
I haven't made up my mind about this yet. Having a single document is pretty convenient because it can be easily moved around and levels can be added/removed by the editor without creating/deleting files in the file system. Note that there would be nothing stopping the document containing multiple Lua source code chunks if needed.
User avatar
raf68
Posts: 31
Joined: Sun Mar 04, 2012 1:58 am
Location: France alsace
Contact:

Re: Dungeon Editor Progress

Post by raf68 »

Pétri I plans for a large dungeon with me that I would convert on the level editor for Legend of grimrock when it becomes available, I am very impatient,
issue of the level editor legend of grimrock can withstand large level ???
User avatar
petri
Posts: 1917
Joined: Thu Mar 01, 2012 4:58 pm
Location: Finland

Re: Dungeon Editor Progress

Post by petri »

raf68 wrote:Pétri I plans for a large dungeon with me that I would convert on the level editor for Legend of grimrock when it becomes available, I am very impatient,
issue of the level editor legend of grimrock can withstand large level ???
Currently all levels are max 32x32 squares and there are no restrictions to the number of levels except available memory.
User avatar
Darklord
Posts: 2001
Joined: Sat Mar 03, 2012 12:44 pm
Location: England

Re: Dungeon Editor Progress

Post by Darklord »

petri wrote: Currently all levels are max 32x32 squares and there are no restrictions to the number of levels except available memory.
Any chance the size can be increased past 32x32 or is it quite a difficult thing to do?

Daniel.
A gently fried snail slice is absolutely delicious with a pat of butter...
User avatar
petri
Posts: 1917
Joined: Thu Mar 01, 2012 4:58 pm
Location: Finland

Re: Dungeon Editor Progress

Post by petri »

Darklord wrote:Any chance the size can be increased past 32x32 or is it quite a difficult thing to do?
It's not particularly difficulty, just takes time to replace all the hardcoded sizes and add a tool for resizing the map. The automap would need to be scrollable or zoomable and I wouldn't want to touch that part of the code because it was pretty painful to make it work with different resolutions...
Post Reply