This post is about content *management *rather than creation, but I think it’s still mostly relevant to this forum.
Over the past 15 months or so, I’ve acquired almost 700 asset packs from the Marketplace. I’ve decided I’m going to use 4.20 to build my (pastime) project (let’s hope it will be stable), as I think I now have all I need. So now, I first have to go thorough all of this, and import (most of) those 700 packs (some I’ll probably ignore; one only needs so many grass materials…). This is going to be a lot of work, so I want to get it right the first time, and waste as little time as possible.
As regards engine releases, don’t ever use the words ‘hope’ and ‘stable’ in the same sentence … Lots of devs found 4.18 stable ‘after’ the fact. But there were/are problems with 4.19 plus 4.20 too. So wait until there’s a 2 or 3 in the release number.
As far as your plan of attack managing asset packs, it sounds like you’re about to do something ludicrous time-wise. You risk being the guy who spends all day managing his music collection, not actually playing guitar-piano…
Renaming and moving all those assets is a full-time job. Plus you may never use half of them. You also need to think about how you will apply Free-Pack-Updates as the engine evolves. If you put them all in a single project it will also cause the Editor to die even if you’ve got a decent PC. You also risk project corruption! Then there’s the thorny issue of Backups too…
Honestly other devs may offer different advice… But I strongly suggest you just get started on your project / game. Start small. Work in isolated folders / projects and build out gameplay / functionality first. Then combine your progress into a single build as you reach milestones. In these isolated projects you can be OCD about structuring hierarchies of folders / naming if you want. But remember, game dev is like film-making or music or any other art. Sometimes you throw out things when you get better ideas. Then all the advance planning goes out the window! Where you actually want to be highly-structured from day-one, is with coding and class structure! That matters far more tbh.
So for now, why not just group the assets in folders of similar functionality (widgets together, landscape packs together etc). As its easy to Migrate-in new assets. Last thing… With so many packs purchased, make sure you secure your account from Fortnite hackers!
What I do is have a separate project called AssetProject that I install any Marketplace assets into.
I can check out those Marketplace assets in that separate project and if there are things I want to bring over to my project, I’ll use the Migrate function from there, that way I only bring over what I want and all it’s dependencies.
I also usually move the assets to a folder in Content/Marketplace/ after bringing them into the Asset project, so when I migrate they go into the right folder in my real project. Then I add the resulting files to Perforce either through the editor or through my workspace view.
This has worked pretty well so far, but there are still some awkward issues that crop up like you mention. Renaming files or folders then doing “fix redirectors” works pretty well to solve some of those issues.
When I upgrade to a new engine version, I make a new AssetsProject for that engine version and use it from then on.
I know; that is why I decided to go for “bleeding edge” (4.20); by the time I’m done, there might be a 4.20.3 …
For most things, I try to buy at least two packs, so I can choose the best for my project. So I could very well not use half of those assets.
That one I hadn’t thought of. Is there some rule-of-thumb as to how much is too much? Or should I just add packs until the editor starts “crawl” and/or use too much RAM?
Still working on this one.
That sounds sensible. My thinking kind of went along those lines: when i have to do some manual work/repair, I first bring all needed tools and materials before I start. Otherwise I spend half of the time going up and down the basement stairs. That is what I wanted to avoid: having to “break the flow” of creating to go and dig through “countless” packages every time I need some specific asset.
I don’t have Fortnite; I’m more of a single-player kind of player.
I was considering doing it that way. But franktech suggest I might run into some editor limits if the AssetsProject becomes too big. I guess I can always break it up in Environment/Character/… if need be.
So you don’t “merge” the asset packs together in AssetsProject, you keep the packs separate, and only move/rename them in your actual project IF you decide to import them?
Once you launch your ‘master asset project’ to migrate assets out, you may experience ‘Out of Video Memory’ errors more often, which can crash all running UE4 sessions. Some engine versions suffer from this worse than others. You may also run out of main memory. Then it can take an age to load as the page-file gets repeatedly hit…
So for that reason I favor keeping smaller side projects. Plus they are easier to update and its easier to find stuff. Sometimes, you want to go back to a project whose author or style you like. Just to see what else they’ve done. Monolithic projects make that harder, because similar names / paths get used by lots of devs. When that happens, everything gets mixed at the top-level.
That’s why it also makes sense to only rename assets when they’re used… Take this example. You have an explosion or bloom laser effect which you scale or colorize later on in duplicate. The latest project requires 4-10 of these for each player in split-screen. Having called them all Laser effect before doesn’t work anymore. So all your previous attempts to put structure seems pointless now. The ‘Super-Asset-Project’ is just an intermediate project, its not the final destination.
You misunderstand. With the rapid rise of Fortnite, Epic have failed to segregate gamer accounts from dev / marketplace accounts. They should going by the sheer number of hacks on here. So don’t leave your credit card exposed or permanently tied to your account. Its risky!
Lots of devs found 4.18 stable ‘after’ the fact. But there were/are problems with 4.19 plus 4.20 too. So wait until there’s a 2 or 3 in the release number.