Hi! I’m kind of a noob, so please forgive me if this question doesn’t even make much sense.
Anyway, I’m working on a JRPG-style game, and one thing I’m not sure of is the best way to handle all the variables that will be required. Stuff like, what the player has in their inventory, how many of each item they have, what items they’ve interacted with (opening treasure chests, etc), dialogue options they’ve chosen (for instance, an NPC in the first 5 minutes of the game needs to remember what dialogue options the player chose if the player comes back 50 hours later). All these things need to be kept track of and persist throughout the entire game, be saved and loaded, etc.
My understanding of UE4 is pretty minimal, the only way I really know to do this would just be to have hundreds (if not thousands) of variables in the game instance, which are saved and loaded and called on as needed. This seems pretty clumsy; is there a better way to do stuff like this?
Every RPG will have hundreds to thousands of variables; that’s just how it is…
You are supposed to split up your game into systems and sub-systems, attribute system, inventory, items, equipables, battle system, quests, etc etc… RPG games are big, a lot of work.
If you want to make your life easier you could make everything based on structs of bytes (max value 255), like in the Final Fantasy X game, a good example; FF12 uses a much much more complex Jrpg design and all of its damage/status formulas are much more complex.
Wouldn’t they also use Data Tables to handle all these many thousands of variables? That’s what has to happen in my game, because my game has over 2,300 variables in it already and that’s just in the text Batch Script version of the game. Abt 70 pages full of variables. I already have a couple of arrays in the game that go beyond the max 255 byte limit.
You definitely won’t want to be putting everything in the game instance. Side note, but I’ve been devving for a while, and only just STARTED using game instances… Interesting how we learn in different ways
Anyway, to get started, I’d recommend crafting an Experience system. Make it so you can get experience by pressing a Key (or doing an action), make it so you can level up, and make it so you can save and load this data.
This is a great point to get started. It’ll give you a bit to learn, but it’s not too much either.
If you need any help feel free to ask. But to start, you’ll want your character. You can store his level, experience, and experience required (3 variables required for a level system) on him.
The save system will also need those variables. You’ll get the data from the character, save it, and load it again later on.
Once you can save/load/affect experience/level/experience required, you can do it for any kind of data really, it’s the same principles
Oh hey, cool, thanks for the advice I use game instances because they’re really the only way I know to have persistent data, and the only thing I know of that can interact with any other blueprint. Unfortunately, and I have no doubt this was a bad idea (seemed good at the time, though :P), I don’t really have a specific player character. Instead I have the actor I want to be controlled spawned every time a level loads. At the time this seemed like the most flexible way of doing things, if I wanted to have multiple PCs etc. Actually, now I think about it, this might not be such a big deal; I’m doing the old-school JRPG thing of having random battles that take place in a separate ‘arena’, so when the player’s moving about in the world their stats don’t matter. Hmm, but they do have to be able to access their inventory…
I think, ideally, I want to have several separate places to consolidate all the variables that would be necessary, eg an inventory, character stats, variables used in levels, variables used in battles, etc. Is there a way to create these separate sets of data in a place that can be accessed by any other blueprint at any time?
Regarding the experience system, I have enough knowledge to implement something like that without too many problems. My issue is more with figuring out where to store that data and how to make it as easily accessible as possible to all other blueprints/actors/whatever.
Anyway, I’m not sure how much sense I’m making, but thanks again
Ah I understand more what you’re trying to do. I can see why putting it on the pawn isn’t necessarily what you want to do (though you could have a main controller pawn depending). You’ll still need a place to store that data between sessions though, which means you’ll need a save system. You’ll need this regardless since the game instance is per session, and they’re fairly easy.
But to answer your question, in this case, I’d likely put much of this on your PlayerController. Then you can use that to save/load data, to spawn in pawns based on their characters with the appropriate stats, access inventory, and so on and so forth.
There’s a few ways you can do it but that’s how I would personally.
Nifty, thanks. I did look through a basic tutorial on save systems a while back, I’ve forgotten everything I learned but at the time at least I understood it, so I should be okay getting another one working
But, now, sorry to ask more, but I just cannot figure out how player controllers actually work. I created a new player controller and set it as the default, but I can’t figure out what it’s actually doing, or how to communicate with it… How do I set and get variables from it? And does the player controller persist when you load new levels? Actually, what things do persist when you load a new level, other than the game instance?
Sorry to ask such basic questions, it constantly surprises me how much I don’t know
EDIT: Hmm, after closing my project and opening it later, it seems my new player controller was working. I’m sure I’d saved/compiled everything many times, so I’m not sure why it took restarting to get it going. But any variables I have on it seem to get reset when switching level.
Dig into blueprintable components. And then inheritance stuff. Also see blueprint interfaces, they are god send for system like this where you use inheritance.
For eg. you can make parent quest component, that connects to player, then knows how to send events to game instance, and receive other events back. So kind of communication blueprintable component. It also holds its own ID for quest and step player is in. When you have basic functionality working, you can make child (inherited) blueprint classes, that handle each questline. To see if player has quest you check if that quest component is attached to player.
When you want implement new quest you create child class to base quest component, then set variables for new quest.
I’ve seen you advocate this technique in the past on several occasions. I was toying with an idea of incorporating it into spaceship building and/or character skillset system (never thought of using it for a quest system, but hey, why not).
Would you be willing to advise on any potential issues when using components like that:
If you want more and see some perfect examples, check out these packs, they are affordable and have the best Blueprint code Content by Vanguard Interactive - UE Marketplace I am not affiliated with them, but i learnt a lot from their code and how they setup everything. But be warned, it is complex and RPG development takes a lot of time.
Thanks for the suggestions. To be honest I’m so incredibly impoverished that buying assets is a huge luxury for me, and those packs actually seem to be a fair bit more sophisticated that what I’ll need. I have no doubt RPGs are pretty **** complex, but really I’m just going for something pretty basic in terms of mechanics and so on, something similar to a 32 bit or even 16 bit JRPG. Any quests I implement will be really basic, gear upgrades and stat improvement will be pretty simple, likewise the combat. Even so, I’m not hoping to do anything more than have the foundations set up and a small part of the world built by the end of this year. Time is something I have
Uh that would require some demo utorial project. Blueprints are quite hard to explain without screenshots of graph.
Generally make solid communication between component and its parent. Best by using blueprint interfaces, because they solve problem of other blueprint class. So you send message to blueprint interface without worrying what class is that blueprint.
Trade off with blueprintable components is that you have a bit more complicated communication, but components are much more flexible.
If your going to limit the inventory size then you could create an array of actor items with a variable inside of them stating how many of that item you currently hold. Then just save the array of actors and make the variable savable(Will it be saved with the actor? I’m not sure) What items they have interacted with could be saved as a bool(s) on each actor(with the same logic? I don’t fully understand the Unreal Save system) Dialoge options could be saved from the NPC itself. But really the best way would be Data Tables(Especially for the Dialoge options).
It turned out to be pretty straightforward; the only thing I was dreading was running into some silly bugs. I was just curious whether you were aware of any no-noes, like ‘don’t rename structs in components or you’ll ruin it all’. And as expected, there’s seems to more casting required than usual. I’ll invest in the interfaces if things get out of hand. Thanks for the tip.
I use game instances because they’re really the only way I know to have persistent data, and the only thing I know of that can interact with any other blueprint. Unfortunately, and I have no doubt this was a bad idea (seemed good at the time, though :P), I don’t really have a specific player character. Instead I have the actor I want to be controlled spawned every time a level loads. At the time this seemed like the most flexible way of doing things, if I wanted to have multiple PCs etc. Actually, now I think about it, this might not be such a big deal; I’m doing the old-school JRPG thing of having random battles that take place in a separate ‘arena’, so when the player’s moving about in the world their stats don’t matter. Hmm, but they do have to be able to access their inventory…