gamedevguide, a developer's Unreal and Houdini notebook

Four years of notes, published as they are converted

The README answers the obvious question first, under a heading that is deliberately informal. These are the author's personal notes from the past four years, and they are being transformed from an internal developer onboarding guide into something public. The conversion is the interesting part, because the author is candid about the cost. The notes lived in OneNote, Evernote and Confluence, and the author says the conversion is lossy and needs a final human pass to clean up small niggles, with the stated aim of processing about one section a day. That sentence sets the expectation for the whole repository, and it is the single most useful thing in the README for anyone deciding whether to rely on the content. The site is published at ikrima.dev, there is a build badge for the site, and the author invites readers to subscribe to the repository for updates, which is a reasonable way to follow a conversion that takes months rather than days.

Migrated from Gatsby to MkDocs, and the site is not the point

The build system is in flux, and the README says so. The site was originally built with Gatsby and is migrating to MkDocs, and the notes about the web development of the site live in the docs folder of the repository rather than in the published output. The author's advice to readers is unusually blunt, that web development is a chore, that they never use the live site any more, so your best experience is cloning the repository and opening it locally. That is a remark worth taking seriously rather than as modesty, because it tells you the site is a way to read the notes rather than a maintained product. The repository layout supports the picture. There are two MkDocs configuration files, mkdocs.yml for the site and mkdocs.dev.yml for development, a netlify.toml for the deployment, a requirements.txt for the Python side, a runtime.txt for the Python runtime, and a lycheeCheck.ps1 script for link checking. The primary language of the repository is recorded as PowerShell, which comes from that one script rather than from the content.

Obsidian is the intended way to read it

The reading recommendations are specific. The author uses and recommends Obsidian, with no affiliation and the argument that it is free, fast and works with zero setup because you just open the notes folder. Foam and Visual Studio Code are named as good alternatives, and for the impatient there is a link that opens the repository directly in a browser based editor, at vscode.dev/github/ikrima/gamedevguide and at github.dev//gamedevguide. The choice of a note taking application as the primary reading interface is a consequence of the content being a collection of notes rather than a manual, and it explains the requirements file. Several of the pinned packages exist to make MkDocs handle Obsidian flavoured Markdown, and there is a whole section in the requirements listing what is not deployed and a section listing what is broken, with a comment explaining that some of those plugins have Obsidian compatibility issues.

What has been converted, and what has not

The repository keeps a checklist, and reading it is the fastest way to know what you will find. The finished conversion list starts with the conversion scripts from OneNote and Trillium to a custom central store, then Houdini, then UE4 with nine named subsections: Environment Setup, Build Guide, Packaging, Source Control, Gameplay, Editor Extensions, Tooling, Engine Programming and Rendering. Those UE4 subsections are the part of the repository with real value for a new hire, since they follow the order in which a person actually needs the answers. The current conversion status list is a different story. Programming and Graphics are both unchecked, OneNote is unchecked, and Notion is half done, with the export to Obsidian ticked and the clean and integrate step still open. The heading above that list says the rationalisation of all notes into one place is being restarted. A reader looking for a rendering or graphics reference should assume it is not there yet, and the topic list on the repository, which includes graphics, rendering, Houdini plugins and Unreal Engine plugins, describes the ambition rather than the content.

The requirements file is an honest map of the build

requirements.txt is grouped by role, and the grouping tells you what the site actually depends on. The core section is the actively used part, with mkdocs 1.6.1, the Material theme at 9.5.39, pymdown-extensions, the awesome pages plugin, a plugin that localises the git revision date, and a progress plugin. The Obsidian Markdown group is also marked as actively used and holds obsidiantools, a breakless lists patch, callouts, a meta descriptions plugin and glightbox for the image lightbox. Then there are the sections that are not deployed, including the minify plugin and the redirects plugin, and a group labelled broken that includes the roamlinks and ezlinks plugins, with a comment that they have Obsidian compatibility issues. The native dependencies group, cairosvg and pillow, is listed as not deployed as well. Almost every version is pinned rather than ranged, which is the right call for a build that has to keep working while the content underneath it is rewritten, and it also means that a dependency with a security issue is a manual edit to this file.

Link checking, linting, and a licence that is simple

The repository has the small pieces of tooling a documentation project needs. lycheeCheck.ps1 is a PowerShell script for checking links, paired with a .lycheeignore file for the links that are not supposed to resolve, which is what a notes collection with years of stale URLs needs. .markdownlint.jsonc configures the Markdown linter, .prettierrc configures the formatter, and there is a .vscode/ directory for editor settings. The .github/ directory holds the workflow whose badge appears at the top of the README as the site build. The licence is MIT, which for a collection of notes is about as permissive as it gets, and the notes themselves are the author's own work. On the maintenance side, the repository is not archived, it has no GitHub releases, and the last push was on 2026-08-09, so the flow of commits is the release channel. The reasonable expectation is that a reader will find the UE4 setup material complete and stable, the Houdini material present, and the programming and graphics sections still arriving, one page at a time.

Editorial conclusion

gamedevguide fits a game programmer who wants a working setup, build and packaging recipe for Unreal Engine or a Houdini workflow written down by someone who did the work, and it fits a team building an internal onboarding guide and looking for a model of how to publish one in the open. It does not fit someone who needs a complete reference, since the conversion checklist shows that programming and graphics are still unfinished, and it does not fit a reader who needs versioned vendor documentation, since these notes carry one author's environment rather than a supported product matrix. Verify three things first: which sections have actually been converted, by reading the checklist in the README rather than the topic list, whether the notes match the engine version you are on, since the content is dated by the author's own four years of work rather than by release, and how the site renders, since the author recommends cloning the repository and reading the notes locally instead of relying on the live deployment.

Frequently asked questions

Official sources

1. ikrima/gamedevguide on GitHub
2. Issues
3. License: MIT
4. Project website
5. README