Indie Tooling

Steam's discounts tab is going algorithmic

The Shipping Desk — Fri, 09 Oct 2026 00:00:00 GMT

On 29 September, Valve announced it will stop running Steam’s Discounts & Events section from a curated calendar. Instead, each logged-in player will see discounted games and events picked for them. If you sell a small game, this one’s worth a few minutes.

What’s changing

Valve has paused scheduling new curated placements: the Daily, Midweek and Weekend Deals. Slots already booked will still run, so don’t cancel yours. A timetable is promised in the coming weeks, with the curated calendar fully retired in early 2027 alongside new tools for managing discounts and events.

It isn’t dynamic pricing, so you still set your own discounts. And there’s nothing to opt into.

Why it’s mostly good news

Under the old system, only a handful of the games on sale each day reached the front of the tab, and they leaned towards bestsellers. Valve says its tests showed players ten times more games a day, with clear rises in store visits, wishlists and cart adds. It hasn’t published the numbers yet.

Developers are seeing it too. Hooded Horse CEO Tim Bender shared one indie game that got 7,341 visits from the grid in one month, against 14 in the previous five. That’s one example rather than an average, but it’s a promising one.

The catch: you can’t pitch your way onto the tab any more. The algorithm decides who sees you, and vague tags or a weak store page mean being shown to the wrong people.

What to do now

Tighten your tags. Your top tags should say what the game really is. A cosy farming game tagged “Action” will meet the wrong players.
Tune the page for a cold click. These visitors have never heard of you, so check the capsule, the first five seconds of your trailer, your first screenshots and a one-line pitch. Store page basics still apply.
Grab a baseline. Note your Discounts & Events traffic in Steamworks now, then compare it after your next sale.
Discount more often, not deeper. Each sale is another chance to be picked. Valve hasn’t said bigger discounts rank higher, so there’s no need to slash prices.
Join themed events and publisher sales, and keep an eye on your review score.

Next up, watch for Valve’s timetable and the new Steamworks tools. That’s where we’ll learn what you control and what you don’t.

Sources: Steamworks announcement, Game Developer, 80 Level.

Unity 7 alpha: what's new, and why to stay on Unity 6

The Engines Desk — Thu, 08 Oct 2026 00:00:00 GMT

Unity opened the Unity 7.0 alpha to everyone on 5 October, two months ahead of the December preview it talked about at Unite Seoul in July. It’s in Unity Hub under Pre-releases. Before you hit download, here’s what’s actually inside.

What changed

The big one: the Unity Editor now runs on CoreCLR, the runtime behind modern .NET, instead of Mono. Unity has been working towards this for years, and it’s the reason Unity 7 exists.

What you write stays the same, though. The alpha still targets C# 9 and .NET Standard 2.1, just like Unity 6. The C# 14 and .NET 10 support shown off in July isn’t here yet, and Unity can’t commit to a public date. Player builds don’t change either.

Domain reloads are technically gone, replaced by a new reload system, but Unity says the speed gains aren’t visible yet. Early testers are seeing reload times much like Unity 6.5. Performance work is planned for a later 7.x release.

Should you switch?

Not if you’re shipping. Unity itself says the alpha isn’t for production, and nothing in it makes your game better today. Stay on Unity 6.3 LTS, which is supported until December 2027.

The more pressing date is closer: Unity 6.0 LTS reaches end of support this month. If you’re still on it, moving to 6.3 matters more than anything in Unity 7.

Get ready from Unity 6

You can do most of the prep without touching the alpha:

Run Project Auditor 2.0’s Domain Reload checks to find code that will break when Mono goes.
Turn on Fast Enter Play Mode now. It will become the only option, and it flushes out statics that never reset.
Swap BinaryFormatter out of your save system. It’s obsolete under CoreCLR.
List your Asset Store packages and native plugins. Unity has tested the 68 most popular packages, so for anything else, ask the publisher. It helps to know what’s in your packages anyway.

