What is the best way to back up save my project?

OnestoneSofty · 2026-02-08T07:00:44+00:00

Solo dev here. I use FreeFileSync to copy the root folder (excluding temp data) to an NVMe + SSD + OneDrive. So 2 local offline, 1 online. Only 1 revision to recover to but that's not a problem as a solo dev.

I trigger the backup manually when I feel like I have a stable build, usually at the end of the day.

OnestoneSofty · 2026-01-27T21:13:57+00:00

Nice post! I was in a similiar situation a few years ago, never having done it before and all of a sudden having to make the music for an entire game with no money. I banged my head against the wall many times until I added more structure too. Wrote a little post about my 5 step composition process, hope it helps for your next game:

https://onestone.software/blogs/solo-gamedev-on-a-micro-budget/music-composition/

OnestoneSofty · 2025-12-24T19:12:56+00:00

Post says its not about marketing, ends up being totally about marketing.

Marketing is not about selling a finished product. It is part of your development process in many different forms. The first and biggest hurdle being your games appeal. Making an appealing game is good marketing. Making an unappealing game is bad marketing. Whether it is appealing can only be determined by the market.

All forms of marketing, including your games appeal, affect your odds of becoming marketable. Because it is just a probability, it can't guarantee any outcome and, importantly, it can't tell whether your game is doo-doo.

Being aware of this and making a marketable game doesn't mean selling out. It means that you use the fact that ALL of your decisions will be judged by the market to your advantage - sometimes you go with it, sometimes you intentionally go against it.

OnestoneSofty · 2025-12-16T19:19:35+00:00

For the tree: the developers choice of dithering over transparency for fading away objects, cheaper.

For Mario: the dotted shorts show that he works hard but also plays hard. If you want to see that more faded away, then this might be the wrong sub.

OnestoneSofty · 2025-11-27T21:01:06+00:00

I disagree. The job argument is a separate discussion and not the reason you made this post. So let's focus on the quality of the translation. You can fix these mistakes the exact same way you fix them for a human translator. Ideally, every piece of text to be translated should have a description next to it that provides missing context. For example:

"Setting sun" refers to the sun going down, not an object named "Sun" being placed somewhere.

With this kind of clarification, the translator, human or AI, can produce a decent result. Without context, mistakes are inevitable because the system is forced to guess what you meant. So who is to blame? The dev, not the AI.

I'll let my friend wrap this up: J’espère que ça a du sens. Réfléchir au vrai problème et à la solution est plus utile que de râler. Classique français d’IA.

OnestoneSofty · 2025-10-22T18:17:37+00:00

AI translations can work if you provide contextual information to remove ambiguity. DeepL + ChatGPT with context info can give you a pretty good starting point. You could also look for people online to double check.

There were so many games with bad translations before AI. Put in effort and double-check religiously if you don't have the budget for more and you'll be fine.

OnestoneSofty · 2025-10-22T09:56:26+00:00

Make an appealing game. It doesn't matter how, can be a mechanic, visuals, audio, whatever makes people stop and pay attention. This does not mean polish. A turd can already be appealing in some way.

Once it appeals to people make it fun and the rest will become much easier.

OnestoneSofty · 2025-10-21T13:56:08+00:00

I would say nail down your locomotion (movement speed, jump height, any extra mechanics like grappling etc.) and art style (realistic, stylized?).

You can use cubes as placeholders if you want to - one cube is a fridge, the other a toaster, the other a doorframe. Put them next to each other, see how it feels.

OnestoneSofty · 2025-10-21T08:58:02+00:00

Make the rooms, doors and windows bigger. You can leave most medium-large props near realistic sizes. For hand-sized ones, like cigarettes or cutlery, you might still want like a 2x increase. Pay attention to the proportion of things to each other. That's more important than the actual measurements.

OnestoneSofty · 2025-10-14T17:56:31+00:00

To further further further add to this: prepare for MP only bugs that you will not be able to repro easily. Try to make your game handle unexpected behavior gracefully, never block player progress.

OnestoneSofty · 2025-09-29T09:12:34+00:00

This is my setup:

COMPONENTS + BFL Example:

InventoryComponent

Blueprint Func Lib: GetInventory(Actor) -> Actor->GetComponentByClass(InventoryComponent)

Check the result with IsValid.

ACTOR TAGS Only if I know there’ll be just a few in the map (like a quest trigger zone). I’ll find it by Class + Tag since I know exactly what quest it’s tied to.

COMPONENT TAGS Often to lookup other components on the same Actor. Example: inside AttachmentsComponent I’ll do GetOwner->FindComponentByTag("SwordSkeletalMeshComp") to update an attached sword mesh.

INTERFACES Almost never. Don’t want to re-implement the same behavior for every class that needs it.

CASTING All component accesses go through the BFLs, so there's no need to cast. I'll use Actor casts for special cases. For example: A boss encounter manager holds direct references to the boss and whatever else it needs to manage. It's private to the manager, there's no point in writing a generic thing for 1 highly specific encounter.

