https://pa.rh.am/index.xml

I spent several years working towards maintaining, restoring, archiving, and cataloging the 16mm and 8mm films that constitute most of UCSD Geisel Library’s film collection. This work involved extensive use of digitization hardware and software. As the person primarily tasked with film digitization, much of the work and troubleshooting was done independently. Moreover, I helped in making digital copies of these films easily accessible and searchable. I believe a huge component of digitally archiving media is to not only preserve the material, but also make the content easy to find and use.

As an organizer for the San Diego Chapter of the International Game Developers Association, I was involved in organizing a wide variety of events in service of the local gaming community. I primarily spearheaded the chapter’s presence at Winter GameFest, the largest competitive gaming event in the city. I organized the panels, which cover a variety of topics, as well as an indie games booth that showcased the work of talented developers throughout San Diego.

I also assisted in the organization of other events, including game jams (similar to hackathons) and workshops for various experience levels. This included creating promotional materials for these events. Additionally, I help managed the chapter’s social media presence.

All copyrighted art used in the promotional material belongs to their respective owners.

Tools: Photoshop, Illustrator, Premiere, After Effects

After the the layoffs and subsequent closure of Bartlet Jones, I transitioned away from the professional game development industry and joined Hive Media, a publishing and ad tech company.

I assumed different roles and responisbilities during my time at Hive, transitioning seamlessly between them as the needs of the engineering team changed. While I primarily helped with project management and coordination, I also became involved with UI/UX design, tools engineering, writing and maintaining data collection scripts, and QA testing. One of my most significant contributions came from helping coordinate development of SWARM, Hive Media’s in-house CMS.

With SWARM, I helped manage the roadmap with key stakeholders, assisted in prioritizing tasks for each sprint, mapped out the UI/UX design for certain elements of the experience, and regularly tested new features and critical fixes. I also wrote extensive documentation about the platform, demonstrated it to external partners, and even worked closely with the engineers and designers to coordinate quarterly UI/UX interviews to ensure SWARM met the needs of its users.

Because my UI contributions to SWARM are still present in its current iteration, I cannot share any wireframes or mockups for the time being.

In early Fall 2017, I was contracted by Filament Games to design the UI for a game-based trainipngng program. In preparation for working on the interface, the lead designer and I engaged in rigorous user research and authored surveys directed towards our target audience (instructors and students).

We ultimately chose to frame the training program as a city building game. As the student accomplished certain objectives, more of the city unlocked and their small town would evolve into a sprawling metropolis. Much to our delight, Filament’s client was incredibly excited by this proposal.

After accepting a job offer from Bartlet Jones Supernatural Detective Agency, I worked with Filament to wrap up my involvement with the project.

Only a small amount of material related to the project can be shared and the Filament’s client has been anonymized.

Tools: Balsamiq, Illustrator, Photoshop

The work below is from early in the discovery phase and does not represent the final product. The background city is from Anton Moek’s Low Poly City Pack 3.

I joined Bartlet Jones in the Fall of 2017 to work on an announced UE4 game. Although my official title was Production Coordinator, I was involved in multiple aspects of the project.

As a production coordinator, I primarily assisted the lead producer with managing the game’s system features. Additionally, I worked with the associate producer to organize the daily standups, reviews, and discussions. Part of my production responsibilities also included administrating our task tracking and wiki software, Manuscript. Because of my light web development background, I was able to customize certain portions of Manuscript to better tailor it for different departments within the studio.

I also designed the wireframes for the game’s UI and screenflow. Additionally, I designed the game’s core system features, which includes replays and rewards. While still very early in the development process, the wireframes, screenflow, and features went through multiple rounds of iteration based on reviews and conversations with multiple department leads and studio heads, as well as the publisher. Special care was taken to ensure the all aspects of my work accounted for any technical limitations presented by the engineers and adhered to platform TRCs.

Unfortunately, as of January 23rd, 2018, the project was canceled by our publisher and the studio laid off most of its staff.

For this project, I shifted to using Axure Pro as my primary wireframing tool. Many of the wireframes were fully interactable and some features would behave differently under certain conditions. The project was cancelled early in its lifecycle, so only some of the features outlined were integrated into the game. However, all were approved by the engineers and project director.

Part of the way through VBL’s development, I shifted from using Balsamiq to Axure Pro as my primary wireframing tool. As a result, many of the wireframes were fully interactable and thoroughly utilized conditional logic. The project was cancelled early in its lifecycle, so only some of these features were integrated into the game. However, they were all approved by the engineers and project lead.

These are some of the wireframes which were made to demonstrate the flow for playing in a public online match with friends.

Tools: Balsamiq, Axure RP, Lucidchart

The initial wireframes started in Balsamiq. This early version was used as a basis for the engineers to start preliminary work of integrating menus into the game. As the video demonstrates, this very early build was still missing key parts of the local exhibition flow and certain features weren’t functional yet.

