Jump to content
Site Stability Read more... ×
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

2635 Excellent

About ryan20fun

  • Rank
    Advanced Member

Personal Information

  • Role
    Amateur / Hobbyist
  • Interests

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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 45ms 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. //----- Edit -----// I misquoted the single DynCube instance game thread time, It was actually 45ms instead of 35ms
  2. Greetings. It's been awhile. Development has been off and on due to side projects that grabbed my attention, Like a adding multiplayer to the FPS template as a base for fun. State of the project: Overall It will be playable if there where some levels and room packs(group of rooms) to use, The UI needs work to make it nice(er) to use. Some work has gone into allowing the player to customise the colours of things, mostly the player ball colours can be changed. I am aiming to have full colour customisation capability. I believe I am close to having a playable game, So that very nice Levels: Levels can either be prebuilt or made from stitching rooms together. Each room is like a level, but requires an entrance and exit teleporter to move between levels. The levels use an array of cubes that move based on their distance to Actors that have a Component that lets the DynCube(Cube Array manager) instance know where important stuff is. Tiled is used as the level/room editor using custom layer and object properties to denote what it is. The Tiled level is then run through a middleman to get the json file for the game to use, It has basic error/warning support. UI/UX I have started overhauling the widgets/menus to make it easier to maintain and add features/extend. Performance Overal performance seams okay. It seams that it is GPU bottlenecked at higher then 720p resolutions(Radeon HD7770), Turning down post processing settings seams to solve that. Having lots of cubes(upto a few thousand) via a HISMC seams okay. I will need to do more indepth profiling and assesment to see what I can do about improving performance. Future work: Build the level packs and custom levels. Have each level object type be randomised to add veriety, but allow the designer to set the type as an override. Overhaul the menus and add ability to rebind controls. Add bindings for GamePad, But I cant test that as I don't have a GamePad Building a community of interested people, Will need to look into what platform(s) to use. Do some blind playtesting and getting feedback on stuff. Need audio for: Player movement Music Menus/UI object impacts, just have to work out how to do that right... Thats all I can think of at this time. //----- Pictures -----// A picture of a test level: A screenshot of a different test level in Tiled: Thanks for taking the time to read this entry. That's all for now, Ryan.
  3. ryan20fun

    Unreal Engine 4: Dynamically Changing Input Bindings

    How do you get the currently pressed key? UMG TextBox ?
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!