Ran out of memory due to UI?

Development Programming & Scripting UI
, , , , , ,
1

So I’ve been creating some UI to support my quest system and I generally tend to create a C++ classto manage the functionality and the Blueprint to maintain the design and make use the the methods I create in C++.

So far i’ve had little issue with this but after leaving the game running for a while, it seems that the game crashes whilst accessing a method in C++ that simply returns an FString:

UQuestObjective::GetObjectiveName() in https://github.com/belven/Mech_RPG/blob/master/Mech_RPG/QuestObjective.cpp

Unless there’s low limit on memory usage, I don’t see how a function binding would the engine to run out of memory?

2

Well firstly, quests giving items as a reward/requiring items as a reward is one of many things a quest will need to do. For instance, you have a quest to go to a place in the map. The quest doesn’t need to know what the objective is just that it’s complete and the go to location objective will just inform the quest that thee player has reached the destination.

There are also many different types of objectives and rewards, some objective examples:
Collect x of item, kill x of enemy, go to location, complete another objective/quest, interact with object in the world etc.

Therefore, I’ve created a list of events on the player that an objective listens to to determine if it’s complete, then it will inform the quest that the objective has been completed.

Also, quest rewards can be, other quests, objectives, items, experience, an area of the map oppening up, a boss spawning, new crafting blueprint, stat boosts etc.

For both objectives and rewards I have therefore created a class for each of these situations to allow them to handle the different situations themselves and just tell the quest when it’s done.

Also all the objects I create have functionality, otherwise I wouldn’t have made them.

3

“giving items as a reward/requiring items as a reward is one of many things a quest will need to do.”

rewarding/requiring items are generic things an inventory can do, so thats not true. quest will not need to do that, if your inventory handles that functionality.

your current method of using quest objects wastes more memory than moving their functionality into the inventory, and moving their data into quest structs.

“The quest doesn’t need to know what the objective is, just that it’s complete”

that sounds like data to me. why make it an object, when it can be a struct?

“The location objective will just inform the quest that the player has reached the destination.”

reaching a destination can be determined by collision with an actor. its no different than a pickup item.

“There are also many different types of objectives and rewards, some objective examples: Collect x of item, kill x of enemy, go to location, complete another objective/quest, interact with object in the world etc.”

those are all the same thing. actor gives item to inventory, based on the type of item, the inventory checks if other relevant items exist, if so, inventory gives itself a questcomplete item. all of that functionality can be built out of 2 functions that the inventory already does: adding items, checking for items.

“Also, quest rewards can be: other quests, objectives, items, experience, an area of the map oppening up, a boss spawning, new crafting blueprint, stat boosts etc.”

all of those things can be simple items in the inventory, mixed with actors that check for those items before spawning a boss, or opening a door, etc…

“Also all the objects I create have functionality, otherwise I wouldn’t have made them.”

some things should not have functionality. its called data. my main point is that if you want to reduce memory, i suggest you replace as many commonly occurring objects with structs, as you possibly can, it will improve performance.

4

So basically your “Inventory” is also a quest manager, sounds like a bad design concept to me. it makes no sense to make an “Inventory” an object soley designed to manage item also look through the players quests every time an item is added and see they have been complete. My way round means that the quest gets told when an item has been picked up and only that quest handles it.

Imagine if the player had say, 30 quests, and only 1 needed x items. Every single time an item was added / removed, you’d have to loop through all the quests to see if they need it.

Also now, every inventory class needs to know about quests, and therefore every time you create an inventory it needs to store quest information as well.

In any case, I’m sure you have a game working with your system and mine has been working fine up until now.

Here’s mine by the way:
Game overview 2016 03 04 - YouTube (Sorry for the bad sound)

5

“it makes no sense to make an “Inventory” an object soley designed to manage items, also look through the players quests every time an item is added and see they have been complete.”

the inventory doesn’t have to loop through a quest’s objective list every time an object is added, only when an objective related to that quest is added.