Based in near-future Shenyang, HUMINT thrusts the player in the middle of a dramatic regional political power struggle. As a CIA agent, the player seeks to traverse the city’s wilderness of mirrors and survive a spy ring bust spearheaded by the Ministry of State Security.

I primarily worked on production, UI/UX design, level design, and 3D modeling for HUMINT. I was involved in authoring and maintaining our development schedule and sprints to meet internal deadlines, as well as planning arrangements for events and overseas travel to China. I also organized and kept record of the daily stand-ups and weekly team-wide meetings. Additionally, I created and managed instances of Confluence, JIRA, MediaWiki, and FishEye on DigitalOcean to facilitate better communication, task management, and bug tracking.

Because of the themes and subject matter, designing the game’s UI presented a challenge: it needed to communicate a large volume of information quickly, without overwhelming the player. Moreover, both the main menu and in-game menu had to visually explore the dark, and often complex, work of spycraft.

HUMINT was a first-person adventure game slated for release on the PC in 2017; however, it was cancelled in late 2016. The text and some of the 2D artwork in the images below should be considered placeholder and not reflective of the final game. The character concept art was created by Shelley Monahan.

Tools (for UI): Photoshop, Illustrator, Unity (+ Unity UI), Balsamiq, Visio, Maya (3D Assets)

main menu

hud and loading screen

inventory

map

intel // missions

intel // data

intel // affiliations

intel // dossiers

communication

Between work and school, I have a unusually heavy workload that necessitates putting a pause on all my projects until the end of this semester. I will still support Konga Beat and Konga Launcher with bug fixes as needed, but everything else is on hold until May.

See you folks then!

“What does Xbox mean to Microsoft?”

A friend and I were chatting on the train. I told him I couldn’t see how Xbox fit into Microsoft’s vision of the future, and I wondered how much longer the division would stay around. And so, I posed that exact question to him: “What does Xbox mean to Microsoft?” The conversation happened over ten years ago, when we were still only about a year and a half into the eighth generation and about two summers removed from the Xbox One’s E3 debacle. After all that time, the question is even more relevant now than it was then. What began as Microsoft’s bid to control the living room now looks more like a superficial brand than a core strategic asset.

Most conversations about Xbox commonly trace the platform’s decline back to the disastrous reveal of the Xbox One. Thanks to the incredible success of the Kinect during the Xbox 360 era, and Microsoft’s overconfidence in media convergence, Xbox shifted away from its core audience’s interests to try to attract a wider audience. Unfortunately, the console’s focus on Kinect and live TV integration felt antiquated from the jump. The world largely moved on from motion control gaming by that point, and streaming services like Netflix and Prime Video had already begun to supplant live TV. Despite Microsoft’s attempts to course-correct after launch, the company never figured out a compelling pitch for the Xbox One, and that bore out in the console’s lifetime hardware sales. In the end, the Xbox One sold 58 million units, compared to the Xbox 360’s 84 million units1 and the PlayStation 4’s 113 million units.2

The failures of the Xbox One cast a long shadow on Microsoft’s foray into the home console space. As Phil Spencer readily admits, the eighth generation was the worst one to lose.3 Every failure during the Xbox One era compounded, leaving the platform in a state of precarity. With retailers removing hardware from shelves,4 Microsoft bringing more of its games to other platforms, readers engaging less with Xbox coverage,56 and the Xbox ecosystem becoming increasingly price-prohibitive to engage with,7 the situation looks dire. The Xbox Series will be lucky to sell anywhere near as many units as the Xbox One, much less seriously compete with the PlayStation 5.

There’s a natural inclination to pin this on Phil Spencer. After all, we’re about ten years into his reign; far, far removed from the Don “We have a console for you, it’s called the Xbox 360” Mattrick era. As much as I abhor Spencer and the “How do you do, fellow gamers?” image he has built for himself, Xbox’s downfall started long before he took the reins. It began back in 2007, when the Xbox brand was arguably at its peak.

As the story goes, Microsoft conceived of the original Xbox in response to the PlayStation’s explosive success in the 1990s and early 2000s.8 At the time, Microsoft wanted to be the central hub of computing in every family’s home. Every household electronic device would in some way connect to the family’s Windows PC. Executives at Microsoft saw the PlayStation 2 as a direct threat to their vision: if the PS2 was as powerful as Sony claimed, what if the game console became the home’s computing hub, relegating the family’s Windows PC to spreadsheet duty in the home office? The threat felt real enough for Microsoft to put its entire weight behind the Xbox. If Sony wanted to make a play for home computing, it wouldn’t be left uncontested.

The iPhone completely upended Microsoft’s vision for home computing. With the release of the first iPhone in 2007, people’s relationship to computers shifted. Everyone was essentially going to carry a computer around with them at all times. Moreover, much of the actual computation wouldn’t even happen locally. Instead, it would be handled elsewhere at a data center somewhere in the “cloud”. In this transition, the family computer wasn’t a hub anymore. Rather, it became another access point to the cloud. The battlefield completely changed in just a few years.

