Grimrock

Petri-

Sorry if this has been asked before, but I didn't see it skimming the thread. Will the dungeon editor be able to display all the GUI elements / panels and have the Lua script defining the dungeon be editable at the same time? Optionally, that would let us paint with broad strokes using the GUI and then switch over to the script and implement something by hand (if we wished). Ideally, the editor would recognize changes made in the dungeon's Lua script in real time, and they would be reflected in the editor and vice-versa. This means that the Lua script controlling the dungeon would probably need to be edited within the dungeon editor, not just in notepad.

Too complicated? Done already?

I guess sometimes it's easier to do as much as possible in advance to prevent problems in the future. i.e something may need to be redone which breaks all previously created fan made dungeons. That wouldn't go down well!

Daniel.

Darklord wrote:I guess sometimes it's easier to do as much as possible in advance to prevent problems in the future. i.e something may need to be redone which breaks all previously created fan made dungeons. That wouldn't go down well!

Daniel.

How do you figure that's even possible? Either the game will run the dungeon or it won't. Adding features to the editor one at a time won't make the game parse the map any differently.

Bees wrote: How do you figure that's even possible? Either the game will run the dungeon or it won't. Adding features to the editor one at a time won't make the game parse the map any differently.

I recall patches in the past for various games that broke saves. Not saying it will but it is often better to be safe rather than sorry.

Also I'm a firm believer in possibilities, in my opinion anything is possible, I'm a proponent of the Infinite monkey theorem.

http://en.wikipedia.org/wiki/Infinite_monkey_theorem

Daniel.

Darklord wrote:I guess sometimes it's easier to do as much as possible in advance to prevent problems in the future. i.e something may need to be redone which breaks all previously created fan made dungeons. That wouldn't go down well!

Daniel.

I understand, but it would suppose, that Petri will be changing "game code", not an editor.
I suppose that e.g. the audibility of sounds is already implemented in game engine (which actually is) and it just needs to be "visualized" in editor (e.g. like in Commandos game).
I should't change any game code.

But maybe you are right, I am just so anxious to play new dungeons

lastsaves wrote: But maybe you are right, I am just so anxious to play new dungeons

Me to, I can't wait!

Daniel.

Consider adding new entity type, door frame?

Does that mean we can kill doors or bash them down? or have demon doors that call you names?

HaunterV wrote:

Consider adding new entity type, door frame?

Does that mean we can kill doors or bash them down? or have demon doors that call you names?

http://oglaf.com/bluedoor/ [this particular comic is SFW, but most of the other episodes aren't]

gambit37 wrote:What I've been talking about is the interface that you give designers to design that "dungeon wiring". From what I understand, you're designing it in a way that to link a switch with a door for example, I will need to open up some kind of script editor/text field and type in some code. Is that the case? Or are you providing point-and-click for these basic building blocks?

Yep, the plan is to use a gui whenever the gui is a better choice (placement of objects, drawing the walls, editing object properties) and use textual representation for things that are better described in code (puzzle logic). Like you said, the editor should be powerful enough to allow recreation of all puzzles and concepts in the original dungeon - complex puzzles need complex logic and these are better described in code. So I think we have established that we need texture scripting (for those complex puzzles) and the question is whether in addition we should support visual scripting. The thing is, I'm not very keen on supporting two ways of scripting (visual and textual), especially when "point and click" is inherently limited in its capabilities to those building blocks we provide. It just feels like additional work without gaining anything.

That said, we want to make dungeon editing as painless as possible, it's just that we have a different view what is "painless"
It's still possible that I change my mind about this but first we'll have to get a bare bones editor up and running and see how the workflow feels.

p.s. I recommend that you look into basics of (Lua) programming - it can give some interesting insights and help see the bigger picture. Not only for modding Grimrock and DSB but it could also become a new tool for solving problems in completely different fields.

Okari wrote:Question about your progress with the dungeon editor; will you be designing it such that when you select a basic level skin (ex first level of grimrock) you can't use level skins from anything else in that, or will we be able to mix and match as we see fit? random example could be wandering through a cavern (rough walls) and then behind a wooden door you encounter an ancient crypt of worked stone (brick and mortar walls).

Only a single wallset per level is supported.