This asset is meant to give you a good foundation to implement your own Diablo-like games.
I made efforts to make the features as modular as possible (Everything is implemented in Actor components).
Everything has been designed to work for both singleplayer and multiplayer.
Most of the features are “data driven” which means that you only need to modify values inside a DataTable to create your own content. [HR][/HR] here is a list of all the fonctionnalities :
**Player stats : **
There are multiple stats for the player : Resistances (Everything which “counter” damages : physical, fire, ice,…), Attributs (Strenght, Dexterity, …) and states ( tooglable “modifiers” which influences the player : Rooted, Invincibility, Silenced,… )
XP and leveling :
Also handled inside the StatsComponent. You gain a certain amount of XP when you kill an enemy and each time you gain one level you unlock points that you can spend to unlock Skills and Skill Sets
**Player skills : **
There are two kinds of skills :
The ones which allow you to unlock passive modifiers which will influence player stats,
The ones which will unlock spells for the player
All skills are data driven : You can add a new skill by simply writing on a Data table
Skills Are grouped inside Skill Sets. You can unlock multiple skill sets.
A skill tree is automatically built in the UI, based on the skills dependencies.
**Spells : **
Spells inherits from a base Spell class. Their are not Data driven so you canwhat you what you whant for them.
Spells will consume stamina
Spells have options to be launched on self, or on a specific target
**Equipment : **
An equipment panel allows you to equip weapons and armors to the player.
Each equipment can modify player’s stats when equiped (A “fire armor” could give you fire resistance)
**Weapons and Damage system : **
Weapons can be “One Hand” or “Two hand” and you can force player to equip them on left hand (Bow,…)
The damage system take “Damage types” into account these damage types are linked to resistance (For example, Fire resistance will reduce Fire damage, …)
**Effect Handling : **
You can apply effects through the EffectHandler component. There are two kinds of effects :
State modifier effects : Will modify player stats when applied
Damage effects : Will damage the player (immediatly or over time)
**Items handling : **
Inventory : You can attach an Inventory component to the player. The content of this inventory can be displayed on UI. Things like item split, stacking and right contextual click menu for items are implemented
Item in world : 3D representation of items once they are dropped in the world.
Chest : Stores items. The chest owns an Inventory component. In multiplayer, only one player can check chest content at a time.
Item bag : Item bag are like chest but they can be automatically created when dropping items (for items which doesn’t have 3D representation) and they automatically desapear when they are empty.
Loot chest : An actor which will spawn loots around it when you interact with it.
**Basic enemy AI : **
Enemies will detect the player and will chase it
**Main menu : **
A main menu is implemented. You can create a new hero, select a hero, and choose between single player game or multiplayer game. (Note : I haven’t implement setting panel)
**Traveling system : **
Go through gates to travel from one level to another.
**Save/Load system : **
Save player location by activating fountains
Save and Load of player is implemented (Saved : Inventory, Equipment, Skills, Stats, player location)
Not great at the feedback thing but what you have here so far just looks amazing, especially cause it has a save/load system so keep up the amazing work man!
I will probably release it at 80$. It seems to be a good price if we consider all the functionalities of this asset.
Took me longer than I thought, but here is the video of the main menu :). It is still a work in progress.
I won’t make it third person for now. That said, Almost all the fonctionalities are made with ActorComponents, so it is very modular and it shouldn’t be difficult to make a Third person mode if you are familiar with Blueprints (All you have to do is replacing the Controller and the Character. Then adding Inventory, equipment, stats as ActorComponents).
In the futur, I will probably split the functionalities into smaller assets so that you can use them separatly (probably one with inventory/equipment/items and one with skills/spells/abilities).
Reading the documentation, can’t see where it says I can add NEW Stats like Spirit, Charisma, etc (see u have Stamina, Intel, Agility). Is it as easy as adding it to the Stats data table?
Stats are plit into 3 concepts : Resistances, Ability and States. Each one is represented by a struct with the same name. and the type of resistance/abilities/states are stored into enums (EResistenceType, EAbilityType and EStateType).
You can easily add new Resistances, Abilities or States. All you have to do is adding a new type inside the enum. and go to the BP_StatsGlobalDatas to add display datas for this new stat (the displayed name, dexcription and icon associated with this type).
Now your new stat is handled by the StatsComponent and will be displayed inside the stats panel. Then it’s up to you to know how to use it. I’ve already used Resistances to handle damages (I do it in the StatsComponent, inside IsDamageCounteredByState(), and GetResistanceValueForDamage()). But basically you can access your new stats with functions like StatsComponent::GetResistanceCurrentValue().
In addition to that, few stats like the health, the mana, the attack speed and the move speed are directly handled by the StatsComponent. If you want to modify them you’ll need to modify the StatsComponent.
I’ve been playing with this for a week now, some impressions:
The good
Works out of the box in almost every aspect.
Player movement and interaction with environment is good, the order system is really eloquent and well designed, at least for my purposes.
Inventory mechanics are well designed.
Solid combat mechanics, albeit a bit limited, but easy to expand.
Component-driven design makes it quite modular, but…(see 4 below)
The not-so-good
I’m not enthusiastic about certain design elements pertaining to items in the game.
The item system design does not really allow for easy randomization of items (as is tradition in these sort of games, Quick Sword of The Owl, anyone?) without major revamps. I’m especially not keen on the datatable-driven approach to items and equipment. I mean, both the item and the weapon contain the necessary information to spawn either, why go through a datatable and not just pass the information along on equip or unequip? To me this is a bit unnecessary and makes the modding of this base a bit more work-intensive. I’m redesigning the whole approach now to be easier to spawn random weapons and equipment.
The multiplayer is buggy. Character movement wasn’t set to replicate for starters. This was just one check-box away, so no biggie. I didn’t test this outside the client, it could work perfectly over LAN on separate machines with cooked content. Running it under the client and starting with two players the character creation screen bugs out and doesn’t allow joining or hosting a game, or creating a character. Didn’t troubleshoot this, because I’m not working on multiplayer until a bit later when I’ve changed some other aspects. Having looked through the code, I don’t see major hurdles ahead. Besides I’m going to implement a separate server, so most of the coding is irrelevant.
Limited options for combat and weapons. Ie. it’s missing regular run-of-the-mill combat aspects like AOE-damage, penetrating missiles etc., but like I said, these are quite easy to add on top of the base.
…it takes a day to understand and modify a simple feature, due to the complexity. This could also be because I’m really rusty on my blueprints, heh.
Bottom line:
If you are making a top down Diablo-style ARPG, this is a good base to expand on and I can recommend it.
Hello @Groatse .
Thank you very much for the detailed feedback. I really appreciate it.
I’ll just comment on the “not so good” points :
1 - I chose to implement items and equipments on data tables because I think it’s a good idea to separate this kind of datas from the rest of the implementation. Let’s imagine that you are working with a game designer and you want him to make some changes to balance the gameplay. Then all he needs to do is open the data tables and tweak parameters (damages,…) to modify the gameplay.
That said, you can skip data tables and implement you own items which inerits from BP_Item. This is what I tried to implement with the ItemKey : if no valid table is found for this key, we will treat the Item as a custom item and spawn it using only its class. (Check BP_EquipedItemsComponent::EquipWeapon() to see an example of how I implement it). The drawback is that for each custom weapon you need a custom item… Maybe I should add an option inside the data table to let you choose if you want to override datas or keep the default datas of the weapon (I add this to my ToDo list ^^).
2 - For multiplayer : It’s normal that the menu bugs if you have launched it in multiplayer inside the PIE. Two players are not supposed to coexists inside the menu, which makes sens because at this point you are not entered in a multiplayer session, you are just on the main menu. But everything works fine if you build the game and launch multiple instances.
For the movement… It’s strange, everything seems to work fine during my tests. I’ll check that.
3 - For combat I wanted to implement a basis and give the opportunity to the developper to build his own system on top of that. Moreover, your weapons and spells basically just need to override base classes to be regognised by the system. So you can easily implement your own behavior inside them.
4 - Not sure if the component-driven implementation increases the complexity. It would have been a hell if I have had decided to implement everything inside actors XD.
But yes, the system can take a little bit of time to be mastered, specially because I implemented a lot of different features. I mean… It took me 4 months to implement it. It will whatever save you a huge amount of time ^^.
Hello @Harcarik !
If you’re talking about the displayed item labels on ground :
A class handles all these labels (the ItemDisplayerPanel). Each tick, this handler will go through each displayed label and it will correct their location so that they don’t overlap each other.
I use the GetPosition() and GetDesiredSize() functions of UWidget to know the Rect of a label, then I check if two Rect overlaps with this function :
!
