🤑 Indie game store🙌 Free games😂 Fun games😨 Horror games
👷 Game development🎨 Assets📚 Comics
🎉 Sales🎁 Bundles

Questions about technicalities.

A topic by mokesmoe created 1 year ago Views: 753 Replies: 21
Viewing posts 1 to 7
(+1)

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.

Host

obviously it's up to you to decide in the end, but I definitely feel that both a palette swapping function and save files are perfectly okay. palette swapping is a really nice courtesy to players who might prefer softer palettes, and save files aren't intended to be opened and read. I suppose if you're counting on or expecting the player reading the save files to help beat the game that's a bit against the spirit of the rules.

I know exactly what I want to make and can't wait to start. can I make personal prototypes before the start?

Why not? I do not know really if so, but there are many things I do not know, then I start before! I need to learn some stuff to make a little game. :)

Not that I think it should be disallowed, but... would it really "help with accessibility"? In what case would a black/white game be less/more accessible than a red/blue one? Or a pastel pink/pastel yellow one?

Host

some people find very high contrast colours (such as solid black and white) hard to look at, and I imagine this is made worse if the colours are also flashing.

Ah, and colors with less contrast to each other could remedy that. I see.

(Edited 1 time)

This is my first time in a jam and i'm full of doubts!

For example, this is my game fullscreen (HTML5), and that giant pixel will be the main way to give feedback to the player. That line below is an input text, where the player will submit the response.

My question is... Is everything ok? or should I make the pixel fullscreen (don't know where i'd put the input then).

Is that input allowed?

That text input is a form of extra feedback, isn't it? The rules also specifically include "this includes text popups[...]" and while this isn't a popup as such, it's still a form of text feedback.

Removed then, thanks!

Host(+1)

this is tough to answer, since the text input only provides feedback in the sense that it shows you what you've typed, and that's almost an accessibility issue (it punishes people who are not precise typers). I think I have to let people use their own judgement for cases which are not completely black or white, like this one.

Isn't pretty much everything an accessibility issue, then? After all, that the game only ever shows you one bit of information at a time is a huge accessibility problem.

The "precise typer" thing is more a difficulty than anything else, isn't it? Some people will of course find it harder to type without seeing the results than others. Plus, is there really a difference between you pressing the up arrow and you've got a character moving upwards, and you pressing the J key and a J appearing on screen? It's still a form of clear visual feedback on exactly what you pressed and what it did.

(+1)

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.

(Edited 1 time)

"Where do the input, output and player end or start?" I love when games turn filosophical.

I think the input is kind of a help too. Because you see if you typed wrong or correctly. That's why I've removed it and worked in a different idea.

I understand that not 'precise typers' will get lost if they think they typed the answer correctly. Should we help them? or not.

(Edited 3 times)

Well, I've already deleted that game anyway.

I had an epiphany this morning and have made a reaaally "a mazeing" thing =)

Thanks for your help!

(+1)

So I have been playing around with some difference ideas but my main question is i'd love some clarification. Now Im assuming in the spirit of the jam the two sounds or lack thereof have to be the same throughout like the colors. but my question is simply on the nature of tone. Typically we think of a single "tone" as a sound with a single sinusoidal waveform. These differ from notes on an like those of an instrument as these contain multiple overlapping tones, a single tone and its overtones(i think this is right is has been a while).

In short this makes listening to a single frequency tone really start to annoy most people, to the point where i have turned them off temporaraly. The same effect as two differing tones could be achieved with two notes. This would be a hell of a lot nicer for all players of the game and in my experience you tend to get annoyed by the repeating notes at about the same time as the flashing colours.

So really, can i use notes or do the "tones" have to be pure tones.

Host

that's a really good point. my musical knowledge is pretty lackluster so I used the term 'tone' with no idea how that would actually sound in a game, and so I'm not surprised to hear that it probably sounds pretty bad. I think using two notes (or one note and silence) is more than fine, but if others want to weigh in and agree or disagree they are encouraged to do so!

(+1)

I personally don't see anything wrong with this, as long as there are only one or two tones locked to the state of the pixel.

I got two questions:

  1. Can we please be allowed an intro screen to tell the player that the game is severely limited and to read the manual? I have a feeling I will encounter players who don't read before launching the game..
  2. Instead of a 1 bit display, since the concept is more about 1 bit of output, could I make the screen random static, or random static that flashes between two different kinds of static? This way it looks a bit more interesting while keeping with the idea behind the rules.

I'm fairly certain people who play bit jam games will be reading the descriptions on the itch.io pages and/or any readme files packed with the game.

Regaring the second question: as long as there are only two states, that should be fine, right? Daniel himself has stated a few times now that it's more about the bit than the pixel representation.

Host

1. that sounds fine, though if it's reasonable I'd try to make sure the intro screen isn't a part of the gameplay loop (e.g. a game over doesn't bring you back to the intro screen).

2. so long as the static is actually random then this is fine, too.

I'll make sure I don't loop back to the title (I was about to ask why, but I think I understand how that might be abused).

And I was thinking pre-generated randomness (so the same repeating pieces for the two states, still not conveying extra info), or yes, complete randomness with only a single variation making the difference between the two states.

Thanks!