Instead of a jam theme, a control scheme has been provided:
- UP/DOWN + UP/DOWN (i.e. Lion and Mario Bros.)
Instead of a jam theme, a control scheme has been provided:
Correct, the two sets are both UP/DOWN + UP/DOWN, similar to Lion and Mario Bros.
Don't worry :) Out of limitation a lot of creativity can come. I'm looking forward to seeing what you do create!
They actually are different...
For the two UP/DOWN D-pads (i.e Mario Bros.) there are three positions that each of the two onscreen character can be in (bottom, middle, and top), and since you can move the two characters independently, you've got 9 unique positions for the two of them to be in at any given time.
For the 4-POSITION button layout (i.e. Manhole) there are only 4 unique positions for a single character to be in at any given time.
What I found when I designed Area 51 using just the LEFT/RIGHT D-pad was that there was alot of variety that could come from the "hazards" in the environment.
Using the two UP/DOWN D-pads I think offers even more possibilities, and requires some very clear design thinking to make a good game using it... I think it's certainly a worthy challenge!
BTW... you don't have to move two characters up and down, although I think there is plenty of creative territory to be explored there.
Here are just a few examples of how you might use this control scheme:
1) Two vehicles on a horizontal road.
2) Crane arms picking defective items off a conveyor belt.
3) Opening/closing doors in a Five Nights at Freddy's type scenario.
Okay, but then you're imposing an additional constraint over and above the control scheme -- in this case, the mechanic of moving a playable character over 3 positions. Lion and Mario Bros just happen to implement characters that can move up and down across 3 positions. But there shouldn't be any reason the up/down control couldn't move each character over, say, 4 positions, or 5, or 2.
In addition, as you pointed out, just because Lion and Mario Bros. happen to control "characters", doesn't mean the playable object under control by the control scheme couldn't be something else entirely different, like in your examples, a vehicle or a door.
Which also means, even the implementation of the up/down control as moving something "up" or "down" is only one possible mechanic. It could just as easily be used to accelerate and brake, open or close, jump or crouch.
So, by logical extension, having two characters, one for each up/down controller, is just one possible implementation of the control scheme, but not the only one. As I pointed out, Egg and Manhole (just to name two) use the same control scheme to control only one playable character on the screen.
Of course, as the host, it's your prerogative to add limitations to the game design on top of the control scheme, but I think allowing participants to work within the constraint of the chosen control scheme (and the other limitations of the Game & Watch technology), without imposing limitations on the game design, is likely to produce far more interesting and innovative games. In fact, I would argue, it was this approach to game design by Gunpei and his team that was able to produce such a wide variety of games in the Game & Watch series, rather than just variations on a theme, even though many of the games share the same control scheme.
"Okay, but then you're imposing an additional constraint over and above the control scheme -- in this case, the mechanic of moving a playable character over 3 positions."
I used 3 positions as an example from the aforementioned games, in contrast to how the other scheme in question does not move the character in such a way. I wasn't implying you must use 3 positions... although in my experience 2 characters/3 positions is challenging to work with on its own!
"But there shouldn't be any reason the up/down control couldn't move each character over, say, 4 positions, or 5, or 2. "
Agreed.
"In addition, as you pointed out, just because Lion and Mario Bros. happen to control "characters", doesn't mean the playable object under control by the control scheme couldn't be something else entirely different, like in your examples, a vehicle or a door. "
Agreed, as long as those two "characters" are independently moving on screen.
"Which also means, even the implementation of the up/down control as moving something "up" or "down" is only one possible mechanic. It could just as easily be used to accelerate and brake, open or close, jump or crouch. "
As long as we don't discard the two independent "characters" I am in agreement, and I'll explain further why below.
"So, by logical extension, having two characters, one for each up/down controller, is just one possible implementation of the control scheme, but not the only one. As I pointed out, Egg and Manhole (just to name two) use the same control scheme to control only one playable character on the screen."
So here's my explanation:
I don't think one can separate the scheme from the gameplay when talking about design... meaning the 2 independent rocker D-pads (UP/DOWN) were always linked to two independent characters in the G&W games., while the 4-POSITION buttons were linked to one character. In conceiving of the jam, I wanted to try working under one specific constraints to see what we might create. So I listed the two control schemes we are discussing (among others) as separate and said we would choose one to work with, along with examples to see beforehand. Technically, in terms of hardware, you are right... these are four inputs. But In designing the jam, I connected the scheme with the gameplay, and in this case, two independent "characters" are always used.
"Of course, as the host, it's your prerogative to add limitations to the game design on top of the control scheme,"
So I'm not adding limitations here, I'm adhering to what was described previously in the jam description. These two schemes relate to different approaches to gameplay design in the two independently moving characters on screen.
"but I think allowing participants to work within the constraint of the chosen control scheme (and the other limitations of the Game & Watch technology), without imposing limitations on the game design, is likely to produce far more interesting and innovative games."
I think I'm being unfairly judged here! Please take my words to heart.
There is always a balance between limitations and freedom in creativity and there are alot of possibilities to mine in just one of the schemes as I described them in the original jam description. It's really a challenge, though, because we are used to being given more possibilities than we will ever use. In this jam, I wanted to push us the other direction.
"In fact, I would argue, it was this approach to game design by Gunpei and his team that was able to produce such a wide variety of games in the Game & Watch series, rather than just variations on a theme, even though many of the games share the same control scheme."
There was a wide variety in the G&W series, and I think it's up for discussion which of these were really great or not... is this based on sales? How fun is Ball today? Was trying to replicate console games a good idea, as in the Legend of Zelda? Which are your favourite games, and why? But I'll leave that for a different thread.
Let me say the following:
Please consider that all my designing and hosting of the jam is done with the best intent, out of an excitement I found when attempting to work within the limitations I imagined Yokoi and others did. The breakthroughs I experienced, and the delight in finding solutions and new insights was something I thought was genuinely profound, and was very much linked to the limitations of the genre.
This isn't a paid role :D
Here's my proposition:
Please consider my responses in this thread. As a long-time teacher and designer, I do have a method to my madness, and for this jam its intended to find a particular gold I think that is within the very constraints we are discussing.
If you feel the chosen control scheme constraint is too limiting for you, then let me know here and I'm willing to add the second layout of the 4-POSITION buttons as well. But we have an entire month to make a game... so please at least give the chosen constraint some real brainstorming time. I really think there's alot more potential in there than we may be giving it credit for.
One way to make art is to have every colour of paint and then to paint whatever you want from this. Another way is to limit yourself to blues, and paint what this inspires. I do feel I'm trying to push us into Picasso's blue period but we are wanting more colours :D
I appreciate your position, but in my humble opinion, your argument is flawed because your premise is wrong:
I don't think one can separate the scheme from the gameplay when talking about design... meaning the 2 independent rocker D-pads (UP/DOWN) were always linked to two independent characters in the G&W games., while the 4-POSITION buttons were linked to one character.
Lion uses 4-POSITION buttons to control two independent characters. Manhole uses the exact same 4-POSITION button configuration to control a single character. There is no direct correlation in these cases between scheme and gameplay when it comes to design. Otherwise, by your argument, Lion should have been implemented with rocker switches since it uses two independent characters!
If you want to focus the jam on exploring game design based on the idea of moving two characters/objects independently, then you should define that as the design constraint and not the control scheme.
Please forgive me for being somewhat pedantic here, especially given the nature of this jam and your well articulated goals for it, but I think the question that started this thread illustrates that there is a mismatch between your coupling of the control scheme with the intended design constraints.
...seems pretty clear. It's asking you to only utilise up and down as the movement similar to the two games given as exemplars.
For further clarification, yes, that would mean two "characters", similar to the two games given as exemplars.
One way to show that some great games can come from this limitation, would be to make them. I was hoping to inspire that in others, as I was inspired to do the same. But I'm not convinced that jam attendees feel they can do this with the given constraint. I'm also not convinced the given constraint is being given a fair chance.
There are some other LCD jams as well as G&W specific ones, so I don't mind shutting this one down. I don't get the sense there's a real supportive spirit for it here as laid out.