Vojtěch Hronek

Software Engineer. Czech Republic.

Ten years of shipped work, since 2016. Over five million downloads of Minecraft content published as Nogard. A chess engine inside a runtime with no JIT and a hard budget per tick, its move generator verified to 84 billion nodes. A web product serving a few thousand people a day. Resource packs and conversion pipelines carrying a commercial server across two engines that share no code, with CDN-backed delivery on the Bedrock side. Thirty-four commits merged into open source. A computer on breadboard around a Z80, because I wanted to know what was underneath.

All of it alongside secondary school, a bachelor's, and the master's I'm finishing now.

Selected work

Hoplite

Resource Pack Manager. 2023 to now.

Hoplite is a commercial Minecraft server. I own the resource packs on both editions of the game (Java and Bedrock), plus the tooling and pipelines around them, and the plugin work that depends on them.

The Java resource pack, 2023 to now. I put everything a player sees into the game: models and textures, item icons, GUIs, progress bars. It reaches me as a file from an artist, and my job is to make it work in Minecraft and look the way it was drawn. Sometimes it's a kind of asset the pack hasn't carried before, with no established way to do it, and then the implementation is my call. That means tuning how an item sits in the hand and on screen, configuring whatever runs through ModelEngine, and fixing or drawing pixel art myself when something needs it. Getting a texture to render sharp usually means rebuilding it at a resolution that lands on an integer scale, rather than fighting the one it arrived at. That was the bulk of the work for three years. Since mid-2026 the repetitive end of it runs through automation, and what reaches me is the edge cases and anything that needs a judgement call about how something should look.

The second job is keeping it all working. Every Minecraft release since 2023 has needed the pack brought forward: read the changelog, find what broke anyway, fix it before the server updates.

Early on I reorganised the pack and set a standard for how its files are named and laid out. A pack nobody can navigate can't be updated quickly, and Minecraft ships on its own schedule.

Custom armour needed a workaround, because Minecraft had no first-party way to do it. I added Fancy Pants to the pack, an open-source method built on GLSL shaders, and kept it running. The renderer changes between releases and core shaders come with no compatibility guarantee, so every version meant working out what had moved.

Then 1.21.2 shipped a first-party equipment method that did the same job. I took the shader system out and ported onto it, which meant reconciling two pack formats and rewriting the server plugin's Java code at once, on a live server. I had put that workaround there myself. It was only ever there because the platform couldn't do it, and once that stopped being true, keeping it would have been the easier and worse decision.

I support the server's internal plugins wherever they depend on pack features. I also wrote the custom blocks plugin in July 2023, since folded into a larger internal one. It adds block types vanilla Minecraft has no support for, without a client mod, by hijacking existing block states and mapping them to pack assets. Nothing in Minecraft keeps server-side state and client rendering in sync for this, so the plugin has to do it. Demo

The Bedrock port, 2025. The two editions use different model formats, different JSON schemas, different rendering behaviour and different client requirements. This wasn't a file conversion. Visual parity had to be rebuilt at a volume where converting by hand wasn't an option, while holding performance on mobile and console as well as PC.

What it took:

The same scene in Minecraft Bedrock Edition on the left and Java Edition on the right. Two characters wear custom hats and hold custom weapons, custom crate models stand behind them, the hotbar is full of custom 2D item icons, and the scoreboard uses custom characters from a glyph sheet. The two renders are identical despite running on engines that share no code.
Hats, weapons, crate models, hotbar icons and custom scoreboard characters, rendered by two engines that share no code.

For the Bedrock port the product manager asked me to lead the development and the other developers on the project, and I did.

Part of that was finding a person. The JSON UI work needed someone deeper in that specific tech than I was, so I went looking. I worked out who in the community actually does that work, wrote to the specific people worth writing to, went through dozens of candidates and hired the one who fit. He improved on what I handed him and put the whole thing together. I write the specs he builds from and have managed him since.

