I am cross-quoting from N.N. Taleb, forgive my errors, but to me it's something in the line of "If you want to be cured from reading the newspaper, spend a week reading old newspaper."
I bought a new basic laptop last year, with enough RAM, and little do you know, the VS Code did not feel faster on the new device. So last week, when I noticed that Zed for Windows is "stable" now, I've uninstalled VSC.
VS Code is still the better tool (imho) but I can't stand it.
In external agents - I have Calude Code, Codex CLI, Gemini CLI and a custom agent for Qwen Coder via Llama.cpp [1]
In MCP - I have fetch, brave-search, puppeteer
In LLM Providers - I have configured Llama.cpp, LMStudio and OpenAI (Zed Agent can access models from any of these providers).
Workflow -
When I need LLM assist I mostly use just Claude Code for specific tasks, with thorough scaffolding. One major drawback in using external agents on Zed is that they don't support history[2], Which doesn't impact me much as I use Claude just for individual tasks. I'm not really sure on how well Zed works for someone who 'vibecodes' entire project.
Sir, we're in a modern economy, we don't ever ever look at productivity graphs (this is not to disparage LLMs, just a comment on productivity in general)
A true Christmas story! Somewhat unrelated, could someone provide insight into the following -
"MonoGame is a "bring your own tools" kind of framework, which means that it provides the building blocks to build your own engine and tools, but it isn't quite an engine itself.
If you are expecting a scene editor (like Unity or Unreal), MonoGame is not that.
If you love coding and understanding how things work under the hood, MonoGame might be what you are looking for. And fear not, getting a game running with MonoGame only takes a few minutes."
Yes, this is basically correct. When you start writing a game with MonoGame, all you get is basically a class with two methods, Update() and Draw() that MonoGame will be calling in a loop, plus a bunch of libraries for input, graphics, audio, content loading etc. you can use in your code. It's a step beyond something like bare raylib or SDL2, but it's a far cry from Unreal, which lets you think in terms of game entities from the very start: "here's the map, here's where the player will spawn, here, add some buildings and you can run around them".
With MonoGame/XNA/FNA, LOVE2D, libGDX, HaxeFlixel you are getting a bunch of tools instead, which is probably not bad if you like coding and your game doesn't fit into one of existing popular genres.
I think a lot comes down to whether a game is art-first or code-first, and almost all modern games are art-first, so it makes sense to have your platform be one that artists and designers are immediately productive in, and the software people are basically writing behaviour modules and plugins for that established system.
But it's good that code-first engines still exist. There are always going to be projects that are more experimental, or don't have a clear pattern of entities, or are dynamic enough that that kind of thing doesn't make sense.
This is a somewhat naive view of engines in modern game development. Full-featured engines allow every department to dive in head first in parallel. The first gameplay elements often get programmed before the first pieces of content arrive. Scenes can be blocked out and drafted immwdiately at the start of the project. Complex animations with states and blend trees can be created amd tested independently of the gameplay code. Audio scenes, complex cues and (dynamic) music can be mixed and mastered independently of any code to integrate audio into the game. The whole process is highly parallelized these days and the engine tools serve to insulate the departments from one another to some extent so that everybody can move faster.
Right, yes. I think all I meant is that in earlier generations you could do modeling/sprites and concepting from the beginning, but there was a hard line in terms of how much code had to exist before the whole thing started to look or feel like much.
Thinking here especially of the Doom / Quake / HL1 era where they were basically building the level design tools in parallel with the game.
Whereas nowadays you can have movement, mobs, dialog flow, etc all with very little code, and it's placeholders like "oh we need a custom shader for this effect" or "that boss needs some custom logic".
You don't have to reinvent all these systems, but in my experience, you still have to code a lot to wire these very generic building blocks up in a good way that fits your specific use cases.
reply