[–] 1 point 1 year ago (3 children)

Fair enough. For future projects, I'd advice using keys - or even better enums - for this. Something like:

{
  "character": "duck",
  "emotion": "angry",
   "lang-key": "dialogue12-box15"
}

And then using lookup tables for the matching sprites and translations of the text.

  • source
  • parent
  • context
  • [–] [S] 1 point 1 year ago (4 children)

    How my dialogue box works is by having a “Dialogue” object that has three parameters: the text, the avatar, and the duration (longer dialogues wait for 5s, shorter could be 3s). And in each “conversation”, it’s pretty much looping through an array of these dialogue objects. So for every conversation there is in the game, I would have to change the dialogue objects of each one.

    And I don’t think I can map it to specific textures since I have multiple textures for different expressions (happy, shocked, angry, etc.) and am likely going to add more in the future so I can’t really hard code that in.

    It’s quite a bit of work for something that I find mostly unnecessary as all the characters introduce themselves when you meet them and there is a clear visual distinction (different shapes, colours, etc.) between all of them.

  • source
  • parent
  • context
  • [–] 1 point 1 year ago (5 children)

    Why would you need to change the dialogues? I assume you have some kind of string or enum already in place to display the proper image, couldn't you map these to a name, too?

    I wasn't thinking of literally writing 'Prometheus: Blabla' into the box, but a name tag below the image for example.

  • source
  • parent
  • context
  • [–] [S] 2 points 1 year ago (6 children)

    On adding the character names to the dialogue box, I don’t think I’ll do that. It’s too much work to change EVERY SINGLE dialogue and all the characters introduce themselves anyways. I think all the dialogue sprites are unique enough (Player is the duck, Prometheus is the human with golden hair, the winds are their own thing, the narrator is a donut thing, etc.)

  • source
  • parent
  • context
  • [–] 1 point 1 year ago (1 child)

    I don't use online services and gave up on local too. Models are too big (storage and download annoyance), GPU I have is a 1050Ti, also too hot for it right now.

    Not too keen on generating code especially if I couldn't recreate a simpler version... unless some general-use 1.5bit model could give advice on Godot and Nim-lang? Not putting too much hope in something like that though, especially due to niche and changing features.

  • source
  • parent
  • context
  • [–] 1 point 1 year ago* (last edited 1 year ago) (3 children)

    I am not sure I got the first issue, you can rotate each tile individually before placing them.

    That's the issue. I don't want a sideways room tile, and for pure cube tiles rotation is only an annoyance.

    based on any provided 2d shape would do that. We can find a way to make them fit in a grid with some roundings

    Sure. I guess this would work but I dislike how custom of a solution that seems to be for what I'd say is general usage.

    I just want bitwise calculation 1x1x1 to 8x8x8, so I can place down a chonky arena wall (8x8x2) in the same grid as a hallway (1x2x1) etc without risk of double-occupying cells. The only time I'd want that is for non-block models that are designed to occupy the same space (different types of wall decorations).

    Autotiling would be nice, but that's a step up. Similarly, cell types like on_wall, on_floor, and on_ceiling (and in_air/not_on_floor?) could (if their cell type is empty) allow autorotated placement (similar to the raycast placement added not long ago).

    These are the sorts of thing that would go in a proposal, possibly someone has already made these suggestions. If not, I am sure someone else would have better results writing it that myself. EDIT: proposal 1713

  • source
  • parent
  • context
  • [–] [S] 1 point 1 year ago* (4 children)

    I am not sure I got the first issue, you can rotate each tile individually before placing them.

    Re. the second issue, I wanted to try use hexagonal objects, those you can find in the packages at https://kaylousberg.itch.io/ and found some addons but they're too specific and bounded to Godot versions, a dyynamic one based on any provided 2d shape would do that. We can find a way to make them fit in a grid with some roundings

    Grid placement: yes, sometimes it's got some issue but that should be discussed in GitHub.

  • source
  • parent
  • context
  • [–] 1 point 1 year ago (5 children)

    What I'm missing here is the ability to restrict rotation. Some cell types you will only want 1 rotation, some not at all (or maybe some other type state flipping/change rather than a different cell type). Especially if this could be done via Blender node name.

    Also would be nice if multiple sizes of cells (like 1x2) were detected properly (both 1x2 gridmap or cells that can overlap are not ideal). I was already planning on smaller gridmap(s) for obstacles/room-decoration etc but I assume populated cells from other gridmaps is not something taken into account there either (unless you manually do something with a script).

    I have also had issues with grid placement (offset) I assume because of origin. I had it working with a nice placement scene but ran into an issue when I had to remake the gridmap (because data loss, and yes I probably did something different), I ended up fixing it by putting all tiles in the center instead. Really annoying to fix that when I need to import the .glb and then export an unchanged scene to the meshlib.

  • source
  • [–] 1 point 1 year ago* (8 children)

    Looking great! But I think you should add the name of each character into the text box, just like you've added it to your transcription.

    What font are you using? I've run into the time sink of creating my own, which probably was not worth it all things considered.

  • source
  • [–] 2 points 1 year ago

    Well, you can do the composition on the fly, by having the different sides of the diagonal on different tilemap layers, that'd make things easier, right?

    Check my thinking here, but you'll get a checkerboard pattern alternating diagonals, right? Then, I'd suggest

    • two layers, 'far' and 'near', for the tile-halves
    • a parent 'control' tilemap layer, with ugly editing tiles offset half a tile, (so it gives you a way to draw using the materials you care about) and code to render that into the fragment layers.

    It's how this works: https://github.com/aes/autotile3d and it would work.

    But then, there's this, I guess: https://youtu.be/dclc8w6JW7Y

  • source
  • [–] [S] 1 point 1 year ago

    Thank you. I thought that maybe there is some more 'official' way of such tile composition, but if not, then I will settle for some clever tile design to maximize reusability, at least for now. I don't want to overcomplicate things just yet.

  • source
  • parent
  • context
  • [–] 15 points 1 year ago*

    It's kind of annoying that this guy assumes pixel snapping is always a problem and never an intentional aesthetic choice. As if the devs of Blasphemous and the other titles he names either weren't aware of it or couldn't figure out how to get rid of it. Really though, this is a fairly basic, generally early consideration in any pixel art game with a free-floating camera, and I can guarantee you that the devs of Blasphemous preserved pixel snapping intentionally for one reason or another. It could even have been the case that the background layers didn't look as good if pixels of one layer were peeking halfway out from behind a layer in front of them, and so the devs might have even enforced pixel snapping to preserve layer alignment. For many devs making pixel art games the artistic constraints generate much of the inspiration, and pixel snapping is one such constraint.

  • source
  • [–] 4 points 1 year ago (1 child)

    First thought: Wow, that looks just like how Syndicate works.

    Second: that's a terrible idea. (at least in 2025)

    There's a tutorial (this one, I think https://youtu.be/i_XV78N7Zuo) on how to make a tool to compose your tiles.

    If you want to make a tile-space renderer, that's harder, but having done it, I can probably talk you through it. You need to look through tile-space diagonally to make in-front/behind work correctly. The way I'd do it today would probably be to 'shoot rays' from the view direction, into the tile-space, and record the first, or however many tile fragments necessary to completely obscure the view. Then, just* render from that look-up-table. (there's a fruity view(x, y) to tile(x, y, z) transform, and you still need to render transient objects at the correct depth. Also, scrolling/panning, do you only do that by tile, or do you also do sub-tile-fragment pan?)

    If you can get away with just stacking some tilemaps, do that instead, but ask if you need more.

  • source
  • view more: ‹ prev next ›