The rest of the Bedrock side is mine, and that comes down to tooling rather than headcount. The conversion scripts and the deployment pipeline are what let one person hold a pack that size.

When I built the Java pack in 2023 I structured its files and naming conventions so a Bedrock port would be possible later. Nobody had asked for one. Two years on, that decision is why the port was feasible at all.

Minecraft 1.21.4, in December 2024, replaced how custom items are defined. Item models moved out of models/item/, the overrides array and its predicates became a tree of nodes, and custom_model_data turned into a range_dispatch property matched by threshold. For a plain item that's a remap. For the ones that change as you use them (bows, crossbows, fishing rods, shields) the old flat list of predicate combinations had to be rebuilt as nested conditions, and those are the same items that were the hard part of the Bedrock port.

The conversion was only half of it. Players on older clients still had to see the same thing, so the pack had to serve both formats at once: the new definitions ship behind pack overlays with the old ones intact underneath. I wrote Python scripts for the migration and ran them across the PlayFuse and FadeCloud packs too, which needed the same conversion. The public converter on nogard.dev came out of those scripts afterwards.

PlayFuse

Resource pack and systems. 2021 to the end of 2025.

My longest engagement. Five years as the only person editing PlayFuse's resource pack, across dozens of Minecraft updates. Most of it was implementing new content from artists and marketplaces like mcmodels.net for the server's own releases. Text titles, ranks, tags and GUIs I made myself.

Every Minecraft release moves something underneath you, and the job is to find what broke in a codebase that has been accumulating for years.

I ran the pack end to end: display and model tuning, ModelEngine integration for complex models, MythicMobs work, and version compatibility.

I also built and maintained a partial Bedrock port so both communities saw the same content.

When 1.21.4 changed how custom items are defined, this pack went across on the same scripts I wrote for Hoplite.

FadeCloud

Resource pack developer. February 2024 to October 2025.

Sole resource pack developer for a multi-gamemode server network, responsible for every asset players saw: models, GUIs, pixel art, the lot. Some of it was mine, some came from artists and marketplaces like mcmodels.net.

Minecraft Java has no dedicated UI system. A custom menu is assembled out of custom unicode characters overlaying a chest inventory, with negative-space spacing to position them, so what looks like a designed interface is closer to typesetting than to layout. Doing both the art and the integration means the two halves are designed against each other instead of handed over a wall.

I wrote GLSL shaders there as well, and this pack went across the 1.21.4 item model change on the same scripts as the other two.

Java to Bedrock ports

Ongoing.

Taking a server's resource pack across the Java to Bedrock boundary is work I do regularly, not a thing I did once. Some of them are on this page: the full Hoplite port, the partial one I maintained at PlayFuse, BeeBlocks in June 2026, a full port of their pack plus fixes on the Java side, PearSMP's Bedrock port along with the Java pack edits that made it possible, and LunarLabs. Over the years I've also done resource pack work for EnchantedMC, Wildnetwork, NauticMC, OtterSMP, SuperSMP, WaveCraft, SunBlock.gg, Boats N' Bunnies, BearTown, ParrotMC, DreamLand and ElCofreDeVal.

They go faster than they used to, because the tooling and the platform knowledge carry from one to the next.

Server setup comes with the territory. Any pack work means standing up a local Paper or Spigot instance to test against, with Geyser running when crossplay is in scope, so I've been configuring servers for as long as I've been building packs. At Hoplite I advised on the Bedrock crossplay setup when they added Bedrock support in 2025, including the CDN-hosted pack distribution and the CI/CD behind it, and I edit plugin configs there wherever a config depends on a pack feature. I've done server setup work for ElCofreDeVal and others alongside the pack side.

A chess engine inside Minecraft

Bachelor's thesis, 2024. TypeScript.

A complete chess engine and AI opponent built on Minecraft Bedrock's Script API. I built the interface too: the models, textures and animations that make a board you can actually play on.