“Imagine if the player had say, 30 quests, and only 1 needed x items. Every single time an item was added, you’d have to loop through all the quests to see if they need it.”

you dont need to loop through all the quests. even when you get an objective, at most, you only have to loop through the quest’s list of objectives, and check the inventory for those objectives.

“Also now, every inventory class needs to know about quests”

this is true, but you only need 1 inventory per player character. its better to create a single object with a tiny bit of extra functionality, than to create thirty objects that each waste memory holding copies of that same functionality, along with the overhead of creating objects.

“therefore every time you create an inventory it needs to store quest information as well.”

you only need 1 inventory per playable character. any player that can collect a pickup item can probably also complete quests.

quests are collectible items. inventories hold and manage collectible items. if you really want to separate that quest checking function from the inventory’s item checking function, you could put it in a static function library.

imagine if ue4 used objects to represent Vectors, instead of using structs, with separate math functions in a static function library. every time you wanted to use a vector, you would have to create an expensive object, which contains extra data for describing all the math functions a vector can do. for a few vectors, it wouldn’t matter, but if you have thousands of vectors at once, separating the data from the functions is necessary to improve the performance.

6

How would the inventory know “when an objective related to that quest is added”? Does it store a short list of RequriedQuestItems?

“you only have to loop through the quest’s list of objectives, and check the inventory for those objectives.”
Again how do you know if only a specific quest needs to change without asking all the quests?

“but you only need 1 inventory per player character”
Fair enough, but in my case, it just has a few methods and contains a TArray, so it’s very small.

“quests are collectible items”
I still don’t see the connection of quests and an inventory. Why would the player go looking through his inventory to see if he’s talked to a particular NPC?

"separating the data from the functions is necessary to improve the performance. "

I’m almost positive that the complier only ever makes one copy of a function and then references it with the current instanced object.

7

Also, just to clarify, I’m genuinley interested in your thoughts, not trying to say I’m right etc. I rarely get to talk to people about design etc.

8

“How would the inventory know when an objective related to that quest is added?”

the general idea is that the objectives have a property that references the quest or list of quests it belongs to, and the quests reference a list of objectives that are required for completion.

“I still don’t see the connection of quests and an inventory. Why would the player go looking through his inventory to see if he’s talked to a particular NPC?”

GTA games usually have a briefs menu, many RPGs like Witcher have a journal menu, WindWaker had a Bombers notebook… its up to you whether you want to have a menu where a player can look up previously spoken dialogue, but you should probably at least keep track of collecting mission dialogues either way.

i think your idea of an inventory is a specific part of a pause menu, whereas my idea of inventory is much larger than just the menu system. its anything that goes into the save file + anything that shows up in any menu + anything the player can collect + any text that shows up on screen. i even consider menu options like SoundFXVolume or XAimSensitivity to be items in the inventory.

“I’m almost positive that the complier only ever makes one copy of a function and then references it with the current instanced object.”

i think thats true, unless you use virtual functions, or maybe template functions, but there are other costs to creating and using uobjects instead of ustructs, and although these costs are very small, they add up, and since this is the most important part of your game which handles all of the collected data, it makes sense to optimize it by using structs whenever you can. also savegame cant save instances of objects or actors, only value types like structs.

im not saying objects are bad for performance, i am saying structs are better for performance, and when you have a system that keeps track of hundreds of thousands of collectibles, getting it optimized is important.

9

to be honest, i haven’t tested the overhead of objects vs structs myself, but i have heard from many sources, including Rama, that structs are cheaper to use than uobjects, and i assume he did the research. also, i have looked at the code of many games, including many game boy rpgs, and they use structs for holding data, and i assume game boy games are about as optimized for performance as you will find. also i have read lots of articles on data oriented design vs object oriented design, and they say that oop has performance drawbacks. although it does have better security and better encapsulation.

