View library

[gumby]

Cloudee's new port of Voodoo Girl to SCI game reminded me of this.  I've been thinking how nice it would be to have a massive library of views (non-animated) that could be used to shortcut some of the process of drawing pics without having to draw everything from scratch.  And now that I think about it, it wouldn't be all that hard.  We could cut/paste parts of existing pics from games and start from there.

Heap wouldn't be an issue because we can use the 'dropped view' approach when implementing the views onto a pic.

Any thoughts?

[Cloudee1]

There's the public domain in the gallery for just that type of thing.

http://sciprogramming.com/community/index.php?action=gallery;cat=4

[gumby]

Yes, we have the place for it - but it's needs some love 

[Collector]

Perhaps we could rip them from some of the fan games.

[Doan Sephim]

I've got tons of views in Betrayed Alliance, but I certainly don't want to spend the time laboriously transferring them.

But feel free to use and modify any of them...I mean, that's what I did (mainly from QfG views)

[Collector]

East enough to dump them with resource.exe, but I was suggesting the fan games to avoid copyright issues with official Sierra resources. I guess this illustrates that that idea doesn't avoid copyright problems as you are probably no where near the first to use Sierra views. It may not attract attention, but with Sierra being brought back from the grave...?

[gumby]

I've started a new project revolving around this idea.  My idea is to dynamically create an entire pic completely out of views.  I'm building up a library of views by creating new ones from pieces of pics.

I'm starting with going through KQ1 pics, so far I've created over 50 views and have only gone through about 25 rooms.  I'm going to go through all the games (Sierra's and fan made) grabbing all the 'props' that I can find.

[Doan Sephim]

East enough to dump them with resource.exe, but I was suggesting the fan games to avoid copyright issues with official Sierra resources. I guess this illustrates that that idea doesn't avoid copyright problems as you are probably no where near the first to use Sierra views. It may not attract attention, but with Sierra being brought back from the grave...?

I don't think using views that have been modified would cause much/any copyright issues, especially when used for fan games that aren't being sold.

I would not recommend using views straight from the sierra games without altering them. Although I did do that for Henry the Hermit, who makes a guest appearance in BA.

[gumby]

Making good progress, I've created 70 views out of sections of existing room pics.  It's slow going, but not too bad.  Trees, rocks and bushes are the vast majority of what I'm putting together.  I'm also grabbing other props and I can identify them, one of my most recent ideas is to grab areas of ground cover.  I've also created ponds, flowers and streams. 

I'm thinking once I get burnt-out on creating views, I'll switch over the 'fun' part of this project and see what I can do about putting together a demo that mashes a random subset of the views together, creating a room pic dynamically.  Maybe a slideshow approach, where it'll build a new room every 20 seconds or so.

[gumby]

I'm starting to burn-out on view creation so I switched gears to the guts of this project.  I've started working on a 'random room generator' game.

Here's screenshots of what it's coming up with currently.  I've only wired in about 30 of the views, and I have it randomly placing 15 views per room.







I'm pretty pleased with the results so far.  As to be expected, it does generate quite a few 'bad' looking rooms because of poor view placement & bad pairings of views.  I need to create a 'save room' functionality in the game which will create a full room script (source code) with the views & coordinates specified just as they appeared when you clicked 'save' (or whatever) - so once you find that 'perfect room' you don't need to go through any effort to recreate it.

[Collector]

Looks good. Is this generated at runtime? If it is, what about retracing ego's route? If ego exits the same side as he entered, is the previous screen recreated as before? If not, I can see a couple of intriguing uses, such as if making ego lose his way. A maze that cannot be solved by always turning the same way. The exit could be determined by x number of screens traversed or by play time.

[gumby]

Yeah, the rooms are completed generated at runtime.  In fact it's only a single room, and right now I've hijacked all the user events to simply re-init the room (generating a completely new random scene) so the ego can't even really move around.  

I'm actually in favor of implementing some sort of permanence to the rooms, so after exiting the ego could re-enter and the room would be recreated.  Collector, I like your idea as well, providing the option for a non-reproducible set of rooms where the rooms would be different each time they are entered - this approach might be useful for creating an 'arcade' type mini-game of some sort.

What I'm considering now is creating a game for creating rooms (imagine, a game that can create a game - well, a small part anyway).  Starting with the same approach I've taken so far, so basically just creating a room from a collection of views but it would be interactive with the developer.  So maybe have an option to start off a room by randomly placing a bunch of views, but then allow for the views to be movable.  Again, the final output would be a 'static' room script.  This would give me a good excuse to use Cloudee's PNC template.

[Collector]

I wonder how much hunk is being used up with all of the views that normally would be just extra lines on the pic resource. It does, however give me some ideas about a PIC editor. Imagine an editor that has some stock objects that could be injected into the vector commands of a pic.

[gumby]

So in testing, I ran into a problem (read: an opportunity to learn).  Views like trees, where the base of the view is relatively small compared to the top of the view don't work correctly from a control line perspective.   What I'm experiencing is identical to Cloudees' issue with his maze, but reversed:  my tree view is blocking the ego too much.  I think I understand it, it's because the NormalBase code is based on the size of the view,  which in the case of a tree just doesn't work.  

I have an idea how to get around it without just adding the view to the pic with the ignoreActors() and programmatically adding the appropriate control lines.  I was thinking about copying the whole view into another cell, then shrinking the 2nd cell down to just be the base of the tree.  Then I can layer the cells on top of each other when I add them to the pic.  The first cell I would add to the pic with the ignoreActors call and the 2nd cell I can add as normal.

EDIT:  This worked perfectly.  I'll post some code soon.

[gumby]

Here's my code so far:

Code: [Select]

(for (= i 0) (< i 15) (++i)
= v Random(1 93)
= xPos Random(xMin[v] xMax[v])
         = yPos Random(yMin[v] yMax[v])

// skip 'bad' views (too big)
(if (<> xMin[v] -1)
    (viewBase:view(v))
   (switch (rType[v])
   (case 1    // ground cover
          (send (View:new()):view(v) x(xPos) y(yPos) cel(0) ignoreActors() setPri(0) addToPic())
 )
 
 (case 2    // 'shadow' foreground
  (send (View:new()):view(v) x(xPos) y(yPos) cel(0) ignoreActors() setPri(15) addToPic())
 )
 (default
  // Cel 1 is for the base of the view, if it's not defined, just add cel 0
  (if (== (viewBase:lastCel()) 0)
                     (send (View:new()):view(v) x(xPos) y(yPos) cel(0) addToPic())
                    )(else
       
     (send (View:new()):view(v) x(+ xPos xHotOff[v]) y(yPos) cel(1) addToPic())
     (send (View:new()):view(v) x(xPos) y(yPos) cel(0) ignoreActors() addToPic())
)  
 )
   )
)
)

A lot going on here, but for the solution of getting the view base correct, it's all in the final 'else' statement.  I had to implement another array (xHotOff) to properly position the 2nd view (the view base) to overlay at the appropriate position on the original view.

I'm moving on to creating a fully working game showcasing this functionality.  Unfortunately, I've run into a snag, the follow script.  It just isn't robust enough for me.  I want to create a game which is 'chase based' and I need some better path finding to get around all the view obstacles that I'm throwing on the screen.

Very preliminary:  I'm looking into implementing an A* (A-star) path finding algorithm, but I'm concerned that we don't have the cycles to get the job done.  Currently, I'm dividing the screen up into a 5x5 pixel grid and still not sure if that will be course/fine enough for what I'm looking for.