Having the island be a magnet and the boat be made of metal made the sailing more fun, but I hated writing with a mouse. Well done.
Recent community posts
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.
I'm Mokesmoe. I participated in the first VARIETY MEGAJAM and I think I finished 4 games? I only remember 3 of them for sure.
I'm uploading all my games to the same page as I make them: https://mokesmoe.itch.io/variety-megajam-2020
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 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.
You could have a separate options file that the player could edit, which wouldn't break any rules but would be a bit awkward.
You could also just do it as even though it breaks the rules it's reasonable so whatever who cares.
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)
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.