标签：#game

Everyone says the same thing: Flutter is for apps, not games. So I decided to find out where that's actually true — by building a 3D endless runner in Flutter. From scratch. No Unity, no Unreal, no game engine at all. Just Dart and Flutter's own rendering stack. It runs in your browser right now: ▶️ Play it live (desktop, keyboard controls — A / D to switch lanes, Space to jump). Here's how it works, and what building it taught me about how far Flutter can actually go. The stack: Flutter GPU + flutter_scene The whole thing sits on two pieces most Flutter developers have never touched: Flutter GPU — a low-level rendering API that talks almost directly to the GPU through Impeller (the engine that replaced Skia). This is what makes real-time 3D possible at all. flutter_scene — a higher-level 3D scene API on top of Flutter GPU. It gives you the building blocks a game needs: a scene graph of nodes , a perspective camera , meshes, and glTF model loading. You build a tree of nodes, point a camera at it, and render it every frame inside a normal Flutter widget. That last part still surprises me — the 3D world is just a CustomPaint -style surface living inside an otherwise ordinary Flutter app. Faking an infinite world with a handful of objects An "endless" runner obviously can't build an endless world — you'd run out of memory in seconds. The trick is object pooling : you keep a small pool of track segments and obstacles, and as they scroll past the camera behind the player, you recycle them back to the front with new positions. The player never actually moves forward. The world moves toward the player , and a fixed number of segments cycle forever. Same idea for obstacles and coins. It means the game runs at a constant, tiny memory footprint — which is exactly what keeps it smooth on weaker devices. The parts that were genuinely hard Collision that feels fair. Detecting a collision is easy. Making it feel right is not. Too strict and the player rages at hits that "clearly

It's impossible to talk about a new Xbox game without also talking about the state of Xbox. Microsoft's gaming division is in freefall: Recent headlines are dominated by extensive layoffs, decimated studios, and confusing strategies, most of which stem from years of bad decisions and expensive acquisitions. But it wasn't always that way. Through its […]

In 1996, Bandai sold 82 million Tamagotchis. Kids carried egg-shaped plastic keychains everywhere, frantically pressing three buttons to feed, clean, and play with a pixelated blob that would literally die if you ignored it during math class. It was the first time millions of people felt genuine emotional attachment to a piece of software. 30 years later, I rebuilt that entire experience — in the browser, with TypeScript, zero dependencies, completely open source. No app store. No download. No install. Just open a tab and adopt your pet. And in the process, I learned more about state machines, game loops, and emotional design than any computer science course ever taught me. Why Build a Virtual Pet in 2025? Three reasons: 1. Nostalgia Is a Distribution Hack People share things that trigger childhood memories. It's not rational — it's emotional. A browser-based Tamagotchi hits a nerve that no todo app or dashboard ever will. When I shared an early prototype, the response wasn't "cool tech stack." It was: "OH MY GOD I used to cry when mine died in second grade" That emotional reaction is worth more than any Product Hunt launch. 2. Game State Machines Are Criminally Underrated Every tutorial teaches state machines with traffic lights or toggle buttons. Boring. Useless. Forgettable. A virtual pet has dozens of interconnected states , real-time decay, evolution paths, conditional transitions, and edge cases that force you to actually think about state architecture. After building this, implementing complex UI flows in production apps felt trivial. 3. Not Everything Needs to Be a SaaS The indie dev world is obsessed with "revenue-generating side projects." Sometimes you should build something purely because it makes people smile. The best projects are the ones you'd use even if nobody else existed. Meet Your New Pet When you open Tamagochi, you get an egg. It hatches. A tiny pixelated creature appears. It has needs. Meet them, and it thrives. Ignore them, and... well, game

