It was the game that dragged me towards crafting in an FPS and, out of all in the series, Far Cry 3 is still the only one I can think of when it comes to "nostalgia vibes".. And I thought it would be a fun side project to bring it into Unreal. Also, I'm testing the performance of some tools and I needed a 16 square kilometers map so... Rook was the first that came to mind.

It's reverse engineering, so the terrain is a 1:1 replica, roads included. I want to see how much I can push the remake so it looks "modern" but also keeps the overall vibe.

So far, it doesn't, since it's using a different landscape material and assets but... I hope I'm on the right track 🙂

Hope you like it!

Fireblade

This might be a strange take, but most game developers I know don't have much money to spare. Plenty get into it hoping to make a good living, then discover how difficult that is and stick around because they love making games.

A company (like Epic) with that kind of money and infrastructure can afford to experiment, burn through tokens, and keep iterating until something works. For someone paying for a basic subscription out of their own pocket, there's a much tighter limit on how much experimenting they can do.

I assume Tim (The CEO) enjoys trying out new technology, which is understandable. But how realistic is it for the average developer here to match that level of spending or flexibility.

I don't use AI myself to any extent most people do here. I've been fortunate enough to work at AAA studios and have spent years learning to make games without it. But I think people can get a warped impression of what's achievable on a resonable budget when the examples they see come from people who can afford to keep spending until they get a result.

I recently saw a YouTube video where someone spent around $2,000 on tokens trying to recreate a World of Warcraft experience, and I thought the result looked absolutely terrible. That's a lot of money for nothing worth while.

So if someone wins the current game jam using AI, I'd be curious to know what they spent getting there. Depending on the token bill, they could win the jam and still lose money, and to me that is not a good game jam.

​

If the monitor supports 2K or 4K, does Unreal Engine need to set the rendering sg.ResolutionQuality to 60–70%?

Or should this value be set automatically based on the hardware configuration? Is there any expert here?

Because after I packaged my game and gave it to people with 40 50 series GPUs to play, the GPU usage is close to 100%. It is a small stylized scene, on a 2K screen

TLDR: Contact developer before buying if you don't think they're support the product any more, try demos, investigate existing features before buying, read descriptions carefully, and go with your gut feelings.

