I have a blueprint that lets me put stars in a level.
Touching a star turns it to glass and sets its collected variable to true.
There are 2 variables, collected which is a bool array, and index, which shows where on the array this star is.
When a star is touched, it looks into the save blueprints collected array at the index of the star and see if its been collected, if it has, it just pops up a message, if not, it sets the collected to true at the index of the star in the save blueprint and saves the game.
Which it does, but, if I collected say 3 stars in a map, when I reload the map, on the last star that I touched is shown as collected, while the others are uncollected.
If I collect those 2 stars, only the 2nd one is saved when I reload, etc.
I figured it out, though I’m not sure, I added a load game node and that apparently fixed it. I assume I was just overwriting the variable each time I hit a star. I didn’t figure you needed to reload the game to get the variable again.
Either way it works, If there is a more efficient way or this is wrong someone tell me.
I guess it is up to you, and if what you have works it works … but if you put your SaveSlot and LoadSlot and DoesSlotExist stuff into your GameState class you can access it from anywhere easily; make your actors look up a variable there, it might be easier to logic out.
I’d try this (and I say try because I haven’t tried it) …
In SaveGame make a vector var which is StarArray (and convert the vector to an array using the little grid icon)
In GameState make a function which is SaveSlot X, and make a DoesSlot exist check and CreateSaveGame step
In GameState make a function which is LoadSlot X
Whether your stars are spawned or placed, do a location collection for each one when the game starts or when relevant and use that to populate your StarArray, then call SaveSlotX in GameState to update your StarArray on disk.
In StarActor, on your Overlap event do a remove-this-star’s-vector-from-array step (maybe loop through the vectors in the array till you get the one that matches), then call SaveSlotX in GameState to update your StarArray on disk.
Unreal Engine youtube has some example videos of ForLoops now…
On BeginPlay or Load, if DoesSlotExist is true, spawn Stars at the vectors remaining in the array (if any remain).
Something like that.
Note: If your star has a cute bobbing animation or similar, don’t get the location of the mesh component, get the location of its root component, or an added component which doesn’t bob.
I had no clue about SaveStates. I had a variable in the save file that was an array of all the stars that could be collected. Each star has its own uniquely set id that correlates to its collected state in that array, when the level loads its checks if its been collected. I like your way if it was something that required 100s of id’s… Like coins
I put this in the character class to use it when I hit a key, a save game function would go in the character class right, because I don’t know how to call the save function from a button.
But it does save, but it seems like a lot of casts?
Um, that short info in the doc link is about all there is to it …
When you start a level you go to the Blueprints menu and choose Create GameMode (or assign an existing one using the World details).
In the defaults on GameMode there’s GameState : …
You can make a GameState just like a regular blueprint in the content browser. Search GameState to find the base class and call your one MyGameState or whatever then assign it to the defaults entry in your GameMode.
So far as I know …
GameMode is typically used for establishing universal type rules of your game or really critical stuff that should persist within your project no matter what level is used.
GameState is typically used for stuff that updates the entire state of the current game or level, like scores and number of lives. I dunno, I just put in there whatever I don’t want in an actor or in the level blueprint.
But that’s just my 2c - from looking on UDK forums I’ve noticed some people do a lot of this sort of stuff in their Pawn class because there will always be a player in a game.
In the end, for best practices, consider that maybe you might one day want a multiplayer implementation of your game, so it is good to design with that in mind from the get go.