OOP is great, but if you get too grainular with how much you split up your objects, you end up with alot of tiny parts that depend on each other, and alot of overhead for creating and destroying small objects, which is bad for performance and hard to read. im not saying throw out Object Oriented programming, just that smaller objects can sometimes be refactored into larger objects to improve performance, and whenever possible, use structs instead of objects, when working with state data.

when you say an inventory and a quest manager should be separate things, it makes me think you are more worried about aesthetics than performance. functionally, they do the same thing: they are both just interfaces that wrap an array. they both just add items and check on items.

why do you need more than one interface for getting/setting elements in an array? why should these be separate objects? if you claim its because the “single responsibility principle”, i would point out that my inventory does have a single responsibility: keeping track of data arrays.

i would also point out that removing the quest responsibilities from the inventory, does not make the inventory any simpler. it will still need to add items and check on items, but now you have another object that also needs to add and check on items. and you need both of those objects to work with your save game system.

10

Yea makes sense, I use structs for a fair few aspects of my game, for instance, weapon data here:

https://github.com/belven/Mech_RPG/blob/master/Mech_RPG/Weapon.h

Mostly because I can then use inheritance in the stuct to add data for stuff like:

https://github.com/belven/Mech_RPG/blob/master/Mech_RPG/MagazineWeapon.h

An inventory could be a stuct but it would only be used for “Items”, stuff you would actually carry with you, although I do think of a quest as a to do list, I don’t think an inventory should manage it. Also because not all inventories will be used by a player, like chests etc.

I’m very concerned that some simple UI is causing the game to crash though, I don’t see how an object that basically stores a string and x objects that store, at most, a string a 2 other properties plus a few methods would do this. The game runs at less than 1 GB RAM and I’ve stress tested it with over 100 AI…

11

im also interested in learning your methods for doing things, and i love discussions like this, it lets me work out the kinks in my programming philosophies, and gives me inspiration to learn many different ways to solve problems. so thanks for pointing out anything i say that is incorrect, im always learning new things, and i have a long way to go.

12

in questObjective.h, you are using:

void SetQuestObjective(FString objectiveName = "Test Objective");

usually when i see an FString set by a literal string, its surrounded by TEXT() for some reason.

void SetQuestObjective(FString objectiveName = FString(TEXT("Test Objective")));

not sure if that is related to your memory problem, but it is near the area that the out of memory error is complaining about. maybe every time you are creating one of these objectives, it is converting the ANSI text to TCHAR which is less efficient.

also this is related to the other discussion of structs replacing objects for state data and small common parts:

do you only run out of memory after adding quests to the list?

im not too familiar with the profiler tools, but this video might help you debug your problem:

https://docs.unrealengine.com/latest/INT/Engine/Performance/
13

It only occurs after about 40 - 50 seconds of starting the game and adding quests. They function correctly for that time but then it runs out of memory after a minute or so. All my other UI is done in the same way, it’s odd that quests would be specifically causing this.

I’ve also done a stress test, with 100 + AI again and the FPS dropped but it worked fine for 20 minutes without quests involved.

I’ll look through the code and see if removing some functionality makes a difference, i.e. remove the event listeners etc.

14

Is this using Slate/UMG, and if so, how is your UQuestObjective::GetObjectiveName function bound to your UI? Slate also requires FText, so I’m guessing it’s being converted somehow?

I’d also be curious to know whether you still see this issue with 4.11 (if it’s possible for you to test). Prior to 4.11, it was possible for a shared pointer to leak its reference count object under a very specific set of circumstances, and FText could cause this leak if used in a certain way.

15

Yes, I’m using a UserWidget: https://github.com/belven/Mech_RPG/blob/master/Mech_RPG/QuestUI.h and creating a blueprint of this and then converting FString to FText in the blueprint function, which is bound to a text field.

I’ll try and upgrade to 4.11 and see what changes. I really want to find a way to directly bind to C++ methods oppsed to creating a blueprint specific one.

16

I tried upgrading but now my character can’t move and the quests still break in the same way.