Finally I have ported the Neverwinter Nights Campaign style database to UE4 (sort of anyhow. hah!!) That database was included with the engine and was very easy to split the databases to individual users/items/objects. Like in example Persistent Time had its own database…resetting the time on the server was a simple as deleting the database files. The reason why I needed time to work is that it carries the heartbeats for everything as well as linking in timed events…such as Auction Hall, festivals, enemy raids…the options are endless. None of that functions without persistent time.
You can use same technique to track player position, health…whatever. You can also grab the heartbeats established in Time (shown here) to activate many other things in the game engine. Limitless uses.
Simply follow the instructions and pics below.
Enjoy!
What it does:
Each frame it adds the Delta Seconds to a 50ms Float. So basically every 50ms a pulse it run. The pulse adds 0.05 exactly to the heartbeat floats. So automatically scales to whatever computer it is running on. Even if the frame time is very long it works very accurately. When each heartbeat float is >= to their values (ie 1000ms) then their heartbeat is available for use.
If Persistent Time is ON (set to 1) then every 1 second the current time values are saved to the database (save file). You may link to whatever heartbeat you wish.
Location of the save file: \Unreal Projects<YourProject>\Saved\SaveGames\PermTime.sav
How To:
Step 1:
Create a Blueprint called: GameData of type in Custom Classes => SaveGame
Open GameData and add the Variables…one the INT are added Compile and Save it.
Step 2:
Create a Blueprint called: Time as an Actor Class (so it can be dragged into the level. There are probably other/better methods but needs to run per frame!
Variables in Time:
TimeSave type SaveGame
Settings Group (change Default to Settings):
PersistentTime int 0=OFF, 1=ON
SecondsPerMinute int 60
MinutesPerHour int 60
HoursPerDay int 24
DaysPerMonth int 28
MonthsPerYear int 12
Runtime Group:
Current Time Group:
Step 3: Blueprint Logic in => Time
Overall Picture for reference.
Hey Krixa, is awesome!! The heartbeat delays alone will be very useful. Are you making a RPG style game based on NWN?
The rest of the blueprint looks interesting as well, I have been thinking of using my weather system to go through all 4 seasons dynamically based on how far into the game you get (but also the starting date can be chosen for a new game), is a calendar generator that can be used to track days/months/years? may be a little complex for what I am looking for (or perhaps not complex enough! :p) but reading through has given me a few new ideas on implementing .
The game design is similar in fashion to NWN1 and 2 engines…3rd person with Top Down style interiors you can zoom way out for strategy or be up close and personal. LoTRO, SWTOR and some others play way as well.
As for ‘Timing and Persistency’…you are exactly correct. above is directly connected to the Sun and Weather. What is not shown above is there is a Game Hours Per Real Hour for faster time cycles on an individual basis…ie 1 Real Hour = 4 Game Hours. There is also the names generated from time…which is then made into a proper calendar. The names can be in English, German, Elvish…whatever.
@Krixa, I look at it a bit, from your screenshot there isn’t a part of logic that use the Tick delta time, nor does 50ms gets updated. So with a very fast system with no framerate cap, it could have run game time a lot faster than real world time(usually preferred).
half is missing…i hate starting on something and left to figure out the puzzle Im no programmer! i thank you for free info but not all of us are programmers…
Sorry…indeed the 50ms pic was missing. hah!! I added it apologies.
As for the 50ms and not say 25ms or even faster. There could be a 10ms tick if really wanted but from my experience with other engines and controllers once the process and game is taking shape the frame ticks become a sore spot. 50ms is a very performance based goal which leaves a lot of headroom for frame dependent resources as well as a monitor for your performance during design.
Lastly what is very good is any frame time over and above 50ms is simply added to the next go around. So what your tick is actually giving you is exactly 50ms near the end of the frame. is incredibly useful.
