AdventureJam

[MusicallyInspired]

I think any engine is allowed. They even allow programming an engine from scratch, but you can't start that until the two-week period starts. I don't know about remakes. Ask on their forums.

[gumby]

Ok guys, I need a little help please.  I've never run into this issue before and it seems like it should be a common problem.  I've got a view that has a significant amount of depth to it (it's a bed that is positioned with the headboard 'nearer' the front-aspect of the room and the footboard towards the back of the room. 

When I drop the view into the pic and navigate the ego around the bed, I don't want to be able to see the feet of the ego when they are walking behind the bed.  For that matter, the ego is able to come too close to the bed from the 'back side' on the z axis.  It looks like the

I've dealt with this problem in the past in a pic by just drawing control lines and preventing the ego from crossing them.  However, the view needs to be movable so I don't think control lines are an option.

Wait, or maybe the issue is that the ego can go too far down on the y-axis and the bed should prevent that movement before the ego gets to that point.  Either way, I've attached a screenshot to illustrate.

EDIT: Is this a priority color issue with the view?  Maybe I just need to bump it up or down into a different band.

[troflip]

One thing you can do is make the collision rect of the bed larger. These are the brBottom, brTop, brLeft and brRight properties properties of a View. However for View and Prop, they are set automatically with the BaseSetter kernel. But Act's have an optional basesetter property that lets you override that. Have a look at the NormalBase instance in the main script. It's assigned to the ego's baseSetter property. So if you made your bed an Act, you might be able to use that.

Of course, that's a rectangle. Given the shape of your bed, you might want the edges to be kind of diagonal?

Perhaps a cleaner option is to create a block. If you notice, an Act (and therefore the ego) have a blocks property. You can add/remove blocks to the ego using observeBlocks and ignoreBlocks. These describe areas the actor can't go. There are classes Blk and Cage in feature.sc that show examples of blocks. It seems like you could make one that describes a polygonal area that the actor can't enter, and then create one of those and add it to the ego's blocks. Then when you move the bed, adjust the boundaries of the block (or your block class could even take a reference to the bed, and automatically update itself?).

[gumby]

Thanks Troflip, I've begun to look at the feature script.  Looks like I can specify a node list which would be the list of blocks (I guess a set of x/y coordinates, not sure?).  This may take me a bit to figure out.

Does anyone have any example code of this?  I'm going to troll through the other fan games that have source code to see if I can shortcut some of the learning curve.

[MusicallyInspired]

I actually ran into this problem with KQ2SCI. I just left it as a problem to solve for later on, though. I figured it'd be a bounding box solution.

[troflip]

An example of the class is something like this:

Code: [Select]

(class DontGoAbove of Obj
(properties
y 0    // The line not to go above
)
(method (doit pObj)
// Return TRUE if the ego is below y, i.e. it can be here
return (> (send pObj:brTop) y)
)
)

And then I put this in the room's init function:

Code: [Select]

(send gEgo:observeBlocks(send (DontGoAbove:new()): y(50)))

So in place of the doit method above, you'd need some kind of test to see if the ego is not inside the shape that defines the bed. You're testing against the ego's brLeft/brTop/brRight/brBottom - basically a box. But your bed's shape I guess would be more of an arbitrary polygon. Something like the separating axis theorem might work. But SCI doesn't have floating point numbers, I'm not sure if it's easy to implement it with integers.

[troflip]

I thought of another option, which would work if your bed was only in a small number of fixed places. You could have n different pic backgrounds that just draw the control lines associated with the bed's n different positions. Then use Rm::overlay to draw them on top of the main background.

[gumby]

Thanks for the sample & the alternate idea - I'll try them out.  I'm pretty sure I can get option #2 working without an issue.

[gumby]

Nope, going with the first option.  Troflip that sample code works perfectly, I'll just have to extend it a bit to create a bounding rectangle as best I can around the bed (maybe coordinates slightly smaller than the bed br values).  If that doesn't work I'll fall back to drawing control lines.

Thank you for sharing this technique, I've never seen it before and it's pretty slick.

EDIT:  Yeah, so now I have a class that is the inverse of the Cage class.  Makes perfect sense!

[gumby]

Here's my code, works all right but really I need something better than a bounding rectangle.

Code: [Select]

(class DontGoRect of Obj
(properties
top 0
left 0
bottom 0
right 0
)
(method (doit pObj)
(if(    (>= (send pObj:brTop) top)
    and (>= (send pObj:brLeft) left)
    and (<= (send pObj:brBottom) bottom)
    and (<= (send pObj:brRight) right)
   )
return(FALSE)
)
return(TRUE)
)
)

And in my room script, in init() (oh yeah, make sure this is executed AFTER you init your view )

Code: [Select]

        (send gEgo:observeBlocks(send (DontGoRect:new()): top(- bed:brTop 15) bottom(bed:brBottom) left(- bed:brLeft 5 ) right(+ bed:brRight 5)))

I agree, a polygon would be a better choice.  However, this is close enough for now.

[troflip]

I agree, a polygon would be a better choice.  However, this is close enough for now.

Glad to see you got it working.

One possibility is that you could add multiple of these to make sort of a "stair step" bunch of rectangles. Sort of a poor-man's diagonal lines  .  The ego movement might feel a little bit weird then though.

[gumby]

Exactly my thoughts, I can break the single rectangle into perhaps 5 (or as many as needed) smaller rectangles that are staggered diagonally.  I can certainly 'layer' them, there's nothing stopping me from that.

I've attached a screenshot to illustrate, but we are on the same page I think

[gumby]

Just learned something new the hard way with my bed-moving.  My code to move the bed was simply to set the new x & y coordinates of the view.  However, if that's all you specify, the other values of the view remain unchanged - the ones I was interested in were the br values.  They retained the original location of the bed.

To fix this issue, you gotta additionally call init(). 

[troflip]

Should you use the posn method? That should reset the base for you.

[gumby]

Never used posn() before, but yeah that seems to work too.  Thanks for that tip as I suppose that there are circumstances where you wouldn't want to call init().