Missed JetBrains GameDev Day 2026, or want to revisit your favorite sessions? All the recordings are now available on YouTube!

On September 28, we brought together game developers, engineers, and industry experts for a full day of technical talks, live demos, and discussions about the tools and challenges shaping modern game development.

From Epic’s open-source Lore VCS and ECS in a live game to Unreal Engine profiling, Unity UI automation, AI-driven PCG in Godot, and debugging across C# and C++, this year’s sessions stayed close to real production problems.

Whether you joined us online, attended one of our watch parties in Belgrade or Limassol, or couldn’t make it this time, you can now catch up on everything at your own pace.

Watch the full JetBrains GameDev Day 2026 playlist on YouTube

Watch the sessions

Not sure where to start? Pick your engine or role:

• Unreal Engine: Death by a Thousand Ticks and Agentic Development in Unreal Engine with JetBrains Rider
• Unity: Fix Your CI Without Leaving the IDE and How We Automated Figma-to-Unity UI Integration With AI Agents
• Godot: Prompt to Playable World
• Engine and backend programmers: Evolving a Live Game Engine and Debugging Across Two Runtimes and Two Different Languages
• Build, pipelines, and infrastructure: Splitting the Difference and Code Quality Never Changes
• Everyone, especially leads and juniors: Pass the Controller?

Pass the Controller? Communities, Data, and AI in Game Development

Anthony Tešija (Discord), Jason Weimann (Boddle Learning), Gennadii Potapov (General Arcade), and Anton Licht (Sudden Forest)
Moderated by Denis Savosin (JetBrains)

Our opening panel explored the role of communities, data, and AI in game development. When should developers listen to community feedback, and when is it better to trust their own vision? How can AI support developers without replacing critical thinking, especially for those just entering the industry?

Fix Your CI Without Leaving the IDE: TeamCity MCP and CLI (with Unity)

Artem Rokhin (JetBrains)

Discover how TeamCity’s MCP support and CLI bring continuous integration workflows directly into your development environment. Using a Unity project as an example, Artem demonstrated how to investigate build failures and interact with CI pipelines without constantly switching between tools.

Learn more: TeamCity MCP and CLI for AI agents

Evolving a Live Game Engine: Introducing ECS Without a Full Rewrite

Alex Zhorau (Meta)

How do you bring an Entity Component System into a mass-market game that’s already live without rewriting the engine? Drawing on proprietary engines and Unreal Engine, Alex walked through a staged migration, the compromises around memory layout and scripting, and why a hybrid of ECS and legacy code is often where a live game should end up, not just a stop along the way.

Code Quality Never Changes: How Static Analysis Can Help in the Age of AI

Kai Schmithusen (JetBrains)

AI-generated code brings new productivity opportunities, but also new challenges for code quality. Learn how static analysis can help teams identify issues, manage technical debt, and maintain reliable development workflows, with practical examples using Qodana.

Learn more: Qodana

Prompt to Playable World: Live-Building AI-Driven PCG with Godot, C#, and Gemini

Sharmishtha Sen (Jet Heart Labs)

Watch a procedural world generation pipeline come together using Godot, C#, and AI. Sharmishtha demonstrated how to turn natural-language prompts into playable environments while combining AI-generated configurations with traditional procedural generation techniques and Rider’s development tools.

Learn more: Godot support in JetBrains Rider

Death by a Thousand Ticks: Why Gameplay Systems Become Slow

Konrad Słoń (Fool’s Theory)

Performance problems rarely appear overnight. Through Unreal Engine examples and live profiling, Konrad explored how small engineering decisions accumulate into gameplay bottlenecks and demonstrated practical optimization workflows using Unreal Insights and Rider.

How We Automated Figma-to-Unity UI Integration With AI Agents

Alina Chupakhina (Playkot) and Olia Chupakhina (Cubic Games)

