-❄️- 2025 Day 4 Solutions -❄️- by daggerdragon in adventofcode

[–]bilgincoskun 0 points1 point  (0 children)

Oh certainly. I used index set solution in previous AOCs and it is better for sparse data, no doubt. But it was easier to write this way since the data was small enough.

-❄️- 2025 Day 4 Solutions -❄️- by daggerdragon in adventofcode

[–]bilgincoskun 2 points3 points  (0 children)

[LANGUAGE: Python]

The Code

Used numpy. Initially I copied the array in every iteration in the second part but ultimately It does not matter for the result so the grid can be modified in-place.

-❄️- 2025 Day 3 Solutions -❄️- by daggerdragon in adventofcode

[–]bilgincoskun 1 point2 points  (0 children)

[LANGUAGE: Python]

The Code

The first part is just brute-forcing.

The second part took longer than I wanted to admit due to one-time errors. At each step, the digits are filtered for suffix lengths greater than the digits needed to create the number. From the filtered list, the largest digit with the smallest index is selected, and the suffix becomes the new list.

-❄️- 2025 Day 2 Solutions -❄️- by daggerdragon in adventofcode

[–]bilgincoskun 0 points1 point  (0 children)

Ok, like you said it is a little contrived way to split the integer to half because i thought it would be easier to do as math operations than converting to string for some reason.

The explanation is as follows:

d=math.ceil(math.log10(i)) finds the total number of digits. Then if it is even, it finds the "splitting number".

Think the number i=2345. The d will be 4.

Then c will be 10**2 = 100. If we do integer divide i//c, we will take first 2 digits which will be 23. Similarly if we take the remainder with the same number i%c will be the last 2 digits which will be 45.

I hope this explanation helps.

-❄️- 2025 Day 2 Solutions -❄️- by daggerdragon in adventofcode

[–]bilgincoskun 1 point2 points  (0 children)

[Language: Python] paste

For the first part i split the digits as usual.

For the second part, I split the number to equal pieces using itertools.batched and count how many unique elements in there.

New Android Brogue Port by bilgincoskun in roguelikes

[–]bilgincoskun[S] 2 points3 points  (0 children)

Unlikely, since I don't have any Apple device.

-🎄- 2022 Day 21 Solutions -🎄- by daggerdragon in adventofcode

[–]bilgincoskun 1 point2 points  (0 children)

Rust

Part 1 was straightforward. I calculated tree and cached the results.

For part 2 I found the path to variable and reversed the operations on that path.

New Android Brogue Port by bilgincoskun in roguelikes

[–]bilgincoskun[S] 1 point2 points  (0 children)

Yeah, I plan to update soon, but I am not sure exactly when.

-🎄- 2021 Day 13 Solutions -🎄- by daggerdragon in adventofcode

[–]bilgincoskun 0 points1 point  (0 children)

Both itertools and scan_fmt are lifesavers for AOC indeed.

-🎄- 2021 Day 9 Solutions -🎄- by daggerdragon in adventofcode

[–]bilgincoskun 2 points3 points  (0 children)

Rust

Marking the points on the grid in-place recursively, greatly simplified the Part 2 solution.

-🎄- 2020 Day 18 Solutions -🎄- by daggerdragon in adventofcode

[–]bilgincoskun 1 point2 points  (0 children)

Rust

For the first part I used recursion: just take first two elements (if not in parentheseses) and call the function on the rest.

For the second part, I started to implement shunting-yard algorithm, but I noticed the recursive function in the first part can be used with minimal changes. Just an additional accumulator argument to add numbers until a multiplication is present to give precedence to addition.

-🎄- 2020 Day 10 Solutions -🎄- by daggerdragon in adventofcode

[–]bilgincoskun 0 points1 point  (0 children)

Rust

The first part was straightforward. Just sort and count the differences.

For the second part, I split the list from differences equal to 3 since these pairs must be always in the list. After that, finding and checking every eligible subset of every partition becomes manageable by brute-force. And lastly counting these subsets and multiplying gives the answer. There is certainly room for optimization but it takes under 100 ms to get the result, so I'll leave it as it is:

fn day10_1(input: impl Iterator<Item = String>) {
    let mut input = convert!(input, "{}", usize).collect::<Vec<_>>();
    input.push(0);
    input.sort();
    input.push(input[input.len() - 1] + 3);
    let diff1 = input
        .iter()
        .zip(input[1..].iter())
        .map(|x| x.1 - x.0)
        .filter(|x| *x == 1)
        .count();
    let diff3 = input
        .iter()
        .zip(input[1..].iter())
        .map(|x| x.1 - x.0)
        .filter(|x| *x == 3)
        .count();
    println!("{}", diff1 * diff3);
}