Got a spare afternoon and a backup? Copy your project, open it in the alpha and report what breaks. Unity is shipping builds twice a week, so today’s bug could be fixed well before 7.0 lands in 2027.

For now, Unity 7 is a plumbing release. The pipes matter, but the water isn’t running yet. We’ll keep covering it in Engines.

Sources: Unity 7.0 alpha announcement, CoreCLR, Scripting and .NET update, Path to CoreCLR upgrade guide, Unity 6 support.

Your downloads folder is not a library

The Asset Desk — Tue, 06 Oct 2026 00:00:00 GMT

Most indie projects do not lose assets inside the engine. They lose them one directory up, in Downloads, in a folder called sort-later, or inside an old project that shipped and then got archived.

The pattern is dull, and it costs money. You need a door tile, a nine-slice panel, or a footstep on gravel. You are sure you already bought it. The file browser shows a zip, a Unity package, or a pile of PNGs still wearing the vendor’s names. Opening each one in an editor is a twenty-minute job, so you buy whatever is on sale. Three weeks later the original turns up while you are looking for something else.

The failure is rarely the big pack. It is Fantasy_Pack_final_v2.zip, bought on a sale, never opened, and sitting two folders from the one you are now paying for again. Nothing in the name tells you what is inside, so you cannot rule it out.

A library, for a solo developer, can be modest. It still needs four fields filled in on the day the pack arrives.

A preview that does not require the engine. If you cannot see the sprite, hear the clip, or recognise the mesh from a thumbnail, the file may as well not exist when you are tired.

Your words, rather than the vendor’s. Village props. UI nine-slice. CC0. Used on the jam game. The filename was written for their shop, not for your project six months from now.

The licence, stored with the pack. Attribution, CC0, and personal-use-only all look the same inside a zip. The question arrives at export time, which is the worst moment to hunt through old email.

One place you open on purpose. A single directory, or a single app. “Wherever it landed” is how the second copy of the same crate gets bought.

Do the chore on arrival. Preview, tag, write the licence, and move the archive out of Downloads. It takes longer than dragging a zip onto the desktop. It takes less time than redrawing a tileset you already own.

Start with the backlog, but not all of it. Take the five newest archives in Downloads, give each its own folder, and put a short text file inside with your tags, the licence, and the shop it came from. The older ones can wait until you next go looking for something. Then the habit is already in place.

A folder and a text file will do the job. If you would rather not maintain them by hand, this is the problem we built AssetHoard to solve. It is a local-first desktop library for the game assets you already own, and it previews Unity packages, Godot resources, Unreal assets, and everyday formats without opening the editor.

Open the package before Unity does

The Asset Desk — Sat, 03 Oct 2026 00:00:00 GMT

A Unity package is a suitcase. Import it and the suitcase unpacks into Assets/, often under a vendor folder you did not choose, plus materials, a demo scene, and a readme you will not open.

Before that happens, four things are worth knowing.

How large it really is. A pack sold as a small prop set can arrive with a demo scene, 4K textures, and a post-processing profile you did not ask for. Import first and delete later, and you will miss a file. Next month you will not know which leftovers are safe to remove.

Scale and pivot. A crate that shows up two metres tall, or with its pivot in the corner, gets copied wrong all over the level. You only need to notice once, before the prefab is duplicated.

Whether the licence covers this build. Shop summaries are short. The terms might want a credit line, or they might forbid resale of the raw files. You are not reselling the files. You still need the credit in the game, and you will not remember it from the receipt.

Whether you already have something close enough. Solo projects collect near-duplicates: three barrels, four sets of UI arrows, two stone textures from different sales. Another import does not make the game clearer. It makes the project heavier.

A .unitypackage is a gzipped tar archive. Inside, each asset sits in a folder named by its GUID, holding the file itself, its .meta data, and a pathname file that says where it will land in Assets/. Extract it with any tool that reads tar and skim the pathnames to see what is really in there.

Unity’s import window lists every file with a checkbox. Untick the demo scene and anything you will not use.