Alina and Olia shared a Figma-to-Unity pipeline that grew over years of production and now runs through an AI agent over MCP. They covered the design foundation that makes automation possible, the lessons learned from building it, and a benchmark of which UI integration tasks the agent can handle today and which still need a human.

Agentic Development in Unreal Engine with JetBrains Rider

Alexander Dzerakh (JetBrains)

Go beyond AI-assisted code generation with agentic workflows tailored to Unreal Engine. Through live demos, Alexander showed how Rider, ACP, and Unreal Engine-specific skills can help AI agents navigate engine architecture, generate C++ code, investigate crashes, and automate development tasks.

Learn more: AI agent skills for Unreal Engine in Rider

Splitting the Difference: How Epic’s Lore VCS Handles Massive Binary Files

Ben Cooke and Ryn Slack (AWS)

Most version control systems were built for code, not multi-gigabyte assets that change every day. Ben and Ryn explained how Epic Games’ open-source Lore VCS splits files into content-addressable fragments so only the changed part of an asset moves, why its edge caches can fill on demand instead of being pre-seeded, and how to deploy it yourself with the Lore module in the AWS Cloud Game Development Toolkit.

Learn more: Lore on GitHub · Lore documentation · AWS Cloud Game Development Toolkit

Debugging Across Two Runtimes and Two Different Languages

Alex Drum (Hytale)

Your client is C#, your server is C++, and the bug lives somewhere in between. Alex showed how to debug both runtimes at once with Rider and CLion, read the data crossing the protocol, and figure out which runtime is lying, and discussed why the boundary between them is the last place to look, not the first.

Keep learning and building

A huge thank you to all our speakers, hosts, and everyone who joined us online or at our watch parties in Belgrade and Limassol! Special thanks to DevGAMM x FTW! for co-hosting our Belgrade watch party. We hope these sessions give you new ideas, useful techniques, and inspiration for your own projects.

Watch all JetBrains GameDev Day 2026 recordings on YouTube

If you’d like to explore the tools featured throughout the event, check out JetBrains tools for game development.

Many of the demos ran in JetBrains Rider, which is free for non-commercial use, including learning, pet projects, and open-source contributions.

To hear about the next GameDev Day first, subscribe to the JetBrains GameDev newsletter.

See you at the next GameDev Day!

I was recently asked to look at a change one of our developers made to RavenDB. He was chasing a particularly slow query with spatial sorting (a “find me all the nearest Thai restaurants” style of query). He found the root cause and had a fix ready. The fix gave us a 25% improvement in query processing time, and the change was about 15 lines of code.

A few years ago, I would have said: great job, merge it, ship it, let customers enjoy the faster queries. But I got a hunch that we could do something different. We asked the AI model to try it out. It took a non-trivial amount of work to even test that, while in the past, it would have taken a few days just to try it out.

The model was able to complete the spike while we were talking about why this should be a good approach and the architectural-level aspects that were driving it.

The result of that spike was an improvement of 12x. Not 12%. Twelve times faster. A 25% improvement is a wow;a 1,100% improvement is damn. In essence, we took a shortcut a couple of decades ago and had to pay a lot more than we could have.

Note that a 15-line fix is local, easy to understand and verify. A structural change like this is… not. We also have to deal with backward compatibility concerns (we had to change the index format), verify that we get the same output in both cases, etc.

Along the way, we found three separate bugs that had been in the product for 10 to 15 years. They're all in very weird edge cases. What happens when you sort on a spatial field that doesn't exist?

If a document has no spatial value, we would treat the missing value as zero distance, which means it is the closest result. I can argue that this is the correct behavior, but not convincingly.

The PR went from 15 lines of code to about a thousand. Review time for that went from under 10 minutes to over an hour.

Compare this to the same task four years ago: a few hours to isolate and understand the problem, a couple of hours to figure out how we could optimize this, write the code, etc. The overhead of actually reviewing the code and merging it would be pretty minimal.

