• 1 Post
  • 24 Comments
Joined 1 year ago
cake
Cake day: June 11th, 2023

help-circle

  • Well that’s an interesting take! What aspects are you opposed to?

    IANAL but I did read through the patents agreement that you linked. It basically says do whatever you want with Go as long as it different infringe on Google patents. Which is pretty much backed by US law anyways and I assume other countries as well. The sketchy part is that your license is revoked as soon as they file a lawsuit rather than win it. Honestly, I’d be surprised if Google ever used this in a legal dispute because there would be a huge community backlash.

    That also only applies to Go developers. You would only be a user for a tool written on Go. How does your using a tool written in Go translate to support for Google and its bad practices? Do you not use any software written in Go?

    Sorry if this is sounding argumentative! I’m generally a big fan of Go and definitely opposed to Google and using its products. This is a topic that I haven’t considered before so my questions represent my sincere curiosity.








  • Yes, unity costs money to develop and a fee is reasonable. But I think the are a few risks with this model.

    How do they track installations? Metrics from steam and other platforms? Connecting to a license server at install time? Or maybe at runtime? I don’t know the answers but they all seem to have implications for users regarding privacy and/or offline gaming.

    It’s also a variable fee to game developers. A single user can install a game on multiple devices despite buying the game once. Similarly, a game can be installed repeatedly over time. This is a financial risk to game development companies. I could see them mitigating this risk in several ways. First, they can pass the fee to the end user. So every install costs the user $0.20. Secondly, they can limit the number of installs per user. You want to install more than 5 times ever? Buy the game again! Thirdly, they could simply shut down the download service after a certain amount of time, making new installations impossible. None of this is good for a gamers.

    And what happens to games made by companies that shut down entirely? Today, games remain available through steam, etc. But with this new pricing model, Unity based games will continue to cost money over time. Who pays the bill after the company is gone? This reminds me of Worlds Adrift, a game that used a licensed library. When the developer company shutdown, they were unable to release their server source code because the third party couldn’t can’t send bills to the open source community. Thus, the servers were destroyed and running the client today (still vailable via steam!) just gives the user an error message about license issues or something. Users paid for a game that they are now unable to use.







  • Well I am only able to offer some lame answers. Mostly because quality answers would take a very long time to construct. But here you go

    • This really depends on what your building. Maybe find a n established project that’s similar to yours and mimick its structure. There are many patterns available.
    • Google it, try it, repeat. Python is loaded with “syntactic sugar”. That leaves you with lots of options for how to structure and format your code. Which leads to many varying opinions. This is extra noteworthy for larger dev teams because of varying experience levels. You might be able to write a short, clear but of code that some devs won’t understand. Lots of good options leads to a lack of clear choices. Opinions will vary.
    • Again, lots of options. I like using the Black formatter because it gives you very few options and forces you into some style choices. Even the ones I don’t like 🙂
    • Oh boy. Google it. Extensively. Google it for several hours and then read some source code. Do this every time you start a new project 😂.
    • I don’t have a specific tutorial unfortunately. But the idea is that your “pyenv” directory will contain the packages your project depends on. Maybe the python installation too. And every one of these items will be a specific version. Because this is all installed in a single directory for each project, you can easily have different projects use and rely on different versions of the same dependency. This avoids all sorts of problems where you accidentally build and test locally using the wrong package version. I think a common practice is to create the “env” folder in the root of your git repo. And add “env/” to your gut ignore. Don’t trust that exact syntax btw 😅


  • Create a new branch on your fork. You need it to be synced with the other fork so there are a few extra tricky steps. On your new branch, you need to delete the latest commits that aren’t merged yet so that it matches the original repo. Then add a remote for the other fork and pull. Now you can build against the other fork and submit a PR to it.

    git checkout -b even-cooler-stuff
    # Remove the last 8 commits. Change this number as needed. Increasing it "too high" is just fine 
    git reset HEAD~8 --hard
    git remote add even-cooler-stuff https://github.com/more-of-url/even-cooler-stuff
    git pull even-cooler-stuff
    

    You should now have a branch that matches the other fork. Make your changes, commit, and push normally. When you build the PR, you want to merge into the other fork.

    Disclaimer: I wrote this on my phone and from memory. There are probably typos and possibly other mistakes. Good luck!