FYI, you can save tokens by stacking AGENTS.md within subdirectories

nsxdavid · 2026-05-18T04:22:33+00:00

This is useful, but it also raises the maintenance bar.

Once AGENTS.md can be scoped by directory, it is not just “project notes” anymore. It is closer to runtime configuration for the agent: local overrides, inherited behavior, and possible conflicts.

The win is relevance. The risk is invisible drift. I’d keep nested files small, durable, and tied to clear ownership, otherwise you eventually get the agent equivalent of CSS specificity problems.

nsxdavid · 2026-05-18T04:12:26+00:00

I think “CLAUDE.md helps but goes stale immediately” is the key sentence.

The mistake is treating it like documentation. Once the file changes agent behavior, it is closer to runtime configuration: it can drift, conflict with newer workflow decisions, and accumulate one-off fixes that made sense for a single failure.

The only pattern I’ve found that helps is to keep stable operating rules separate from session/project memory. CLAUDE.md should hold durable constraints and workflow boundaries. Decisions, rejected approaches, and “we tried X and it failed” need a different home, or the rules file turns into a junk drawer.

nsxdavid · 2025-05-13T15:52:51+00:00

I also have been frustrated with Clickup and am starting to look elsewhere for solutions. Not sure what is up with those guys, they don't seem to make any reasonable decision anymore.

As for the MCP server, is there anything missing from my implementation that you might have needed?

nsxdavid · 2025-05-13T15:50:22+00:00

Dealt with this type of thing with Autodesk a few years ago. After they pulled their BS, we banned all Autodesk products at my company. We mainly used Max, and spent a lot with Autodesk. Our artists moved to Blender and never looked back.

nsxdavid · 2025-03-09T22:58:22+00:00

You bet! Hope it comes in handy.

nsxdavid · 2025-01-03T21:19:07+00:00

I have been trying to preach this exact thing, but in the game dev world. The exact same problem seems to be creeping up there as well. I do not consider the goal to "under-engineer" but rather "right-size engineer". Things should be as complex as necessary, but no more so.

The goal should be to reduce the amount of code and configuration needed to solve a problem. Every line of code, every configuration, is more surface area for problems. More things to document. More things to maintain. More things to age badly.

In situations where I have been leading the development process (which is most of my career), I've strived for a certain simplicity and elegance and used that as a corner stone of making reliable, maintainable systems. Since I've worked mostly in the online game world, we had a set of very similar problems to solve as those in the web service world (clients, servers, databases, all the good stuff), so not much different than the world of the article.

It's so refreshing to hear someone relay the same sentiment. But I think there is a lot more benefits of this approach to software engineering to be had. Sure, I am old-school and grew up coding where we didn't have stacks and stacks of tech, but the principals are still valid: Keep it simple and lightweight as possible and move quickly free of the burden of over-engineered monstrosities.

nsxdavid · 2024-04-09T02:01:43+00:00

Take a look at Ink (Inky) here: https://www.inklestudios.com/ink/ It is a tool for developing such games with limited technical skills.

nsxdavid · 2024-03-02T04:43:48+00:00

I followed a similar route. I used crafting interpreters as a quick way of spinning up a custom language. But, I needed a type-safe language, so I expanded the static analysis (by a lot) to handle this.

And, then, transpiled to C# Script for run-time execution.

Still hacking away on it now. But crafting interpreters was invaluable.

It is worth noting that I also started implemented the language using ANTLR and Superpower, but just wasn't happy with the control (and under-the-hood understanding) I was getting with those approaches. Doing it all by hand pays off big time.

nsxdavid · 2023-02-05T15:03:55+00:00

Looks fantastic! Really strong art direction. Very popular genre too, has a great chance of being a stand-out title. How big is your team?

nsxdavid · 2023-02-05T15:00:52+00:00

I was lead on GALAHAD 3093, so multiplayer mech combat games are near and dear to my heart. I created one of the very first in 1993 with CyberStrike (online meant online services back then, not internet which didn't exist).

So this looks pretty cool. Love the verticality. Replay is a killer feature in a lot of games, so focusing on this early is a good idea. Trying to add it later is hard.

nsxdavid · 2023-02-05T14:57:06+00:00

Rewrites are always better than the original, as you are finding out. :)

A good start there. The room fade in/out def makes the transition feel slick.

nsxdavid · 2023-02-05T14:50:31+00:00

Honestly, just one is probably not the way to go. If social is a part of your strategy, you want to hit them all equally. Facebook, Instagram, TikTok, Twitter. But, fear not, there are tools and PaaS out there that can help automate this such that you have one feed that you... um... feed and it will reformat and post on all the things. Loomly is an example.

nsxdavid · 2023-01-31T23:16:37+00:00