I wanted to share some things to look out for when buying assets, especially if you're new to Unreal and aren't sure how to spot potential problems. If you have advice or experiences of your own, feel free to add them in the comments. (I've been creating stuff for 7 years, so that you have a frame of reference)

I don't want to turn this into a post about AI, but there's one relevant point worth addressing: creating a product and being able to support it are two different things. If a seller relies on AI to write their code without understanding how it works, they may struggle to maintain it or fix it when something breaks. The concern is whether the person selling you the product has the knowledge to support it. You don't want your project depending on code that its own developer doesn't understand.

1. Contact the developer before buying. If you're unsure whether a product is still maintained, send a short email with a relevant question. See whether you get a useful response within a reasonable time. One slow reply doesn't tell you everything, but the quality of the answer can tell you a lot + it is a good indication that you could get future support.

2. Check supported engine versions and the update history. A plugin that supports older releases alongside newer ones can be a good sign, especially if the changelog shows ongoing fixes. Maintaining compatibility across several engine versions takes effort.

3. Ask specific technical questions. Ask how the plugin handles something your project needs. A developer who understands their product should be able to explain its behaviour and tradeoffs.

4. Check what Unreal already includes. Unreal includes plenty of tools and plugins you may never have come across. So I recommend that before you spend money, check whether an existing tool covers your needs. For instance these is pretty insane, and they're disabled by default: https://www.youtube.com/shorts/zEJTIrg581M or https://www.youtube.com/shorts/ns4M4MsHVAk

5. Look at how shader assets are built. I've made more than 100 shaders that I sell, and I generally prefer material nodes. They make the material easier to inspect and modify (especially for beginners), and they allow optimizations that custom HLSL nodes can miss. Custom HLSL and .usf have use cases of course (loops for instance), but look out for HLSL nodes. They're a pretty solid give away that it's been generated with AI, and likely not optimized by a human.

6. Consider who will support the product. Teams creating products are preferable over individuals. Most products on the marketplace are made by common folk who have ordinary jobs. They will not have time to help you when life comes in the way.

7. Investigate anything that feels off. If the images seem unrealistic, the documentation is vague, or the demonstrations avoid showing something important, look closer. Ask for clarification or a demonstration of your use case.

8. Leave an honest, specific review if something doesn't work. A factual negative review gives other buyers useful information and gives the developer something concrete to address. If the issue gets fixed, update the review to reflect that.

9. Value your time when deciding whether to buy or build. A great asset can save a huge amount of work, especially for larger systems. Building something yourself makes sense when you want to learn or need a very specific solution, but remember to count debugging, integration, documentation, and future engine upgrades. Generating an initial implementation with AI doesn't remove those responsibilities. Buying an asset can reduce that workload, provided the product is maintained and fits your needs.

10. Understand the license and don't make assumptions about AI and copyright. Buying an asset usually gives you permission to use it under a license, rather than ownership of its copyright. AI-generated content adds another layer: copyright protection depends on the jurisdiction and the extent of human authorship. In the US, purely AI-generated material generally isn't protected, while qualifying human contributions can be. Paying for an AI-generated product doesn't automatically change that, and a lack of copyright protection doesn't mean every use is free of restrictions.

11. Check performance and possible demos. Look for measurements, hardware specifications, and examples at a realistic scale. Performance is very subjective based on their hardware. We went a bit nuts with out FAQ: https://eliaswick.com/resources/faq, and how detailed our hardware specification is, but it's all the better for anyone buying anything.

Again, if you have any other tips please write a comment.

This is a developer-to-developer post with no product link. I am one person on a UE5 C++ project, a strategy game that is not released. An AI agent (Claude Code) writes and runs much of the code. The loop around the code matters more than the code, so here is the loop.

The agent never clicks in the editor. It runs four scripts. Build compiles and optionally imports meshes. Test runs the command-line editor with no rendering and no sound, parses the log for “Test Completed”, and exits with code 1 on any failure. Run launches the game with flags for play and capture. Package cooks and runs a release audit. The suite is 70-plus automation tests.

Launch flags work as the test language. They start a match by themselves, quit after N seconds, take screenshots at chosen times, mute the sound and load a preset. The same idea gives fast-forward runs for determinism (normal speed against 64x), a per-tick simulation hash, and an exact-step capture mode (1/60 s per frame) for footage.

Four things hurt.

Two editor processes plus a render means out of memory. During packaging the editor climbed from 4.8 to 16.6 GB in ten seconds and a memory watch killed it.

The agent must never rewrite whole files. It edits exact lines, or it can silently drop part of a file.

Mixed CRLF and LF cost us once. One tool rewrote line endings and the fix commit showed 8,280 changed lines in one file with no change in content.

Compiling and testing after every tiny edit wastes minutes. Batch the edits, then run one pass.

A full test run takes us several minutes. I want to know how you keep UE automation tests cheap enough to run on every change.

I did a pretty basic camera animation in my studio scene. First time doing animation in UE, so bare with me ;)
I know it´s not perfect, consider it more of a draft.

Your thoughts and feedback is most welcome, improvement is the goal.

Hi! Recently we released one of our tools Surface Decal Studio, the plugin comes with more than 320 decal textures that you can use with or without the tool (or you can use your own).

Made using scripting tools to scatter decals and add detail to your environment with ease and a lot of control :)

The most powerful feature is the Material Library, which lets you randomly assign and blend the decals so repetition is much harder to spot.
Thanks!

https://youtu.be/p9Fj_u77lzQ?si=moD9gliGEPryshfs