Although Microsoft made several plays to break into the smartphone market, none of them ever took off. Other than the Xbox and Surface, Microsoft never quite gained the traction it needed with its consumer hardware offerings. They did, however, strike gold in the cloud computing space with Azure around the same time. Over the next several years, Microsoft completely reimagined itself as a tech company focused almost exclusively on businesses. They always prioritized their business customers, but now more than ever, Microsoft’s consumer-facing ventures felt like a byproduct of their infinitely more lucrative B2B products and services. The pivot proved to be remarkably successful for them.

To get a better idea of where Microsoft’s priorities lie, consider how much of the company is even consumer-first anymore. Back when Microsoft was more serious about Xbox, they had entire hardware and software product categories specifically tailored to consumers. Other than Xbox, what’s left now besides Surface laptops? If this is the company’s new direction, why make a game console at all?

As it exists today, Xbox will never matter as much to Microsoft as PlayStation does to Sony. For both Sony and Nintendo, success in the games market is essential to their very existence. The stakes could not be higher. Xbox mattered quite a lot to Microsoft when the company cared more about directly targeting consumers, but not anymore. The drive from Microsoft’s corporate leadership to stay competitive in the game console space simply isn’t there. It never made meaningful money relative to Microsoft’s core businesses, and the company’s strengths were always elsewhere: first Windows and Office, now Azure.

Game Pass was an effort to make Xbox relevant to Microsoft again. It spoke to Microsoft’s executives in a way they could understand: here’s a recurring subscription service we can sell to consumers and an entire infrastructure that can be built on top of Azure. What if we could sell a white-label version of the service’s streaming platform to EA, Ubisoft, or even Sony? The possibilities were endless.

Unfortunately, it didn’t work out that way. People don’t play games the same way they watch shows or movies. No matter how many publishers and developers they pulled into the service’s orbit, players weren’t showing up in the numbers Microsoft’s leadership had hoped for.9 The big play to restore Xbox’s relevancy fell short.

Now, we’re here: a division belonging to a different era of Microsoft, growing less relevant by the day. Spencer bought them some time with Game Pass, but now that time has run out. You could put any executive in the same position and the result would have been the same. Eventually, the gap between Xbox and Microsoft’s vision of the future would grow too wide to keep Xbox around. Everything else is simply a debate of whether someone else would’ve gotten the division more time or less.

So what does Xbox mean to Microsoft? It was a lynchpin to owning every family’s home. Now? It’s a brand to license out to OEMs. It’s a brand to give Microsoft’s game publishing arm a recognizable name. In the end, that is all that will remain: a brand. Xbox, as we’ve known it, is gone. It has far outlived its original purpose. The grand experiment that began in 2001 is over.

Microsoft has moved on. It’s time that we do too.

1. [GameSpot] E3 2014: $399 Xbox One Out Now, Xbox 360 Sales Rise to 84 million (Mirror) ↩︎

2. [Sony Interactive Entertainment] Business Data & Sales (Mirror) ↩︎

3. [The Verge] Microsoft’s Xbox chief thinks losing the Xbox One generation was ‘the worst generation to lose’ (Mirror) ↩︎

4. [TheStreet] Costco pulls a popular product line from its warehouse shelves (Mirror) ↩︎

5. [Alex Battaglia via BlueSky] Looking over the year, our coverage of Xbox titles in videos almost feels like it is getting harder and harder to justify from a work return perspective. Very little views there even for titles that you think could draw them in. I wonder what the future is there. (Mirror) ↩︎

6. [Jez Corden via BlueSky] same and we literally only cover xbox from a gaming perspective. doing far more traffic on steam deck (!!!?) it’s wild. (Mirror) ↩︎

7. [Xbox] U.S. console pricing updates announced September 19, 2025 (Mirror) ↩︎

8. [Bloomberg] Xbox: The Oral History of an American Video Game Empire (Mirror) ↩︎

9. [Axios] Microsoft misses Xbox Game Pass subscriber target for second year (Mirror) ↩︎

Over the past year, I’ve gradually moved away from Microsoft’s products and services. Xbox, Office, Windows, you name it. Frankly, I’m not interested in dealing with Microsoft any more than is absolutely necessary.

As part of this effort, I’ve switched from GitHub to Worktree, a Gitea-based git hosting service. I’m not completely obliterating my presence on GitHub, but further work on my projects will live on Worktree instead.

I was never really much of an audio guy. Time signatures, tempos, measures—these were all abstract ideas. I knew they existed, but never what they meant or represented. So, if someone were to ask me in 2019 whether I’d ever work on anything even adjacent to a rhythm game, I’d say not a chance.

