Toy on a Mission UE4 Remix - NewDirection - N1 Greetings. Notable Stuff done since last entry: I have replaced the old WIP options widget with a new WIP options widget that uses tabs like a browser Set custom built UE levels to not be packaged with the game, Instead I am using the UserMap system (json file that a level is built from at runtime) Added a Actor Component to some classes to have the DynCube(array of cubes that adjust based on distance to registered data) A lot of work into profiling and optimizing DynCube The map now is made from multiple DynCube instances, This allows disabling of instances that are not visible Options widget: The old one ooked like this: And the new one is this: The old widget had all its logic stored in itself, which made it a bit messy and a bunch of code that repeated itself in different ways. The new one is made from multiple widgets with each widget handling one side of the options setup (Graphics, input, game settings, Etc) The graphics options comboboxes are each a widget that handles their own logic based on what setting they are supposed to change/represent, This does have the downside of each option applying immediately. DynCube (optimization): Using one instance for the whole map worked well until testing a map that had a path length of 10 and seed of 500, I estimate over 15,000 instances that can be affected by Queued updates. Queued updates are done by a component that registeres with each DynCube instance that tells each instance its data (location, radius, curve that affects instance offset, Etc ). The cube array is built as a rectangle based on a width & height. The array construction checks to see if each cube instance overlaps with a rectangle from one of the lists: Non moving: the cube stays in the out position so that the level has walls/floors. No instance: the cube stays in the in position so that any Actor in that location is not hidden. Area: Used to have Queued updates only affect instances in the Areas that they have enabled So using multiple DynCube instances to build the map made the game thread shoot to over 300ms, thus turning the game into a slideshow. Using one instance did not have this problem, The game thread time was in the 35ms range for the same map. It turns out that checking Area IDs & instances chews up a lot of CPU cycles if each DynCube instance has unnecessary Areas. I am certain that using multiple DynCube instances of 10x10 size results in upto a few hundred loop iterations that ultametly does not affect that instance. So I added a Actor that would build a flat tree of each DynDube instance and enable their Tick (update) if the player was within range; And added a method to DynCube that removed rectangles & areas that did not overlap with the instance, this removing all the unnecessary iterations. The result being that the game thread was now in the ~30ms range, Quite acceptable for now (I want to hit 60fps). Future work: The next 'big' thing I am going to do is use a material effect to only show stuff around the player in a range to work with disabling DynCube instances. Get back to improving/working on UI/UX Checking performance on other computers. Adding a end peice to levels that brings up a widget with info and asking the player what to do Thanks for taking the time to read this entry. That's all for now, Ryan. https://ift.tt/eA8V8J

Greetings. Notable Stuff done since last entry: I have replaced the old WIP options widget with a new WIP options widget that uses tabs like a browser Set custom built UE levels to not be packaged with the game, Instead I am using the UserMap system (json file that a level is built from at runtime) Added a Actor Component to some classes to have the DynCube(array of cubes that adjust based on distance to registered data) A lot of work into profiling and optimizing DynCube The map now is made from multiple DynCube instances, This allows disabling of instances that are not visible Options widget: The old one ooked like this: And the new one is this: The old widget had all its logic stored in itself, which made it a bit messy and a bunch of code that repeated itself in different ways. The new one is made from multiple widgets with each widget handling one side of the options setup (Graphics, input, game settings, Etc) The graphics options comboboxes are each a widget that handles their own logic based on what setting they are supposed to change/represent, This does have the downside of each option applying immediately. DynCube (optimization): Using one instance for the whole map worked well until testing a map that had a path length of 10 and seed of 500, I estimate over 15,000 instances that can be affected by Queued updates. Queued updates are done by a component that registeres with each DynCube instance that tells each instance its data (location, radius, curve that affects instance offset, Etc ). The cube array is built as a rectangle based on a width & height. The array construction checks to see if each cube instance overlaps with a rectangle from one of the lists: Non moving: the cube stays in the out position so that the level has walls/floors. No instance: the cube stays in the in position so that any Actor in that location is not hidden. Area: Used to have Queued updates only affect instances in the Areas that they have enabled So using multiple DynCube instances to build the map made the game thread shoot to over 300ms, thus turning the game into a slideshow. Using one instance did not have this problem, The game thread time was in the 35ms range for the same map. It turns out that checking Area IDs & instances chews up a lot of CPU cycles if each DynCube instance has unnecessary Areas. I am certain that using multiple DynCube instances of 10x10 size results in upto a few hundred loop iterations that ultametly does not affect that instance. So I added a Actor that would build a flat tree of each DynDube instance and enable their Tick (update) if the player was within range; And added a method to DynCube that removed rectangles & areas that did not overlap with the instance, this removing all the unnecessary iterations. The result being that the game thread was now in the ~30ms range, Quite acceptable for now (I want to hit 60fps). Future work: The next 'big' thing I am going to do is use a material effect to only show stuff around the player in a range to work with disabling DynCube instances. Get back to improving/working on UI/UX Checking performance on other computers. Adding a end peice to levels that brings up a widget with info and asking the player what to do Thanks for taking the time to read this entry. That's all for now, Ryan.

from GameDev.net http://bit.ly/2PL9sXs