Skip Navigation
InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)QU
quilan @lemmy.world
Posts 0
Comments 107
What demos did you play today? | DAY 3
  • I've been playing Heart of the Machine, and really enjoying it. It's a fascinating 4x ish in a future city, in a bit of an inversion of AI Wars (same developer). Before playing, I was merely intrigued, but now I'm excitedly awaiting where it goes. It was, however, initially difficult to figure out what to do. Perhaps more UX is going to be useful here.

  • Meet the woman who cannot forget
  • I'm pretty sure this is what Tim Rogers from Action Button Reviews has. His masterpiece Boku no Natsuyasumi review goes into a lot of detail about it. The end of part 5 had me literally sobbing in my chair for the first time in perhaps 20-some-odd years, followed immediately by a very confused laughing at a surprise hbomberguy appearance. I'd highly recommend watching it - it's quite the long form journey.

  • Should i continue programming?
  • As someone with decades in the industry, the amount of awful code out there is staggering. The code that I write is also often awful - at least the first time I'm exploring a new complex problem. Once you've done something once though, your second or third time writing it is typically a lot better.

    Typically my first pass ends up being a "get it done" pass. Explore the space with as best effort as you can to get something that works. Then identify what issues or problems you had with the process.

    Refactor your code, back up frequently! Prefer to keep things to generally one abstraction per function. This allows you to quickly look at a something and identify what it's doing, and to (with experience) sus out any potential bug areas. Make your code consistent in naming & code flow if you can. Test your code frequently.

    It's like playing a factory-genre game; your first pass is likely going to be some spaghetti monstrosity that quickly runs into scalability problems because you didn't know what you'd need ahead of time. With the knowledge of what pain points you had, you make a new base, maybe incorporate a bus setup and your scalability now goes much higher before it reaches problems. On your nth pass, your base is now a train based system that runs like clockwork and can do things you never thought possible before.

    Tl;dr: Everyone's first approach often sucks and eventually runs into problems. Understand what didn't work and learn from your mistakes. Do it again with these lessons in mind when you feel inclined (if you're experiencing scalability problems). Look at other code & learn from others. Keep writing as much as you can - programming is difficult and hard learned experience is often the best teacher.

  • Foundry Factory Builder Game
  • I've been really enjoying it, even in its limited state. Jetpacks are a total game changer, and I love that the fuel lasts a long time. There's still a few obvious QoL additions needed, especially with stuff like the cargo ships (gotta type the name in?!), but otherwise it's got a really strong foundation. Also, elevators are amazing; just realized last night that one cam connect wire to the cab. Really excited to see how the game develops in the future (traaaaaains).

  • These racing game players are 11 days into an exhausting race to climb a deadly tower
  • I don't play Trackmania at all, but it's been really fun to watch the daily edits that Wirtual's YouTube has been making for the live streams. Watching someone's heart rate shoot up ~40 bpm just after making a butt clenching jump is vicariously entertaining in the max. His video on Deep Dip 1 was also fantastic.

  • Professional Scientists of Lemmy: What is your field of study's, most complex unanswered question?
  • For the purposes of OPs problem (P v NP), it considers not particular solutions, but general algorithmic approaches. Thus, we consider things as either Hard (exponential time, by size of input), or Easy (only polynomial time, by size of input).

    A number of important problems fall into this general class of Hard problems: Sudoku, Traveling Salesman, Bin Packing, etc. These all have initial setups where solving them takes exponential time.

    On the other hand, as an example of an easy problem, consider sorting a list of numbers. It's really easy to determine if a lost is sorted, and it's always relatively fast/easy to sort the list, no matter what setup it had initially.