Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add custom menu - to add custom grids #10

Closed
wants to merge 26 commits into from

Conversation

@BKSpurgeon
Copy link
Contributor

BKSpurgeon commented Jan 13, 2020

There is a performance issue I have noticed.

  • set the x and y to maximum values. e.g. 20 and 20.
  • set the bomb count to something very low: e.g. 1
  • when the game is started it takes an inordinately long time to get going.
BKSpurgeon added 8 commits Jan 1, 2020
Fix: add a negative sign if the number of bombs placed are greater than then number existing

Fix: minesweeper.png to better display positive and negative signs

Fix:    display of negative signs

Formatting

Fix: to use String.toList

formatting
WIP: add fields for custom grid types

WIP: add custom menu types, working through the compiler errors

WIP: trying to display the custom menu

WIP: trying to work out why it is not working!?!

WIP: displaying all the input fields
src/Main.elm Outdated Show resolved Hide resolved
src/Main.elm Outdated Show resolved Hide resolved
@brandly

This comment has been minimized.

Copy link
Owner

brandly commented Jan 14, 2020

good find on the slow performance! haven't dug into it yet.

i think some of this structure could improve. it's late here and i'm tired... i can lay out more of my thoughts tomorrow.

@BKSpurgeon

This comment has been minimized.

Copy link
Contributor Author

BKSpurgeon commented Jan 14, 2020

good find on the slow performance! haven't dug into it yet.

i think some of this structure could improve. it's late here and i'm tired... i can lay out more of my thoughts tomorrow.

I suspect the problem might lie somewhere here:

floodCells cells grid =

(TBH there is still much I don't understand when attempting to read the code. ) I might have a closer look at the Grid.floodcells method tomz.

chrs

src/Main.elm Outdated Show resolved Hide resolved
src/Main.elm Outdated Show resolved Hide resolved
src/Main.elm Outdated Show resolved Hide resolved
@brandly

This comment has been minimized.

Copy link
Owner

brandly commented Jan 14, 2020

in terms of defining the general goal for this menu, here's a nice screenshot:

in this menu, you can click the radio buttons to switch between options, but then you have to click "ok" to confirm. you could also "cancel" to just close the menu and forget about it.

the three Ints are always visible, regardless of the current selection. it looks like height/width/mines support some pretty large numbers.

when you open the menu, the current level is pre-selected for you. this kinda works in Elm, but currently, it doesn't pre-select anything if you're on Custom.

can we aim for all this? does anything seem unattainable?

@BKSpurgeon

This comment has been minimized.

Copy link
Contributor Author

BKSpurgeon commented Jan 14, 2020

in this menu, you can click the radio buttons to switch between options, but then you have to click "ok" to confirm. you could also "cancel" to just close the menu and forget about it.

  • A cancel button can be added.
  • Re: the ok button. I suspect that the windows makers of minesweeper added an ok button to handle the situation where users wish to toggle multiple things: i.e. to display animations, or to play sounds and to then click ok when they're done, otherwise it might be burdeonsome for the user if they have to reopen the menu multiple times to toggle multiple settings. in our case, the only situation where users will want to play around with multiple fields is if they are toggling a custom difficulty. I propose to leave the ok button for this situation, but to add the cancel button to allow users to play as they were before: because the user might select "beginner" and then would have the additional burden of clicking ok, rather than having the game start immediately: which is likely what the user wants. I suppose, if the results were more drastic: i.e. records were being deleted, then an ok button definitely has merit. my two cents: what do you think of the merits/demerits of this approach.

when you open the menu, the current level is pre-selected for you. this kinda works in Elm, but currently, it doesn't pre-select anything if you're on Custom.

I have added the above defaults in windows: 9 * 9 * 10.

The rest is just adding the text / labels + css.

the three Ints are always visible, regardless of the current selection. it looks like height/width/mines support some pretty large numbers.

The is a performance problem somewhere, so when large numbers are added and the bomb count is low, my browser basically crashes. can easily added support for large numbers though.

Question re: deubbing:
I am having trouble debugging this using the elm debugger. right now i am using elm reactor and simply refreshing. elm live is not delivering the elm debugger to me. am wondering how you are debugging on your end?

can we aim for all this? does anything seem unattainable?

can be done, more or less. it's just a matter of css, and i gotta have a look at that performance issue.

pls LMK your thoughts.

rgds

Ben

@brandly

This comment has been minimized.

Copy link
Owner

brandly commented Jan 15, 2020

$ npm run build -- --debug

will build a JS file that includes dev tools. then, open dist/index.html.

@brandly

This comment has been minimized.

Copy link
Owner

brandly commented Jan 15, 2020

makers of minesweeper added an ok button to handle the situation where users wish to toggle multiple things

i guess i like opening the door to supporting other settings. in general, settings menus tend to have ok/cancel buttons as an explicit step to dismiss the menu. i also think it'll simplify some code, since we'll be dispatching the same Msg constructor for each radio button.

the three Ints are always visible, regardless of the current selection.

it doesn't look very smooth right now when the inputs jump in. disabling the input, instead of removing them, when a non-custom difficulty is selected will make this less jarring. (i think it'll also make some of this code more straight-forward 😄)

i can help with the styles once all the functionality is settled. i have an idea of how this code might look, but i don't want to rob you of figuring it out lol. let me know if i should explain further

src/Main.elm Show resolved Hide resolved
src/Main.elm Show resolved Hide resolved
src/Main.elm Outdated Show resolved Hide resolved
src/Main.elm Outdated Show resolved Hide resolved
@BKSpurgeon

This comment has been minimized.

Copy link
Contributor Author

BKSpurgeon commented Jan 16, 2020

$ npm run build -- --debug

will build a JS file that includes dev tools. then, open dist/index.html.

Excellent. The debugger now comes up, but for some reason the images etc. are missing. Any ideas?

@brandly

This comment has been minimized.

Copy link
Owner

brandly commented Jan 16, 2020

Do “npm run static” to copy images and stuff over

@BKSpurgeon

This comment has been minimized.

Copy link
Contributor Author

BKSpurgeon commented Jan 16, 2020

(Above commits are simply work in progress WIP - it's a little buggy and inchoate atm). will notify when it progresses.

@BKSpurgeon

This comment has been minimized.

Copy link
Contributor Author

BKSpurgeon commented Jan 19, 2020

Try out the functionality of the latest push:

auto-updates-in-field

@BKSpurgeon BKSpurgeon closed this Jan 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.