Look inside the package, decide what you will keep, and import only that if the tool allows it. Delete the demo scene the same day. Write one line in your own notes — barrels, commercial, credit in the options screen — and move on.

If the only way to look is a throwaway project, use a throwaway project. Do not use the game. A blank project is cheap. Untangling a third-party folder the night before a jam deadline is not. Import it there, check the scale against a one-metre cube, read the licence file, and only then move the pieces you want across.

From Aseprite to the engine, on purpose

The Tools Desk — Tue, 29 Sep 2026 00:00:00 GMT

Aseprite is usually the calm part of a 2D pipeline. The mess starts at export, in a folder of files called final, final-2, and the one you actually shipped.

Pick a convention and write it where you will see it, which means in the project, not in your head. A serviceable one looks like this.

Source files stay out of the engine’s import folder. art/src/player.aseprite is the drawing. The export goes where the engine already looks, with the same stem: res://art/player.png, or Assets/Art/Player.png. The frame size is decided once. If the player is 32 by 32, the export is 32 by 32, including the idle that only uses the middle.

Tags are doing real work. idle, run, and hit still make sense in six months. a1 does not. If you slice a sheet by hand, name the slices after the frames. “The third row is the attack” is not documentation.

Aseprite’s export dialog can write the tag names and frame ranges to a JSON file beside the sheet. A script can then read the ranges, so you stop retyping them whenever the run cycle gains a frame.

Set the import filter once per project. Pixel art wants nearest in Godot and Point in Unity. A blurry sprite is usually an import setting, not a drawing problem.

Export the sheet the engine expects, not the one that is easiest to preview on a desktop. Godot is happy with a spritesheet and region sizes you set on the animation. Unity is happy with a sliced texture and a pivot you chose. The mistake is a new layout every time you add a frame, then an animation player offset by four pixels, then an evening spent nudging it back.

Keep the Aseprite file. PNG is what the build consumes. The source is how you change an ear colour without redrawing the walk. Back it up with the project. A PNG you cannot edit is a trap you set for yourself.

Try it today on your newest character. Rename the tags and export once. Check that the sheet width is a whole number of frames.

When a pack arrives as someone else’s source file, the same rules apply. Read the tags, export into your convention, and record the licence next to the export. Do not drop their folder tree straight into the game and hope.

Keep the art packs out of the Git repository

The Tools Desk — Sat, 26 Sep 2026 00:00:00 GMT

Git is for the game: scenes, scripts, the small textures made for this project, and the export presets. It is a poor cupboard for two gigabytes of packs you might use.

The symptoms are familiar. The repository takes twenty minutes to clone onto a new laptop. A one-line script change sits beside a diff Git cannot show, because an art file changed underneath. Git LFS helps until the storage quota arrives and the new machine cannot fetch the files. You are a solo developer, so the new collaborator is you in three months.

Split the problem in two.

What belongs in Git

The project holds what the build needs, at the size the game needs. A 256-pixel prop, not the 4K source you might reuse on another title. Commit that. Review it. Tag a release against it.

Ignore patterns earn their keep. Vendor zips, demo scenes, and lock files from the art tool should not be a surprise commit. Check status at the end of a long art day. That is when a 400 megabyte pack sneaks in.

Rewriting history to remove it is possible, but it is a bad afternoon. Catching it before the commit takes ten seconds. Run git status and read the list of new files before you stage anything. If a path surprises you, it does not go in.

If a binary truly has to live in the repo, prefer the exported file the engine imports. Keep the vendor archive in the library. Write the licence into a text file next to the code. Git is good at text.

What belongs in the library

Everything else: shop zips, full packs, source files, near-duplicates, the door you did not use. Keep a short text note per pack with where it came from and what the licence allows, so the answer survives the shop page disappearing. It does not have to be in Git. It has to be backed up, and it has to be searchable, so you can answer whether you already own a barrel without cloning anything.

A second disk, a plain folder with a ruthless naming scheme, or a local asset manager will all do. Whichever you pick, it should stay on the machine and not become another remote you log into before you can see a sprite.

