I’ve been working on an icon-based Inventory screen for a game and I decided to release it as a UDK Starter Kit, and now it’s ready for a release. Therefore I can now present Chosker’s RPG Inventory Starter Kit.
This Starter Kit implements an Inventory system into UDK including a Scaleform Inventory screen (written in ActionScript 2), integration with the Pawn’s Inventory Manager, weapon/Armor/Item stats, Weapon/Armor equipping along with an Armor attachment system, Item Dropping, and Pawn and Container Looting.
Much like UDN’s Starter Kits it is meant to serve as a basis for a new project, but there’s nothing to stop anyone from implementing it into an existing project’s code.
I’m back with a new update. Things have been slow lately but I’ve gone one step forward by implementing an important feature. Yeah you guessed it from the title, it’s the Random Dungeon generation.
The idea behind how I’m generating the dungeon comes from this page, but my implementation has nothing to do with BSP (only the concept of splitting areas into child areas and keep the tree as a reference). In reality I’m doing it as follows:
Following up on the work on Dungeon Escape (name pending, sounds a little too generic and there’s a few ones with that name around) I’ve further developed the dynamic pathing and AI aspects, which actually work very close together.
The dynamic pathing is just a series of custom dummy actors (imagine something like a Note actor) which I can place in the editor and spawn at runtime. Besides that all of the pathing is done by the AIController by using traces to check if such a DynamicPathNode is available to walk to.
With this I’ve developed a patrolling routine that makes the AI control the Pawn to navigate between available DynamicPathNodes and prioritizes them to decide where to go next (usually driven to the right but also takes into account unvisited Nodes and a few extra stuff to make sure it doesn’t go on weird loops or leave places without visiting). In general it works quite well and it doesn’t eat too much resources. In addition it also detects when it reaches a dead end and once he does he will turn back around a rest for a few seconds before going back to his patrolling; it’s also able to cut corners in a curve to prevent the patrolling from looking stiff, as well as going around other Pawns that might be on the way or totally avoid them if they are also patrolling.
The next feature (here’s a pic) is following the Player.
Back when I was starting with AnimTrees and scripting I encountered a problem when trying to play a non-looping animation from within the AnimTree: once an anim sequence node becomes relevant it will start playing the animation at the time it was if it was played before, which means the animation will only play from the start the first time.
I’m working on a menu that will allow the player to re-bind the game actions to different keys. Before the menu comes though, there’s some stuff needed to make it work: being able to re-bind a game action to a different key.
As you probably know the keybinds are found in UDKGame/Config/UDKInput.ini. If you press a key it goes and tries to find the apropriate function in the PlayerController class, and then on his owned Pawn class. However you might not know that before looking in the PlayerController class, it looks in the Input class. To keep things clean then, we’ll implement this functionality in the Input class.