That is until my curiosity about a cartoon gorilla got the best of me.

In late 2019, during a conversation about cover songs in rhythm games, my friend Ian asked a harmless and throwaway question: can the cover songs in Donkey Konga be replaced with their originals? That was enough to send me down the rabbit hole. Let’s crack open the game and see what’s inside. What I found in the first game was promising: you could swap out the audio, but the notes were more complicated. It was not impossible to edit, but it required more work than I was willing to put in. I replaced the game’s version of All-Star by Smash Mouth with the original, and it worked. That satisfied Ian’s original question, but now I wanted to do more.

I shifted my attention to Donkey Konga 2 next. It turned out to be much more modular than the original. The songs used the same audio format as Donkey Konga 1 but kept the notes in easily modifiable MIDI files. In fact, you could even modify the metadata for each track, including the song title and assigned genre. This meant it was actually possible to replace the game’s existing tracks with entirely new ones. Jackpot!

Working with my friend Dexter, I put together a pipeline combining Reaper and a series of community-made tools to author tracks that can run in the game. I thought about writing a guide covering this process and sharing it online, but I kept procrastinating. Then, one night deep into the COVID-19 lockdown, I thought, “You know what’s better than writing a guide? An editor dedicated to making Donkey Konga tracks.” Konga Beat was born.

It was an imperfect process. What was supposed to be a short project ended up taking years. Some weeks, I would get swaths of features and bug fixes done; others were much less fruitful. For at least a year, I didn’t touch the project at all. Still, I jumped into it the same way every time: slowly chipping away at it, doing a little bit here and there until it transformed into something exciting and unexpected.

The first time I got a Konga Beat-made track to load in Donkey Konga 2, I nearly jumped out of my chair in excitement. Although I was always tempted to pursue other projects, I knew I wanted to see this one to the end. I loved the process of gradually putting everything together. So even if no one uses Konga Beat, that’s fine. I’m just glad I made it.

In that way, this project is self-indulgent. The Donkey Konga franchise is not popular enough to warrant a custom editor, much less the entire documentation infrastructure that goes along with it. A simple walkthrough, as others have posted in the years between me learning how to make custom tracks and releasing Konga Beat, would have been sufficient. There were several points in the development process where you could reasonably say Konga Beat was good enough to ship, but I couldn’t resist. Making the editor, assembling the site, commissioning artists, writing this preface—it was all too damn fun.

More than that, over the past four years, Konga Beat became a reliable port to keep returning to amidst the rolling storms. Life can be unrelenting and unforgiving, but Konga Beat always provided a much-needed reprieve. It’s fun, goofy, and unserious. How can you see Donkey Kong wailing away on bongos and not laugh?

If anyone does work with Konga Beat to make a track, I hope, above all else, it’s enjoyable and easy to use. Writing new tracks for a 20+-year-old GameCube game should be fun. Otherwise, why bother? Whenever you’re having a rough day, jump in, kick back, and enjoy some quality Konga time. Maybe it’ll give you the break you need, just as it did me. Because if there’s one thing I’ve learned while working on this project, there’s no better cure for the stresses of life than a giant cartoon gorilla banging out tunes.

This is Konga Beat.

The party is over. The era of companies offering their products and services at unsustainably low prices is coming to a close. Growing pressure from shareholders to transition from maximizing growth to maximizing revenue has pushed many commercial software companies to reevaluate their business models. In other words, introduce price increases and new fees. Those dependent on their software must now decide between accepting the increased financial burden or switching to alternatives. The video game industry is no exception to this changing tide as major game engine developers explore new ways to monetize their users. It raises a lot of questions for the community. How will we, as developers, manage these rising costs? Just as importantly, considering the immense impact licensing changes can have on developers, should Epic and Unity continue having a disproportionate influence on the game development landscape? While there is never a good time to wrestle with these questions, the rise of free and open-source game engines over the past decade gives independent game developers an opportunity to evaluate where free and open-source software can have a role in their next project.

I want to make this clear from the start: I will not be doing a head-to-head comparison of free and open-source game engines. The summaries of each engine discussed will not be exhaustive nor specifically highlight exclusive features. This is a celebration of the hard work of the game development community. I want to use this as a platform to get you excited about free and open-source game development and consider options beyond proprietary engines like Unity, Unreal, and GameMaker.

If I tried to cover every feature of every modern free and open-source engine, this wouldn’t be a single article but an entire book series. For that reason, I identified notable features and characteristics of some handpicked engines I thought would be worth sharing. While reading this, keep in mind that no engine is one-size-fits-all, and, as I’ll explain later, picking an engine is about choosing the right tool for you. With that out of the way, let’s start!

As the name suggests, free and open-source software (FOSS) includes two notable characteristics: it is free (libre) and its source code is available. You can use free (or libre) software for any purpose at your sole discretion. You will most commonly hear something like: “free as in speech, not free as in beer.” It may be available at no cost, but even more importantly, the user has complete control over the software. The open-source aspect of FOSS describes how everyone has access to the code that makes up the software.

