I ended up taking longer than planned to have my second day but here it is!
My second game is Diagonal Tetris.
I had planned on making a more complex game with tetris as a base, but it ended up taking me all day just to make tetris, so I just swapped out the normal pieces for some weird ones and called it a day. Considering my plan would have made the game into a different genre, I might still be able to make my planned game on a different day using this one as a base.
The game is very difficult; my best score is 2. It would probably be a lot easier and more fun if I spent the time to make more powerful downwards kicks, but that would take playtesting I don't have the time for, considering I started adding these pieces half an hour ago.
Overall this game was kind of a failure, but I did end up putting out something playable so I guess I barely pass.
My first game is PARRY. I took an old versus multiplayer swordfighting prototype I made a while ago and turned it into a single player action game where you use your sword to deflect rockets.
I won't be taking my days consecutively so I'll see you all in a couple!
I set out at dawn in search of the mythical puddle. Hours of searching turns up naught but dew. But I won't give up; I can feel it just around the corner!
I think a good solution would be to pick a fixed number of AIs (say 3) before entering the match, and then in each of the random maps you can set up your army from just the AIs you brought with you.
This means you can still mix different AIs together and somewhat adapt to the map without being able to have a separate AI for each map.
No, I think that that separate program would be cheating as it's taking information from the game, violating the "1 bit of output" rule. However if you made a program that read the bit and converted it from morse code to text that wouldn't violate the rule.
Really the point I'm trying to argue here is that the mouse is not a source of output. What the mouse does affects the game, but what the game does has no bearing on the mouse. Information is only travelling one way: into the game. You keep saying the mouse will correspond to a game location, but I don't see how that matters. The game isn't telling you it treated the mouse position as an in-game location, you only know that because you know how the game works.This doesn't violate any rules of output because this info isn't coming from inside the game.
All of those points are true, but you aren't getting that precise feedback from the game, you are getting that feedback from your computer. And seeing the mouse doesn't even give you precise feedback about the game. Sure you know exactly what you are inputting, but you don't know what that's doing. You don't know that moving your mouse is moving an in-game character around at a 1:1 ratio. You don't know if clicking is doing something in that particular part of the screen. Sure you can infer that info from what the pixel is doing and what the manual told you about the game, but the player inferring what's going on from their limited knowledge is exactly what this jam is all about.
I think you are confusing feedback as a whole and feedback from the game. The feeling of a key being pressed down is a form of feedback telling the player they pressed a key. Seeing the mouse cursor move around the screen is a form of feedback telling the player where they are moving the mouse. Seeing the one pixel turn on or off is a form of feedback telling the player what is happening in the game. The first is feedback from your real life keyboard, the second is feedback from your computer's operating system, the third is feedback from the game. If you start disallowing forms of feedback that aren't from the game then where do you draw the line? What if my game uses the current size of the game window as input, requiring them to resize the window to beat it. Do I need to somehow make them not able to see the window's current size?
With the exception for audio and questions about similar things with vibration and such, I think there's a better way to rule it that allows all this. The main limitation I feel you are going for in the jam is "One bit of output", and the rules about how to display the screen are just to enforce that. I think it would be reasonable to have as many different outputs as you like as long as these outputs perfectly match which colour is on screen. In fact I don't even think having a screen at all should be mandatory. As long as there is only 1 bit of output since that's what the jam is really about, "the minimum (non-zero) feedback that a game could possibly have."
Some examples of 1-bit output that I feel should be allowed (as long as they all match if you use more than 1):
Visual: switch between 2 colours
Audio: on/off or two sounds
Vibration: on/off or two intensities.
CD drive: in/out (the time it takes to move would make this awkward though. If you rapidly switch you could make it stay at certain lengths; although this is still 1-bit, the drive itself converts the 1-bit into different info.)
Fullscreen: on/off (this is getting silly but you get the point)
Also, if you follow the interpretation of 1-bit of output this brings up some other points: Do the two states you switch between have to be represented by "blank" outputs? Like instead of switching between solid black and solid white could you switch between a picture of a cat and a map of Spain? Could you start playing music when the screen turns black, and pause it while the screen is white? There's no way these choices of states could give any more information than a manual or included file could.
The berlin rule is "Exploration and discovery". If we remove exploration but keep discovery we are still breaking the rule by not having both. It's a technicality but it keeps the challenge possible so I'll take it.
I don't see how the mouse cursor is a form of feedback. The game doesn't affect the the mouse cursor in any way, so it's not output from the game. And if just being able to see what your input is is feedback, does that mean I can't use keyboard keys as I can see if the key is pressed down or not by looking at it? The mouse cursor isn't a part of the game.
I think this gets more into the discussion of what exactly is input. If you consider the input here to be keystrokes then yes the text box is giving feedback, but if you consider the text box not part of the game, and the input to be the string passed from the text box to the game itself then it's fine.
Let's imagine a game where you have to type something in an arbitrary text file, then when you start the game (or press something or whatever) the game does stuff based on what text was in that file. I think this is very clearly not against the rules.
So you have an html page with a text entry, a frame, and a script that takes input from the text entry and draws one of the two colours on the frame. Is the "game" here the entire webpage or just the script? Is the text entry a part of the game, or just a part of the webpage external to the game? As long as the script doesn't affect the text entry in anyway, it's only form of output follows the rules of the jam.
We are required to use 1-bit graphics, but can we have a button that switches the palette? Obviously changing the palette due to stuff happening in-game would be a very direct breaking of the two colour rule, but I feel like if it's not attached to anything in-game it shouldn't break the spirit of the rule and it will help with accessibility.
(Another point is that it should be usable at all times during the game, so that it can't be used to check what state you are in.)
My second question is if I can use a save file. A save file that is human readable would technically be another source of output, which could be used to verify information about the game.