I built it on Microsoft's official Script API starter and their Bedrock debugger rather than the third-party pipeline I used for client work at the time. I kept to stable APIs instead of experimental ones, which cost me features but meant the add-on wouldn't break on the next Minecraft release.

Full thesis and a demo. I kept working on it after submission, turning it into a product ready to ship on the Minecraft Marketplace, so the demo shows a later state than the thesis describes.

A chess game part-way through, played on a board built out of blocks in a Minecraft world. Custom three-dimensional piece models stand on the squares, the blocks under the legal destination squares glow green, and the block under the selected piece glows gold.
The legal moves for the selected piece, generated and highlighted in game.

A real search engine. Minimax with alpha-beta pruning, move ordering, quiescence, a phase-switched evaluation and a perft-verified move generator is the standard hard problem, and it's most of the work. Minecraft added a second one on top.

The server ticks twenty times a second, and anything started in a tick has to finish in it or the world stops advancing. Go past the watchdog threshold in a single tick and Minecraft terminates the script and closes the world. The stable Script API has no mechanism for spreading a computation across ticks, so I built one, using green threads to yield mid-search and resume on the next tick. That is what makes a search this size possible in there at all.

The answer was minimax with alpha-beta at depth four, stepping to five at eight pieces and six at five pieces, taking one to five seconds per move. Depth four is what the platform allows, not what the algorithm reaches. The same code runs roughly twenty times faster outside the game. At that depth it beats players rated around 800 on Chess.com in the vast majority of games, and doesn't make a mistake inside its own horizon.

Those are the numbers as the thesis measured them. I came back to it in 2026 and more than doubled the engine's speed.

What I measured.

I verified the move generator with perft, counting every reachable position to depth eight: 84,998,978,956 nodes, about 15.7 hours of continuous computation, matching the Chess Programming Wiki's reference counts. I ran it against the standard test positions to depths two through six as well, so the count is verified from a set of awkward starting positions and not just the opening.

I ran the same workload across four runtimes and found Minecraft's script runtime is roughly 20x slower than V8. That splits into about 11x for QuickJS having no JIT and about 2x for in-game overhead.

Runtime perft(4)
Minecraft, in-game 7.078 s
QuickJS, standalone 3.498 s
V8, JIT disabled 1.495 s
V8 0.305 s

I store the board twice on purpose, as a 64-square array and as a piece list kept in sync on every move, because I measured that hybrid at 2x faster than a piece list alone. The two kings sit at fixed array indices so check detection never has to search for them.

Against other engines inside QuickJS, mine does perft(4) in 3.498 s against chess.js at 4.137 s, and loses to Lozza at 1.472 s. chess.js is a rules library, Lozza is a real engine.

I implemented both legal and pseudo-legal move generation, measured them, and chose legal, which is the opposite of what the strongest engines do. At the depths available to me it was faster in my codebase.

I did the same with the search, building plain minimax first, then alpha-beta, then alpha-beta with move ordering, and measured all three across a sample game at depth three. Minimax visited 14,000 to 28,000 nodes per move at 600 to 1,150 ms. Alpha-beta with ordering held at 500 to 800 nodes and 50 to 80 ms.

The number that mattered was the spread rather than the average. Alpha-beta without ordering was usually fast and then spiked to 18,800 nodes and 900 ms on a single late-game move. Against a watchdog that closes the world, a search that is usually quick is worth less than one that is bounded, and ordering is what made it bounded.

The evaluation is material plus piece-square tables that swap over for the endgame, built on the Chess Programming Wiki's standard tables, with an endgame term that drives the losing king toward the edge of the board adapted from Sebastian Lague's series. When it's ahead, that means it forces mate rather than shuffling, and won't take a draw unless it's well down on material. King safety and castling fall out of the table values rather than dedicated code. That was deliberate: fewer moving parts to get wrong when every one of them costs time against a watchdog.