Using a FOSS game engine provides several advantages. First, no licensing fees. While contributors always appreciate donations, none of the notable FOSS game engines expect or require upfront payment, subscriptions, or ongoing royalties. FOSS engines also provide independence from a single organization. If changes to a FOSS engine’s terms upset the community, the engine’s license allows developers to stick to the version with the most favorable terms and even fork off the project if they choose.

The community guides the development and growth of their FOSS game engine of choice. Many FOSS game engines have active and passionate communities that share their knowledge, advocate for their engine, and help newcomers. These vibrant and dedicated communities serve as a potent learning resource when working solo or as a small team. Some community members even contribute to their engine, improving it for everyone.

FOSS game engines allow anyone to modify the engine to fit their needs. For example, if the engine lacks a specific feature, has a persistent bug, or needs quality-of-life improvements, anyone can update it as necessary. They can even take the additional step of contributing the changes to the project for everyone’s benefit. One of the greatest strengths of FOSS game engines lies in their communities and a willingness for everyone to work towards a collective good.

Although FOSS game engines have existed for decades, the past several years have seen an explosion in the number of game engines available, as well as contributors, money, and resources dedicated to them. It would be impossible to cover all the FOSS game engines available now. In fact, if you have a passion for a particular language or framework, more likely than not, someone built a game engine with it.

This post will focus on some of the more notable modern FOSS game engines: Bevy, Godot, Open 3D Engine, and Stride. However, this is not an exhaustive list. As I mentioned before, there are more engines out there than I could ever cover in a single blog post. Many skilled and dedicated folks have put serious time and effort into making game engines and shared them with the world. I encourage you to use this post as a starting point and look at what each community offers.

• Written in Rust, Supported Languages: Rust
• Platforms:
  • Development (Code Only): Windows, Mac, Linux
  • Build Targets: Windows, Mac, Linux, iOS, Android, Web

As the most popular Rust-based game engine, Bevy offers a rich code-only development environment (an editor is coming in the future) capable of running on all major operating systems (Windows, Mac, and Linux). At the heart of Bevy’s vision for game development lies the Entity Component System (ECS) paradigm. While there are other resources available that can explain the benefits of ECS better, in a nutshell, ECS breaks down the code into three core pillars: entities, components, and systems. Entities are composed of components that can interact with each other using systems. For example, the player character could be an entity with a health component that tracks the player character’s health bar. An enemy character could also use that health component for the same purpose. ECS encourages modularity and reusability by enabling developers to create components applicable to distinct entities. While other game engines can approximate a similar system, Bevy makes this part of its core design ethos.

As established with Bevy’s use of ECS, the engine’s developers care deeply about modularity. The engine’s plugin system accentuates their commitment to that principle in every part of Bevy. Developers can organize the game’s systems into discrete plugins. An example of this is organizing all the UI code into a UI plugin. From there, developers can slot the plugin into the game’s initialization step. The plugin system helps organize the code and encourages modularity by allowing developers to add or remove the plugin based on their needs. This paradigm even applies to the engine’s core features, as they are all organized into plugins. It becomes trivial to activate or deactivate any part of the engine—including rendering, audio playback, and event loops—as the developer sees fit.

Asset libraries provide a wealth of resources that empower developers to learn the tools quickly and get their game to a playable state. The community assembled a library of assets available on the official website for everyone to use and share. Bevy’s library includes tutorials, plugins, and templates that address subjects like physics, networking, and input management. Even entire games and applications are available in the asset library to either build on or use as a reference while learning the engine. Bevy’s structure encourages developers to use any of the resources from this library freely as part of the building blocks that will make up their game. In conjunction with Rust’s package manager, there is a strong emphasis on modularity at every level of the engine.

• Written in C++, Supported Languages: GDScript, C#
• Platforms:
  • Development: Windows, Mac, Linux, Android (Experimental), Web
  • Target: Windows, Mac, Linux, iOS, Android, Web

Godot has the largest and most active community among all the modern FOSS game engines available to date. As the drama around Unity has unfolded, you have likely heard mentions of Godot on more than a few occasions. It is not without merit, as Godot encourages developers to shape the engine around their needs. Coming in at only 40 MB, the engine includes a lightweight, multi-platform editor capable of running on any major operating system (Windows, Mac, and Linux). In fact, you can even use a web-based or Android version of the editor, albeit with some constraints. Godot can meet developers on whatever platform works best for them.

GDScript is Godot’s primary programming language. While the prospect of learning an engine-specific language may turn you off at first, don’t fret! It shares a lot of commonalities with Python and Godot provides detailed documentation on how to use the language. Assuming you already have some experience with object-oriented programming, it won’t take long to get going with GDScript. You can even use C# for scripting if that is more up your alley, as it’s the other language officially supported by Godot. That said, if you would still like to write some code in another language entirely, Godot provides the means to use alternative programming languages by way of GDExtension.

