Jan 23 2007, 6:16 pm
|
|
Jtgibson
 |
Ritchieee2, I'm going to preserve your wisdom for the ages. I'll engrave it in a stone tablet and bury it under the cornerstone of a random building. People will then wonder who Ritchieee was and marvel at how English had changed since then to include lower case and the spelling "has"!
|
Jtgibson wrote:
Ritchieee2, I'm going to preserve your wisdom for the ages. I'll engrave it in a stone tablet and bury it under the cornerstone of a random building. People will then wonder who Ritchieee was and marvel at how English had changed since then to include lower case and the spelling "has"! SO THERE HASE A SMARTASS? | |
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.
| |
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 | |
Airjoe wrote:
Speaking of which, Leftley, can we enter a game intended for the original two-button, or only new games? Any answer? | |
NO
| |
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.
| |
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. | |
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)?
| |
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?
| |
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()).
| |
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. | |
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? =) | |
Jtgibson wrote:
Leftley wrote: You have two inputs that do the same thing? Then you don't get to use your second input verb. | |
Team-Based as in designed to play in teams. Sorry for the confusion that I may have caused.
| |
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. | |
Question about the multiplayer features.
Does it have to be more than Two players at a time? | |
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"?
| |
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. | |
Yeah, I already sent you my entry the LAST time you had this contest, and disappeared. Check your email. ;-)
| |