Today, it took an hour to reproduce the problem, another with the model to find & propose the original 15-line fix. Then we dove deeper into this and did the rest in another couple of hours. The 1K LoC PR would take two hours to review.

Interestingly enough, I don’t think we would have hit on the 15-line fix if we had been working manually. That took advantage of a library function I didn’t even know existed. We would have headed directly to the proper fix we ended up with.

That leads to a few observations about the process. The quick fix with the AI would have delivered an inferior end result. It is funny when I say that a 25% improvement is inferior, but it would have been in this case.

The other aspect is that each decision we made along the way made sense, but we ended up with something that was big. To the point that you need to meditate over the code to understand it.

This is a very small and focused change, mind. And it grew from 15 lines to 1K. We are seeing the size of PRs grow from a few hundred to many thousands of lines of code.

All of that pushes the complexity into the review process. And for long-lived software, review is not something you can skimp on. RavenDB has been around since 2009. Code we merge today is code we will be supporting and reasoning about for the next decade.

There is a wide spectrum of opinions on this right now. Some people say they never read the code; some have an agent review it. Others insist on going through every line, and that is where I stand.

The code that goes into RavenDB gets a manual review by a person who understands everything about the system. Not just whether the code is correct, but how it interacts with all the other stuff we have, the history behind it, and the things that are not in the diff.

Productivity? Where is it at?

As an industry, we expected AI to make us dramatically faster. If AI writes 90% of the code, sometimes 100%, shouldn’t we be shipping more often? And better software as well, no?

Every developer I've talked to says the same thing: I cannot not use AI. The benefits are too high to give up. I have seen people who left the IDE entirely and some who just use AI to explain and reason about the code, but everyone is using AI in some capacity. But we aren't seeing the change in productivity that everyone predicted.

I think a big part of the answer is in the story above. We aren't doing the same work faster. We're doing more work, arguably better work. We find opportunities we would never have considered, because the cost of checking a hunch dropped significantly. The cost of accepting the answer didn't decrease; in fact, I would argue that it became much higher.

To be clear about the scale of this: RavenDB did not suddenly get 12 times faster across the board. As much as I wish a 1K PR could do that. A single scenario got dramatically better. That is great, but it is also more code, more behavior to understand, and more surface area to maintain.

When we keep going like that, we end up with better software overall, but also a much larger mass of code to work with. It also means much more effort from the people who actually have to deliver it.

I think that we’ll see major shifts in how we build and maintain software, but at the same time, I think that the key fundamentals haven’t really changed. In the past quarter, RavenDB (the company, not the software) hired more R&D staff than we did in the past two years, to give you some context.

There is going to be a greater need for developers than ever, and even more digitalization of the world.

Introducing Kimi K3.1 Pro

Kimi K3.1 Pro landed on the Kimi API today - it's not yet open weights, but Moonshot promise "Full model weights will be released by Nov 4, 2026".

They're also offering a "Highspeed" version that's 2-3x faster, at twice the price (except for input token cache hits, which are priced the same).

The US dollar pricing is $2.00/million tokens for input and $10/million for output - the same as GPT-6.1 Sol and half the price of Claude Opus 5.5.

Moonshot's own benchmarks show Kimi as approximately level with Opus 5.5 and GPT-6 Astra - beating them on a few benchmarks, coming close on others.

Artificial Analysis scored Kimi at 55 - ahead of Claude Fable 5.1, GPT-6 Astra, and Gemini 4 Argon (all at 53) and behind only Claude Opus 5.5 (58).

This is the first time a (soon-to-be) open weight model has scored this highly against the frontier.

I tried it out via the Moonshot API using the llm openai endpoint command I added to LLM 0.32 back in August:

llm openai endpoint \
  https://api.moonshot.ai/v1 \
  --key kimi \
  -m kimi-k3.1-pro \
  "Generate an SVG of a pelican riding a bicycle" \
  --responses \
  -o reasoning_effort low \
  > kimi-k3.1-pro-pelican-low.stdout.txt \
  2> kimi-k3.1-pro-pelican-low.stderr.txt

