Balkan RP — a FiveM community site built around one scroll-controlled video

Balkan RP is not a client business. It is my subdomain and our project, created without a client, and it says so on the site itself: in the corner of the screen there is a tile with the inscription DEMO, and terms of use in the first sentence say that the RP server under that name does not exist and that all the figures, rules and organizations shown are made up for display.

What is real is the audience. FiveM is a mod for GTA V that allows private servers, and roleplay communities from the Balkans are among the biggest users. Such a server has its own Discord, its own rules, its own factions, and its own donations — and almost always has a site that is either a forum template or a single in-game image with a Discord button.

The content that the site displays is therefore written as if it were real: whitelist reception, in-game economy, jobs, factions with hierarchy, heists, custom maps and donations that do not break the balance. The chapters are called Getting Started, About the Server, Character, Factions, Heists, Donations, and Join — exactly in the order in which a potential player asks: where am I, who am I, who am I with, what's going on, how much does it cost, how do I get in.

Why even make a demo for a job that no one ordered: because it was a training ground for a technique that is later used on real sites — an entire site driven by a single video, instead of a 3D scene in the browser.

The audience for a site like this is among the most visually demanding audiences: gamers who look at game graphics every day. A page with a stock photo and three cards means nothing to them. The first impression must be the city itself.

• Atmosphere before text — the visitor must see the movement through the city before reading any rules.
• To work on a weak device — part of the audience uses phones and computers that barely run the game itself. The site must not demand more from the device than the game itself.
• No heavy 3D — the first version of this site was a Three.js scene with just one module weighing in at 934 KB. It's too much for one homepage, and it looked like a 3D scene, not a city.
• One story, multiple modes — the same page must make sense even when the visitor is looking for less movement, saves data, or the script doesn't work at all.

The decision was to remove the 3D scene and replace it with a movie: one continuous flight through the city, filmed so that it can be scrolled. The camera moves forward without a single cut — from the waterfront and the pier, through the golden hour above the center, past the towers and across the square with the fountain, to the neon boulevard at dusk. The chapters alternate over it, and the color of the text follows the time of day in the frame.

Technically, this trades real-time rendering for a controlled media download. A three-dimensional scene consumes the processor every second the page is viewed; the video is downloaded once and then then decoded, and decoding is a job for which the device has a dedicated circuit. For content that is a predetermined camera path anyway, film is cheaper on every device and more visually convincing.

Sixteen seconds of continuous flight is not achieved in one go. Video generators from the image provide segments of several seconds, so the movie is assembled by chaining.

The procedure was the same for each segment: first, one static frame is generated in full format, motion is made from it, and an image (ffmpeg -sseof) is extracted from the last frame of that segment, which becomes the starting frame of the next one. The seams aren't visible because at the end of each segment, the camera cuts into something—the glass of a tower, the shadow of an overpass—so the splice occurs at a moment when the frame is already blacked out. It is not a trick over the material but a condition that is written in the request for generation.

Two details from the encoding are worth noting. The first: before the final pass, the material goes through a mild denoising (hqdn3d), which makes the file lighter by about a fifth — and the texture that is thus lost is restored by a CSS layer with grain over the video, which costs nothing measurable. Second: the movie is encoded so that each frame is independent (-g 1), because in this mode it is not played but rewinded, and rewinding to a non-key frame means decoding backwards to the nearest key frame.

An unpleasant surprise came from the generator billing side. The pre-generation price check reported one loan amount, but the actual per-segment charge was more than double. The rule that has been followed since then: after the first generation, check the balance on the account, and only then release the series. Preflight is not a promise.

The page does not have nested sections. It has one scene stuck to the top of the screen and a 1050vh high bar on widescreen (800vh on phone) that it scrolls through. The ratio is deliberately such that one second of film corresponds to about two-thirds of the scroll screen — slow enough to see the frame, fast enough not to get bored.

