Re: [Pen-devel] resolution on victory conditions & part state

[Michael G. <mdg...@cs...>]

Joe Strout wrote:
> On Dec 16, 2008, at 8:52 AM, Michael George wrote:
>
>   
>> My biggest objection to doing something different is complexity, and  
>> not
>> having a clear vision for how it will work UI-wise.  Maybe you could  
>> put
>> together a description or a mockup of what you have in mind?  I like  
>> the
>> idea of having more flexible victory conditions (although I'm not
>> convinced it's necessary to make the game fun), I just can't see how  
>> it
>> will work yet.
>>     
>
> OK.  My primary inspiration here is Crazy Machine, and I know that  
> Kevin's familiar with TIM, but I think they both work approximately  
> the same way.
>
>   
This all sounds good to me.  I'm curious where everyone else stands.  
It'll be a fair amount of work, but I've been thinking we need to 
overhaul the editor a bit anyway.  A few comments:
> First, we need a way to present a small menu of options for the  
> selected object in the editor.  CM presents these as little icons that  
> appear in a circle around the selected object.  I'd be just as fine  
> with an OS-standard pop-up menu, or a rectangular game menu that  
> appears next to it.
>   
I don't think one or the other's actually any easier (except that 
showing an OS menu is hard/impossible in pygame), so we should just go 
with what looks good and works well.
> Whatever it looks like, the menu presents these choices:
>
> * Change State
> (sets the initial state of the object: candle lit/unlit, light on/off,  
> switch up/down, etc.)
>
> * Rotate
> (provides another way to rotate a part for people who don't have  
> scroll wheels -- which is still pretty common on the Mac)
>
>   
I'm not convinced these should be separate.  I kind of like what we're 
doing now, which is to have a generic "tweak" that behaves differently 
for different objects.  The reasons I'm wary of providing a general 
purpose rotate is because different objects have different rotation 
behavior:
 - the cannon rotates the barrel but not the base, and only from 10 
degrees to 170 or so.
 - objects like planks should be allowed to rotate fairly freely, 
perhaps on 15 degree increments
 - many objects will probably rotate on 90 degree increments or flip 
(although we don't have any yet)
 - many objects won't rotate at all (balloon?)
It's also not clear to me what happens when you click "rotate" in the 
menu.  Is the object then tied angularly to your mouse?  until you click 
again?  until you release?

I like lumping rotation behavior into generic "tweaking" behavior partly 
because I think it's a nice natural "modify this object" gesture, which 
makes some intuitive sense to me.  However, if there are compelling 
examples of objects that we want to rotate and change the state of (or 
more generally, that we want to change the state in two different ways), 
then we'll need a more general interface.
> * Resize
> (provides a way to resize objects that are resizable -- like walls and  
> target zones)
>   
It's also not clear to me what happens when you select this option.
> * Lock/Unlock  (or maybe Pen/Pencil?)
> (defines whether it's a fixed item, part of the initial layout that  
> players will see, or an extra item that appears only in their palette)
>   
I think for learnability we write lock/unlock, but draw it in pen/pencil 
as you suggested.
> * Set As Goal
> (defines this object as part of the level's victory conditions;  
> exactly what that means depends on the part type -- light a candle or  
> lightbulb, roast a hot dog, pop a balloon, blow a steam whistle,  
> launch a rocket, etc.)
>
> * Define Target
> (enters a mode where you drag from this object to the target zone or  
> object, and then within the editor, we show this as an arrow (or  
> string of arrows) between this object and that target).
>
> On that last item: note that there would be one extra thing in the  
> palette, in design mode only, which is a "target zone".  You drag this  
> out onto the board and resize it how you want it.  It has no impact on  
> game play except to provide you a way to define a target region.
>   
Sounds good to me.  Maybe we could make a nice cross-hatching texture 
for that.  I think we'll have to be a bit careful to avoid too much 
visual clutter, but lets worry about that when we come to it.  Also, for 
some of the things we were talking about we need to specify the state 
that corresponds to the goal (i.e. is the goal to get the candle lit or 
to keep it from being lit?)
> Finally, there should be a couple of menu commands that let you enter  
> the "Introduction" and "Completion" text, which provide the story for  
> the level.
>
>   
Maybe I'm just dumb, but I've found text entry to be really hard to do 
well, and I haven't come across a nice library for it.  Eventually I 
think it's clear that we'll want it, but maybe for version 0 we just add 
that information by hand to the levels we ship (they're just XML files).
> That's really it.  Data-wise, it's just a couple of extra pieces of  
> information for each initial part on the board:
>    - Locked (yes/no)
>    - Goal (yes/no)
>    - Target (object reference)
>
> The level is solved when every Goal=True object reports that its own  
> individual victory state has been achieved, and when every object with  
> a Target set is in contact with that target.
>
> Note on the Lock/Unlock state: I know we've discussed that before too,  
> and you've wanted to avoid it, but I think that was in part an attempt  
> to avoid adding a menu.  Once we have a menu, adding this in it is no  
> big deal, and it offers several advantages over the current approach  
> of not having unlocked items in the level design:
>
> 1. The level designer can tweak the level a bit at any time, and test  
> it, without having to laboriously re-solve the level by dragging stuff  
> back out of the bins.
>
> 2. We can provide a "hint" function that randomly places (or fixes the  
> position of) some object, according to the original design.
>
> 3. We can even provide a "give up" feature that shows the player the  
> correct solution.
>
> #1 is the big one for me, though.  I really don't want to have to  
> design a big complex level without being able to put unlocked parts on  
> the board, and having them stay put.
>   
This will also require rethinking how the data is organized into files 
and how things are loaded.  Right now the data is split into levels and 
solutions.  A level contains all of the fixed parts, while a solution 
contains all of the movable parts.  Each level has a single solution 
associated with it (in fact IIRC they are parts of the same object).

One easy way to support feature #1 is to simply draw the solution in the 
editor along with the level and allow both of them to be manipulated 
(and parts moved back and forth with the lock/unlock menu).  However, 
this still leaves you unable to test playing the level from scratch 
without losing your saved solution.  Also, it doesn't support features 
#2 and #3.
> Best,
> - Joe
>
>   
Have fun,

--Mike