Howdy, my name is Damien. I often go by Dae, or D. So what is this page about, how did it come to be, and what's its purpose? This is just a little biography page I put together for people to get to know me. There are so many individuals that it would be impossible for me to know everyone and remember every single detail, especially if I don't see you often. So I put this page together for my peers to get to know me and gain a bit of perspective on who I am. Think of it like a welcome introduction to myself.
So, what do I do, what are my goals, and what are my hobbies? Currently, I work as a Data Center Technician (DCO), helping with Machine Learning and Machine Learning Zone-related issues. As for goals, I've set many, maybe too many; it feels like I'm daydreaming a bit, who knows. I've been with Amazon since 2022, heading into my 4th year this November. Most of the goals I've set are primarily around software and hardware development. Understanding both aspects isn't only important to my career; it's also a genuine personal interest in what I do day to day. When I develop these tools, it's mostly to speed up any workflows where I find improvements can be made, but also to ease the job a bit more than it is. If you think about it, the time I spend developing tools for myself, whether personal or contributed, is just more experience for me. I think it's vastly important to be obsessed with what you find yourself good at, and I'll always advocate for being the best version of yourself.
As for hobbies, outside of work I program and play video games. I've played many games from old to new; I've been at it since age 4, when I discovered the computer we had, and the first game I was really interested in was Halo: Combat Evolved. Since then, I've been hooked on Pokémon. I had a DS and DSi on which I played just about every Pokémon game. I've played a lot of Zelda, especially Ocarina of Time, plus lots of Doom, Quake, Gears of War, RuneScape, F.E.A.R., MX vs. ATV, Sly Cooper, Phantasy Star, and Metal Gear Solid. I've played just about any game on many platforms, but primarily a lot of Halo. I've had a vast obsession with game development; however, I don't wish for it to be my job (haha) for many reasons, but I have been building my own game. I still attend university, and I plan to obtain my Master's in Computer Information Systems & Computer Science (dual enrolled). My specialization under my degree is Cloud Networking Systems and Administration, and my end goal is to be a Cloud Systems Developer Engineer, and once obtained, work on becoming a Distinguished Systems Engineer for Software & Hardware. I'm very young, only being 23, with many years to come. I'm taking my time in DCO to build more mechanical skills alongside technical ones, as I've never worked in a Data Center role before. This also plays a huge part in what I can develop. It will take some time to be fully settled and understand my limits, but I do plan to make some pretty cool things here.
Outside of all of these things, I plan to be here for many years to come. As I like to say: I'm forever stuck in Paradise, I'm banned from leaving. I hope you enjoyed the read. If anything, ask questions; hopefully I can help. My main purpose is to teach, mentor, and lead.
Woah, seems curiosity might kill the cat this time huh? This is my collection gallery of screenshots from when I used to play a lot of games. For now I just have my Halo stuff included and one photo from Call of Duty: Black Ops 2. If you're curious, yes, I did compete and would attend events. I've been playing Halo throughout all my life. I love it, I hate it. The franchise has semi gone down the drain, and I don't play as often. Do I still got it in me? Of course I do! It's just I moved on, you know. I'll fill in more screenshots (like WoW, OW, Quake, and much more) soon!
no photos loaded yet
Howdy! In here you'll find helpful documents, links, and books: resources I use and actively still follow up on. If you enjoy any kind of development, this is the right place to snoop around, and hopefully you find something that piques your interest too. Other than that, if you have things to share with me, by all means don't ever hesitate to message me on Slack!
By Halo 2 the AI spanned dozens of behaviours across some thirty character types, and the obvious implementation stopped fitting: a full behaviour tree per actor cost roughly 192 KB, impossible for a hundred actors on the original Xbox. Having each behaviour return an analog "desire to run" had also stopped being tunable past about twenty competitors.
The tree became completely static and shared, each actor storing only the few hierarchy levels it currently sits in, about 25 KB for a hundred actors. Cost scales with the tree's depth, not its behaviour count, so behaviours were nearly free to add. Spore built its AI as "version 1.5" of this, and Hecker published that shipping code as a literate program, C macro-driven declarations, static plain C structs, C++ objects via placement new.
When id released the source in 1997, Carmack used the README to list what he considered mistakes rather than achievements. Doom compiled a BSP tree for every level but used it only to draw the world front to back; movement and line-of-sight ran on separate, messier code with failure cases. Clipping was done in polar coordinates, which he flagged as simply the wrong choice.
His own prescription: a single front-to-back walk of the BSP tree that collects subsector contents, treats floors and ceilings as real polygons, and clips sprite billboards into subsector fragments, with that same tree reused for sight and movement instead of a parallel system. Quake is roughly what the correction looks like shipped, adding a precomputed visibility set on top so most of the world is discarded before drawing begins.
Bungie arrived at Destiny from a Windows-focused background, with a content toolchain already written in C#, and needed a live service that dozens of components could be built on without a separate ramp-up for every engineer. The authoritative game logic, meanwhile, lived in native engine code and could not simply be rewritten to match.
The services were written in C#, sharing a language with the existing tools, on Windows with SQL Server behind them. Native C++ game-logic DLLs are loaded into the C# WorldServer, so the simulation stays in engine code while everything around it stays managed. Bungie's own retrospective is candid that they would harden that C#/C++ boundary if they built it again.
Quests, NPC conversations and cutscenes change constantly and are authored by designers rather than engine programmers. Compiling that flow into the client would tie every dialogue tweak to a client build, and would put designer mistakes in the same binary as the renderer.
The client embeds Lua 5.1, and event logic ships as precompiled bytecode alongside the art, quest scripts, conversation handlers and scene functions driving camera, animation and dialogue against server-side state. Content updates become data updates. Worth flagging: this one is documented by people decompiling the client, not by Square Enix, so treat it as well-evidenced rather than official.
EVE runs each solar system on a single server node, and a thousand-pilot fleet battle overloads it. The core is a cooperative scheduler of Stackless Python tasklets; under overload a tasklet that yielded could wait five seconds or more for its turn. Module activations lagged by twenty, forty, six hundred seconds, ships took minutes to die, clients black-screened. Nothing degraded gracefully.
Rather than strip mechanics to shed load, CCP slowed time itself. Most of the work is tied to the clock, modules, physics, travel, so stretching it cuts work per real second in proportion while leaving the rules untouched. The factor moves in fine increments to keep the tasklet queue near empty, then ramps back up as the fight thins. Afterwards, 1,300 to 1,400 pilots in one system held module response under a second.
Every RPG Maker before XP hardcoded the parts that mattered, battle system, menus, damage rules, the event command set, all inside the executable. Creators could draw maps, place events and fill in database values, but could not change how the game actually worked. A different combat model meant a different engine.
XP shipped the entire default game as editable Ruby, exposed in the editor as RGSS. Damage calculation, menus, map scrolling, even the built-in event commands became scripts you could rewrite, or delete and rebuild into genres that were never RPGs. The documented tradeoffs: no bundled standard library, a locked framerate, and a closed runtime you could only get by buying the editor.
Character and account state began as an ordinary relational schema, thousands of attributes per account and per character, plus versioned content on top. At Destiny's scale that made analytics queries and one-off "SQL fixups" painful, and incremental updates saved little, since touching a single field still meant paying for the row structure around it.
They collapsed it into one blob per account, character and item collection, still stored in SQL, cutting roughly 90% of the space while making loads faster and bugs easier to read. The migration ran live: write to both, then move reads across by hashing accounts into A/B buckets. A leftover you can check yourself, Destiny's public API still ships its manifest as a SQLite database.
Alpha-era Minecraft saved every 16×16×128 chunk as its own file, so a well-travelled world became hundreds of thousands of tiny files. Jens Bergensten's own assessment: workable on Linux, "quite slow on Windows." The modder who fixed it was blunter, calling chunk updates the number one cause of Minecraft lag.
The Region format packs 32×32 chunks, 1,024 of them, into one file behind a header table of sector offsets, each chunk deflate-compressed and aligned to 4 KiB sectors. Mojang's own figure was "about 500 to 1000 times fewer files." It arrived as a mod by Ryan Hitchman and was adopted nearly unchanged in Beta 1.3, gaining a chunk timestamp table; Anvil replaced it a year later. The language is visible in the fix itself, RegionFile.java.
Running a real engine in a browser meant shipping a plugin, NPAPI, Flash, Native Client, each with its own security friction and install drop-off. Ordinary JavaScript was too slow for the job: garbage collection, dynamic types, unpredictable JIT behaviour. Hand-porting a million-line C++ engine into JavaScript was never a serious proposal.
Mozilla defined asm.js: a strict subset of ordinary JavaScript with static types and no garbage collection, shaped so it could be compiled ahead of time rather than traced at runtime. Emscripten cross-compiled UE3's C++ into it, with WebGL drawing the result. Mozilla's numbers, over a million lines, four days, roughly half the speed of native C++, no plugin. One honest note: this is real JavaScript that runs in any browser, but it is compiled to rather than written by hand.