Chapters are absolutely positioned on the tape, at zero, then at 14, 28, 42, 57 and 71 percent. The last one, the one with the instructions for joining, is not on the percentage but is attached to the bottom of the tape. It's not a stylistic decision, but a fix: while it was also on the percentage, on lower screens it slipped below the end of the movie, so the visitor would exit the scene before even seeing the invitation. The last chapter grabs at the bottom, not the percentage—the little thing that you don't see until it breaks.

Each chapter carries its own mood — gold, dusk, neon, night — and the bold color of the supertitles, chips and numbers follow the arc of the film itself from day to night. When the text is over the video, the only thing that keeps it legible is that the color changes along with the frame below it; the fixed palette would disappear into the background halfway through the film.

On the side is a seven-point navigation that shows where you are in the story, topped by a thin progress bar. Both are derived from the same number — the current position in the movie — so they cannot diverge, which is the most common failure of sites that calculate progress and navigation separately.

The same site supports three presentation modes, selected when the page loads.

• Video scrubbing — on devices with a precise pointer, the video playhead follows the scroll position. Light smoothing prevents nervous movement, while a one-frame threshold avoids unnecessary updates.
• Frame sequence — on touch devices, 161 WebP frames totaling about 5 MB are loaded progressively and rendered to a canvas.
• Poster — when data saving or reduced motion is enabled, the video is not loaded. The result becomes a conventional scrolling page with a poster above the chapters.

The fallback mode also tests whether the concept is structurally sound. Chapter copy remains real text in the document, every chapter is a proper section with its own heading and identifier, and scripts control only the timed reveal. Without JavaScript, cards remain visible and the site loses the film rather than its content.

Frame loading is staged: the first twelve load immediately, followed by groups of eight during browser idle time. This area exposed the most costly bug in the mobile path. The idle-scheduling function expects its second argument to be a deadline-options object, but it had received a number. That caused an exception during initial load and stopped the entire script only on phones, because desktop never executed that branch. The desktop site looked complete while the mobile experience was broken. Since then, every device-specific path is tested on the target device rather than inferred from desktop behavior.

The whole site is three files that are maintained: one HTML, one CSS of ten kilobytes and one JavaScript of five. No frames, no packages, no assembly steps. What opens in the editor is exactly what is served, so the change does not depend on whether the tool used to compile the site is still maintained.

Movie files have a version in their name (hero-scrub-a1.mp4, frames-a1/, poster-a1.jpg) and are cached by the server for a year as immutable. That's the only way long cache and future changes can coexist: when a movie is replaced, the name changes, not the content at the same address. In-place video overwriting is invisible — neither the author nor the visitor sees the new encoding, so it's concluded that the fix doesn't work, even though it does.

The movie comes in two sizes: full for wide screens, about 20 MB, and narrower for small ones, about 9.5 MB. The server also responds to partial requests, so rewinding does not wait for the entire file. HTML is deliberately not cached, because it is the only file that can be changed at the same address.

Foremost is nginx with a full set of security headers and content policy, denying access to hidden files and backups, and permanently redirecting from HTTP to HTTPS. The certificate is issued by Let’s Encrypt, as well as for the rest of the server.

One local detail that is remembered only when it hurts: the homepage of this site is locked at the file system level. Until it's unlocked, it can't be overwritten — neither by unzipping the archive nor by simple copying — and the error message doesn't say why. The convention is useful until it is forgotten, so it is written with the project itself.

The first thing you see is not a video but a poster — a single frame of about 150 KB, which is loaded with the highest priority and covers the entire screen. The video sits above it and only appears when there is enough data to display, with a short fade. That's why the visitor never sees a black screen, and the element that makes up the first display of the page is a picture, not a movie.

The video itself is not touched until it is decided which mode applies. The document states without a source and with the instruction that nothing be downloaded in advance; the source assigns it a script, and only the one selected by scrub. The full version is never requested on the phone, and none is requested in poster mode.

The grain and vignette layer over the movie is one SVG noise and one gradient — both without any pixels from the grid, and both are rendered once, not per frame. It's what gives it the feel of a movie instead of a game footage impression, and it costs nothing measurable. The title on the first screen is plain text with an overlay, not an image, so it stays sharp at any resolution and can be read aloud.

