标签：#gamedev

Enlace a post en Español Click If you are developing games in Godot and using AI to help you code, you are probably tired of constantly switching tabs between your editor and the browser. Copying code, pasting it, explaining your scene context over and over again... it is a massive workflow killer. To solve this, I built Golem-AI (named after the Godot Engine logo because let's face it, it looks like a tiny, friendly mechanical golem). It is a "Cursor-style" AI assistant extension integrated directly into a dock right inside your Godot 4.2+ editor. Today, I am opening the repository to the community as a completely open-source project. It is currently in Beta and has some bugs, but it is fully functional, and I want to share it so we can improve it together. / ____/___ / /__ ____ ___ / | / _/ / / __/ __ \/ / _ \/ __ `__ \______/ /| | / / / /_/ / /_/ / / __/ / / / / /_____/ ___ |_/ / \____/\____/_/\___/_/ /_/ /_/ /_/ |_/___/ 🎮 How it Looks Inside the Editor Here is a glimpse of the integrated dock interface, its session history, and the context autocomplete system in action: 🔥 Key Features 🦙 Local & Cloud Providers: Connect it to Ollama or LM Studio for a 100% free, offline local workflow, or hook it up to OpenAI, Anthropic, Gemini, or Cursor proxies. 🧠 Cursor-Style UX & Context (@ Mentions): Type @ in the chat composer to automatically attach open scenes, specific project files, or custom skills directly into the prompt. 🛠️ Editor Tool Calling: It features an optional multi-step verification loop. The AI can actually interact with native Godot editor tools to help you iterate and fix things faster. 📚 Markdown Skills System: Feed the assistant specific workflows, style guides, or documentation using standard markdown files (/skill or @skill :id). 💬 Advanced Chat UI: Built-in "thinking blocks", agent step progress tracking, searchable history sessions, and a native bilingual UI (English / Spanish). 🛠️ The Current State: "It works, but..." (Looking for Beta Testers!) L

As a developer who frequently switches between competitive FPS titles like CS2 and Valorant, re-tuning mouse sensitivity is always a hassle. I wanted a fast, ad-free tool to translate my aim perfectly across titles, so I built a clean Game Sens Converter . The Approach I built this using 100% Vanilla JS. It’s a simple utility, so there was absolutely no need for a backend or heavy frameworks. It loads instantly and calculates right in the browser. Here is a quick look at the core logic handling the sensitivity conversion multipliers: function convertSensitivity ( gameFrom , gameTo , currentSens ) { // Standardized multipliers relative to CS2 / Source engine const multipliers = { ' cs2 ' : 1 , ' valorant ' : 3.181818 , ' overwatch ' : 0.3 , ' apex ' : 1 }; if ( ! multipliers [ gameFrom ] || ! multipliers [ gameTo ]) return null ; // Convert to base (CS2), then to the target game const baseSens = currentSens * multipliers [ gameFrom ]; const convertedSens = baseSens / multipliers [ gameTo ]; return convertedSens . toFixed ( 3 ); } Try it out You can use the live tool for free here: Game Sens Converter Let me know what your main game is or if you'd add any other FPS titles to the list in the comments!

I didn’t expect to care this much about language tools. I started messing around with two different projects, Linguaboard and Parley , mostly out of curiosity. What I got was a surprisingly clear look at two very different ways we interact with language as developers and builders. Linguaboard: translation as exploration, not just output Linguaboard isn’t trying to give you the translation. Instead, it feels more like it’s saying: “Here are several valid ways this could be expressed, pick what fits your intent.” That shift is subtle but important. Most translation tools optimize for a single “correct” answer. Linguaboard leans into ambiguity in a way that actually helps you understand nuance instead of hiding it. I found myself thinking less like: “What does this mean?” and more like: “How should this sound in context?” Parley: learning through interaction, not memorization Parley takes a completely different angle. Instead of treating language as something to decode, it treats it as something to use. You’re not just passively consuming translations, you’re engaging with patterns, context, and recall in a more active loop. What stood out to me is how quickly it shifts you out of “study mode” and into “usage mode.” It feels closer to building intuition than studying rules. The interesting contrast What I didn’t expect is how well these two complement each other: Linguaboard → helps you understand nuance and meaning Parley → helps you internalize and use language One is about interpretation, the other about retention through interaction. Put together, they highlight something a lot of dev tools miss: Language work isn’t one problem. It’s at least two: understanding, and using. Why this matters (especially for devs) If you’re building anything with multilingual UX, AI translation, or global audiences, you’ve probably hit this wall: Translation APIs give you “correct” text But correctness ≠ clarity, tone, or intent These tools made that gap feel very obvious to me. And o

When we started experimenting with AI translations, we assumed the biggest challenge would be accuracy. We were wrong. The harder problem was preference. Give two AI models the same sentence, and both translations can be technically correct. Yet people almost always have a favorite. One sounds more natural. One feels more human. One is the version they'd actually use. That observation eventually led us to build Parley , a simple game where players compare two translations and choose the better one. What happened next surprised us. People became highly engaged with a task that looked almost trivial. They started debating word choices, discussing tone, and noticing subtle differences between translations. Some users spent far longer interacting with translation examples than they ever would reading documentation or language-learning materials. It highlighted something interesting about AI products: evaluation can be more engaging than generation. Most AI interfaces focus on creating content. But humans are often much better at judging quality than producing it from scratch. Asking someone to choose between two outputs requires less effort while still training their intuition. The experiment also changed how I think about language learning. Traditional language apps often rely on memorization and repetition. But comparing alternatives forces you to think about meaning, context, and natural expression. You're not just learning vocabulary, you're developing taste. And in a world where AI can generate endless content, taste might become one of the most valuable skills we can build. Have you seen similar patterns in AI products where evaluation turns out to be more engaging than creation?

Hey. No new feature this time - just a pass through the corners before the next one. We had a list of nine bugs we'd written down and kept walking past. Most were small. One wasn't, and it was hiding behind a button. When you import a file the studio already has - same bytes - we ask whether to share the existing file or make an independent copy you can edit on its own. Pick "independent copy" and you expect exactly that: your own file, safe to change or delete without touching anything else. It mostly worked. But the new copy's internal name was built from how many copies already existed - copy 2, copy 3, and so on. The problem shows up after a delete. Say you had three, removed the middle one, then made another. The new one counted "two exist, so I'm number three" - but number three was already taken. The studio saw the clash, quietly kept the old file, and pointed your new scene at it. You thought you'd made a clean copy; you were sharing the original, and the real copy you just made was orphaned on disk with nothing pointing at it. Edit "your" copy later and you'd be editing the original too. Nothing crashed. Nothing warned you. That's the worst kind. The fix: stop counting, and instead look at which names are actually taken and pick the first free one - so a copy made after a delete always gets its own identity. We also made the studio shout in the logs if two files ever collide again, instead of silently dropping one. Better a loud bug than a quiet one. The rest were smaller. A menu element could jump for a single frame when you grabbed it (the drag started from where the element was saved , not where it was shown ). A countdown number sat blank for one frame before popping in. And the end screen had a leftover timing delay we fixed - which you'll never see, because that screen is solid black either way. Real bug, just invisible. The one we'd marked most important? We went to fix it and found a rebuild from two weeks ago had already solved it. We checked three

As part of my game development journey, I recently created Hidden Collector , a Unity-based game where players explore levels and collect hidden items while progressing through different challenges. This project started as a way for me to improve my Unity and C# skills, but it quickly became an opportunity to learn about game design, UI systems, audio management, scene transitions, and player experience. What I Worked On While building Hidden Collector, I implemented: Player movement and interactions Collectible item systems Multiple game levels UI menus and game screens Audio and sound effects Progress tracking Game flow and scene management Challenges During Development One of the biggest challenges was making different game systems work together smoothly. Something as simple as collecting an item often required updates to UI elements, game state management, and progression systems. Debugging these interactions taught me a lot about organizing Unity projects and writing maintainable code. What I Learned This project helped me gain experience with: Unity Engine C# scripting Game architecture UI implementation Audio management Debugging and testing Most importantly, I learned that building complete projects teaches far more than following tutorials. Play the Game You can try Hidden Collector here: https://sinxcos07.itch.io/hiddencollector Screenshots What's Next? I'm continuing to improve my game development skills by building new projects, experimenting with different mechanics, and learning more about creating engaging player experiences. If you try the game, I'd love to hear your feedback. By Suryansh Sinha (sinxcos07) Connect With Me GitHub: https://github.com/sinxcos07 LinkedIn: https://www.linkedin.com/in/suryansh-sinha/ Play Hidden Collector: https://sinxcos07.itch.io/hiddencollector

Hi! I want to share a project that I work for a while. It started from idea to get rid off manual copying data from game design documents to game engine. Here you can define your game objects, their props, relations and everything will be stored in structural JSON format that can be read by Unity, Godot, Unreal and other engines. What we have now? construct **wiki-like documents **using a block editor and template system (markdown is supported too) design dialogues of your game in special graph editor create maps and prototype levels on canvas store and manage database of game objects use created objects inside engine directly or export data to customizable data formats (arbitrary JSON, CSV) Made it free and open source. Please try (have Windows and Mac builds) and give your feedback Source code: https://github.com/ImStocker/ims-creators Itch.io: https://nordth.itch.io/imsc-desktop

Bugs, crashes, glitches... Game development is full of them, and even experienced teams run into issues. But while no game is perfect, that doesn't mean we should stop chasing better quality. In this live session, we'll look at why even seasoned game development teams make mistakes and how you can reduce the number of issues in your own projects. What's the talk about? The speaker, Gleb Aslamov, developer advocate and static analyzer developer at PVS-Studio, will walk you through common and less obvious reasons behind code errors, share real-world bug examples from actual game projects, discuss development practices that help prevent bugs before release, and demonstrate tools designed to catch those issues early. Gleb will show some amusing bug examples from projects like osu!, GZDoom, and SanAndreas Unity. The discussion will cover how code reviews, testing, and CI/CD, combined with profilers, dynamic analyzers, and static analyzers, can help detect issues long before players ever encounter them. Also, expect to see static analysis in action, including warnings that reveal performance-sensitive issues and other hidden problems in game code. When? Mark your calendar for June 2, 2026, at 1:00 PM UTC+1 . Join the live talk and learn how to make your game code more reliable—one bug at a time. P.S. And don't forget to check your inbox to confirm the registration!