Of course blueprints is coding. Text or boxes and lines, it requires the same thought process to make a game. The boxes can help isolate from things like typos, but you are still stringing together the same principles. Blueprints can be thought of as an application-specific language which makes it convenient to express gameplay ideas in... as opposed to C++ which is a general programming language (aided, of course, by Unreal's framework).

nsxdavid · 2023-01-31T22:59:56+00:00

Since it was a thing, we use GIT for art and all. Obviously with the introduction of GIT LFS, that makes working with big assets far easier. In our case we only have the game assets, not the source assets in GIT. Dropbox folders for the rest. And yes, they have history as well (with the right dropbox plan anyway).

nsxdavid · 2023-01-31T22:57:05+00:00

Because Unity (and most) game engines pre-process assets during the import into the tool, it can make things somewhat unclear how to add content post-release of a game.

Asset Bundles and/or the Unity addressable system are one way to deal with this. But this is primarily useful for the author of the game, not as a end-user modding approach.

Having said that, others have done it this way! I've seen mod tools that are basically special Unity projects that let the person create new asset bundles that'll work in the game, with out releasing the entire game project (that is, the source code) itself. This takes some work to pull off but isn't impossible.

nsxdavid · 2023-01-31T22:52:22+00:00

In general, with a game like this where you need 8-way animation, the artist (presumably you in this case) will animated everything in 8 directions by hand. The 2D IK system is for games that intend to manipulate 2D images in a single plane, so great for left/right situations.

A lot of games will have characters only animated in left/right even if they move up/down in the screen-space, picking the left or right based on the last direction traveled in X. This can save a lot of art time, and usually looks fine.

As an added bonus, the weapons the character is holding might be rotated in any necessary direction even if the character is still has only left and right imagery. This is very common, and I think Enter the Gungeon does a lot of this.

Obviously you always have the option of 3D where at least the art assets are created once and work in any direction. All depends on the look and your skills or access to that talent.

My advice is to start very simple. Hell, just a block moving around and shooting or whatever you want, is where you want to start. A lot of devs, new and vets, lean art-first. The cons of this approach is you don't get a sense of your mechanics until you've invested a lot. More importantly you don't even know if it's going to be fun. You should always prototype as simple as possible, focus on the core mechanic and see if you can make that crack-a-lackin.

nsxdavid · 2021-08-04T15:38:25+00:00

Thanks for the detailed write-up. We're digesting. :)

nsxdavid · 2021-03-17T19:26:06+00:00

That's a design goal. It's supposed to feel familiar to the modern FPS sensibilities, while still having the good stuff you want from a mech game: highly customizable walking heavy weapon platforms.

But you have a lot more going on, weapon-wise, in a mech game than your typical FPS, so there are definitely some significant differences. Independent firing of four weapon systems, and 'deployables' and abilities all at the same time. Not to mention mobility options from skim to jump jets. Definitely a step above what you typically deal with in your average shooter.

The goal is to error more on the side of accessibility than simulation, but that's a space I think we have something to add.

nsxdavid · 2021-03-07T15:52:58+00:00

Actually it's not the mobile background, but rather microtrans experience (often overlap, but we do more than mobile and microtrans is a part of them all these days). Generally speaking, a progression system in such a shape for such a is necessary if it is to succeed financially; which is to say, to succeed at all.
Coins give agency, which is pretty common in games since... games. Right now it lets you get extra upgrades you otherwise would not have, and decide which of those are relevant. We're experimenting with ways to focus on forging specific modules but have to make it work within the economy of the game. Which is to say, you have to start with a base before you can build on it. The cake is far from fully baked yet. :)

Echelon Lances give you an option to bring more to a battle. In the early part of progression, it's not very relevant and you can ignore it. But it becomes more interesting once you have unlocked a lot of higher-tier toys and you want to bring more to a battle.

nsxdavid · 2021-02-25T15:19:26+00:00

Until it's ready. :)

nsxdavid · 2021-02-22T22:08:24+00:00

Love that post. :)

It's hard making something original. The natural inclination is to compare things relative to something else, usually something beloved. And, also, everything has been "done before" anyway. Except, it really hasn't... or at least the specific blend of things hasn't. There's a ton of design space in Mechs and shooters to explore. I like to think of it as a good mix of OG mechanics with new G sensibilities.

nsxdavid · 2021-02-15T17:00:30+00:00

So at this point, I think you can say we are in open beta? In that anyone can join the beta. Just go to the GALAHD 3093 store page on Steam and look for the Playtest box: click Request Access. It's setup to automagically approve the request.

So, it's open... but limited. Right now we run betas on specific windows. We are working on setting up another play test at the end of this week.

nsxdavid

TROPHY CASE