Fonts are loaded from Google services and that's the only thing on the page that comes from outside. For a real client site they would be local; here they remain as they are, and that is written in the privacy policy instead of being silent.

The engine that drives this movie rewinds the video — it writes a new time to it at each scrolling frame. It's a common recipe and it works here, but later, on another site from the same family, it was measured as not being the best. Each entry in video time is a separate jump: the browser empties the decoding pipe, goes to the requested frame and displays it, and entries that arrive during the jump are swallowed. Through a quick transition, instead of all the frames, only a part of them is displayed, and the eye reads it like a slideshow, not like a movie.

A better solution is to play the video through the transition, and let the playback speed be controlled according to how far the scroll has progressed and how far there is to the goal. Rewinding remains only for the back jump and landing on the end. The new encoding goes along with it, because the recipe "every frame is key" pushes the record into a format that no graphics card can decode hardware — so everything falls on the processor, exactly where the most savings were made.

The same applies to the mode selection. Here, the phone is recognized by being touched, so it receives a sequence of images. It is more correct to ask the device what it can play, not how it is touched: today's phone handles real video beautifully, and the image sequence gives it fewer frames than it would have with film. The sequence remains meaningful as a backup when the video goes down, not as the main route.

Both are known, measured and recorded, and both require a new film encoding and a new version label in filenames. For a non-client, non-indexed site, that's a queued item — but it's written here, because a silent find isn't a find.

The extension of the film itself is also planned: the third segment, the night finale with the neon boulevard and the ascent towards the silhouette of the city. The source material and the encoding script are ready on the server, only waiting for the generation and extension of the tape so that the new meter of film has something to screw through.

A demo that looks like a real site can easily become a fake. That's why the label is visible on every page, and not hidden in the footer: a small tile with the inscription DEMO stands fixed in the corner of the screen, both on the homepage and on the legal page, and does not move when scrolling.

The site is intentionally out of search. The document prohibits indexing, and robots.txt prohibits browsing the entire site. The consequence is that there is no structured data on it: a schema that represents a fictional organization as a real one is exactly what should not be done, so there is none. In a real client it would be the first layer to be added, here it is the first to be omitted.

Privacy Policy and conditions have not been copied from anyone. They write what really happens: that there are no forms, that no personal data is collected, that the server keeps standard records of access and how long it keeps them, and that fonts are pulled from someone else's service. The conditions in the first sentence say that the server does not exist and that the join, login and donate buttons do not start any process.

Of little things that are rarely done: there is a skip link at the top of the page that goes straight to the join chapter, the chapters are arranged in the correct title hierarchy, and the video is taken out of the keyboard row and marked as decoration, because there is nothing to do with it with the keys. The address to connect to the server is copied with one click, with a short confirmation instead of a silent action. At the footer is the year and the author, without any trace of the tool used to create the site.

For someone running a roleplay community, the bottom line is this: a site that looks like a game-server trailer doesn't require the visitor to have a powerful machine, and its content is plain text that changes in a single file. The server name, number of slots, rules and login steps are sentences, not images — so they change in a minute and don't need to be redrawn when something on the server changes.

For anyone else, this is a demonstration exercise for a technique that has nothing to do with gaming. The same engine can drive a home, mobile bar, or product presentation — anywhere there's one continuous motion that tells a story automatically, a video is lighter and more convincing than a browser-rendered 3D scene in a browser, and measurably lighter for a weaker device.

What has been carried over from this project is the method, not the code: the video is produced in segments and chained through the last frame; the mode is selected according to the capabilities of the device, not its type; file names carry the version, because a long cache is otherwise a trap for whoever makes the change; the final chapter aligns with the end of the sequence; and the page must remain legible even when the movie is not shown at all.

The site has been live since July 2026 at rp.svilenkovic.rs and is there as a demo — without a client and without an actual game server behind it. If the concept gains a client, the content is already written, and the content structure is ready to be adapted.