The test is a fresh clone. Do it today: clone the repository into an empty folder, open it in the engine, and follow your own notes. Time it. If a new checkout builds with the steps in your notes, the repo is the right size. If it only builds on the machine that already has the packs, the packs are still pretending to be source control.

Godot scenes are text, so read them

The Engines Desk — Wed, 23 Sep 2026 00:00:00 GMT

Godot’s text scenes are easy to waste. A .tscn file is a scene you can open in the editor, and it is also a diff you can read. That second fact matters the first time a change you do not remember lands in a file you did not mean to save.

Prefer text resources over binary .res for anything you might review later. Binary is a reasonable place for an imported cache. It is a bad place to keep a scene you wrote. Save when you mean to. An editor that writes the scene every time the window loses focus will fill your history with accidents.

Name nodes as if you will search for them, because you will. Camera2D is a type. IntroCamera is a name. Renaming later changes the scene and every path that pointed at the old node, so rename early, before animations and scripts have memorised the placeholder.

Open a .tscn in a text editor once. Each node is a header line with its name, type and parent, such as [node name="IntroCamera" type="Camera2D" parent="."], followed by the properties that differ from the defaults. External files are listed at the top as ext_resource lines. Once you can read that, a renamed node is one changed header and a swapped texture is one changed path.

Keep scenes small enough to diff. A level that is one file with hundreds of nodes shows a wall of changes when you move a torch. A level built from instanced rooms shows you the torch. Instancing is how Tuesday’s edit stays visible.

Exported script values land in the scene as data, which is what you wanted, and they show up in the diff as data. A magic number buried in _process shows up as code, and you will misread it at midnight.

When an import setting changes — filter, repeat, a sprite region — Godot writes that beside the asset. Commit those import files with the asset they describe, or the next machine will guess. Leave the editor cache out of the repository.

Once a week, read a diff before you commit, even if you are alone. You are looking for accidental churn: a moved camera, a duplicated node, a path that escaped to an absolute disk location, the kind of thing that also breaks an export preset. Text scenes make that visible.

You nudge one platform, and the diff shows forty changed lines. Now you know the file changed for a reason you did not choose, and you can revert it before it becomes history.

If the player has to squint, the system is not finished

The Engines Desk — Sat, 19 Sep 2026 00:00:00 GMT

There is a moment in every systems-heavy game where the person who made it says the game is deep, and the player says they cannot tell what just happened. Both can be right. Depth that does not read is a private joke.

Readable at a glance means a stranger can tell, in about a second, which pieces are theirs, what is dangerous, and whether the last action worked. It does not mean the game is small. It means the picture stays honest when there are a lot of pieces.

A few tests beat a style conversation.

Hide the tutorial and play for two minutes. Where did your eyes go, and were they right? If you needed a log window to know the state, the log window is doing the game’s job.

Turn the effects down in your head. If the feedback only exists as screenshake and a particle, add a change in shape, colour, or number that survives a screenshot. Pause on a messy frame and look at the still. You should still know who is winning.

Try the squint test. Take a screenshot from the busiest moment, shrink it to the size of a postage stamp, or blur your eyes. The player character and the thing that can kill them should still separate from the background. If two shapes merge into one blob, they are the same object as far as a tired player is concerned.

Colour needs a job. Yours, theirs, neutral, warning. Then stop inventing new jobs. A fifth colour for “special, but not a warning” is how the warning colour stops working.

Numbers need a home. If currency, health, and ammunition all float in the same font in the same corner, they are one number pretending to be three. Separate them by position before you separate them with a paragraph of explanation.

This is a production rule as well as a taste rule. A readable game is faster to debug. When a system breaks, you can see it break. When everything is a similar sprite with a similar particle, you will add print statements and call it a mystery.

Watch someone else play, and say nothing. Every time they ask “what was that?”, write down the frame. Three of those questions are worth more than a week of your own opinion, because you can no longer see the problem. You already know what everything is.