llm openai endpoint can run prompts against any OpenAI-compatible endpoint but doesn't log the results, hence the extra options to save stdout and stderr (the reasoning trace).

Here are the pelicans I got for Kimi K3.1 Pro on the three reasoning levels it supports - low, medium, and max. This is max:

For comparison, I ran fresh pelicans against Kimi K3 on those three reasoning levels.

Via Hacker News

Tags: ai, generative-ai, llms, llm, llm-pricing, pelican-riding-a-bicycle, llm-release, ai-in-china, moonshot, kimi

OpenAI explains how we strengthened containment for frontier model training and evaluation, including offline environments and high-compute red-teaming.

For the first time, the UN has declared that exceeding the Paris Agreement's 1.5C warming limit is "imminent and unavoidable." "We are now saying this window has closed, but we can open it again by making the overshoot as brief as possible," UN Environment Program Executive Director Inger Andersen said on a call with reporters. "This is about how to find a way back as shortly and as quickly as possible with as limited an overshoot as possible." CNN reports: Past reports have examined the distance between countries' emissions reduction commitments and what it would take to limit global warming to 1.5 C above preindustrial levels. However, this year's report redefines the gap. Instead, it examines new emissions overshoot scenarios, and what it would take to limit peak warming to just 1.7 to 1.8 degrees C before bringing temperatures back down to 1.5 C through emissions cuts and the use of carbon removal technologies. The report makes clear that every additional fraction of a degree of warming above 1.5 C "raises the risk of irreversible changes including in ice sheets, permafrost carbon, ocean circulation, and coral systems, along with devastating human impacts." Each added fraction of a degree of warming can have an "immense" impact "as measured in terms of damage, cost and loss of lives," said climate scientist Michael Mann of the University of Pennsylvania. Mann was not involved in producing the UNEP report. According to the UNEP, which is based in Nairobi, the lowest overshoot scenario would keep peak warming to between 1.7 and 1.8 degrees C and return global average temperatures to at or below 1.5 C by 2100. However, to follow such a pathway, global greenhouse gas emissions would need to be slashed by far more than anything currently on the table at the upcoming COP31 talks. This would require an 18% cut by 2030, 45% by 2035, and 69% by 2040, relative to 2025 levels. Meeting this lowest-possible overshoot scenario would require a tripling of renewable electricity capacity by 2035, and dramatic cuts to fossil fuels, including the phaseout of coal by 2040, the report states. In addition, there would need to be a major scaling up of carbon removal technologies, which so far have not been proven to work at such a large scale. In stark contrast to these figures, the fulfillment of existing emissions reduction pledges would only yield a 5-to-8% emissions cut by 2030 and an 11-to-15% reduction by 2035, the report found. This would be associated with a peak warming of about 2.6 degrees C. If countries simply follow their current policies, then warming could reach a peak of about 2.8 C. That estimate has increased since last year, in part because of the withdrawal of the United States from the Paris Agreement and retraction of its emissions reduction commitments, the report states. Even the scenario that assumes countries meet their existing reduction commitments, and nations with net-zero pledges succeed in fulfilling them, still brings warming to a peak of 2.1 C.

Read more of this story at Slashdot.

Who gets to shape a future that will impact us all, and what happens when the voices we need most are missing from the room?

In this episode, Toni Townes-Whitley joins the WIT Podcast for a wide-ranging conversation about leadership, technology, and the responsibility that comes with having a seat at the table. She explores the growing intersection of technology and civic life, the need for greater accountability as AI outpaces policy, and why women must be part of shaping what comes next. Toni also reflects on resilience, building a career beyond titles, and what it means to get in the room, stay in the room, and ultimately open it for others.

https://www.linkedin.com/in/toni-townes-whitley/

Download audio: https://dts.podtrac.com/redirect.mp3/media.transistor.fm/6e2b0185/20562aa6.mp3