Design Contest: Two-Button Challenge (For Reals edition)
Some time ago I had a thought for an interesting little design contest: create a game that is played using only two buttons. Not two buttons + arrow keys, not two buttons + verbs, two buttons + mouse, or two buttons + context menu. Two keyboard buttons: that's it. Unfortunately the idea just kind of petered out and didn't go anywhere, so I'm kicking things off again. We're going to make it a bit simpler this time, so here's the rules:
Rule the First:
All entries must include a .dms script file with the following lines of code:
Player mobs, of course, must include "buttonA" and "buttonB" verbs. The entire game must be playable using nothing except these two macros. You may include other forms of getting at these two commands if necessary--you could macro left arrow to buttonA and right arrow to buttonB, or create HUD buttons that call buttonA() and buttonB(), etc.--but games will be judged solely on their playability with the required a + b macros. Anything that can't be done in game with the a + b button doesn't count, so if the game's not playable with those two buttons, it's out.
Just to clarify: The player is not allowed to interact with or affect the game in any fashion save through inputs that go directly to buttonA() and buttonB(), neither of which can accept arguments or use input dialogs.
(Chat functions and commands of a purely administrative or social nature are the only exception to this rule, so long as they do not directly have any influence on gameplay and are not required to play the game as intended.)
Rule the Second:
Entries must feature some sort of multiplayer interaction. Multiple players playing separate games in parallel do not qualify--a player must be able to have some affect on other players, either directly or through a shared environment.
Rule the Belated Third:
Source code must be included for all entries to verify that the limits on input aren't being circumvented, but you don't have to distribute the source openly if you don't want to.
And... really, that's about it. All entries must be submitted to t_leftley@hotmail.com by February 28, 2007 (either mailing the game's source package or just sending a link to a hub entry or site where the source is available to download). Games will be judged in four categories:
-Presentation (general appearance and user-friendliness)
-Creativity (original and unique approaches to the design constraints)
-Depth (the game's variety and replay value)
-Overall Fun (general enjoyability and non-suckiness)
Assuming there are at least four participants (because it's not a real contest unless you can call someone the loser!): First place will win a BYOND membership for the recipient of their choice (include themselves) plus $10 Paypal, second place wins a BYOND membership plus $5, third place wins just a BYOND membership. Multiple entries per contestant are allowed, but only the best will qualify to place for a prize.
In addition to entries, if anyone wants to volunteer to help judge I'd be much obliged (theoretically, more judges means more of a commitment means less chance I'll get bored and wander off before the contest ends).
Rule the First:
All entries must include a .dms script file with the following lines of code:
macro
a return "buttonA"
b return "buttonB"
|
Player mobs, of course, must include "buttonA" and "buttonB" verbs. The entire game must be playable using nothing except these two macros. You may include other forms of getting at these two commands if necessary--you could macro left arrow to buttonA and right arrow to buttonB, or create HUD buttons that call buttonA() and buttonB(), etc.--but games will be judged solely on their playability with the required a + b macros. Anything that can't be done in game with the a + b button doesn't count, so if the game's not playable with those two buttons, it's out.
Just to clarify: The player is not allowed to interact with or affect the game in any fashion save through inputs that go directly to buttonA() and buttonB(), neither of which can accept arguments or use input dialogs.
(Chat functions and commands of a purely administrative or social nature are the only exception to this rule, so long as they do not directly have any influence on gameplay and are not required to play the game as intended.)
Rule the Second:
Entries must feature some sort of multiplayer interaction. Multiple players playing separate games in parallel do not qualify--a player must be able to have some affect on other players, either directly or through a shared environment.
Rule the Belated Third:
Source code must be included for all entries to verify that the limits on input aren't being circumvented, but you don't have to distribute the source openly if you don't want to.
And... really, that's about it. All entries must be submitted to t_leftley@hotmail.com by February 28, 2007 (either mailing the game's source package or just sending a link to a hub entry or site where the source is available to download). Games will be judged in four categories:
-Presentation (general appearance and user-friendliness)
-Creativity (original and unique approaches to the design constraints)
-Depth (the game's variety and replay value)
-Overall Fun (general enjoyability and non-suckiness)
Assuming there are at least four participants (because it's not a real contest unless you can call someone the loser!): First place will win a BYOND membership for the recipient of their choice (include themselves) plus $10 Paypal, second place wins a BYOND membership plus $5, third place wins just a BYOND membership. Multiple entries per contestant are allowed, but only the best will qualify to place for a prize.
In addition to entries, if anyone wants to volunteer to help judge I'd be much obliged (theoretically, more judges means more of a commitment means less chance I'll get bored and wander off before the contest ends).
Posted by Leftley on Monday, January 22, 2007 07:23PM
- 41 comments
(link)
/
Keywords:
contest,
challenge,
twobutton
(Edited on Monday, February 12, 2007 08:05PM)

Login to post a comment.
#41 ATP Development:
When is the exact deadline? The post says by February 28th, do we have until the end of the day on the 28th?
Tuesday, February 27, 2007 01:29PM
#40 Jtgibson:
You know what the very worst part of this thing is? After going weeks thinking that this would be a waste of time, I came up with the perfect concept for a game precisely one week before the deadline, coincidentally the same week where I'll be off in Jasper, AB for my stepbrother's wedding!
Incoherent-but-vehement-expression-of-annoyance...
Wednesday, February 21, 2007 11:31AM
#39 Evi of au:
Yeah, I already sent you my entry the LAST time you had this contest, and disappeared. Check your email. ;-)
Wednesday, February 21, 2007 09:21AM
#38 Leftley:
No, "multiplayer" just means more than one in this context (supporting singleplayer in addition to multiplayer is fine, but the judging will be based on the multiplayer mode only.)
Airjoe, the official two buttons stand as A and B for reasons of nostalgia. If we were talking about games with more complex control schemes, having more convenient control layouts would be a higher priority, but while it's an unusual position I can't see it being too much of an inconvenience. You're still welcome to macro Z or S or whatever you like as a duplicate B-button, so long as you include the default A and B macros.
Thursday, February 15, 2007 10:51AM
#37 Airjoe:
Eh, can you change it from "a" and "b" to two keys closer together? I think that'd make for a better experience. the "A" key and the "B" key aren't too close. Perhaps something like "a" and "z"?
Thursday, February 15, 2007 09:34AM
#36 The Naked Ninja:
Question about the multiplayer features.
Does it have to be more than Two players at a time?
Monday, February 12, 2007 08:53PM
#35 Jtgibson:
D4RK3 54B3R wrote:
> You have two inputs that do the same thing? Then you don't get to use your second input verb.
Bzzt, wrong, but thanks for playing. ;-)
There are no provisions against allowing multiple inputs or control schemes, provided that there is no way of specifying additional data -- in essence, a different button is just a different way of pressing the original button.
Monday, February 12, 2007 08:31PM
#34 Bandock:
Team-Based as in designed to play in teams. Sorry for the confusion that I may have caused.
Monday, February 12, 2007 08:29PM
#33 D4RK3 54B3R:
Jtgibson wrote:
> Leftley wrote:
> > Spuzzum: Since client.East() and client.West() aren't allowed to do anything except call the original two verbs, that would be a quick way to create an infinite loop.
>
> Well, semantically, what's the difference? If buttonA() calls client.East() instead of client.East() calling buttonA(), what exactly have you lost or gained? =)
You have two inputs that do the same thing? Then you don't get to use your second input verb.
Monday, February 12, 2007 08:28PM
#32 Jtgibson:
Leftley wrote:
> Spuzzum: Since client.East() and client.West() aren't allowed to do anything except call the original two verbs, that would be a quick way to create an infinite loop.
Well, semantically, what's the difference? If buttonA() calls client.East() instead of client.East() calling buttonA(), what exactly have you lost or gained? =)
Monday, February 12, 2007 08:27PM
#31 Leftley:
DarkView: Sorry, no. The A and B procs can't take any outside input other than the initial function calls. (You can have outside input, but all it can ever do is call A or call B. Also remember that the game must still be fully playable using nothing but the default A and B macros in the script.)
I think I may have misworded the interaction clause, though; players do not really need to be able to affect each other directly.
Bandock: Do you mean "team-based" as in a game developed as a team effort, or as in a game designed to be played in teams? Either is fine, so long as it adheres to the other rules.
Dfourkthree: No. It just means you include the sample .dms and have double copies of each of your two buttons.
Spuzzum: Since client.East() and client.West() aren't allowed to do anything except call the original two verbs, that would be a quick way to create an infinite loop.
Monday, February 12, 2007 08:14PM
#30 Jtgibson:
IIRC, according to the rules, you can't omit the DMS. You're allowed to define those two buttons as convenience shortcuts, but the game still has to work if only the original contest commands are used instead (even if the purpose of the original two verbs is simply to call client.East() and client.West()).
Monday, February 12, 2007 08:11PM
#29 D4RK3 54B3R:
Just for clarification, if I override client.WEST() and client.EAST(), does that mean I need to/can omit the .dms from the environment when I submit?
Monday, February 12, 2007 06:43PM
#28 Bandock:
I have a question if you don't mind answering, is it okay to build a team-based game (that involves just using two-buttons)?
Sunday, February 11, 2007 09:40PM
#27 DarkView:
I might be able to rig something up. The multiplayer interaction rule is a bit of a pain though.
I've got a couple of ideas, but one of them needs a rule clarification.
Is it within the rules to make it so that A and B react differently depending on what the mouse pointer is over? I really doubt it, but without it I'm going to have to go with the plan B interface which is much slower and pretty much eliminates the idea.
Sunday, February 11, 2007 09:12PM
#26 Leftley:
Whoops! Sorry about that, Airjoe. There's nothing disqualifying a game made for the original contest from being entered now, although it would probably have to be updated to conform to the slightly stricter rules requirements.
Thursday, February 01, 2007 11:47PM
#25 Elation:
NO
Thursday, February 01, 2007 04:44PM
#24 Airjoe:
Airjoe wrote:
> Speaking of which, Leftley, can we enter a game intended for the original two-button, or only new games?
Any answer?
Thursday, February 01, 2007 04:28PM
#23 IainPeregrine:
I've already got my game planned out. It'll be like B17:FoG, only you'll control 8 planes, and... well, actually the game I have planned is nothing like that. Just to let you know in advance, I will be cheating in a most excellent way which you will enjoy.
> SO THERE HASE A SMARTASS?
This is getting classic. Where's Elation to enjoy this with me?
> this is not my kitty
Wednesday, January 24, 2007 06:12AM
#22 Leftley:
Using Loduwijk's KeyState library would be fine--so long as KeyDown() and KeyUp() do absolutely nothing except call either mob.buttonA() or mob.buttonB(), no arguments. Remember also that the game must still be playable with the plain macros.
Tuesday, January 23, 2007 09:31PM