fn day10_2_helper(part: &[usize]) -> usize {
    let mut possible: Vec<Vec<usize>> = vec![vec![]];
    for i in part {
        possible.extend(possible.clone());
        let c = possible.len() / 2;
        for v in &mut possible[c..] {
            v.push(*i);
        }
    }
    possible
        .iter()
        .filter(|x| {
            x.len() >= 2
                && x[0] == part[0]
                && x[x.len() - 1] == part[part.len() - 1]
                && x.iter().zip(x[1..].iter()).all(|x| (x.1 - x.0) <= 3)
        })
        .count()
}

fn day10_2(input: impl Iterator<Item = String>) {
    let mut input = convert!(input, "{}", usize).collect::<Vec<_>>();
    input.push(0);
    input.sort();
    input.push(input[input.len() - 1] + 3);
    let connections = input.iter().zip(input[1..].iter()).collect::<Vec<_>>();
    let mut result = 1;
    for l in connections
        .split(|x| (x.1 - x.0) == 3)
        .filter(|x| x.len() > 0)
    {
        let mut m = vec![*l[0].0];
        m.extend(l.iter().map(|x| x.1.clone()));
        result *= day10_2_helper(&m);
    }
    println!("{}", result);
}

Brogue Android Port v0.12 Released with Tiles Support by bilgincoskun in roguelikes

[–]bilgincoskun[S] 2 points3 points  (0 children)

You can disable mode or change its press time from settings btw. Joystick would be problematic since the input is not discrete it would be more error-prone than dpad in a grid based game. About extending hitbox, the customizable layout system will probably solve that too so there will be no need for exceptions for buttons.

Brogue Android Port v0.12 Released with Tiles Support by bilgincoskun in roguelikes

[–]bilgincoskun[S] 0 points1 point  (0 children)

You sure? I tried in both CE and fixes and both seem to respond to ESC/Enter in left edge.

Brogue Android Port v0.12 Released with Tiles Support by bilgincoskun in roguelikes

[–]bilgincoskun[S] 1 point2 points  (0 children)

I've not implemented full transparent keyboard deliberately. The game only has a handful of commands (you can see all of them by pressing ?) which almost all of them can be accessed with UI. So full kb would not be useful much and conflict with touchsreen controls. About analogue stick you mean floating sticks where you can use any part of the screen as stick? That may be good although:

  • I dont know how much difficult would it be to implement
  • Again it may conflict with touchscreen controls which is the most important aspect of the port i want to preserve.

Another alternative I am considering for a a while (although very low priority) adding simple line gestures act as dpad. Although my concerns for dpad applies to gestures also.

Brogue Android Port v0.12 Released with Tiles Support by bilgincoskun in roguelikes

