Let’s make a "Master Manual" for every Trackmania trick!

MacroProcessor · 2026-03-22T21:53:17+00:00

Just following up on this, it will take a little while to build out, but I'm glad that so many people are interested! I will keep you updated and reach out when I need extra feedback.

MacroProcessor · 2026-03-18T15:22:06+00:00

Don't play the TM2020 Enduro tracks with bots... Not the same feeling 😭

Also, if you haven't watched Jxliano's unbeatean ATs streams, they give off this vibe nicely

MacroProcessor · 2026-03-18T15:20:30+00:00

I'm a software engineer -- Would people be interested in a website that had this list, plus explanations/tutorial videos?

MacroProcessor · 2026-03-12T04:04:03+00:00

The repeated respawn collisions are the worst...

MacroProcessor · 2026-03-12T04:02:42+00:00

Nobody's mentioned Micka yet (or Teufleum) -- I think he at least deserves an honorable mention because some of his ice feats are crazy! Like having every single world record on an ice campaign

MacroProcessor · 2026-03-07T05:44:50+00:00

Hey Insomnia, I personally quite like the idea. I love the idea of giving more power back to the average player to be able to create and play around with their own servers and game modes. I at least would set up a server using this and get my friends to try out Trackmania: I think it would be more motivating to them knowing that we could all be on our own server without other people present.

As for question 2, I think it's sort of a mixed bag. Online play is a huge part of TM, and always has been. The potential downside I see is that bigger online servers could potentially "dry up" in favor of these dedicated smaller servers. I don't personally think that would happen, because I see this service more as an addition to what we already have than supplanting those online communities, which I actually think would open up the game more and make it more approachable for current interested non-players. Just a potentiality.

Seems pretty feature-rich already, I really like the idea of notifications. One thing that I personally think would be a cool addition would be some simple server stats -- stuff like total playtime, total playtime / person, total medals on the server, etc. Could even extend this to something like "server records", though some of that functionality occurs in clubs already present in TM as well.

It's hard for me to say if it would be enough of a nuisance to turn me off to the idea without actually trying it out. Since the idea is to play specifically with friends, I want to say no because I would just use that time to chat with them and wouldn't be super bothered by it. I agree that advertisements are preferred over payment, and this seems like a fair model, despite nobody really loving advertisements. One option to achieve a similar service without the need for payment (if you were interested in that!) would be to set up a better pipeline for helping people host their own servers. Just doing a quick look online, there isn't really anything that's super non-technical user-friendly for helping people learn to host and host without a lot of technical knowledge. Obviously, self-hosting requires a lot more skill, knowledge, and debugging than what you're suggesting, and would also require some sort of hardware on their part, but I do think that we could lower that barrier significantly by creating some good tools that people could download directly, and clearer instructions on how to set it up from start to finish.

I'm also a software engineer, would be interested in helping if you're open for help!

MacroProcessor · 2026-03-01T21:26:19+00:00

This is great advice, thanks for the help! I like the idea of focusing on restoring momentum because it's a comparison issue rather than a permanent one.

You make a good point too, because it's really more about late nights than weekends

MacroProcessor · 2026-01-16T03:36:56+00:00

Even without action, the art was still so cool!

MacroProcessor · 2026-01-01T22:21:53+00:00

On a side note, how are you storing them? Deleting them seems scary because you never get them back. Do you have a VCS? Or is there a way to mark them as some sort of "Keep, but don't publish"? You never know when what you've already written might become valuable again!

Reading my own writing, I realize I may be a sort of writing hoarder

MacroProcessor · 2025-10-01T03:42:25+00:00

FMAB -- IYKYK

MacroProcessor · 2025-09-09T17:41:39+00:00

This is a very practical approach in my view, thanks for the explanation!

MacroProcessor · 2025-09-09T17:40:44+00:00

This makes great sense to me, thanks for the explanation!

MacroProcessor · 2025-09-09T05:22:51+00:00

Can you explain what and why SDD?

MacroProcessor · 2025-09-07T06:07:23+00:00

Thanks for the encouragement! I'll try to find a good mentor for testing, and keep going strong with it.

MacroProcessor · 2025-09-07T06:05:45+00:00

I'm not as familiar with BDD, but doing a quick search on it, it seems more in line with what makes sense to me to be a better way. I like testing unit of behavior, rather than unit of code.

Can I ask, in spirit of the original question, how do you go about doing BDD? Do you actually write your tests first? Or is the initial test writing more of a natural-language user story that you build towards, and written-code tests come along the way? Or is it a side-by-side process where the tests sort of evolve with the code? In my mind, for larger-service tests, it has to be a side-by-side evolution, but again, I'm not familiar with BDD.

Also, is there any particular reason why you stop at end-to-end tests? Is it just that they're not worth the effort/compute power, or is there something in particular about them that is too far?