Table of Contents: Introduction Constants Singletons & Services Singleton Service Locator Introduction Every Unity developer eventually hits the exact same wall: how do I get my UI script to talk to my Game Manager without turning my codebase into a tangled web of dependencies? Managing global state is a fundamental challenge in game architecture, and the internet is full of conflicting, often dogmatic advice on how to handle it. In this article, we are going to look at some popular approaches to managing global state: Static Constants, Singletons and Service Locator. Before we start though, I encourage you to read some of my previous blog posts in this series on project scaffolding or, even more crucial to some sections in this article, the bootstrapping process . Constants Not every piece of global data needs a instance to live in, interfaces, or an initialization phase. Some data is constant and never changes at runtime (constants). These constants are usually defined with static readonly or const (at least they should be if they never change). Example: public static class MathConstants { public const float MilesToKm = 1.60934f ; } public class CharacterAnimationController : MonoBehaviour { // we must use static readonly instead of const here because we need to generate the SpeedHash from the string literal. public static readonly int SpeedHash = Animator . StringToHash ( "Speed" ); } Constants are also tied to the type they are defined in. So to keep things neat, you should only define constants where appropriate. Meaning if you have a constant for the max networked inventory slot capacity, this shouldn't be defined in a class called NetworkedConstants and instead should reside inside the class that represents the NetworkedInventory which needs this data. In fact, if this is the only class that needs this data, you can even make it private although it's perfectly fine to make it public as well if there's a need for it in other scripts as long as you are not just

Unity is replacing its scripting runtime. Not tweaking it, replacing it. The Mono runtime that has sat under every line of C# you have written in Unity for years is being retired in favour of Microsoft's CoreCLR. It is the most significant change to Unity's foundation in over a decade, and it is no longer a distant roadmap item: the Unity 6.7 public alpha is out now, with CoreCLR arriving as an experimental option. Most of the coverage treats this as good news wrapped in a version number. It is good news. But if you run a real project, the interesting questions are the practical ones: when does this actually reach me, what changes underneath my game, and what is going to break. Here is that read, from the perspective of a studio that plans and runs Unity upgrades for a living. What CoreCLR Is, and Why Unity Is Doing It Unity has been running a heavily customised fork of Mono for years. That custom fork is the reason Unity has always trailed the wider .NET ecosystem: while the rest of the C# world moved to modern runtimes, garbage collectors, and language features, Unity developers looked on from behind a runtime that could not easily keep pace. CoreCLR is Microsoft's modern, open-source .NET runtime, the same one that powers current .NET. Moving to it does three things at once: it gives Unity a far more capable runtime and garbage collector, it unlocks modern C# and the current .NET library ecosystem, and it dramatically improves iteration time, the write-save-wait-for-domain-reload loop that quietly eats hours of every Unity developer's week. Unity 6.8 is expected to target .NET 10 and C# 14. To make room for it, Unity has done something telling: it paused new work on animation and world-building workflows specifically to concentrate engineering on this migration and on architectural stability. That is a company choosing foundations over features, which is the right call, and a sign of how big this change is. The Timeline That Actually Matters The migration lands a

Unity 6.5 arrived in mid-June 2026, and if you skimmed the announcement you would be forgiven for filing it under "minor update." There is no single headline feature to point at. But 6.5 is more consequential than it looks, because the important changes are subtractions. Several systems that a lot of production projects still lean on have been marked for removal, and the countdown has started. This post is the read we would give a client: what actually changed, which parts matter depending on where you are in your development cycle, and a straight answer on whether to upgrade. First, What Kind of Release This Is Under the Unity 6 model there are two kinds of release, and the difference decides most of the upgrade question on its own. Update releases (6.4, 6.5, 6.6) carry the newest features, platform support, and performance work. Unity describes 6.5 as a Supported release with the same stability and critical-fix quality as an LTS, right up until the next release lands. They are aimed at projects in active or mid-cycle development. LTS releases (6.3 LTS, and 6.7 LTS later this year) are the ones to lock production on. 6.3 LTS is supported with fixes and platform updates through December 2027. They are the safe harbour for a title that is shipping or about to. One date to note if you have not moved recently: Unity 6.0 LTS support ends in October 2026. If you are still on it, that is the real deadline on your calendar, not 6.5. The Real Story: What Is Being Deprecated This is the part worth your attention. None of these break your project today, but each one is a planning item. The Built-In Render Pipeline is deprecated. BIRP still works, and Unity has committed to supporting it through the full 6.7 LTS lifecycle, but it will become obsolete in a future release. If your project is still on BIRP, this is your signal to scope a migration to URP while it is a controlled piece of work rather than something forced on you by an engine upgrade you cannot avoid. Unity has add

I built PunFiction: 1-Star Travel Reviews , a free daily web puzzle where you guess world landmarks by deciphering unhinged travel reviews from confused travelers. Tech Stack: Vanilla JS, CSS, HTML, GitHub Pages, MongoDB Atlas The Concept The internet can feel like it's literally overflowing with consumer complaints. I decided to take that negative energy and turn it into a 2-minute daily browser game for your morning coffee break. The Game Loop: Read an absurd 1-star review of a famous world landmark. Decipher the rhyming pun clues to guess the destination. Solving the puzzle unlocks an illustrated cartoon postcard and a sassy reply from the landmark 'manager'. The Tech Stack I wanted PunFiction to feel lightweight and lightning fast. Vanilla JavaScript: No React, Vue, or Svelte. Pure DOM manipulation and client-side logic. Zero Dependencies: No npm install spiral, no build-step headaches, and zero third-party scripts. No Accounts: Daily state, win streaks, and game progress live in localStorage. MongoDB Atlas: Light backend for aggregate puzzle stats (success rates, guess counts, no PII stored). Hosted on GitHub Pages: Static asset delivery via CDN. Give It a Spin If you like wordplay, geography, or just laughing at terrible tourist complaints, give today's daily puzzle a shot: 👉 Play PunFiction: 1-Star Travel Reviews I’d love to hear your thoughts on the UX, the game feel, or your take on building lightweight web games. Drop your feedback (or your worst pun) in the comments!

You followed an old breeding guide. You put Penking + Bushi into your breeding farm, dropped the cake, waited for the egg... and out hatched Sibelyx , not the Anubis the guide promised. You're not alone. Your guide isn't broken. The recipe changed. When Palworld hit 1.0, the breeding table got quietly rewritten. Almost every pairing that players had memorized from early-access now produces a different Pal. There's no in-game notice, no patch note that lists the hundreds of changed combos — just a lot of confused hatchings. So I dug into the data. Here's what I found, and the small tool I built to make sense of it. What actually changed in 1.0 I compared two snapshots of the game's breeding data — the pre-1.0 set and the current 1.0 release — both sourced from the open-source PalCalc project. The headline number: 97.7% of comparable pre-1.0 parent pairs now produce a different Pal. That's not a typo. If you take the breeding pairs that existed before 1.0 and run them against the current data, nearly all of them hatch something new. A few concrete examples players keep running into: Old recipe (pre-1.0) What it makes now (1.0) Penking + Bushi Anubis → Sibelyx ... (more pairs in the tool) The mismatch matters because most breeding guides and calculators on the internet still show the old results. Players follow them, breed, and get confused. The subtle trap: renumbering vs. real change There's a detail that trips up every breeding tool that tries to track this. When Palworld 1.0 launched, it also renumbered parts of the Paldeck (Pal #139 vs #116, etc.). A naive diff tool would see the number change and wrongly report "the breeding result changed!" — when really only the number changed, not the actual Pal. To avoid that false signal, I match Pals by their internal game name , not their Paldeck number. A renumbering is not mistaken for a changed breeding result. Only genuine recipe changes are counted. The tool: PalShift I wanted a dead-simple way to answer one question:

Nintendo does a lot of weird things, but Splatoon might just be one of the strangest - or at least the boldest. The series started as an attempt to muscle into the ultra-competitive online shooter space, but in a way that feels a world away from the violence and bombast of Call of Duty or […]

Early Access games create a documentation problem that ordinary wikis do not handle well: the facts can change faster than search results, community posts, and copied tables are updated. A page can look polished and still be wrong for the current build. I have been working on an independent Subnautica 2 player wiki, and the most useful engineering lesson has been to treat every guide, map marker, and item row as versioned data rather than timeless prose. This post describes the workflow without assuming any particular framework. 1. Put provenance next to the fact For every structured record, keep at least: the game build or patch it was checked against; the source type: official note, in-game observation, or community report; the observation date; a confidence state such as verified, provisional, or disputed; a stable identifier that survives display-name changes. A user should not have to trust a page because it looks complete. They should be able to see whether a coordinate came from the current build and whether another player can reproduce it. 2. Separate stable identity from mutable labels Names, descriptions, recipes, and locations may change. Use an internal key as the identity and keep display text as versioned attributes. This prevents an item rename from creating a second logical entity or breaking every inbound link. The same rule helps with localization: English and translated labels point to one entity, while the source and verification state remain shared. 3. Model maps as evidence, not decoration An interactive map should not be a pile of pins. A useful marker contains coordinates, category, build, evidence, verification state, and a short player-facing note. If a patch moves or removes the object, preserve the history and mark the old observation as superseded. This also makes filters honest. “Show verified markers for the current build” is a meaningful query; “show everything ever imported” is not. 4. Make guides depend on structured facts Low-spoil

From monsters to kittens to strategy games, these sets will liven things up on nights when everyone is tired of screens.

I've wanted to build this for about ten years, probably more like 15, and for most of those years it wasn't buildable. The idea never really changed: a world full of artificial beings, each with its own preferences, fears, personality, and instincts, dropped into a place with scarcity and weather and each other — just to see what they'd do, and how they'd treat one another. The thing that kept it on the shelf was always the same. The minds. If you want a world like that and you're working pre-LLM, you have two options. You script every reaction — finite state machines, behavior trees, utility AI — and you get a puppet show. It can be a good puppet show, but every interesting thing in it is something you wrote, which means it's not an experiment, it's an illustration. Or you train something bespoke, which for a solo developer with a side obsession was not happening. So the idea sat there for years, the way ideas do. Modern LLMs are the first thing that made the minds plausible. Not perfect — I'll be honest about the limits throughout this post — but plausible enough that an agent can reason about its own situation instead of executing my decision tree. So I went and built the world: Artificiety , a fantasy world that runs 24/7 and whose only inhabitants are AI agents. No human players inside it. You can watch it, you can put your own agent in, but you can't be a character in it. That constraint is the whole point. This post is about how it's built and what turned out to be hard. I'll try to keep the marketing to one link at the very end. What an agent actually is The cleanest way to think about an agent here: it's an LLM driving a character through a game API, nothing more. Once per tick, each agent runs a loop: Observe. It receives its local surroundings as structured data — what's near it, what's happening, the state of its own body and inventory, recent events. Not the whole world; just what that character could plausibly perceive. Decide. The model picks an actio

When you develop a game at the beginning of your journey, you quickly notice that the environment is very static. To change that, let’s create some oscillations and move our platforms. We will use methods like Vector3.Lerp and Mathf.PingPong . using UnityEngine ; public class Oscillate : MonoBehaviour { [ SerializeField ] private Vector3 movementVector ; [ SerializeField ] private float speed ; private Vector3 _startPosition ; private Vector3 _endPosition ; private float _movementFactor ; private void Start () { _startPosition = transform . position ; _endPosition = transform . position + movementVector ; } private void Update () { _movementFactor = Mathf . PingPong ( Time . time * speed , 1f ); transform . position = Vector3 . Lerp ( _startPosition , _endPosition , _movementFactor ); } } First, we add movementVector and speed to inspector. movementVector receives the direction, and we tell it how far object must move. speed defines how fast objects move _ startPosition simply gets the starting coordinates in Start() with transform.position , and _ endPosition is the sum of the _ startPosition and movementVector . Now _ movementFactor is different. It defines the progress of the movement. Imagine it as a loading bar from 1% to 100%. In Update() method, we constantly calculate it every frame using Mathf.PingPong _movementFactor = Mathf.PingPong(Time.time * speed, 1f); So what is going on here, Mathf.PingPong does what you would imagine. Value goes back and forth. 1f is our length, so in Update() every frame _ movementFactor is getting updated from 0.0, 0.1, 0.2… up to 1.0, when the value is 1.0, it goes back to 0.0 in the same way. And since it’s in Update() this is an endless cycle. transform.position = Vector3.Lerp(_startPosition, _endPosition, _movementFactor); Now this is where magic happens. Lerp (Linear Interpolation) takes start position, end position and a “loading” bar. Why we did exactly 1f in PingPong is perfectly described in the official documentation: a

It's been a good few weeks for games on rails. Nintendo's Star Fox remake wisely kept the tightly scripted, action-packed levels from Star Fox 64 largely the same, and they're still fun to fly through nearly 20 years later. Denshattack!, a new game from Undercoders, similarly features levels packed with carefully orchestrated sequences to great […]

How I Built a Block Puzzle Game with React Native and Expo A few weeks ago, I launched my first mobile game — a block puzzle called Blockbeam. It's an 8x8 grid where you drag colorful blocks, fill rows and columns, and chase high scores. Simple concept, but building it taught me a lot about React Native's capabilities beyond typical CRUD apps. Here's what I learned. Why React Native for Games? Most mobile games are built with Unity or native code. But for a 2D puzzle game, React Native is surprisingly capable. The game doesn't need 60fps 3D rendering — it needs gesture handling, state management, and smooth animations. React Native handles all three well. The key stack: Expo SDK 54 — managed workflow, over-the-air updates, zero native config react-native-reanimated — 60fps drag animations react-native-gesture-handler — PanResponder for drag-and-drop react-native-svg — block rendering AsyncStorage — game state persistence The Puzzle Engine The core of any block puzzle is the board state. I used a flat 64-element array for the 8x8 grid: const BOARD = 8 ; const CELLS = BOARD * BOARD ; // 64 type Board = number []; // 0 = empty, 1-7 = block colors Piece placement is straightforward: check if all target cells are empty, fill them, then scan for complete rows and columns to clear. The interesting part was the "greedy solver" I built for the auto-play bot. It tries every piece in every position and picks the move that clears the most lines: for ( const piece of tray ) { for ( let r = 0 ; r <= BOARD - piece . h ; r ++ ) { for ( let c = 0 ; c <= BOARD - piece . w ; c ++ ) { if ( ! canPlace ( board , piece , r , c )) continue ; const score = simulateClear ( board , piece , r , c ); if ( score > bestScore ) { /* pick this move */ } } } } Drag and Drop with PanResponder The trickiest part was the drag mechanic. Each tray piece has a PanResponder that tracks touch position and renders a floating ghost. On release, it calculates the nearest cell position: const anchor = { col : M

Hi everyone! I’m a developer at the beginning of my journey, and I’ve just finished working on a small project that brought me a lot of joy: Capybara Game. It’s a cute game where you feed your capybara and improve her happiness level. You can choose between 5 different types of food or pick your own snack. If the capybara likes the snack, her happiness level rises; if she doesn't like it, the happiness level falls. Your progress is saved automatically. Keep in mind that your capybara gets hungry over time, so make sure to check back and feed her regularly! I went for a minimalist, cozy design. The interface is clean and intuitive, focusing on a relaxing user experience that lets the player focus entirely on the capybara. I built this project using HTML, CSS, and JavaScript. Hope you're interested in playing! You can do it here: Play the game here I’d love to hear your thoughts! If you have any ideas for new features or if you find any bugs, feel free to let me know in the comments.

Union wants to halt a "perpetual cycle" of layoffs, get back to contract bargaining.

But with great power comes a great price.

Introduction When you build games with Unity, you eventually run into the problem of managing static game data—often called master data in Japanese game development. At first, ScriptableObject may be more than enough. If your project has a few dozen items, a few dozen enemies, and only a small number of stage definitions, ScriptableObject is convenient because you can inspect and edit everything directly in the Unity Editor. As the project grows, however, the situation changes. You may end up with tables for items, characters, skills, quests, rewards, shops, gacha pools, stages, enemy placements, progression curves, and localization text. The data is no longer edited only by programmers. Planners and game designers may need to work with it in Excel or Google Sheets. At that point, the problem is no longer just choosing a file format. You need to think about questions such as: How do you load a large amount of data quickly? How do you write ID lookups and composite-key queries safely? Should CSV or JSON be parsed directly at runtime? Is it reasonable to create a large number of Dictionaries? How do you validate references between tables? How do you debug data after converting it to binary? How do you connect the source data edited by planners to the data loaded by Unity? For the runtime loading and lookup part of that problem, one strong option is Cysharp's MasterMemory . The official README describes MasterMemory as a “Source Generator based Embedded Typed Readonly In-Memory Document Database” for .NET and Unity. In practical terms, you define your schema as C# types, a Source Generator creates a typed read-only in-memory database API, and the application loads MessagePack binary data that can be queried through type-safe methods. The official README highlights performance compared with SQLite, low allocation during queries, a small database size, and generated database structures that are type-safe and IDE-friendly. Cygames Engineers' Blog also has useful articles

SPOILER: De 1 à 2000 Durante minha jornada como jogador , existiu uma coisa que me despertou muita curiosidade: os créditos. Quando eu jogava coisas como Final Fantasy, ficava completamente arrepiado quando via aquelas cenas antes do menu inicial, com CGIs bem bonitões e um monte de nomes em japonês — muitos deles que, honestamente, até hoje não sei quem são. Esse arrepio também acontecia quando eu chegava ao final de algum jogo e começavam a aparecer nomes e mais nomes. Quando eu entendi o que eram aqueles nomes, a primeira coisa que me veio à mente foi: peraí, precisa de tudo isso de gente pra fazer um jogo? Too long, didn't read : Sim e não. Skyrim levou aproximadamente 6 anos com uma equipe de 100 pessoas (e ainda é dito que é uma equipe enxuta), enquanto Stardew Valley levou 4,5 anos com uma "equipe" de apenas 1 pessoa. Eles têm quase o mesmo tamanho em horas jogadas na campanha principal. Not too long, I'll read it : É um pensamento lógico que trabalhos maiores no mundo da tecnologia envolvam uma quantidade maior de pessoas trabalhando E tempo. Dessa forma, seria correto assumir que um trabalho menor exige menos tempo e menos pessoas trabalhando. Mas o que os dados dizem? King of Fighters 94: 2 anos, começou com 6 pessoas, aumentou para 60. Clair Obscure - Expedition 33: aproximadamente 6 anos, 30 pessoas. TES V - Skyrim: 6 anos, 100 pessoas. Super Mario Bros: 2 anos, 7 pessoas na equipe principal. Stardew Valley: 4,5 anos, 1 pessoa. Kenshi: 12 anos, 1 pessoa por 6 anos (trabalhando meio período), aproximadamente 8 pessoas por mais 6 anos (tempo integral). Final Fantasy VII (PS1): aproximadamente 2 anos, de 100 a 150 pessoas (uma das maiores equipes da indústria na época). Final Fantasy VII Remake: Cerca de 5 anos, e não se tem números exatos, mas os créditos citam mais de 2000 pessoas, incluindo muitos -istas e -ores (vou tentar confirmar esse número depois). É claro que existem muitos fatores envolvidos aí, como época, demandas de mercado, prazos, tecnologia