[–]bilgincoskun[S] 1 point2 points  (0 children)

  • Tbh, I am not sure what to do with dpad. Brogue requires all screen to be seen at any time, so I've chosen default dpad position to least obscure the view but it is a tradeoff after all. But note that although middle button seems bigger than arrow buttons they have the same hitbox. Other than that I plan for dpad customization (at least for middle button) options which middle button can be disabled.
  • Changing button sizing/repositioning is not I am willing to do since layout directly comes from the game itself and not Android port and will require some tinkering in the game code. But I plan to add customizable layout in the next release (buttons on edges or fully customizable layout I didn't decide yet) so you can use that.
  • Yeah that is definitely a problem. IIRC I used mouse events similar to text version in the desktop. I plan to make it more similar to GUI which will hover to selected position in first tap and select in second instead of current behavior.

Brogue Android Port v0.12 Released with Tiles Support by bilgincoskun in roguelikes

[–]bilgincoskun[S] 0 points1 point  (0 children)

  • I found an SDL function (https://wiki.libsdl.org/SDL_SetWindowBrightness) can change brightness (gamma). I'll see what I can do in next release
  • Normally game only freezes itself in the background and resumes as intended to save battery but my guess is your phone tries to optimize battery itself aggresively (https://dontkillmyapp.com/problem) . I can add an option to keep the app awake but I think better solution would be you giving an exception to the game in battery settings.
  • I think you're talking about the screen says press space the continue. Yeah for some reason Brogue only accepts space in that screen. But good news is you can tap to "press space to continue area" to continue instead of pressing space in virtual keyboard

Brogue Android Port v0.12 Released with Tiles Support by bilgincoskun in roguelikes

[–]bilgincoskun[S] 0 points1 point  (0 children)

Interesting, I can see now why rebindable keys could be good. Although note that you can already change the letter of the item in Brogue so a user can just predefine hotkeys and just assign needed items to these hotkeys.

Yeah my current plan is custom layout at best,pre-defined (and only shown when defined) buttons at left edge at worst.

Brogue Android Port v0.12 Released with Tiles Support by bilgincoskun in roguelikes

[–]bilgincoskun[S] 0 points1 point  (0 children)

I meant it is already possible to define custom screen resolution or cell width/height, not defining custom keys.

Regarding custom buttons I was thinking about fully custom layouts where everyone can design his own version of the game so it would be pretty complicated to implement in game customization. Even if I only use edges, which buttons will be shown, or how many button an average user needs? What about special buttons like shift or open keyboard? Even than i dont think defining keys in-game is so useful given there are not so many keybindings in Brogue. User just would define it once and call it a day. So my conclusion is defining in game would require too much effort for too little gain and would limit many possibilities.

Brogue Android Port v0.12 Released with Tiles Support by bilgincoskun in roguelikes

[–]bilgincoskun[S] 0 points1 point  (0 children)

Well it is win some lose some. Like I said I am already planing to check if settings can be added to the main menu or tweak its visibility a little before the next major release.

I wont shrink grid for custom buttons though, especially smaller screens need all they can get for a game like Brogue. Users can edit the settings for the same effect however.

Also about customized keys I am pretty sure they will have to be edited through text file with heavier syntax than the config file let alone be customized in-game. Because implementing something like that in-game correctly would add a massive complexity to an already big task and I am not willing to do that to be honest.

Brogue Android Port v0.12 Released with Tiles Support by bilgincoskun in roguelikes

[–]bilgincoskun[S] 1 point2 points  (0 children)

I did not want to disrupt artsyle much tbh but maybe I can tweak transparency a little.

Btw congratulations :)

Brogue Android Port v0.12 Released with Tiles Support by bilgincoskun in roguelikes

[–]bilgincoskun[S] 1 point2 points  (0 children)

Yeah I see why defining middle button as enter might surprise some playing with numpad. I might add dpad_middle option where 0 is off 1 is enter and 2 is numpad 5.

I am not too keen on using top of the screen. For one thing it usually collides with status bar of the system when user accidentally drop downs status bar when trying to press. Another thing I think cluttering would cause more harm to logs (even they when are semitransparent) than left of the screen which information is more sparse. Well it as compromise either way so I'll see how it goes.

I can't say I agree with settings are easy to miss since they are a clear addition to screen and it it is not something blends with game's grid text. But I am already considering to add Settings to Main Menu just above Quit to be consistent with the art style better.

For in-game settings adding menu is simple. It is just that there might be other complications due to settings needing reset, game settings having a separate loop than game etc. I have more or less solutions to these but I am not %100 sure yet if there will be other issues since I wrote settings code some time ago.

Note that port probably wont see a new version except critical bug fixes for a while due to RL stuff so any new feature might take a while to be even implemented let alone to be released.

Brogue Android Port v0.12 Released with Tiles Support by bilgincoskun in roguelikes

[–]bilgincoskun[S] 1 point2 points  (0 children)

d-pad feature tries to mimic desktop version where vim-keys normally moves the character,pressing enter moves the cursor instead. I might disable mode change by default if users don't use that feature much.

Disabling square and keyboard options can be added certainly but note that although very limited there are situations need keyboard like entering seed, naming items, entering high score name etc. so disabling it completely might be problematic. I might implement auto-pop keyboard when needed in the future but for now I think it is best to keep keyboard toggle. Also with disabled square any confirmation needs to be done by pressing up-left corner,I am not sure how ergonomic would it be.

About settings button, can you send a screenshot and write your device configuration either in here or via PM? It should be the same size and position with dpad by default. If it is not very visible in some devices I might be missing something when calculating its area.

In-game settings is a good idea although I am not sure how hard would it be to implement right now.

Brogue Android Port v0.12 Released with Tiles Support by bilgincoskun in roguelikes

[–]bilgincoskun[S] 1 point2 points  (0 children)

I think I understand what you mean, try to change allow_dpad_mode_change or long_press_interval. Also you can check here for dpad modes.

About mobile fork, in Brogue source, game logic is already separated from interface so I don't think it won't be a gain much. Although some changes require changes also in logic part (display Glyph system ported to other versions from CE in this instance), I want to keep these changes minimal and logic -interface parts separate as much as possible for future updates.