A point-of-sale system for a village pub

University team project, November 2024 to May 2025. PHP, Nette. Source and a live demo

The IS Project course at the University of South Bohemia, built for a real client: a family-run pub near České Budějovice still running its orders on paper chits. Four of us, two developers, and I was one of them.

I owned the order management, the payments, the statistics and the interface. My teammate set the stack, the application skeleton and the conventions.

The payments are the part worth reading about. Czech bank transfers can be initiated from a QR code in the SPAYD format, so each part-payment generates one carrying the amount, the pub's IBAN and a message naming the order.

We chose that over a payment gateway deliberately, and the trade-off is exact: a gateway confirms automatically that money arrived, a QR code can't. The client's binding constraint was that the system must not raise their running costs, and a gateway would have. So the staff member confirms the payment, the system records it, and everyone involved knows that's what the button means.

The order model underneath it is less obvious than it looks. An order has no fixed total, because a table splits the bill. A payment covers whichever items it covers, and the order is only settled once every item is, so the amount due is computed per payment rather than stored per order.

The rest of my side was the statistics module with its period filtering and charts, and making the whole thing usable on a tablet, since that's what the staff actually hold. The sidebar becomes a top bar on small screens, every table sorts and searches in Czech, and prices render with a decimal comma.

The client tested it themselves, in the pub, and the system was deployed to a server and handed over.

Ten years of Bedrock projects

2016 to now. Thirty-four Bedrock write-ups, plus hundreds of private commissions.

The published catalogue is on nogard.dev. What it records is a decade of working against a platform that keeps moving underneath you, and what each era allowed.

2016 to 2018, before custom entities existed. Bedrock add-ons started out as a way to override vanilla entities rather than add new ones: behaviour components on one side, models and textures through the resource pack on the other. So anything new had to be an existing mob wearing a disguise. Half the fun was picking which one, because every entity came with hardcoded parts you couldn't strip out. Spiders were a common base for coming in two variants and being able to climb walls. Sheep because they can be dyed any colour.

It starts with YouTube Villagers in late 2016 and a YouTuber blocks pack in January 2017, then a GTA-themed turf war that February: four factions built entirely out of villagers, husks, zombie pigmen and skeletons, using nothing but hostility tables to make them fight each other. The sports minigames start here too. Ice hockey in July 2017 took two months to build, with an add-on that turned a rabbit into a puck and a knockback-enchanted sword into a stick, redstone that carried the puck back to centre after a goal, and players who counted the score themselves. Ping pong and floorball followed the same year on the same principle, custom models over edited behaviour components.

The summer of 2018 was mostly rideable things: a BMX bike that is really a witch, then a shopping cart, a sofa car, a kart and a unicycle inside three months. Butterflies are bats, since both fly, and I made killing one drop an Elytra. A fox add-on in September. Then futsal in November, which took what the earlier minigames had and added the part they were missing: a scoreboard system counting goals and respawning the ball in the centre after each one, a ceiling that opens, and a lot of command block logic underneath to drive it.

2019 to 2020, custom entities and multi-entity systems. A hoverboard in February 2019, shipped as two builds at once, a real custom entity for Minecraft 1.8 and up and the old mob-replacement trick for 1.2 to 1.7, so nobody was left behind by the version boundary. Ice Hockey V2 in May rebuilt the 2017 map from scratch: a fully automatic in-map scoreboard, command-block puck return, a roof on a lever, goal signalling with fireworks and a horn, an intro corridor you ride through on a minecart, and command blocks under the entire stadium. It went out in all 29 languages Minecraft supported and I still maintain it, most recently in 2024.

