Design Contest: Two-Button Challenge (For Reals edition)

Page: 1 2 3
ID:26129
 
Jan 22 2007, 5:23 pm (Edited on Feb 12 2007, 6:05 pm)
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:

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 [email protected] 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).
Jan 22 2007, 5:48 pm
Pong.
Jan 22 2007, 5:52 pm
Great, I'm in. I have a question though, buttons used to start the game don't count do they?
Jan 22 2007, 6:23 pm
I'm definitely in this contest. An interesting concept.
Jan 22 2007, 6:37 pm
Worldweaver wrote:
Great, I'm in. I have a question though, buttons used to start the game don't count do they?

There's no reason you can't have say the buttonA() command do different things at different times; it seems it would be easy enough to just use the A + B buttons for basic game startup functions. And if for whatever reason it isn't, well... that's kind of the point!

For more complicated startup options: purely cosmetic functions like changing a player's color (assuming that you don't assign special properties to different colors) or changing the non-interactive background of a map could be done however you want without needing to go through buttonA() and buttonB(). Gameplay-relevant functions like choosing a character class or switching between map layouts would have to be fully accomplishable through buttonA() and buttonB() alone, however.
Jan 22 2007, 6:39 pm
What's the verdict on the mouse and clicking? It's not a button per say.
Jan 22 2007, 7:21 pm
I've already started on mine. ^_^
Jan 22 2007, 7:24 pm
I'm thinking of doing something.

Joining/starting games is going to be interesting, though. <_<. Ring menus are not fun to navigate.
Jan 22 2007, 7:42 pm
Worldweaver wrote:
What's the verdict on the mouse and clicking? It's not a button per say.

And since it is not, per se, a button, it clearly cannot be used in a contest to design a game that is controlled with two buttons and nothing else. (I edited the rules post with a clarification for Rule the First about this.)

In theory, you could put up HUD buttons for button A and button B; you could even have the buttons change icons depending on circumstances, or even have different buttons appear at different times, so long as the only statements to appear in their Click() procedure are either "usr.buttonA()" or "usr.buttonB()". Trying things like "usr.buttonA(src)" or "usr.buttonB(value)" is right out, since that can't be duplicated using only the two keyboard macros.

Come to mention it, it's going to be rather difficult to verify that an entry is playing within the rules without the source, so I added a rule that source must be included along with each entry.
Jan 22 2007, 8:24 pm
Out of curiosity, what games out there accepted only two buttons? Pong is the only one I can think of -- up or down. And even then, it was played on an arcade system that was designed to allow two push buttons plus four or eight directions for a joystick.

I could make a damned fine game with two buttons and four arrow keys, but two buttons and nothing else is way too extreme for me to ever consider.
Jan 22 2007, 8:46 pm
Clearly your childhood was sorely deprived in the area of cheapo handheld LCD games.

Granted, those quite frequently had more than 2 buttons anyhow. Not that that really has much to do with anything, since the challenge is not about what has been done so much as it is about what could be done.
Jan 22 2007, 8:55 pm
Anybody looking for any sort of inspiration, check out my entry to the original competition.

It's a little buggy and I don't think I have the source for it anymore, but it gives you an idea of how to handle joining/starting a game, etc.

Good luck! Maybe I'll get another game going here :)
Jan 23 2007, 2:05 am
ATP Development's Fallout was also originally for the two-button, so you can check that out as an example, too.

Speaking of which, Leftley, can we enter a game intended for the original two-button, or only new games?
Jan 23 2007, 2:31 am
I smell another Game in a Day coming with the results. >_>. Anyways, I suppose I might enter this one, since it's long term. Muahahha.
Jan 23 2007, 5:14 am
Hmm. I think I might be able to come up with something for this!
Jan 23 2007, 5:33 am
I wish there was some way of knowing if keys were pressed down or not. That way, 2 buttons could become more - like pressing B when A is already down, or vice versa.

You could use javascript for this (Loduwijk's library for this is available!) - would this be allowed, Leftley? Technically it'd still be two buttons.
Jan 23 2007, 11:41 am
This is a great idea. I may contribute if inspiration strikes me... otherwise I should really be working on my other stuff, heh.
Jan 23 2007, 11:55 am
SO THERE HASE A CONTEST?
Jan 23 2007, 11:56 am
HAS
Jan 23 2007, 5:56 pm
My initial experiments have been encouraging. We shall see!
Page: 1 2 3