Theoretically, GDExtension supports any programming language that can interact with its C-based API. While Godot officially supports scripting in GDScript and C#, GDExtension allows the community to introduce new language bindings to Godot’s development ecosystem, including Rust, Go, Swift, and Haxe. Not all language bindings are feature-complete, but many are in active development. With that in mind, committing to one language for an entire project is unnecessary, as GDExtension languages can work alongside GDScript. This means developers can, for example, even use GDScript with other languages like Rust in the same project.

Work in an editor long enough and you will probably want to tinker with it. For those interested in creating utilities and tools, as is common practice when using Unity or Unreal Engine, Godot provides the option to customize the editor to your liking. You don’t need to write in C++ and re-compile Godot to create plugins. Because the editor runs on Godot itself, it is possible to tune or extend the editor with GDScript, Godot’s scripting language, by simply appending @tool to the top of the file. Writing a plugin becomes as easy as writing code for your game.

• Written in C++, Supported Languages: C++, Lua
• Platforms:
  • Development: Windows, Linux
  • Target: Windows, Mac, Linux, iOS, Android

Open 3D Engine’s origins trace back to Amazon’s foray into game development. Amazon licensed Crytek’s CryEngine 3 and then used it as the foundation for their own game engine: Amazon Lumberyard. In the following years, Amazon offered Lumberyard for free to the community with specific terms requiring games built with Lumberyard use Amazon Web Services for their online features. By 2021, Amazon overhauled Lumberyard, rewrote 95% of the code, rebranded it as Open 3D Engine (O3DE), and placed it under the supervision of The Linux Foundation. Now, O3DE is available as a free and open-source engine under dual Apache and MIT Licenses for everyone, with no strings attached.

Only a few game engines offer visual scripting out of the box, and O3DE is one of them. O3DE supports both C++ and Lua for scripting, but for folks less inclined to write code, there is also Script Canvas, OD3E’s visual scripting environment. Visual scripting provides a way to write game logic without needing to write code in C++ or Lua. It presents programming concepts like functions, variables, and events as nodes that can be strung together in a graph. Script Canvas also allows developers to write custom nodes either in C++ or within Script Canvas itself to better fit their workflow. Fortunately, anything written using O3DE’s visual scripting system will not incur any serious performance hits, as the engine ultimately converts the graphs into Lua scripts.

O3DE modularizes its engine by breaking down major components into plugins called Gems. This is the paradigm through which O3DE manages all its features and plugins. For example, it is possible to swap out features like the physics engine, allowing developers to choose between PhysX 4, PhysX 5, or another solution entirely, custom or commercial. The modularity afforded by O3DE through Gems allows developers to add and remove components of the engine with relative ease–using as many or as few of the features as they want and in whatever combination best fits their needs.

With the Atom Renderer, the engine’s rendering system, O3DE strives to provide an advanced renderer that is also exceptionally customizable. The Render Pipeline Interface (RPI) and Rendering Hardware Interface (RHI) constitute the primary channels for working with Atom. The RPI provides the tools necessary for customizing the rendering pipeline and implementing higher-level graphical features, such as split screen or additional rendering passes. Meanwhile, the RHI abstracts access to the GPU’s functionality, allowing developers to write lower-level graphics logic without needing to target specific graphics APIs like DirectX or Vulkan. In short, the rendering stack provides incredible flexibility to developers.

• Written in C#, Supported Languages: C#, F#, Visual Basic
• Platforms:
  • Development: Windows
  • Target: Windows, Mac, Linux, iOS, Android

Stride began life as Xenko (and before that, Paradox): Silicon Studio’s premium game engine. After several years of providing Stride to the public through a subscription-based model, Silicon Studio released the engine’s source code and editor freely to the community under the MIT license. Among the higher profile FOSS game engines available, it is unique because Silicon Studio completely wrote it in C# from top to bottom. There is no delineation between the language used for the core engine and the language you would write with day-to-day while working on the game. It becomes much easier to override or change any inherent engine behavior when coding in the same language. No need to develop an interop system to interface with the engine’s core logic. With that said, the code-only version of Stride supports any language that is part of the .NET family (C#, F#, and Visual Basic), providing some flexibility in language choice.

The engine offers a pure .NET experience that includes many of the advantages inherent to the framework, like hot reloading. At the time of writing, Stride runs on .NET 8 (the latest version of the framework) and supports C# 12. Because the engine closely follows the .NET update schedule, you often get the most modern and up-to-date implementation of C#. You can seamlessly incorporate almost any C#-based library or tool available through NuGet, GitHub, and other platforms into Stride, enhancing your workflow. Stride is modular enough that sections of Stride are available as standalone NuGet packages. The engine provides the ability to tailor-make your game development experience.