A mech car that December, the add-on successor to a 2015 mod that had needed a third-party launcher to run at all, rebuilt as native content. It stayed popular for years after release. A Coca-Cola truck in early 2020, with a detachable semi-trailer that couples automatically when you drive close enough, where the trailer's hitbox is deliberately confined to its front section so it responds correctly to steering. And at the end of that year a Cyberpunk 2077 add-on with several vehicles, the largest at 816 cubes with emissive textures, two rider seats and a five-slot inventory, which took over 46 hours for the model alone. Alongside those, the smaller releases: vanilla backpacks and trophies in 2019, then a Fortnite GUI pack, a Strider add-on three weeks after the mob first appeared in a Java snapshot, and a Minecraft Live 2020 pack.

After 2020. Most of what I built from here went through studios, and that work is in Commercial studio work. Under my own name: craftable chainmail armour in mid 2022, then the football map that December, the biggest of the sports maps so far, with two stadiums so two matches can run at once, both with opening roofs, an automatic scoreboard on the larger one, and vehicles with animated wheels, steering and dashboard dials parked between them. In 2024 the Mace 3D pack, out about twelve days after the weapon first appeared in a snapshot, on both editions, with the Java side in two variants, one for the snapshot and one that back-ported the model onto older clients as custom model data on a stone sword. A Minecraft Movie skin pack that September.

nogard.dev

First concepts 2015, published 2023.

nogard.dev carries the name I've shipped Minecraft work under since 2016, and the site predates the work. The first concepts are from 2015. It was designed and built several times over the years before any of it went public. The first published version went live in 2023 and it has been growing into its current shape since.

Today it holds thirty-nine project write-ups, twenty-five free browser tools, and the portfolio and contact pages the brand runs on. A few thousand unique visitors a day come through it. The number moves with whatever people are searching for: around 3,000 a day as of August 2026, down to about 1,000 in quiet stretches, and over 11,000 at its busiest.

That makes it a product rather than a portfolio piece: it has to keep running, keep ranking, and keep being worth returning to. Most of the traffic arrives through search, so SEO is ongoing rather than something done once, and the same goes for the tools and the tech underneath them. A good share of it comes direct, though, people typing the name in, which is the part that took ten years to build.

The site is about Minecraft. Building and running it isn't. It's a web product first: markup, styling and JavaScript, structured data, a build pipeline and performance work.

The image tools draw the most traffic. The chibi skin maker most of all, then the pixel art tag generator, the Mojavatar maker, the skin renderer and the glyph generator. They're also the ones with the most moving parts: a model, a camera, lighting and an export path, which is why the harness below compares rendered output instead of checking the code still runs.

The rest are developer utilities, and nine of the twenty-five aren't Minecraft-specific at all: UUID generation, base conversion, colour picking, palette extraction from images, JSON formatting, cron expressions, unicode conversion, font generation and Discord timestamps. Plenty of them get used for Minecraft work anyway. Three more are for Hytale: a skin viewer, a username checker and a pack manifest generator.

One of them started as the Python scripts I used for that Minecraft 1.21.4 migration. Paste in the old override format, get back the new item definitions, with the multi-state items handled properly instead of flattened.

The measuring matters more than the count. Changing how the tools are built means having something to check the change against, so a lot of the work is harnesses: INP, parse and compile time, and a render-equivalence check that hashes the output across every style, view and pose, so a change can be shown to be neutral instead of assumed to be. That caught a bundler bug that deletes inline event handlers outright: the page loads, renders, throws no errors, and every button is silently dead. Reading the documentation would never have surfaced it.

The site is still moving. New tools go up, the older ones get reworked, and the whole thing is being rewritten onto Astro with components rather than the hand-rolled setup it grew out of.

hronek.dev

2026. Astro, hand-written CSS, no framework.

The family domain at hronek.dev. My brother and I each link out to our own subdomain from it, so mine is vojtech.hronek.dev and my address is vojtech@hronek.dev. Addresses that read as a name.

It exists for case studies I can send with a CV, at a URL that doesn't need explaining, on something I built rather than a profile on someone else's platform.