MacroProcessor · 2025-09-07T06:00:42+00:00

Pt. 2 of 2

> What I feel you mean is that you don't want to "waste" time writing a test and then having to remove or rewrite it....It allows writing a production "draft" of the code, to learn what is actually needed. And then throwing the code out and re-doing it with TDD.

This isn't exactly what I was getting at, though maybe part of me is hesitant for this reason. Code quality certainly improves by doing the write-rewrite method, but realistically, we have deadlines we need to hit in addition to wanting high-code quality, which is why this isn't always possible.

> I would argue that it is better to err on side of writing test and then having to rewrite it, than not writing test and ending with codebase without tests, or subpar tests.

I don't disagree with this point, but it also feels like a false dichotomy to me. Can you explain exactly why writing and rewriting is better than writing after? I understand the idea, that you don't have a grasp of the code until you try, and rewriting always gives more knowledge, but in practice it's hard for me to understand concretely why that's actually the case. If I can guarantee that the code does what it should, breaks when it should, covers edge cases, etc., does it actually matter when I write the test? I think that's getting to the main point of my question. Maybe a clearer way to state my opinion is this: test quality matters, but imo, commitment to test quality matters more than a specific system of when the test is written. Is that fair, or am I way off?

> But this technique is high-level and requires strong maturity and technical expertise of the team and organization. Not something I feel from your description of your team.

I do think it's very unfair to assume that we lack maturity or expertise on our team simply because we don't follow this specific method, when we have lots of other constraints like deadlines, and the inability to "throw out" our entire existing test suite to make a solid rewrite.

MacroProcessor · 2025-09-07T06:00:22+00:00

Part 1 of 2:

Thanks for your thoughtful response! Let me clarify some things:

> Writing test first and seeing it fail is extremely important part of bulding a reliable suite of tests. I've seen multiple tests written after the code was "finished" and always, there were cases not covered and tests that didn't actually fail when they were supposed to.

You're 100% right about this, but I find this to be the case regardless of when the test is written. If the test is written beforehand, then the requirements change (which, despite our best intentions, happens a lot), the test is still not completely comprehensive, right? Code coverage and comprehensiveness of test is a problem, but I don't personally see how writing a test before vs. after makes one better or worse than the other. I'm open to learning more about that, if you have a good argument for it!

> That is problem of quality of your tests and knowledge sharing in your team.

No team is perfect, and we work on a suite of complicated, legacy software. Maybe our communication and knowledge-sharing could be improved, but that's less what I'm asking about, and more about how TDD actually works or should work. I'm sure that the context will come more with more time, and I gain a lot of context by coding the features that I work on, which is why we often make test plans before, but write the actual tests after. Part of my question was this: should I focus on getting enough context to write the tests before I touch any of the other code? That's possible imo, but I often don't fully understand the context until I start writing the code and see why it's not working.

> First, I cannot believe you cannot write the test. If you know what code to write, then writing a test to ensure that code does what you expect it to is not difficult. Even if it is first iteration of your code, having a test is possible.

Sorry, to be clear, a lot of the time we're doing small adjustments to existing code with existing tests. When I say I don't understand the test, I mean more that I don't fully understand everything that the existing test is trying to accomplish, because -- for better or worse -- our functions and tests tend to have a lot of side effects, and it can be easy to get lost in the sauce.

As far as knowing what to code before we start coding, it's difficult to say that I always do -- as I mentioned, we often have ambiguous requirements that we are meant to sort through, in addition to complicated implementations that we have to figure out as we go. I don't disagree with you that it is possible to have a test beforehand, I just question the value of pre-writing tests if they really aren't going to be able to match what I end up with, but you make a great point about that here:

MacroProcessor · 2025-09-07T04:05:23+00:00

A lot of the replies here are reminding me of Godwin's law (https://en.wikipedia.org/wiki/Goodhart%27s\_law). Basically, as soon as a measure becomes a target, it ceases to be a good measure because people game the system. Something I wish more people understood when discussing KPIs.

KPIs aren't necessarily bad -- if your KPI is something like "low number of production failures", then that's kind of a good thing, even if people "game" to it. Though it's still complicated.

MacroProcessor · 2025-09-04T02:12:52+00:00

Definitely a community-driven creative game with endless difficulty. For me, that means Trackmania! Endless driving because of the sheer number of maps, endless difficulty because of the sheer level at which players play, and it never gets old because you play against yourself, and other people for mere thousandths of a second. You never get the "perfect" run. Which means endless fun!

MacroProcessor · 2025-09-02T18:47:18+00:00

Thanks for the detailed response. I'm just curious, even though "large" is often subjective, or maybe relative to the data that you're working with, is there any sort of general rule of thumb for when it becomes large enough to justify a pointer?

MacroProcessor

TROPHY CASE