welcome to the yap zone
if you're reading this, you found the least serious corner of my site.
yapspace is where i dump thoughts, notes, half-baked ideas, and whatever else i feel like writing down. no schedule, no agenda, no format rules.
not a blog. not a newsletter. just... yapping.
expect posts about:
- games — what i'm playing, what i think about it, what broke me
- arma 3 — mission design, SQF scripting, the eternal war against engine bugs
- code — things i built, things that blew up, lessons learned the hard way
- communities — running them, breaking them, fixing them
- random — shower thoughts that somehow ended up here
might post daily. might post once a year. no promises.
"this is the yap zone and i will not be taking questions"
things i wish someone told me about SQF earlier
after years of writing arma 3 mission scripts, here's the accumulated wisdom i keep going back to.
locality is everything
the single most common mistake i made early on — and still see constantly — is ignoring locality. arma runs code on different machines. the server owns objects. clients own their own players. if you spawn a vehicle on the server and try to attach a script to it from a client, you're going to have a weird, inconsistent, infuriating time.
always ask yourself: who runs this code, and do they have authority over the thing this code touches?
waitUntil is not free
waitUntil { condition } loops and checks every frame. if your condition is expensive (iterating all units, checking distances, etc.), it will chew through performance. use sleep inside your loops, or better, use event handlers where the engine can tell you something changed instead of you constantly asking.
JIP matters more than you think
players joining in progress (JIP) are a constant headache. broadcast your mission state properly. anything that was set via setVariable on objects should use the broadcast parameter. anything spawned after mission start needs to handle the case of a JIP player who missed the original setup.
keep your scripts flat
deeply nested spaghetti is the default arma 3 scripting style and it's awful to debug. i started enforcing a rule: if a function is longer than ~60 lines, something probably should be extracted. it makes life significantly easier six months later when you're staring at a crash you don't remember writing.
these are the four lessons that have saved me the most time. everything else is just variations of them.
how ffredyk.cz came together
i've rebuilt my personal site probably five or six times over the years. this version finally feels like me.
the brief
i wanted something that actually represents how i think about aesthetics — dark, spatial, a bit sci-fi, interactive without being annoying. not a template. not a portfolio generator. something handcrafted.
the stack
- ASP.NET Core MVC on .NET 10 — i write C# every day, felt right to use it here too
- Markdig for rendering markdown — used for portfolio entries and this blog
- vanilla JS — no frameworks on the frontend. canvas APIs for all the visual effects
- CSS custom properties everywhere — they make theming per-page surprisingly clean
the visual system
each page has its own canvas-based background. the home page has the starfield + hex grid + noise + beam system. about has drifting node cards with connection lines. socials has the solar system orbit thing.
the idea was: same space aesthetic, different interactive metaphor on each page.
what i'd do differently
honestly not much yet — i'm still adding pages. yapspace is the newest. the blog-as-hexgrid concept came from staring at the home page hex canvas and thinking "wait, what if those were clickable."
so here we are.
kkk
the ones that actually changed how i think
not a top 10. not ranked. just the games that left a mark.
SA-MP — where it all started. san andreas multiplayer. i was a teenager writing PAWN scripts for a gamemode i was running. it was bad code. it worked. that gap between "bad code" and "it works" is where i lived for years and it taught me more about debugging than any course.
Arma 3 — the game i've probably spent the most total hours in if you count all the time in the editor. mission design in arma is a completely different discipline from normal game design. the tools are hostile, the documentation is sparse, and the community has somehow produced incredible things anyway. it gave me a deep respect for people who make tools and content for other people to use.
Minecraft — specifically the period when i was running a server and managing a community around it. i learned that the hard part of online spaces isn't the technical infrastructure — it's people. always people.
Cyberpunk 2077 (post-patch) — i played it late, after the fixes. phenomenal worldbuilding. Night City feels more alive than most "live service" games. it made me want to build more things.
the pattern i notice looking back: the games that shaped me most were the ones where the meta-game — the community, the modding, the running of things — was as compelling as the game itself.
what i've learned from running gaming communities
i've been founding, running, or helping run gaming communities since my early teens. here's what actually matters.
the first 50 members are everything
the culture of a community is almost entirely set by the first group of people who join and stay. if you let toxic behavior slide early because "we need members," you're importing that toxicity into the culture permanently. it is extremely hard to change later.
be selective. be patient. build slowly.
activity ≠ health
a Discord server with 500 messages a day can be miserable. a community with 20 active people who genuinely like each other can be the best online space you've ever been part of. don't optimize for numbers.
someone always does the work
communities don't run themselves. someone moderates. someone organizes events. someone answers the same question for the hundredth time. if that someone is always you, you'll burn out. the hardest skill is finding and empowering people who want to help — and then actually trusting them.
when to let go
i've shut down two communities that i built from scratch. it hurt both times. but running something past its natural lifespan because you're attached to it is worse for everyone involved than ending it well.
the best community i've ever been part of was small, chaotic, impossible to explain to outsiders, and ended abruptly. i think about it more than any of the "successful" ones.