pen-devel Mailing List for Puzzles from the Engineer's Notebook
Brought to you by:
mdgeorge
You can subscribe to this list here.
2007 |
Jan
|
Feb
|
Mar
(7) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(10) |
Dec
(49) |
From: Joe S. <jo...@st...> - 2008-12-31 16:23:18
|
Here are some general ideas on how to keep making forward progress. (I've been working this week because I have some deadlines coming up, but I can probably put some time in on PEN tomorrow.) The general strategy I've found most effective in completing an open-source game is this: first get it minimally playable, without worrying about how ugly it is; then flesh out the feature set and tweak the game play to make it more fun; and finally, put the effort into making it pretty. As an example, Zombies [1] started out as red and green squares drawn on a white 2D board, with little numbers in the corners showing the stats of the humans and zombies. But a few of us played it in that ugly state and found it was fun, and that kept us motivated to finish it. It became one of the most popular games I've worked on, and by far the largest game I ever finished. In contrast, with OpenMULE [2] I probably put too much effort into UI up front, trying to honor the look & feel of the original, and got bogged down with a long list of to-do items on a game that you can't even play all the way through yet. (Even though you'd expect that to be an easier project since the observable design was already laid out.) I still hope to finish that one someday, but it's become a slog rather than an enjoyable way to spend my evenings. So here's what I suggest we do for PEN: 1. Define some victory condition. Any victory condition! Whatever's easiest to code. Perhaps a way to define that a part must end up touching some target part -- when all such parts are touching their targets, you've solved the level. Or perhaps a way to specify that some parts must be "activated" (whatever that means for that part type). Whatever. 2. Update the editor so that we can specify those victory conditions. 3. Start building and exchanging real puzzles! We have a decent handful of parts now, and I think we could give each other some fun challenges. 4. Update the main menu UI so that the player can select any of the built-in puzzles, and maybe see when each one was solved. At this point, we take the puzzles we've been exchanging by whatever informal means, and check them into svn as built-in ones. Notice that at this point, anybody who downloads PEN has a game that is actually playable and fun, even if it only has ten puzzles or whatever. So we could probably generate some renewed outside interest if we want. But most importantly, WE will be playing it and having fun! And that will lead directly to: 5. Add more part types and behaviors, so that we can implement some of the things we found ourselves wishing for in step 3. In doing so, don't let ourselves get caught up on making the graphics pretty or the editor fancy -- just do whatever's necessary to make the puzzles work. (This step will probably go on for a while as we flesh out the part set and build lots of cool puzzles.) 6. When we feel like we've got a good set of parts and puzzles -- enough to actually ship as version 1.0 of the game -- then we go back and apply polish: better graphics and sound effects, fancy editor tricks, online puzzle exchange, screen resolution switching, etc. These steps don't need to be following in strict sequence; I know Mike likes to experiment with fancy editor UI (and is very good at it), so there's no harm in continuing progress on that while we're also building parts and puzzles. But I really do think we need to get to step 3, which is the most rewarding part, as fast as possible. That will keep us all motivated and ratchet up the energy level of the project substantially. Best, - Joe [1] http://www.codenautics.com/zombies/ [2] http://codenautics.com/openmule/ |
From: Joe S. <jo...@st...> - 2008-12-31 16:03:18
|
Michael George wrote: > I'm all for working on ropes. Cool -- though I think my message about them that appeared the other day was a repeat, not sent by me but somehow burped up by the list software. > One of my personal goals with making PEN > is to fix some of the annoying UI problems that I've come across in > similar games. The biggest one is having to move your mouse to exactly > the right pixel to place something, which is why I wrote the collision > avoiding drag stuff. I'd like to do something similar for ropes. That's reasonable, though I think the problem with ropes is much easier -- in CM, at least, you can only attach ropes to tie points. So when you're attaching one, if you get anywhere close to a tie point, you just snap to it; no precision mousing is required. If the resulting rope intersects something, then it appears in red and you can't click it down there, which in my book is good enough. But... > What I've been trying to hack up works as follows: as you suggest, a > rope mode is selected, and then the user drags from some connection > point (or an empty space). As they drag however, the rope is kept taut, > without passing through other objects. Thus the user can easily wrap > the rope around pulleys or wheels. They can then drop the rope either > on a connection point or on an empty space. Once the rope has been > created, they can drag either end to reposition it (in which case it > acts as if they had started dragging it from the other end), or in the > middle to reroute it. By dragging the middle they can pull it over the > top of obstacles... This sounds way more complex than it needs to be to me, but if you can make it work and the coding is fun, then go for it! > 1. After playing FC, I'm starting to realize that coiled up ropes hold a > lot of potential for interesting puzzles and solutions. We could > conceivably handle these by having a separate part that is a "coil of > rope" (perhaps different size coils of different length) that has > connection points for both ends, but this seems a little hokey. Hmm. Can you give me an example of how you'd use this? > 2. It's not clear to me whether ropes should intersect with themselves > or with other objects or only with certain other objects. It would be > nice to allow ropes to overlap themselves at least because then we could > have things like crossed belts connecting two pulleys. Yes, I don't think ropes should intersect themselves. It does make sense not to let them intersect boards and such, though. On the other hand, balancing a bowling ball on a rope doesn't seem realistic either... in fact I wouldn't expect anything that can fall to be much troubled by a rope in the way. How about this simplification: ropes can intersect anything that doesn't fall, but not anything that's fixed to the wall? > 3. We can use the convolution code (or something similar) to implement > thick ropes, but I'm not sure the best way to draw them besides just > black lines. But then it becomes hard to distinguish different kinds of > rope if we want to have them (e.g. stretchy vs. non). Hmm, good point. I can imagine some uses for a bungee cord, but that could be drawn quite differently from a regular rope -- it'd have hooks on the end, and a stripey pattern. > Also, clicking on a rope may be hard if it's too thin, > so we need to be careful about that. True, but we shouldn't require the user to click on where the rope is actually drawn -- just calculate the distance between the click point and the rope line, and if that's anywhere within (say) five pixels, consider it a click on the rope. > 4. Do we want length-limited ropes? I don't think it's necessary. (We may want length-limited electrical cords, though.) > I like the idea of a spool, but maybe we could implement it by adding > connection points to other gear-like objects instead of making it a > special object? That way we could create a variety of behaviors > (powered winding/unwinding, etc) I don't think just having connection points does it; you need something that will actually wind and unwind. I suggest we have a special spool/winch object, but make it ALSO a gear (or belt sprocket), so that you can still create that variety of behaviors. It will be a lot of fun having some boards where you need a power source to lift or drag an object, and other boards where you use it (tied to a falling weight) as the power source to make something else happen. Best, - Joe |
From: Michael G. <mdg...@cs...> - 2008-12-29 22:09:18
|
Hey all, I'm all for working on ropes. One of my personal goals with making PEN is to fix some of the annoying UI problems that I've come across in similar games. The biggest one is having to move your mouse to exactly the right pixel to place something, which is why I wrote the collision avoiding drag stuff. I'd like to do something similar for ropes. What I've been trying to hack up works as follows: as you suggest, a rope mode is selected, and then the user drags from some connection point (or an empty space). As they drag however, the rope is kept taut, without passing through other objects. Thus the user can easily wrap the rope around pulleys or wheels. They can then drop the rope either on a connection point or on an empty space. Once the rope has been created, they can drag either end to reposition it (in which case it acts as if they had started dragging it from the other end), or in the middle to reroute it. By dragging the middle they can pull it over the top of obstacles: | \ | \ | ### ###\ x-> ### ===> ###| | ### ###/ | / | / (click) (drag) (result) We could also provide loops (belts, rubber bands) that work similarly but are always in middle dragging mode. I have a few concerns to work out: 1. After playing FC, I'm starting to realize that coiled up ropes hold a lot of potential for interesting puzzles and solutions. We could conceivably handle these by having a separate part that is a "coil of rope" (perhaps different size coils of different length) that has connection points for both ends, but this seems a little hokey. 2. It's not clear to me whether ropes should intersect with themselves or with other objects or only with certain other objects. It would be nice to allow ropes to overlap themselves at least because then we could have things like crossed belts connecting two pulleys. 3. We can use the convolution code (or something similar) to implement thick ropes, but I'm not sure the best way to draw them besides just black lines. But then it becomes hard to distinguish different kinds of rope if we want to have them (e.g. stretchy vs. non). Also, clicking on a rope may be hard if it's too thin, so we need to be careful about that. 4. Do we want length-limited ropes? I like the idea of a spool, but maybe we could implement it by adding connection points to other gear-like objects instead of making it a special object? That way we could create a variety of behaviors (powered winding/unwinding, etc) Thoughts? --Mike Joe Strout wrote: > Should we consider adding ropes to the editor? > > I suggest defining certain parts that have "tie points" to which one > end of a rope can be attached. The 1000 lb weight, since it is > technically not an anvil and has a handle on top, looks like it has > one tie point. The new "lever" object has two (one at each end). The > balloon would have one on bottom. > > Maybe at some point in the future, we could have a "spool" that, when > turned in one direction, would wind the attached rope up; and in the > other direction, would play it out. And conversely, a strong pull on > the attached rope would cause the spool to turn. > > In the editor, I imagine that instead of drag-and-drop, we'd need to > use modes somehow -- maybe when the rope is selected, you click once > on the first tie point, and again on the second. Or maybe click on > the first tie point, drag to the second, and release. > > Once we have some way to define ropes in the editor, I'm pretty sure I > can work out the physics model. > > Best, > - Joe > > -- > Joe Strout > Inspiring Applications, Inc. > http://www.InspiringApps.com > > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Pen-devel mailing list > Pen...@li... > https://lists.sourceforge.net/lists/listinfo/pen-devel > |
From: Valerie G. <val...@gm...> - 2008-12-23 21:20:21
|
Please find my comments below as well. On Tue, Dec 23, 2008 at 2:02 PM, Joe Strout <jo...@st...> wrote: > Great stuff. A few thoughts... > > > 2b. the menu expands in an animated way > > - however the menu is completely responsive during the animation > > I don't think animation here is important -- nice eye candy, but let's > not let it delay getting to the playable-game milestone. Agreed. > > 3. The appearance of the menu > > - something like this: > > > > \ <-> / > > \ / > > foo \ / other > > \ / action > > > > ------ obj ------- > > > > toggle / \ set > > state / \ target > > / X \ > > / \ > > > Looks pretty good. I still think there needs to be a "flip horiz./flip > vert." option... > Arrows and X should be universal enough to be clear, but I'm wondering if > we need to specify "rotate" and "delete" somewhere (either in the menu > itself or in the "rules") > > > - objects obscured by the menu should be either faded out, drawn with > > dashed > > lines (it's not clear the best way to do this), or both > > If we can make the menu translucent, that'd be best. If not, obscuring > stuff temporarily is no big deal. When puzzling through this, we used > tissue paper as a menu circle and placed it over the drawing to see how > translucence might look...I honestly think that's the best way to do it, but > the lines underneath should then become dotted. Keeping solid lines > underneath results in a messy/distracting menu with lines everywhere. I > think that also adds a nice bit of detail to the game. > > > - the object in the center is drawn normally, above the menu > > I don't see how that can work. Some objects will be much larger than > the menu, and an obscured menu is pointless. It also makes more > conceptual sense to me for the menu to appear on top of everything else. What if we had a set menu radius, and scaled the selected object to fit within the inner menu circle (so some objects would appear smaller, others larger, and the main screen behind the menu maintains the original size)? This might also help deal with the issue of objects that are too large, and help the user view smaller objects. The gray lines in the background will be demonstrating where the object is moving to, so the user would be able to use that as reference of scale within the full machine. > > > > - the entries themselves, and their positions and sizes are specified > > by the > > part. I was thinking of an api where the designer specifies, for > each > > entry, an action, an image, and a weight. The weight determines the > > relative size of that entry. For example, to get the following > shape: > > > > | > > | > > --- --- > > / \ > > / \ > > > > they could specify weights of 3, 3, 2, 2, and 2 > > Hmm. I would much prefer that the menu options, positions, and sizes > always be the same, and different parts simply enable or disable them. > This allows players to use their muscle memory -- an option always > appears in the same place, and the gesture is always the same, for any > part to which that option applies. Agreed. > > The only exception to this would be that some options may have two > different "versions", if they're related but always mutually exclusive. > Then those two could occupy the same pie slice. I can't think of a > good example of that at the moment, though. Could this be included in the > "other" button? Perhaps we could have an empty pie section that leaves room > for special features of specific objects. I also can't think of any at the > moment. > > > - I think we should have conventions for where things "should" go > > though, for > > example rotation is always on top, delete is always on the bottom or > > something. Again, this helps muscle memory > > Yeah, but not as much as always having them there, period. Again agreed. > > > - One thing I'm a little worried about is that the menus have to be > > different for the editor and the game. > > Good point. We might be able to get away with not having any for the > game. Game players shouldn't get to set the initial state of an object, > and obviously can't define victory conditions; all they can do is set > the position and orientation of an object. So as long as there is > another way to set orientation (including handedness), we should be fine > with no menus for players. I'm thinking an "engineer's toolbox" in game mode (below the inventory list?) that holds tools such as flip/rotate, resize, delete, etc. This also makes me wonder whether we should have an option for the user to copy/paste components? > > > > - It's also not clear what to do with large objects (e.g. a plank that > > spans half the screen). > > Yeah, my point exactly. :) The menu should appear on top, but I'm not > sure in this case if it'd be nice to warp the pointer (and menu) to the > center of the plank. Maybe we should just pop up the menu wherever the > user clicks instead. Again, I think scaling the component to fit within a specified menu size might be a neat way to do this. > > > > - finally, it's not clear whether the inner and/or outer radii of the > menu > > should be fixed, specified by the designer, or computed > > They should be fixed. Yes. > > > 4. Interaction with the menu > > - there's no buttons that the user has to hit exactly. Anywhere they > > click is in one of the "wedges". I think this will aid usability > > If there's an inner radius (and I think there should be), then that > should be a "dead zone" -- you can click (or right-click) there to > dismiss the menu, without having to move your mouse somewhere else or > otherwise get creative to do so. Agree, though you should also be able to > click elsewhere to get rid of the menu if you so choose. My comments end here. Rest sounds good. Val > > > > - as they move the cursor around the selected action is highlighted > (e.g. > > drawn in blue). We might make a little clicky sound when they cross > the > > border > > That'd be cool. > > > - Left click selects an action from the menu, right click dismisses > > the menu > > I see the logic in that, but I can imagine my kids getting confused. > They right-clicked to bring up the menu; they'll want to right-click > again to select something from it. It'd be easier if, once the menu is > up, either button click on a wedge (outside the dead zone) selects that > option, and either button click anywhere else dismisses it. > > > - Some actions (e.g. rotation) may change the shape of an object, > possibly > > causing it to intersect with another object. We will always show > > the black > > object where the user has positioned it, but we will also have a > faded > > object underneath that shows the closest legal position. When the > > menu is > > dismissed, the gray object will be the actual one. > > Sounds like a good approach. > > > now that I think of it, this might be a good way to do the collision > > avoiding dragging as well. > > Yes, that's not a bad idea. > > Best, > - Joe > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Pen-devel mailing list > Pen...@li... > https://lists.sourceforge.net/lists/listinfo/pen-devel > |
From: Joe S. <jo...@st...> - 2008-12-23 19:04:44
|
Great stuff. A few thoughts... > 2b. the menu expands in an animated way > - however the menu is completely responsive during the animation I don't think animation here is important -- nice eye candy, but let's not let it delay getting to the playable-game milestone. > 3. The appearance of the menu > - something like this: > > \ <-> / > \ / > foo \ / other > \ / action > > ------ obj ------- > > toggle / \ set > state / \ target > / X \ > / \ Looks pretty good. > - objects obscured by the menu should be either faded out, drawn with > dashed > lines (it's not clear the best way to do this), or both If we can make the menu translucent, that'd be best. If not, obscuring stuff temporarily is no big deal. > - the object in the center is drawn normally, above the menu I don't see how that can work. Some objects will be much larger than the menu, and an obscured menu is pointless. It also makes more conceptual sense to me for the menu to appear on top of everything else. > - the entries themselves, and their positions and sizes are specified > by the > part. I was thinking of an api where the designer specifies, for each > entry, an action, an image, and a weight. The weight determines the > relative size of that entry. For example, to get the following shape: > > | > | > --- --- > / \ > / \ > > they could specify weights of 3, 3, 2, 2, and 2 Hmm. I would much prefer that the menu options, positions, and sizes always be the same, and different parts simply enable or disable them. This allows players to use their muscle memory -- an option always appears in the same place, and the gesture is always the same, for any part to which that option applies. The only exception to this would be that some options may have two different "versions", if they're related but always mutually exclusive. Then those two could occupy the same pie slice. I can't think of a good example of that at the moment, though. > - I think we should have conventions for where things "should" go > though, for > example rotation is always on top, delete is always on the bottom or > something. Again, this helps muscle memory Yeah, but not as much as always having them there, period. > - One thing I'm a little worried about is that the menus have to be > different for the editor and the game. Good point. We might be able to get away with not having any for the game. Game players shouldn't get to set the initial state of an object, and obviously can't define victory conditions; all they can do is set the position and orientation of an object. So as long as there is another way to set orientation (including handedness), we should be fine with no menus for players. > - It's also not clear what to do with large objects (e.g. a plank that > spans half the screen). Yeah, my point exactly. :) The menu should appear on top, but I'm not sure in this case if it'd be nice to warp the pointer (and menu) to the center of the plank. Maybe we should just pop up the menu wherever the user clicks instead. > - finally, it's not clear whether the inner and/or outer radii of the menu > should be fixed, specified by the designer, or computed They should be fixed. > 4. Interaction with the menu > - there's no buttons that the user has to hit exactly. Anywhere they > click is in one of the "wedges". I think this will aid usability If there's an inner radius (and I think there should be), then that should be a "dead zone" -- you can click (or right-click) there to dismiss the menu, without having to move your mouse somewhere else or otherwise get creative to do so. > - as they move the cursor around the selected action is highlighted (e.g. > drawn in blue). We might make a little clicky sound when they cross the > border That'd be cool. > - Left click selects an action from the menu, right click dismisses > the menu I see the logic in that, but I can imagine my kids getting confused. They right-clicked to bring up the menu; they'll want to right-click again to select something from it. It'd be easier if, once the menu is up, either button click on a wedge (outside the dead zone) selects that option, and either button click anywhere else dismisses it. > - Some actions (e.g. rotation) may change the shape of an object, possibly > causing it to intersect with another object. We will always show > the black > object where the user has positioned it, but we will also have a faded > object underneath that shows the closest legal position. When the > menu is > dismissed, the gray object will be the actual one. Sounds like a good approach. > now that I think of it, this might be a good way to do the collision > avoiding dragging as well. Yes, that's not a bad idea. Best, - Joe |
From: Joe S. <jo...@st...> - 2008-12-23 18:29:45
|
Michael George wrote: > For some reason I was worried that moving the cursor along with the > background wouldn't work nicely, but it seems to be fine. Ah, I didn't even notice you were doing that. That works fine. Best, - Joe |
From: Michael G. <mdg...@cs...> - 2008-12-23 18:16:02
|
Hello all, Val and I had a discussion this weekend about the menus, and I wanted to share what we came up with to get some feedback. Here's most of it: 1. To invoke the menu, user right-clicks anywhere on an object 2a. the cursor is warped to the center of the object - we move the cursor because there are two logical places for the menu to appear. We want it to appear around the center of the selected object so that we can show the object without it obstructing the menu. We want it to appear where the cursor is so that the same gesture (i.e. right-click move up and right) always selects the same action. 2b. the menu expands in an animated way - however the menu is completely responsive during the animation 2c. if the menu is off the edge then the screen slides to make it visible - the cursor slides with the menu so that it stays in the same logical spot. Again, this supports the correspondence between gestures and actions - something amusing should be in the background 3. The appearance of the menu - something like this: \ <-> / \ / foo \ / other \ / action ------ obj ------- toggle / \ set state / \ target / X \ / \ - objects obscured by the menu should be either faded out, drawn with dashed lines (it's not clear the best way to do this), or both - the object in the center is drawn normally, above the menu - the entries themselves, and their positions and sizes are specified by the part. I was thinking of an api where the designer specifies, for each entry, an action, an image, and a weight. The weight determines the relative size of that entry. For example, to get the following shape: | | --- --- / \ / \ they could specify weights of 3, 3, 2, 2, and 2 - I think we should have conventions for where things "should" go though, for example rotation is always on top, delete is always on the bottom or something. Again, this helps muscle memory - One thing I'm a little worried about is that the menus have to be different for the editor and the game. - It's also not clear what to do with large objects (e.g. a plank that spans half the screen). - finally, it's not clear whether the inner and/or outer radii of the menu should be fixed, specified by the designer, or computed 4. Interaction with the menu - there's no buttons that the user has to hit exactly. Anywhere they click is in one of the "wedges". I think this will aid usability - as they move the cursor around the selected action is highlighted (e.g. drawn in blue). We might make a little clicky sound when they cross the border - Left click selects an action from the menu, right click dismisses the menu - Some actions (e.g. rotation) may change the shape of an object, possibly causing it to intersect with another object. We will always show the black object where the user has positioned it, but we will also have a faded object underneath that shows the closest legal position. When the menu is dismissed, the gray object will be the actual one. - - - - - - - - - - - - - - - | (Obstruction) +---+ | - - - - - - - - | | - - - - | | / | | \ | | / | o | / | b | (gray object) | j | / | e | | c | / | t | / | | | | / | | | | / /| | now that I think of it, this might be a good way to do the collision avoiding dragging as well. That's enough for now. I've checked this in in docs/menu as well. Thoughts? --Mike |
From: Michael G. <mdg...@cs...> - 2008-12-23 17:05:32
|
Joe Strout wrote: >> PS - also let me know if the mouse movement is smooth on your platform >> in the demo if you try it out. >> > > I'm not sure what you're getting at there -- what I see is just the > standard system mouse. So it's perfectly smooth, as always, and doesn't > have anything to do with our app until you click. Is there supposed to > be a custom mouse cursor or some such? > > For some reason I was worried that moving the cursor along with the background wouldn't work nicely, but it seems to be fine. --Mike |
From: Joe S. <jo...@st...> - 2008-12-23 15:54:44
|
Thanks for the work on the pie menu, Mike. When I run piemenu.py, I get a warning: piemenu.py:35: SyntaxWarning: import * only allowed at module level It also fails to run for other reasons, but that's probably fine; the above though looks like something we should fix. But anyway, when I launch pen.py instead and navigate to the pie menus demo, it seems to work fine . > I was enticed by the idea of adding pie menus to the editor. One > problem with this is what to do when the menu is requested near the edge > of the screen. I've put together a little experiment (demos/piemenu.py) > that slides the paper over to show the whole menu. I wonder if the > sliding is too distracting or if people like it? I wasn't crazy about the idea at first, but I do like your idea of having some amusing doodles in the margins that are revealed this way. That might make it worth it. > PS - also let me know if the mouse movement is smooth on your platform > in the demo if you try it out. I'm not sure what you're getting at there -- what I see is just the standard system mouse. So it's perfectly smooth, as always, and doesn't have anything to do with our app until you click. Is there supposed to be a custom mouse cursor or some such? Best, - Joe |
From: Michael G. <mdg...@cs...> - 2008-12-20 06:10:30
|
Hey all, I was enticed by the idea of adding pie menus to the editor. One problem with this is what to do when the menu is requested near the edge of the screen. I've put together a little experiment (demos/piemenu.py) that slides the paper over to show the whole menu. I wonder if the sliding is too distracting or if people like it? I have a better animation and an easy scheme for building the menus in mind, but they're not coded up yet. I was also thinking we could draw something amusing on the sides of the paper (where it's just black in my animation). Cheers, --Mike PS - also let me know if the mouse movement is smooth on your platform in the demo if you try it out. |
From: Michael G. <mdg...@cs...> - 2008-12-20 06:09:45
|
Hey all, I was enticed by the idea of adding pie menus to the editor. One problem with this is what to do when the menu is requested near the edge of the screen. I've put together a little experiment (demos/piemenu.py) that slides the paper over to show the whole menu. I wonder if the sliding is too distracting or if people like it? I have a better animation and an easy scheme for building the menus in mind, but they're not coded up yet. I was also thinking we could draw something amusing on the sides of the paper (where it's just black in my animation). Cheers, --Mike |
From: Michael G. <mdg...@cs...> - 2008-12-17 02:32:35
|
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 |
From: Joe S. <jo...@st...> - 2008-12-16 18:09:56
|
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. 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. 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) * Resize (provides a way to resize objects that are resizable -- like walls and target zones) * 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) * 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. 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. 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. Best, - Joe |
From: Michael G. <mdg...@cs...> - 2008-12-16 15:53:23
|
Joe Strout wrote: > But I think I can see that this is an argument I'm going to lose. And > it's only proper -- this is Mike's project, and I'm just the > newcomer. I think I'll leave you to it, and whether I go back to > making my own game, or just give up on the idea completely, is > something I'll have to work out for myself. > > Best, > - Joe > > You give up too easily :). I don't think this is an argument you're doomed to lose. Both Val and I said we're on the fence about it, and I think Kevin agrees with you. 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. ---Mike |
From: Joe S. <jo...@st...> - 2008-12-16 15:22:45
|
On Dec 16, 2008, at 6:28 AM, Valerie George wrote: > Thanks for bringing it up again...I initially avoided expressing my > opinion, then just plain forgot. > > I too am leaning toward the concept of moving the engineer through > his own machine. Maybe it's because I'm not on the coding side, but > I don't see much of a difference between setting conditions for a > place the object needs to end and setting a place where the engineer > needs to end, other than requiring more code. That may be true, but I wasn't proposing that the only victory condition be to get a particular object to a particular place. That's one possibility, but there are many more: get SEVERAL objects to a particular place; light a candle or light bulb; roast a hot dog; disconnect the power from a bomb before it explodes, etc. And even within the subcategory of "get an object to its destination," there is a LOT more story potential and interest if you allow that to be any object, than if it's always the engineer, time after time. Compare "oh look, on this level we have to rescue the little robot that's trapped between two boxes!" to "oh gee, we have to get the stupid engineer to his notebook, AGAIN." But I think I can see that this is an argument I'm going to lose. And it's only proper -- this is Mike's project, and I'm just the newcomer. I think I'll leave you to it, and whether I go back to making my own game, or just give up on the idea completely, is something I'll have to work out for myself. Best, - Joe |
From: Valerie G. <val...@gm...> - 2008-12-16 13:29:02
|
Thanks for bringing it up again...I initially avoided expressing my opinion, then just plain forgot. I too am leaning toward the concept of moving the engineer through his own machine. Maybe it's because I'm not on the coding side, but I don't see much of a difference between setting conditions for a place the object needs to end and setting a place where the engineer needs to end, other than requiring more code. You might think of it as: In our minds, when these conditions are met, the engineer gets to where he needs to go and the level is over. However, a user might find a uniquely creative way to get him there that we weren't able to envision. I suppose this would also be true in the sense of "get the ball here" any way you can, but then it would involve more end conditions (e.g., ball here and stick there). However, taking this route would mean the context of the level editor wouldn't make much sense. In theory if we carry the story line of an engineer stuck in his machine needing to get out, there would eventually need to be an end to the story. I like complete game play and endings, but that limits us in the number of levels, and means anyone wanting to make their own levels wouldn't have a context to it. I propose two basic game plays (that might lead to an identity crisis so you might not go for it): 1) (in the game itself) You're the engineer, you've fallen into the machine and need to collect tools to work your way out. (One thing I didn't mention before is this might be a neat way to "unlock" certain tools). 2) (when making your own levels) You're the engineer and you want to invent more machines; AND (when playing levels made by other users) You're the engineer's assistant and you need to complete his machines. One thing we should consider is which "role" the user would be better able to quickly understand to add that bit of a story behind the game, which would make the multiple roles in different game play modes a little difficult. Honestly, they're both good ideas and I'm perfectly fine with anything the majority cares to do. Val On Mon, Dec 15, 2008 at 11:19 PM, Michael George <mdg...@cs...>wrote: > I've avoided expressing an opinion on this because I'm a bit on the > fence. On the one hand, I agree with Kevin and Joe that allowing > flexible victory conditions would allow a more "realistic" storyline, > that the engineer left a bunch of partial solutions in his notebook that > you, as his assistant, needs to solve. > > However, I think I agree with Joe that it would be nice to make a > release in the near future. With that in mind, I think I'm still > partial to the idea of having a fixed goal of moving the engineer to the > page. Here's why: > > 1. No new UI is necessary - it's completely clear how this would work in > terms of the level editor. The engineer and the page are normal parts. > We might need to add small changes to ensure that every level has a > goal, but for an alpha release, we can even do without these. Nobody > has put forward a concrete proposal for the alternate scheme, and I > can't think of any that don't require a fair amount of overhauling of > the editor (which I'll point out is the biggest part of the codebase > right now). > > 2. Restricted victory conditions will require more creativity on our > part - I think we all have interesting ideas for levels by now. I think > that requiring us to come up with widgets to adapt those ideas to moving > the engineer or the page around will force us to come up with > interesting mechanisms for interactions. I think these mechanisms will > be the important thing to really focus on between version 0 and version > 1, so getting a bunch of ideas together now will be good. > > 3. As a fan of Godel Escher Bach I'm always up for a bit of > self-reference. Putting the author of the book in the book just makes > me happy (despite being rather non-sensical :)) > > Anyway, my $0.02 > > --Mike > > Joe Strout wrote: > > I think we're to the point where we could be defining real, playable > > levels. We don't have a lot of parts yet, but it's enough to present > > some challenges, and it would be very rewarding to sending around > > levels I've designed, and trying my hand at levels you all have > > designed. > > > > But to do that, we need to come to a decision on victory conditions, > > and get the editor to the point where you can define them as part of > > the level. We've kicked around some ideas for that, but don't seem to > > have gotten anywhere, and to be honest, this is sapping my enthusiasm. > > > > We are SO close to having a complete, playable (albeit small) game. I > > really think the best way forward would be to focus on the few > > remaining features that are getting in the way of us playing this with > > our families. Once we get to that point, we'll have lots of ideas for > > additions and refinements, and plenty of renewed enthusiasm to write > > them. > > > > Best, > > - Joe > > > > > > > > > > > ------------------------------------------------------------------------------ > > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, > Nevada. > > The future of the web can't happen without you. Join us at MIX09 to help > > pave the way to the Next Web now. Learn more and register at > > > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > > _______________________________________________ > > Pen-devel mailing list > > Pen...@li... > > https://lists.sourceforge.net/lists/listinfo/pen-devel > > > > > > ------------------------------------------------------------------------------ > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > _______________________________________________ > Pen-devel mailing list > Pen...@li... > https://lists.sourceforge.net/lists/listinfo/pen-devel > |
From: Michael G. <mdg...@cs...> - 2008-12-16 04:20:15
|
I've avoided expressing an opinion on this because I'm a bit on the fence. On the one hand, I agree with Kevin and Joe that allowing flexible victory conditions would allow a more "realistic" storyline, that the engineer left a bunch of partial solutions in his notebook that you, as his assistant, needs to solve. However, I think I agree with Joe that it would be nice to make a release in the near future. With that in mind, I think I'm still partial to the idea of having a fixed goal of moving the engineer to the page. Here's why: 1. No new UI is necessary - it's completely clear how this would work in terms of the level editor. The engineer and the page are normal parts. We might need to add small changes to ensure that every level has a goal, but for an alpha release, we can even do without these. Nobody has put forward a concrete proposal for the alternate scheme, and I can't think of any that don't require a fair amount of overhauling of the editor (which I'll point out is the biggest part of the codebase right now). 2. Restricted victory conditions will require more creativity on our part - I think we all have interesting ideas for levels by now. I think that requiring us to come up with widgets to adapt those ideas to moving the engineer or the page around will force us to come up with interesting mechanisms for interactions. I think these mechanisms will be the important thing to really focus on between version 0 and version 1, so getting a bunch of ideas together now will be good. 3. As a fan of Godel Escher Bach I'm always up for a bit of self-reference. Putting the author of the book in the book just makes me happy (despite being rather non-sensical :)) Anyway, my $0.02 --Mike Joe Strout wrote: > I think we're to the point where we could be defining real, playable > levels. We don't have a lot of parts yet, but it's enough to present > some challenges, and it would be very rewarding to sending around > levels I've designed, and trying my hand at levels you all have > designed. > > But to do that, we need to come to a decision on victory conditions, > and get the editor to the point where you can define them as part of > the level. We've kicked around some ideas for that, but don't seem to > have gotten anywhere, and to be honest, this is sapping my enthusiasm. > > We are SO close to having a complete, playable (albeit small) game. I > really think the best way forward would be to focus on the few > remaining features that are getting in the way of us playing this with > our families. Once we get to that point, we'll have lots of ideas for > additions and refinements, and plenty of renewed enthusiasm to write > them. > > Best, > - Joe > > > > > ------------------------------------------------------------------------------ > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > _______________________________________________ > Pen-devel mailing list > Pen...@li... > https://lists.sourceforge.net/lists/listinfo/pen-devel > |
From: Joe S. <jo...@st...> - 2008-12-16 03:30:04
|
I think we're to the point where we could be defining real, playable levels. We don't have a lot of parts yet, but it's enough to present some challenges, and it would be very rewarding to sending around levels I've designed, and trying my hand at levels you all have designed. But to do that, we need to come to a decision on victory conditions, and get the editor to the point where you can define them as part of the level. We've kicked around some ideas for that, but don't seem to have gotten anywhere, and to be honest, this is sapping my enthusiasm. We are SO close to having a complete, playable (albeit small) game. I really think the best way forward would be to focus on the few remaining features that are getting in the way of us playing this with our families. Once we get to that point, we'll have lots of ideas for additions and refinements, and plenty of renewed enthusiasm to write them. Best, - Joe |
From: Valerie G. <val...@gm...> - 2008-12-08 01:01:51
|
Are we dealing with friction at all? E.g., rope on a pulley has less friction that rope around a corner. On Sun, Dec 7, 2008 at 12:49 PM, Michael George <mdg...@cs...>wrote: > Joe Strout wrote: > >> 4. python setup.py build in pen > > > > This did too, and they sound more serious: > > bitmask.c:71: warning: right shift count >= width of type > > > bitmask.c is copied directly from the pygame source, so also not my > bugs. I might look into them though. > > > >> 5. copy build/whatever/maskutils.whatever into src/ > >> 6. python drag.py in src/ > >> 7. if it works, tell me how awesome it is (you can press space to get > >> some more objects to play with) :) > > > > It works, and it's awesome! Nicely done. > > > :). I also borrowed a windows laptop for the weekend and got it to > build there (http://pen.sf.net/windows.html if you're curious), so I > think I'll start integrating this into the editor. > > Also, here's a teaser of what I'm working on for the ropes: > > > *ooo* ## > o#####oo #### *oooooo > *# #### oo ###### oo# oooooooooooooo > o## ### oo ###### o ### ooooooo* > o### ## oo #### o ##### ########* > o#### # oo ##oo ### ########o > *##### o** # ########o > o ### ########o > o ### ### ########o > o # ## ### ########* > o ## ## # # o > o ## ### ## o > o ## ### o > o #### #### * > o #### > o #### o* > o###### oo > o###### oo > *###### oo > *oooo*o > > > It's still pretty fragile, but you can play with it in cursesropes.py > > I think for the game, we should just draw the collision bodies (which > > are always either circles or convex polygons) into the drag mask. As > > you say, that should be close enough, or so I hope. Come to think of > > it, it'd be a very handy debugging feature to draw the collision > > bodies on screen during play too. That'd be a great way to make sure > > the collision bodies are a good fit for the sprite. > > > I wonder if we might want to allow unions of these. For example, the > balloon might best be modelled by a big circle at the top plus a > triangle or trapezoid for the bottom. Also, this would allow us to have > concave shapes. > > Also, I'm wondering if we should write a little tool for drawing the > boundary on top of the image and capturing the coordinates, just to make > our lives easier. > > Best, > > - Joe > > > > > > > > > > ------------------------------------------------------------------------------ > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > _______________________________________________ > Pen-devel mailing list > Pen...@li... > https://lists.sourceforge.net/lists/listinfo/pen-devel > |
From: Michael G. <mdg...@cs...> - 2008-12-07 21:13:16
|
I've been playing fantastic contraption all weekend. One of the things that makes it really cool is the way it allows you to see and rate other players' solutions seamlessly. I think that would be cool to have for pen (although not quite as cool, because I suspect pen's dynamics will mean there will be fewer ways to solve a level). Then I was thinking about how we would support that. The obvious solution is to run a server that pen connects to, and host all of the content ourselves. However, if we get any volume, that could be costly (note that sf does not support hosting game services). Another solution that sprang to mind though is that we could use a distributed hash table like pastry or chord to store all of the user-supplied content. Each user would store their own data, but would also host some shared levels as well. Ratings could be used to determine how widely replicated solutions are. Anyway, just a thought. --Mike |
From: Joe S. <jo...@st...> - 2008-12-07 19:54:17
|
On Dec 7, 2008, at 10:49 AM, Michael George wrote: > I wonder if we might want to allow unions of these. For example, the > balloon might best be modelled by a big circle at the top plus a > triangle or trapezoid for the bottom. Also, this would allow us to > have > concave shapes. Yes, we certainly need that. > Also, I'm wondering if we should write a little tool for drawing the > boundary on top of the image and capturing the coordinates, just to > make > our lives easier. Wouldn't hurt -- I've been using a graphics program for that, but a custom tool could spit out the Python code with less effort. Best, - Joe |
From: Michael G. <mdg...@cs...> - 2008-12-07 17:49:15
|
Joe Strout wrote: >> 4. python setup.py build in pen > > This did too, and they sound more serious: > bitmask.c:71: warning: right shift count >= width of type > bitmask.c is copied directly from the pygame source, so also not my bugs. I might look into them though. > >> 5. copy build/whatever/maskutils.whatever into src/ >> 6. python drag.py in src/ >> 7. if it works, tell me how awesome it is (you can press space to get >> some more objects to play with) :) > > It works, and it's awesome! Nicely done. > :). I also borrowed a windows laptop for the weekend and got it to build there (http://pen.sf.net/windows.html if you're curious), so I think I'll start integrating this into the editor. Also, here's a teaser of what I'm working on for the ropes: *ooo* ## o#####oo #### *oooooo *# #### oo ###### oo# oooooooooooooo o## ### oo ###### o ### ooooooo* o### ## oo #### o ##### ########* o#### # oo ##oo ### ########o *##### o** # ########o o ### ########o o ### ### ########o o # ## ### ########* o ## ## # # o o ## ### ## o o ## ### o o #### #### * o #### o #### o* o###### oo o###### oo *###### oo *oooo*o It's still pretty fragile, but you can play with it in cursesropes.py > I think for the game, we should just draw the collision bodies (which > are always either circles or convex polygons) into the drag mask. As > you say, that should be close enough, or so I hope. Come to think of > it, it'd be a very handy debugging feature to draw the collision > bodies on screen during play too. That'd be a great way to make sure > the collision bodies are a good fit for the sprite. > I wonder if we might want to allow unions of these. For example, the balloon might best be modelled by a big circle at the top plus a triangle or trapezoid for the bottom. Also, this would allow us to have concave shapes. Also, I'm wondering if we should write a little tool for drawing the boundary on top of the image and capturing the coordinates, just to make our lives easier. > Best, > - Joe > > > |
From: Kevin S. <thi...@gm...> - 2008-12-07 04:29:39
|
On Tue, Dec 2, 2008 at 2:43 PM, Michael George <mdg...@cs...>wrote: > > > Joe Strout wrote: > > On Dec 2, 2008, at 12:59 PM, Valerie George wrote: > > > > > >> it's really just a picture of a shallow 3D space -- > >> there's room for stuff to stick out enough to avoid other stuff, at > >> least to some extent. > >> > >> Has there been any thought to how this would be done? It might be > >> difficult for the user to grasp visually... > >> > >> (that doesn't mean I'm against it, just curious) > >> > > > > Well, you just draw that stuff on top — it's still not obvious that it > > won't collide with other things, until you run it. It seems to me > > like the sort of thing the user will pick up quickly enough. > > > > > My sense is that we will probably end up with a handful of different > layers - backround stuff (like text, and the supports on your shelves > for example), then maybe wires above (in front of) those, then normal > objects (most everything), and then on top of that maybe ropes (if ropes > interact with pulley objects but not everything). But every part would > have a fixed layer that it interacts with (and maybe it interacts with > multiple layers e.g. a pulley attached to a gear). I think this is an excellent approach. The layer concept should probably be invisible to the player, but is good for the programming model. > > > > Have you guys seen Fantastic Contraption [1]? It's a very simple (yet > > surprisingly deep) online contraption game, where they basically have > > two kinds of struts: those that collide with other stuff, and those > > that don't. The latter kind are called "water" struts or some such, > > and have funny blue bumps crawling over them. I don't quite see how > > that represents noncolliding struts, but the fact is that in real life > > there is nothing like that -- it's magic. Yet my 8-year-old grasped > > it right away and had no trouble using them appropriately to solve the > > puzzles. > The incredible machine had things that did and did not interact with other parts, but no visual indication of which was which (i.e. no "water" surface). As long as the model is consistent for each piece, the player grasps the concept very quickly without an immediate visual clue. If everything that moves passes "through" (conceptually "behind") a rope, it's easy for the player to quickly realize that the rope only interacts with objects that it is tied to and certain rope-specific items (e.g. pulley). Especially with our black-and-white sketch-style of graphics (which I love, btw), I think not providing this visual clue will make the game more visually simple and approachable. (The player doesn't have to realize that the flowing water texture means that parts don't interact with moving objects, which is only a virtual concept, with no real-world analog). > > > > > > I've done astonishingly little oppo. research :). I confess I haven't > even played TIM except for having downloaded the demo and played it for > a few days many years ago. I'll definitely check out FC though when I > get a chance. > > > --Mike > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Pen-devel mailing list > Pen...@li... > https://lists.sourceforge.net/lists/listinfo/pen-devel > |
From: Joe S. <jo...@st...> - 2008-12-07 04:24:20
|
Punching hand: a boxing glove on a spring in a box, activated by a button on top. So when something hits the button, the glove flies out, which can then send balls flying or knock down dominos or whatever. Can be rotated in 90-degree increments. Jack-in-the-box: same idea, but it's a Jack instead of a glove, and to activate it you have to turn the crank (by connecting it with a belt to some other rotating thing). Three turns, and out he pops. Best, - Joe |
From: Kevin S. <thi...@gm...> - 2008-12-06 23:18:10
|
On Sat, Dec 6, 2008 at 4:23 PM, Joe Strout <jo...@st...> wrote: > Have you guys given any more thought to the more general victory- > conditions idea we were kicking around last week? I haven't played the other games that you've been discussing, but played a lot of The Incredible Machine years ago. The puzzle designer mode had victory conditions for each object on the screen. By default each object had no victory conditions, but could be assigned several based on the type of object. Movable objects had location-based conditions, off the top (e.g. balloons), bottom (e.g. bowling ball), or left/right of the screen, or in a certain area of the screen, set by a draggable rectangle. Light sources and switches have on/off conditions, cannons have fired/unfired, candles, fuzes, etc. have lit/unlit conditions. Once all conditions are met, the puzzle is solved. (The unfired/unlit conditions are for things like "get the soccer ball off the screen without lighting the rocket"). This made it possible to have very diverse puzzle types. I really like the idea of having the engineer be a puzzle element. (TIM also had a cartoon human character along with animals). The engineer perhaps can move on his own toward food sources (e.g. pizza), and have other interesting interactions with the environment. However, I think that requiring the solution to involve an engineer is very limiting to the type of puzzle available. It should certainly be possible to involve him/her, but other puzzles should be possible with no engineer at all. I'm excited to see this discussion started up again. I will be glad to contribute some code where I can. I am an experienced programmer, but have only worked on python here and there. I'm interested to check out some of the flash games you've mentioned in the next few days. Kevin > > > Thanks, > - Joe > > > > > ------------------------------------------------------------------------------ > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > _______________________________________________ > Pen-devel mailing list > Pen...@li... > https://lists.sourceforge.net/lists/listinfo/pen-devel > |