None of this asks for a complicated pipeline, a realistic art style or a large team. It asks you to decide what the picture is for. The picture tells the truth about the rules, quickly, including on the frame where everything goes wrong.

Your file browser cannot see inside the engine files

The Engines Desk — Wed, 16 Sep 2026 00:00:00 GMT

File browsers are good at documents. They are poor at game files. A Unity package, an Unreal asset, a Godot resource, a zipped store pack: these are often a generic icon and a size. The size tells you almost nothing. Forty megabytes might be one texture or a whole UI kit.

That is a nuisance in one engine. It becomes a real cost when you work in two, which a lot of indie developers do. A jam in Godot, a prototype in Unity, a pile of packs bought for both. The packs sit in one folder. The editors that could preview them are not open, and you are not going to launch two of them to remember what you own.

You can live with that while the set is small. You cannot live with it once the folder holds a year of sales and “free this week” downloads. At that point the file browser is not neutral. It is hiding the catalogue.

Here is how it goes wrong. You buy a UI kit in a sale. Six months later you buy another, because the first is called ui_kit_final.zip and tells you nothing. Both are in Downloads. Neither has a preview. You do not find the duplicate until you open the second and see the same buttons.

A few habits shrink the damage before you pick a tool.

Name the archive when you download it. A prefix you would actually type — cc0-, by-, commercial- — sorts faster than a good intention. Put the game you meant it for in the name if you have nowhere else to write it.

Do not unpack everything just to see. Unpacked vendor trees multiply. If you unpack, unpack into the library, look, and keep either the export you will use or the original archive. Three copies in three projects is how disk space and certainty both disappear.

You can start today with ten minutes. Sort the folder by size, take the ten largest archives, and rename each one so a stranger could guess what is inside. It is dull work. It is also the first time you will learn what you own.

Prefer a preview that understands the format. A thumbnail of a zip icon is not a thumbnail of the sprite. If a tool can show the sprite, the mesh, or the waveform without an import, use it for the library and keep the engine for the game.

The project should receive the files you chose, at the size you chose. It should not be the place you browse everything you have ever downloaded. Those are different jobs. Mixing them is how the project folder becomes a landfill while Downloads stays untouched.

Make the export boring before you touch the store page

The Shipping Desk — Sat, 12 Sep 2026 00:00:00 GMT

The interesting part of a release is the game. The part that decides whether the interesting part arrives is the export preset, and it should be dull.

Dull means one command, or one button, produces the build you intend to upload. The version in the window title matches the version in the filename. Debug menus are off. The default resolution is the one you tested, not the one your monitor happens to use. A second run of the same preset produces the same folder, with the same name, without you renaming a copy.

Do that for every target you claim. If the page says Windows and Linux, both presets get a run on the day you upload. “Linux worked in March” is not a platform. A web export needs a refresh with the console open. Godot and Unity will both let you ship a build that prints errors into a place the player will never see, and you will not see them either, unless you look once before the upload.

Check the output folder as well as the build. Old zips, a leftover debug binary, and a test save file all travel well. Open the finished archive in a fresh folder, ideally on a machine that does not have the editor installed, and run it. Missing files and a missing runtime only show up there.

Write the steps in the project, even when you are the only author. Which editor version, which preset name, whether you upload the folder or the zip. Future you will have switched versions and forgotten which tickbox mattered. In Godot, the export templates have to match the editor version, and “why won’t it export” is a bad question to meet on release day.

Run the preset twice and compare. The file sizes should match, and so should the folder layout. If they do not, something in the build depends on the clock, your machine, or a file you forgot you had.

Only then open the store page. Screenshots from a build that still says it is a dev cut teach the player to expect a dev cut. Bump the number. Play for ten minutes from the exported binary, not from the editor, and then take the shots. Editor play and exported play are different products. Fullscreen, input, and the question of where a save file went only show up in one of them.

A release note can then be short. Version, platforms, what changed, what you tested, what you know is broken. That is a useful note. A paragraph about how excited you are is not.

Write the store page while the build is still ugly

