Scene Builder

[gumby]

Here's a project I've been working on and off for the past 3 years or so.  My original intent was build a 'view library'; a collection of views to be utilized in game development.  Now it has morphed into a dynamic scene builder, where every new room the ego visits is built on the fly with views.  I created all the views from PIC resources from the KQ1 remake and I intend to continue to build up the collection from other SCI games.

From a tool perspective, it's still in it's infancy.  Right now all it does is select 15 random views and drops them into the room with some positional help (e.g. a view that was originally clipped on the left side of the room will still be placed on the left side of the room).   I need to create menu options that will allow the developer to select characteristics of what a room should consist of (outside 'sunny', outside 'swamp', inside 'cave', inside 'building', etc), background options and/or color schemes.  After a room is created, the developer will be able save off a room script generated from the rendered scene so it is reproducible in their own game.  Being able to drag a view around the screen for re-placement would be a nice feature as well.

I've attached a few screenshots of some of the better results - the hit ratio of 'good' rooms to 'bad' rooms is about 1 to 5 right now, mostly because of conflicting view types (a bed placed in a forest or stalactites placed in a meadow for example).

[NewRisingSun]

I think that's how Legend of Kyrandia constructed its backgrounds.

[Kawa]

I think that's how Legend of Kyrandia constructed its backgrounds.

^{[citation needed]}

[MusicallyInspired]

Ohhh that's awesome! Perfect idea for a tool!

[gumby]

Initial version uploaded to the games page, very pleased with how it turned out:  http://sciprogramming.com/fangames.php?action=review&id=202

Very easy to use, just input your parameters on room startup and after the room is rendered, any keyboard/mouse input will bring up the cancel/skip/save dialog.  If you choose to save, it'll write out a complete room script (in the game directory) including references of the views to reproduce the scene.  From there all you'll need to do is export the related views into your game & copy/paste the room script text.

The current library of views (over 200 to choose from) is based on the rooms from the KQ1 SCI.

[MusicallyInspired]

So, this compiles a scene with a library of views? Nice work. However, what do you think of the idea of compiling a scene with draw commands instead? I realize there are some pitfalls, namely in overlapping objects, but could that be worked around? Just a theoretical question.

[lskovlun]

So, this compiles a scene with a library of views? Nice work. However, what do you think of the idea of compiling a scene with draw commands instead? I realize there are some pitfalls, namely in overlapping objects, but could that be worked around? Just a theoretical question.

The views are addToPic'ed, so in principle the memory usage is not that great, nor should the performance be a problem. For some reason, there is one view instance per view (which is not necessary because of the addToPic), but that can be fixed. The compromises made here are quite reasonable in my view.

[gumby]

Good catch Lars, in fact in the scene builder rm001, I do only have a single instance of a view and re-use it each time I add a new view.   I will be needing to create one instance per view in the future; I'm planning on not addToPic'ing them so that the user can click/drag it around as they wish before saving out the room definition.  But this doesn't mean that I can't fix the room script generation to only use a single instance.

MI, as for creating pics instead of views it would be much harder to do (for me anyway), creating vector art instead of just creating new views from existing portions of pics.

[MusicallyInspired]

I didn't realize that you could addtopic and have it not be on the screen as a view. That's cool!

I only bring it up because SCI Companion has the ability to select a collection of draw commands and copy/paste/move them around wherever you want (I assume by just manipulating its draw point coordinates). Just wondering if something like this could do that in a similar way. I did that for a couple KQ2SCI screens, which I stole draw command content from KQ1SCI and KQ4. You can also mirror/stretch/skew/resize/rotate them.

[troflip]

Definitely an interesting tool. Is there a reason you're not using the Sierra syntax? :-)

fyi, in the version currently uploaded, it produces scripts that don't compile. Some parentheses are in the wrong place.

So, this compiles a scene with a library of views? Nice work. However, what do you think of the idea of compiling a scene with draw commands instead? I realize there are some pitfalls, namely in overlapping objects, but could that be worked around? Just a theoretical question.

The views are addToPic'ed, so in principle the memory usage is not that great, nor should the performance be a problem. For some reason, there is one view instance per view (which is not necessary because of the addToPic), but that can be fixed. The compromises made here are quite reasonable in my view.

It turns out to be about 46 bytes per addToPic (not including the method calls to create them, nor the extraneous instances in Gumby's current implementation). I imagine you'd be able to drive them based on an array that contains the essential data (view, cel, loop, x, y, pri) - that's 12 bytes, so now you're up to only about 58 bytes per item. Doesn't seem too bad. There's also some memory fragmentation that happens though so it's a little more than that. If you're low on heap space, this could be a problem.

Drawing them directly into pic resources might use up more memory (and be a little more challenging to implement), but the advantage is that this is hunk space (which is garbage collected in Sierra's interpreter, right?), not heap (which needs to be managed carefully).

[lskovlun]

Drawing them directly into pic resources might use up more memory (and be a little more challenging to implement), but the advantage is that this is hunk space (which is garbage collected in Sierra's interpreter, right?), not heap (which needs to be managed carefully).

As far as I remember, SSCI caches the list of patch files - so in addition to the pain of generating a pic file from inside SCI, you'd have to restart the interpreter when creating a new resource. Rewriting an existing one might work, if you're careful to UnLoad() the old one explicitly. You're right about hunk versus heap.

By the way, I was thinking that a simple indicator of class size could be a valuable addition to Companion. In the class hierarchy screen, perhaps? It should be easy enough to extract from the binary class files.

EDIT: Also, you lose the ability to drag elements around that Gumby seems to have planned.

[troflip]

As far as I remember, SSCI caches the list of patch files - so in addition to the pain of generating a pic file from inside SCI, you'd have to restart the interpreter when creating a new resource. Rewriting an existing one might work, if you're careful to UnLoad() the old one explicitly. You're right about hunk versus heap.

I'm confused - Gumby's tool currently outputs a text file that you then copy into your game as a script. This would do the same thing - generate a pic resource that is then imported in to the game. No hot-loading required.


re showing class sizes - maybe it could be in left-hand pane for a script. i.e. breaks down a script into code size, total class/instance size, size for each class/instance, etc...

[gumby]

Definitely an interesting tool. Is there a reason you're not using the Sierra syntax? :-)

Nope, I will add in the Sierra syntax in the next version.

fyi, in the version currently uploaded, it produces scripts that don't compile. Some parentheses are in the wrong place.

Whoops, I didn't run into that.  I'll check that out.  I probably made some change and didn't fully test it out.

[gumby]

New version uploaded:

- Save functionality now writes out two scripts per room, one in 'Studio' format and the other in 'Sierra' format
- Change room generation to not create view instances to reduce generated script size
- Now possible to interact with generated scene for fine-tuning. Views can be moved, changed to a different view and/or priorities updated.

[lskovlun]

Nice update! However, this is actually worse from a memory standpoint; you create instances dynamically (View new:) then throw them away. This will leak memory and cause fragmentation. Rather, my idea was to have a single instance in the room script and then reuse it.

EDIT: Hmm, I see that the system actually does add addToPics to a list. This is odd, and would furthewr complicate matters. I can't investigate now, though.