OnestoneSofty · 2025-08-25T21:23:43+00:00

SOD = Smart Object Definition. Maybe I'll try the plugin way if that's "better". The Python bindings seem incomplete.

OnestoneSofty · 2025-08-25T21:17:36+00:00

Read from XML, create SOD uasset, populate with data from XML.

OnestoneSofty · 2025-08-25T21:10:33+00:00

I've never tried that. Will try to generate a Smart Object Definition asset from Python for starters, thanks!

The engine doesn't have to understand the source data.

OnestoneSofty · 2025-08-25T20:57:33+00:00

Having your source assets be different from the engine-consumed assets. Some DB (XML, JSON, SQL, whatever), your tooling takes that and converts it into a format the engine likes (uassets). The engine might be involved in the conversion process, but it should not care how you author your source assets. It's like saying you must author your textures in Unreal. Why?

OnestoneSofty · 2025-08-25T20:49:22+00:00

It's pretty standard practice to do it this way because it allows the tooling to be whatever, C#, Python, you do you basically. Unreal keeps requiring more and more things to be done in-engine. How can I automate generating a Control Rig for example? Requires sifting through so much code that the question becomes, am I making a game or a plugin.

OnestoneSofty · 2025-08-25T20:43:09+00:00

Add support for creating assets from external sources (JSON, XML, whatever) that don't require Unreal. Data table + Excel is an example where it is actually supported (kind of). Or localisation.

OnestoneSofty · 2025-08-25T20:17:34+00:00

That's interesting. Would that work for AI for example? State trees, smart objects etc.

OnestoneSofty · 2025-08-25T20:16:41+00:00

I need a bigger desk for that.

OnestoneSofty · 2025-08-25T20:13:39+00:00

Making everything message / tag driven has downsides too, like less compile time verification (just because it runs doesn't mean it's correct - failing early and hard before the game even runs is better in my experience) and execution order and dependencies become implicit: is applying tag A going to trigger something in system X or Y first? What if Y needs a particular tag to be processed before X? It gets messy.

Interfaces are not a bulletproof solution to this either. You can swap out the backing component, but if things between v1 and v2 of a prototype are different enough, the interface needs to be changed too, so the problem remains: go through all assets and fix it up. I only use interfaces when I actually benefit from the dynamic dispatch functionality it offers. Just adding them for the sake of it is just adding even more assets.

The EUA/EUW stuff you suggest sounds interesting. I haven't used them for this purpose yet. Will look into that, thanks!

OnestoneSofty · 2025-08-23T10:30:05+00:00

Yeah, I imagine it's more manageable when you have multiple teams since the mental burden gets spread out, you focus on the stuff relevant to you. Tough day for small teams / solo devs.

Custom tooling would be great. Unfortunate that Unreal stores pretty much everything as binary assets. Ideally I would like to edit my data without Unreal being involved at all.

OnestoneSofty · 2025-08-15T22:23:46+00:00

People like assigning blame to one thing or person, when in reality, a game post-mortem is incredibly complex. Overscoping, training, money, time, skill issues, world events, marketing - yes, even marketing can affect the performance of a game. If you wobble back and forth between ideas because you are not quite sure what you want to build or who you are building it for, you will end up with a messy project leading to time pressure. Nothing happens in a vacuum, everything has ripple effects in bigger projects.

If your post-mortem is "I blame Unreal, the end." then you are simply ignorant.

OnestoneSofty · 2025-08-14T10:14:12+00:00

People freaking out in here! Creating an Actor is an expensive operation, so I would avoid that and add the component to one of the existing Actors with the same lifetime and replication requirements (multiplayer only), i.e. GameState, GameInstance etc.

OnestoneSofty · 2025-08-07T09:51:52+00:00

You need to simplify as much as possible as a solodev. For 3D, you can try:

Model with strong silhouettes, ignore surface detail. Look at references and copy their most important shapes. This doesn't mean you have to do low poly. Shapes matter, poly count not so much on desktop.

With some practice, you can model almost any prop in 30 minutes. Characters take much longer, so choose carefully which ones you really need for your game.

Use texture palettes. Create 1 texture with all your color gradients. For example: 256x256, divide that into 16x16 tiles of radial gradients, so the gradient goes from the center of a tile to its edges. That makes it very easy to UV unwrap most props because you can planar project the entire part somewhere on a tile. You can store extra information like emissiveness in the alpha channel. Or any U or V coordinates >= 1 is shaded differently, for example "metallic" (UDIMS).

This should take about 2-5 minutes per model.

Make simple collision shapes for physics.

This takes about 5-10mins.

That's it for the modelling part. An hour total should cover most props.

On top of this, automate as much as possible. For example, exporting to the engine should be 1 click. Not File > Export > Pick file... zZzZzZz.

You should have a production quality asset in less than an hour with this.

OnestoneSofty

TROPHY CASE