The page you're reading is markdown. Astro's content layer parses it at build time and renders it into the site's own components, so editing a portfolio entry is editing a text file rather than touching markup, and nothing about it needs a CMS.

The cycling headline is a CSS animation over server-rendered markup, so the text is in the HTML for crawlers and for anyone with scripts blocked, and screen readers get the full list as static text instead of the animation.

It shipped no JavaScript at all until three things earned their way in: applying a saved theme before first paint, so the page never renders in one scheme and flips to the other; an analytics beacon; and a correction that re-aims a link to a specific section once the webfont has settled, because Firefox otherwise scrolls to where the text was before the font changed the layout. None of the content depends on any of them, and the theme control is rendered hidden and revealed by script, so nobody is shown a dead button.

Open source

Thirty-four of my commits are merged into six open source projects. Every link goes to that project's commit list, filtered to my account.

Project What it is Merged
Blockbench The 3D editor most of the Minecraft ecosystem models in 6
Geyser The proxy that makes Java and Bedrock crossplay possible 2
GeyserDisplayEntity Display entities for Bedrock players 10
GeyserModelEngine ModelEngine models for Bedrock players 9
GeyserExtras Feature parity for Bedrock clients 5
GeyserModelEnginePacker Blockbench extension for packing models 2

Most of it started as something blocking a client project.