The engine does its best to ensure it does not become a technical bottleneck for your game. A lot of processing within Stride is multithreaded. This means it allows logic to run on multiple threads of execution concurrently. The engine even implements a custom thread pool to maximize engine performance. As a result, Stride takes full advantage of the hardware it is running on, providing players with faster and smoother experiences. All the tools Stride uses to support multi-threading under the hood are also accessible to developers. Nothing is out of reach. An entire library exists within the engine focused on multi-threading that anyone can leverage in their projects. Used with features like the upcoming Bepu physics integration, it becomes possible to have tens of thousands of physics-based objects concurrently in a scene with little effort. Stride provides the space to explore multi-threading and have fun with it.

There is no one right answer. Don’t trust anyone claiming otherwise. Here is the truth: the answer lies in whichever you enjoy using the most. Game development is a process. It requires a healthy level of commitment and discipline. Anyone can do it, but you need to put in the effort. The better your tools fit with your way of working and thinking, the more likely you’ll commit to your project and put in your full effort.

All these engines are free and include active communities ready to help new folks. Pick whichever engines strike your fancy and try them. Maybe one of them has that one specific feature that hits just right. Maybe another has a community you love hanging out with or the engine integrates well with a tool you’re using already. Whatever the case, it’s a matter of taste and what works best for you.

Wanting to know if an engine can make a specific type of game is asking the wrong question. People make games in Excel. You can make just about any game in any engine. It’s not always a trivial task, but you can do it. Instead, ask yourself which tools you enjoy using the most.

When you settle on an engine, remember this: your engine is not your identity. Your tools are a means to creating something, not a core pillar of your very being. I cannot stress this enough. Your tools do not define you. This may sound obvious, but I have seen many, many folks make their engine of choice a centerpiece of who they are and become unnecessarily hostile toward other engine communities. Please don’t do that.

You are not simply a Bevy developer, Godot developer, O3DE developer, Stride developer, or whatever else. You are a game developer. So don’t get hung up on which engine you should pick. Choose the engine that resonates with you the most, and you’ll quickly learn skills you can apply anywhere. Make creating something rewarding in and of itself. If you enjoy working in your environment, you will enjoy the act of development. Once you manage that, creating anything, game or otherwise, will feel immensely satisfying in its own right. Be curious and have fun.

This article was only possible with the input of contributors and users involved in these game engines. I appreciate all the folks who were kind and patient enough to fact-check me and provide their feedback, including Vaclav Elias, Joreyk, Doprez, Judah Perez, Clay John, Adam Scott, Fredia Huya-Kouadio, Pāvels Nadtočajevs, as well as the Open 3D Foundation and Open 3D Engine contributors.

Last but not least, thank you to Ed (Meltted) for creating the featured image.

This post was originally written for Stride’s blog. It has been mirrored here with minor modifications.

This article offers a sample of basic Markdown syntax that can be used in Hugo content files, also it shows whether basic HTML elements are decorated with CSS in a Hugo theme.

The following HTML <h1>—<h6> elements represent six levels of section headings. <h1> is the highest section level while <h6> is the lowest.

Xerum, quo qui aut unt expliquam qui dolut labo. Aque venitatiusda cum, voluptionse latur sitiae dolessi aut parist aut dollo enim qui voluptate ma dolestendit peritin re plis aut quas inctum laceat est volestemque commosa as cus endigna tectur, offic to cor sequas etum rerum idem sintibus eiur? Quianimin porecus evelectur, cum que nis nust voloribus ratem aut omnimi, sitatur? Quiatem. Nam, omnis sum am facea corem alique molestrunt et eos evelece arcillit ut aut eos eos nus, sin conecerem erum fuga. Ri oditatquam, ad quibus unda veliamenimin cusam et facea ipsamus es exerum sitate dolores editium rerore eost, temped molorro ratiae volorro te reribus dolorer sperchicium faceata tiustia prat.

Itatur? Quiatae cullecum rem ent aut odis in re eossequodi nonsequ idebis ne sapicia is sinveli squiatum, core et que aut hariosam ex eat.

The blockquote element represents content that is quoted from another source, optionally with a citation which must be within a footer or cite element, and optionally with in-line changes such as annotations and abbreviations.

Tiam, ad mint andaepu dandae nostion secatur sequo quae. Note that you can use Markdown syntax within a blockquote.

Don’t communicate by sharing memory, share memory by communicating.
— Rob Pike1

Tables aren’t part of the core Markdown spec, but Hugo supports supports them out-of-the-box.

 1<!doctype html>
 2<html lang="en">
 3<head>
 4  <meta charset="utf-8">
 5  <title>Example HTML5 Document</title>
 6</head>
 7<body>
 8  <p>Test</p>
 9</body>
10</html>

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>Example HTML5 Document</title>
</head>
<body>
  <p>Test</p>
