• 1 Post
  • 12 Comments
Joined 10 months ago
cake
Cake day: April 12th, 2024

help-circle
  • I really like the general idea of the brackets as a starting point and a language for rule 0 discussions and match estimation. Where I’m playing, most of the pods are looking for PL 7 but as there is almost never a rule 0 conversation, I don’t really know what to expect (as we all know, every deck is a 7). But now, if for example I’m looking for a casual, lower powered pod with a precon, I can look for bracket 2 and already know what I shouldn’t encounter there and can refine the pre-game discussions accordingly.

    However, they need to modify the communication to make the central point of intent for these brackets more clear. I don’t know how many messages I’ve already read in the form of “my previous PL 8-9 deck is clearly a bracket 1 deck, because it fulfills the conditions” and I’ve already grown tired of them tbh. The blog post already explains rather well that the intention of the deck is the most important condition for bracket placement. But many people only look at graphics like these and thus they must be extended to make this more clear. Otherwise stompers will ruin lower bracket matches because “they can according to Gavin” and thus undermine the whole system.

    And while it is a great help that Moxfield etc. show bracket estimations if not manually set, this also distracts from the point of intention because they can only objectively rate the bullet point conditions. And even only looking at them, some can’t really be included as combos etc. are a very complicated thing to determine from data alone. It even ranks most current precons at bracket 1, although they are by definition intended to be in bracket 2.

    So tl;dr brackets have a potential to guide gathering of similar minded people/decks to good and “balanced” matches, but apparently people don’t read and don’t like to talk with each other, so they need to adjust their presentation material accordingly to make the central aspects more clear and visible.


  • I did not expect Duskmourn to play a part in this story at all. The thought of Valgavoth as a team principal with his followers as drivers/members is rather funny.

    There are quite a few plot threads and possible endings for this story. Maybe the Aetherspark really is unstable and whoever uses it ends up at the Edge of Eternities. Or Valgavoth gets it in his wings and begins to domesticate other planes to really become the current big bad. Or something completely unexpected happens.

    Whatever it is, I’m now even more interested in the setting than before.


  • As these precons are themed after the two returning planes (and IIRC Maro said in his blog that the “vanilla matters” of Muraganda is quite difficult to design for nowadays), it probably will be dependant on the set in question. I can see 5 precons for the Tarkir set, for example.

    But yeah, 2 per set is much more feasible and hopefully the main way forward. The only downside I see is that you can’t play a full precon pod with one set.


  • They MUST capitalize as much as possible on any weekend where Max/RB are not strong, such as this one.

    In a perfect world, Lando and Oscar would have worked together to defend from Ferrari and secure their 1-2 with Lando at the front. That would have been 17 points to relieve them a bit of this pressure of performing perfectly on all remaining weekends.

    Of course we don’t know if Charles/Ferrari would have won either way with their strategy. But Oscar gifting Charles a Lap 1 overtake on Lando and both McLarens straining their tyres racing against each other probably didn’t hurt Ferrari.

    Before today I seriously thought that Lando/McLaren had a chance at WDC, especially with Baku and Singapur still coming up. But as you said, they have shown again and again this season that they can’t execute the race weekends necessary for this to happen.



  • Do you have any sources about this “unfitness” of Rust for gamedev? From my experience many people have problems with the borrow checker due to habits they obtained coding in other languages. Due to the strict enforcement of ownership rules some things can’t be done exactly like in e.g. C++, but the language offers the tools to design and implement the software in a way to work with (not around!) the borrow checker (an example would be the discussion in another comment thread).

    So I’d be interested what special behavior occurs in gamedev that makes coding in Rust more difficult than for other software.

    Also, I really like that you’re considering users with lower spec machines for your game. However, have you run a profiler over your software to see where there is optimization potential? In cases like this, I often use the (maybe over-used) quote from Donald Knuth:

    We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

    Many people think that with this quote, no optimization whatsoever should be considered. However, humans are often bad predictors on where the real bottlenecks are.

    So yes, have some things in mind like e.g. algorithm performance for the expected input sizes. But in many cases, “optimization” done doesn’t impact the runtime at all but makes the code much more difficult to understand and often more “unsafe” due to potentially increasing UB or other issues.

    For this, a profiler helps to detect where your “critical 3%” are. And when you know them, then you can start optimization work to get big improvements. This also helps to direct your most likely limited effort to spend to the important parts of your game.





  • This seems like the most likely case. I could have sworn that I saw mentions to Arena elsewhere a few days ago, but now I can’t find anything else than this wiki page.

    And as far as I understand all previous starter kits did have such codes (this is my first one, so I can’t speak from experience 😅), so a copy-paste error makes sense.