The Shipping Desk — Wed, 09 Sep 2026 00:00:00 GMT

The store page is not a coat of copy you add at the end. It is a list of promises, and it is cheaper to write them while the game is still allowed to be bad.

Open the page when you have a screenshot you are slightly embarrassed by. Fill in four things.

The sentence. One line on what the player does. “Stack rooms, then leave before the tide” is a sentence. “A unique atmospheric experience” is fog. If you cannot write the sentence, you are not ready for tags, a trailer, or a price. You are ready to play the first minute and notice what you actually do. Say the sentence to a friend who has not seen the game. If their first question is what the game is, the sentence is not finished.

The tags you can defend. Puzzle, local multiplayer, pixel art, the engine you used. Tags are how strangers arrive. A tag you only half fit is how they leave. If it is single-player, do not tick multiplayer because a second controller technically moves a debug camera.

The controls and the length. Keyboard, about twenty minutes, a browser build. People buy small games on purpose. Hiding the length does not make the game larger. It makes the page feel like it is talking past them.

The status. Prototype, jam build, or a version you are willing to leave up. Say which. A jam build can be wonderful and unfinished. Calling it finished is how a kind player becomes a disappointed one.

Once the four are filled in, read the page as a stranger would, top to bottom, without the game open. Every claim should be something you could point to in a build today. Underline the ones you cannot. Those are not copy problems. They are work you have not done, and the page has just made a list of it.

Then keep the page in step with the build. When a feature dies, the sentence loses it the same week. When you add a Linux build, the page says Linux after the preset has been run, not before.

Screenshots can be ugly at this stage. They should still be from the game, cropped the way the store will crop them, with the interface readable at thumbnail size. A shot that only works fullscreen is a poster. Open the draft page on your phone before you decide. Most strangers will see it there first, at a size where small text turns into grey.

Price can wait. Zero is a fine price for a page that is still a promise to yourself. The sentence should not wait. You will aim the rest of the work at it, or you will notice the sentence was a wish and change it.

A release brief, annotated

The Shipping Desk — Fri, 04 Sep 2026 00:00:00 GMT

This page is a specimen. The game is not real, the version is not real, and nothing was uploaded. It is here so a release brief on this site has a shape you can copy: short, specific, and unwilling to invent a feature.

Specimen. Northroom 0.3, a fictional one-room stealth toy, imagined for this page.

Platforms. Windows and a web build. There is no Linux build in 0.3, so the note does not say Linux.

What changed. Guards now lose you when you break line of sight for a full two seconds, instead of knowing your tile forever. The lantern uses oil, and oil is a pickup in the room rather than an infinite meter. The pause screen shows the actual controls. That is the list. There is no line about various fixes, because that line is where specifics go to hide.

Each item is something a player could notice and check. “Guards lose you after two seconds” can be tested with a stopwatch. “Improved AI” cannot. If you cannot say how a reader would confirm a line, rewrite it until you can, or cut it.

What was tested. The Windows export and the web export, from the preset, not from the editor. One full clear, one deliberate failure, and a refresh on the web build to see that progress does not pretend to save. There is no save in 0.3. The store page should say so, and this note says so.

Left broken on purpose. Windowed mode on Windows remembers the wrong size. It will not be fixed in 0.3. Writing it down is the difference between a known limit and a surprise. It also saves a player the bug report, and saves you the reply.

What the page may claim. One room, about fifteen minutes, keyboard, no saving, Windows and web. It may not claim a campaign, a map, or controller support. Those were wishes, and they are not in this build.

Write the brief before you upload, not after. Drafting it late means writing from memory, and memory remembers the features you meant to finish. Do it with the exported build open beside you.

That is a release brief. It is boring to write and easy to trust. Version, platforms, the behaviour that changed, the test you actually ran, and the bug you are leaving in. A reader — including you, next month — can tell what the build does.

When Indie Tooling runs a real release note, it will use this shape and it will be about a real build. If a sentence needs a feature that does not exist, the sentence goes. That rule is the point of the page.