In Blockbench I added shelf display support to the display-settings editor, including left and right reference slots so an item can be positioned against its neighbours. In Geyser I fixed custom trim patterns and materials (#6218) and a passenger y-offset when riding a player (#6595).

One of them is smaller than either and easy to miss. Minecraft animation keyframe times were being written with Java's default number formatting, which follows the machine's locale, so on a Czech or German system 0.5 came out as 0,5 and the JSON was malformed. Correct on the maintainer's machine, broken on mine.

I also publish MEGAnim, a Spigot plugin under AGPL-3.0 that exposes ModelEngine animation playback as commands, with five targeting strategies and per-server safety limits. I wrote it because testing an animation otherwise meant recompiling a plugin every time. It's a tool rather than a product. I also maintain a fork of misode.github.io that runs as mcfunctions.com.

Commercial studio work

I started publishing on MCPEDL and kept going from there. I was around early, but the route onto the Marketplace then was becoming an official partner, and that wasn't open to someone still in high school. So the work went through studios: a decade of building Marketplace products under other people's names.

Gamefam, 2024. World Utilities, a Marketplace add-on of around thirty in-world tools and abilities: vein mining, tree felling, a spawner wrench, a disenchanter, chunk borders, a hoe that replants what it harvests. Roughly three months of full-time work. It came out of the 5 Frame internship, and that work is very likely what led Gamefam to me.

I implemented the artist's assets into the game across both the resource pack and the behaviour pack, which on Bedrock is the join between how a thing looks and what it actually does. I worked in Regolith, the filter-based build pipeline for Bedrock add-ons, rather than hand-editing JSON in a pack directory: a source tree separate from the output, composable filters that generate content at build time, and a reproducible artefact at the end. It launched as one of the first nineteen add-ons on the Minecraft Marketplace. I no longer work with Gamefam, and my focus now is on releasing under my own name, since the thing that ruled that out at seventeen no longer applies.

5 Frame Studios, summer 2023. University internship, 280 hours across 35 days, 3 July to 20 August, weekends included. Two Marketplace products, X-Ray Hacker Base and Hacks: Speed Bridge.

The x-ray effect is faked by mass block substitution, replacing stone and ore with transparent variants. Doing that for every block by hand wasn't viable, so I wrote a Python generator for the commands, integrated it with the rest of the systems, and ironed out what it got wrong. I built it in two versions, one for low-end devices and one for higher-end, then shipped the leaner one to everyone rather than maintain both.

Speed Bridge places blocks from your hotbar ahead of you as you walk, inside the map it ships with. I built the add-on and integrated it into the map, along with a helicopter, a small football pitch with goal effects, chests of hacks, and easter eggs scattered through it.

Keystone Builds, 2021 to mid 2024. Two projects.

Zombie Apocalypse, the add-on side of a project built for the Minecraft Marketplace, and one of the largest things I have built. Around 670 entity definitions, 98 models, 755 textures, 50 animations and 111 function files across the behaviour and resource packs: a dragon boss and a pet dragon, a weapon set, rideable vehicles with custom player animations, and a full decoration range. The vehicles and furniture come in multiple states, from rusted and worn to repaired, and players can restore them.

I built it alone for a long stretch before hiring a second developer to work on it with me. I built it in Regolith, the same tooling I used at Gamefam, which keeps the add-on's source in one tree and deploys it into Minecraft's own folders on build.

The other, in 2022, was a Minecraft world sold as an NFT through NFT Worlds, the project that later became Hytopia. I built its Bedrock pack, and Geyser handled the Java and Bedrock crossplay, which makes it the earliest Geyser work in my record and a direct precursor to the Hoplite port.

Furniture: Modern Makeover, work completed July 2020. Commissioned by one of Waypoint Studios' partners and published through Waypoint on the Minecraft Marketplace in March 2021. I built both the resource pack and the behaviour pack: the models through to working entities in Bedrock, which is the entity definitions, display setup and behaviour that turn a model into something the game can actually use. The brief stopped there. The models arrived in a single colour, so I repainted every texture into all sixteen Minecraft dye colours and reworked the models where they needed it for better interactivity.

RareLoot, 2024. Toilets vs TVs & Cameras, a Marketplace skin pack of 25 skins. I made the pack and led its marketing campaign. It first went out through Cynosia, who later pulled it, so I took it to RareLoot instead. It went through several rounds of revisions before it cleared Marketplace review. I also worked with Plonix Build on RareLoot's side of things.

Code Studios and Maker Camp. An add-on commissioned for the Italian Fire Department, with vehicles, NPCs and the rest of the equipment around them. The only project in this record whose end client was a public institution rather than a game studio or a server.

Blockbytes LLC. Two add-on projects: tree pods, originally meant for a skyblock map, and an animated world border driven from commands and the Script API. Their later Farming Pots add-on appears to run on the same tech, though I wasn't involved in that one.

How I work

I don't ship on impressions. If I claim something is faster, smaller or equivalent, there's a number behind it.

A desktop with five windows open at once: a Minecraft font definition file in a code editor showing unicode ascent and character mappings, the matching menu artwork being drawn in an image editor with its layer stack visible, a three-dimensional model open in Blockbench with its display rotation, translation and scale controls, plugin source code in Java, and the finished result running in the game.
A font definition, the artwork it points at, the model, the plugin source and the running game.

I want to know what's underneath. Years ago I built a computer around a Z80 on breadboard, because I thought building one would teach me how computers actually work. It did, and the habit stayed. When Minecraft's scripting felt slow I measured it against V8 across four runtimes instead of accepting the impression, and found the penalty splits into the runtime having no JIT and the game's own overhead. When a CDN-hosted pack wouldn't load on Bedrock, I worked out which HTTP headers the client actually requires. University coursework got the same treatment: an assignment to present the Python libraries for statistics and time series analysis, which I steered towards algorithmic trading, where the useful part was understanding how they worked rather than what they claimed to do.

I measure before deciding. I built both move generators for the chess engine, timed them, and picked the one that contradicts what the strongest engines do, because it was faster in my case. I store that engine's board twice because I measured the duplication at 2x before accepting the cost of keeping two structures in sync.

I take responsibility past where it's assigned. It goes back to the first Marketplace work I did: in 2020 a furniture add-on arrived in one colour and I repainted the lot into sixteen because it would be better that way. In 2023 I structured the Java pack so a port would be possible later, which nobody had asked for and which is the reason it was feasible when it came. The Bedrock port then kept hitting limits in tools I didn't maintain, so I fixed them in those projects instead of working around them, and those commits are merged upstream. I dropped a shader system I'd maintained for years as soon as the version that replaced it became our minimum supported one, which was the earliest the swap could happen.

I've run people as well as work. Building things since early adolescence pulled me into coordination roles alongside the technical side, and my degree is in business informatics rather than straight computer science because I wanted the management and leadership coursework that came with it.

On the Bedrock port the product manager asked me to lead the development and the other developers, above my title, and I did. When the pack needed a JSON UI specialist I found and hired one, and I've written the specs he builds from since. On Zombie Apocalypse I brought in a second developer once the scope outgrew me and ran that too. Under my own name it goes back further: trailer editors, modellers, whoever a release needed, hired and directed by me. Through 2024 and 2025 I ran three server packs at once, Hoplite, PlayFuse and FadeCloud, on separate release schedules.

Scoping is part of it. In 2025 a client sent me a project document and asked for a three-week turnaround. I put it at three months and said so rather than take the work and miss. I lead by example and take ownership of outcomes whether the title says so or not, and running people is the part of this work I'd take more of, not less.

None of that is separate from the engineering, and that combination is the point. The reason I could scope the Bedrock port honestly, or hire for JSON UI knowing exactly what the work needed, is that I can read what a decision costs in the code instead of taking someone's word for it. Plenty of people can do one or the other.

Background

Now. Hoplite (2023 to now). nogard.dev, which is both the catalogue and a working income. Commissions as they come.

Before. BeeBlocks (2026), LunarLabs, PlayFuse (2021 to 2025), FadeCloud (2024 to 2025), Gamefam (2024), 5 Frame Studios internship (2023), Blockbytes LLC, Keystone Builds (2021 to mid 2024), Waypoint Studios (2020). Publishing independently since 2016, with hundreds of private commissions alongside.

Education. MSc Applied Informatics, Software Engineering specialisation, University of South Bohemia. Started September 2024, in progress, expected 2027. Already past the 120 ECTS minimum, with the coursework complete and only the thesis itself left to finish. BSc Business Informatics, University of South Bohemia, 2021 to 2024. Completed with more than 200 ECTS credits against the 180 required. IT secondary, SPŠ Písek, 2017 to 2021.

Both degrees were done while working. The extra credits went into technical subjects beyond the study plan, taken in the same years I was shipping commercial work, because they were worth having. The business, management and leadership side came with the programme, which is why the bachelor's is in business informatics rather than straight computer science.

The languages and the computer science I work from came out of formal study, starting at secondary school and continuing through both degrees. The domain didn't. Minecraft's Script API is documented and the changelogs are real, so the vanilla surface is learnable from the reference. What isn't documented is everything a level down: how the renderer actually behaves, where the two editions disagree, and the whole crossplay layer, where Geyser and its extensions are the thing you have to read the source of. That part came from ten years of reading, testing and being wrong in public. Where I could, I pointed coursework at it, and the bachelor's thesis is the clearest case.

Tools. Blockbench and Blender for 3D, Paint.NET and Photoshop for pixel art and image work, Premiere Pro for video, Figma for interface design. On the server side, ModelEngine, MythicMobs, Nexo, ItemsAdder and DeluxeMenus.

DevOps. GitHub Actions and Docker mainly, GitLab CI/CD on earlier work. CI/CD pipelines, automated builds and deployment, CDN-backed delivery. Kubernetes once, on a university project.

Also. Most of the graphics around my own content are mine, and so is the video: I edited every commented video on my YouTube channel and around half the trailers, and directed the rest. Networking I studied as heavily as programming through secondary school and university, which is where the CCNA certificates below come from.

Certifications. Cisco CCNA: Introduction to Networks. Cisco CCNA: Routing and Switching Essentials.

Languages. English (C1), Czech (native), German (A1).

Contact

vojtech@hronek.dev