</body>
</html>

 1<!doctype html>
 2<html lang="en">
 3<head>
 4  <meta charset="utf-8">
 5  <title>Example HTML5 Document</title>
 6</head>
 7<body>
 8  <p>Test</p>
 9</body>
10</html>

1. First item
2. Second item
3. Third item

• List item
• Another item
• And another item

• Fruit
  • Apple
  • Orange
  • Banana
• Dairy
  • Milk
  • Cheese

GIF is a bitmap image format.

H2O

Xn + Yn = Zn

Press CTRL+ALT+Delete to end the session.

Most salamanders are nocturnal, and hunt for insects, worms, and other small creatures.

1. The above quote is excerpted from Rob Pike’s talk during Gopherfest, November 18, 2015. ↩︎

Hugo ships with several Built-in Shortcodes for rich content, along with a Privacy Config and a set of Simple Shortcodes that enable static and no-JS versions of various social media embeds.

“In addition to being more logical, asymmetry has the advantage that its complete appearance is far more optically effective than symmetry.”
— Jan Tschichold pic.twitter.com/gcv7SrhvJb

— Design Reviewed | Graphic Design History (@DesignReviewed) January 17, 2019

Lorem est tota propiore conpellat pectoribus de pectora summo.

Redit teque digerit hominumque toris verebor lumina non cervice subde tollit usus habet Arctonque, furores quas nec ferunt. Quoque montibus nunc caluere tempus inhospita parcite confusaque translucet patri vestro qui optatis lumine cognoscere flos nubis! Fronde ipsamque patulos Dryopen deorum.

1. Exierant elisi ambit vivere dedere
2. Duce pollice
3. Eris modo
4. Spargitque ferrea quos palude

Rursus nulli murmur; hastile inridet ut ab gravi sententia! Nomine potitus silentia flumen, sustinet placuit petis in dilapsa erat sunt. Atria tractus malis.

1. Comas hunc haec pietate fetum procerum dixit
2. Post torum vates letum Tiresia
3. Flumen querellas
4. Arcanaque montibus omnes
5. Quidem et

The Van de Graaf Canon

Victa caducifer, malo vulnere contra dicere aurato, ludit regale, voca! Retorsit colit est profanae esse virescere furit nec; iaculi matertera et visa est, viribus. Divesque creatis, tecta novat collumque vulnus est, parvas. Faces illo pepulere tempus adest. Tendit flamma, ab opes virum sustinet, sidus sequendo urbis.

Iubar proles corpore raptos vero auctor imperium; sed et huic: manus caeli Lelegas tu lux. Verbis obstitit intus oblectamina fixis linguisque ausus sperare Echionides cornuaque tenent clausit possit. Omnia putatur. Praeteritae refert ausus; ferebant e primus lora nutat, vici quae mea ipse. Et iter nil spectatae vulnus haerentia iuste et exercebat, sui et.

Eurytus Hector, materna ipsumque ut Politen, nec, nate, ignari, vernum cohaesit sequitur. Vel mitis temploque vocatus, inque alis, oculos nomen non silvis corpore coniunx ne displicet illa. Crescunt non unus, vidit visa quantum inmiti flumina mortis facto sic: undique a alios vincula sunt iactata abdita! Suspenderat ego fuit tendit: luna, ante urbem Propoetides parte.

Mathematical notation in a Hugo project can be enabled by using third party JavaScript libraries.

In this example we will be using KaTeX

• Create a partial under /layouts/partials/math.html
• Within this partial reference the Auto-render Extension or host these scripts locally.
• Include the partial in your templates like so:

1{{ if or .Params.math .Site.Params.math }}
2{{ partial "math.html" . }}
3{{ end }}

• To enable KaTex globally set the parameter math to true in a project’s configuration
• To enable KaTex on a per page basis include the parameter math: true in content files

Note: Use the online reference of Supported TeX Functions

Block math: $$ \varphi = 1+\frac{1} {1+\frac{1} {1+\frac{1} {1+\cdots} } } $$

Emoji can be enabled in a Hugo project in a number of ways.

The emojify function can be called directly in templates or Inline Shortcodes.

To enable emoji globally, set enableEmoji to true in your site’s configuration and then you can type emoji shorthand codes directly in content files; e.g.

🙈 :see_no_evil: 🙉 :hear_no_evil: 🙊 :speak_no_evil:

The Emoji cheat sheet is a useful reference for emoji shorthand codes.

N.B. The above steps enable Unicode Standard emoji characters and sequences in Hugo, however the rendering of these glyphs depends on the browser and the platform. To style the emoji you can either use a third party emoji font or a font stack; e.g.

1.emoji {
2  font-family: Apple Color Emoji, Segoe UI Emoji, NotoColorEmoji, Segoe UI Symbol, Android Emoji, EmojiSymbols;
3}