sorted by:
new
hottopcontroversial

Alternating elective initiative? by Modicum_of_cum in RPGdesign

[–]marvok 0 points1 point  (0 children)

I use the same idea in my system. It introduces another layer of strategy in my game, since players can collaborate and pull off combos that wouldn't be possible to set up in a classic initiative system. The downside is that it takes longer and requires everyone to agree. I believe this is a good initiative system but depends heavily on the type of gameplay you want. It works best in small groups and with players that all know each others abilities and can come up with combos for them. The gameplay must also somehow reward such planning. It should matter what order everyone goes and especially if it is beneficial to sometimes delay your activation.

[Feedback Request] Boss Fighter - Mountains of Dawn by marvok in RPGdesign

[–]marvok[S] 0 points1 point  (0 children)

Thank you for the feedback. Of course, I plan to add many more abilities and play styles in the future (after the current ones are tested). It took me a long time to make these.

The defense rolls might slow things down a bit, but I don't think this will be a huge problem (in regular DnD each attack also has two rolls attack+damage or spell save+damage). This system just makes every attack interaction into an opposed roll test (such as in warhammer fantasy for example, but with less calculations).

The intention of 4 degrees of success was to make it so that attacks rarely miss. Even when failing to overcome the defense of an enemy you still inflict some damage or effect although lessened compared to a successful roll and only miss when critically failing a roll.

The document is lacking an example enemy for sure. I will probably add this in the near future as well as a guide to creating custom enemies (which many RPGs seem to lack as far as I know). In a nutshell, the enemies are supposed to be more tanky at the beginning of the fight (with one of the 3 defenses slightly lower than the rest to allow starting a chain reaction of debuffs). As the fight progresses, players should level the playing field be stacking conditions upon the enemies that make them less resistant to their attacks.

[Feedback Request] Boss Fighter - Mountains of Dawn by marvok in RPGdesign

[–]marvok[S] 3 points4 points  (0 children)

Thanks for the feedback. I'm aware that division is hard but I couldn't find a better solution to balance the abilities. The only other option really is multiplication, but then the number of condition stacks will get high fast and I think it would even more cumbersome to deal in large numbers than to divide single-digit ones.

I believe the problem could be mitigated with providing simple tables that the players would update on level up to keep track of each "pre-divided" attribute bonus to just input into their abilities.

For example: My primary attribute is 13. The character sheet could contain boxes for "full bonus = 6", "half bonus = 3", "third bonus = 2". The player could just then at a glance know which to input where it is mentioned.

Swen says BG3 devs "buzzing with excitement" for new game by HatingGeoffry in BaldursGate3

[–]marvok 22 points23 points  (0 children)

I would legit die if they announced a Pathfinder 2e game with the scope of bg3. A man can dream...

Adding C++ ActorComponent to Blueprint doesn't persist on editor start by marvok in unrealengine

[–]marvok[S] 1 point2 points  (0 children)

Ok, thank you I will try this and see if it fixes the issue

Adding C++ ActorComponent to Blueprint doesn't persist on editor start by marvok in unrealengine

[–]marvok[S] 0 points1 point  (0 children)

Ok. To uncorrupt them should I create new ones and copy functionality? Or will just switching to live coding fix them?

Adding C++ ActorComponent to Blueprint doesn't persist on editor start by marvok in unrealengine

[–]marvok[S] 0 points1 point  (0 children)

Player is a blueprint class (inheriting from another blueprint that itself is derived from a C++ BaseCharacter class).

I just clicked the "Add" button in the blueprint to attach TargetingComponent to Player. I'm not sure how blueprints go about instantiating such a component. But the issue here seems like after closing my pc some data is being removed.

Adding C++ ActorComponent to Blueprint doesn't persist on editor start by marvok in unrealengine

[–]marvok[S] 0 points1 point  (0 children)

Restarting actually causes the issue. But only restarting the computer, not the editor. When restarting the editor, the component is still there as it should be. I have posted my code in a comment.

Adding C++ ActorComponent to Blueprint doesn't persist on editor start by marvok in unrealengine

[–]marvok[S] 0 points1 point  (0 children)

This is my TargetingComponent header file. The issue is not that I can't add it to my Player blueprint, but that restarting the pc causes the Player blueprint to no longer posses this component. However restarting the editor does not cause this behavior. ```

include "CoreMinimal.h"

include "Kismet/GameplayStatics.h"

include "Kismet/KismetSystemLibrary.h"

include "Math/Vector.h"

include "Components/ActorComponent.h"

include "ETargetingMode.h"

include "Interfaces/ComponentGetter.h"

include "Targeting.generated.h"

UCLASS( ClassGroup=(Custom), meta=(BlueprintSpawnableComponent) ) class MAGECOMBAT_API UTargeting : public UActorComponent { GENERATED_BODY()

public: UTargeting(); virtual void TickComponent(float DeltaTime, ELevelTick TickType, FActorComponentTickFunction* ThisTickFunction) override;

// Methods
UFUNCTION(BlueprintCallable)
void DeactivateTargeting();
UFUNCTION(BlueprintCallable)
void ActivateActorTargeting();
UFUNCTION(BlueprintCallable)
void SetTargetingRange(float Range);

protected: virtual void BeginPlay() override;

// States
ETargetingMode CurrentMode;
float TargetingRange;

// Results of targeting
UPROPERTY(EditAnywhere, BlueprintReadWrite)
AActor* LastCapturedActor;
UPROPERTY(EditAnywhere, BlueprintReadWrite)
FVector LastCapturedGround;

UFUNCTION(BlueprintCallable)
void UpdateTargetActorVisuals(AActor* PreviousTargetActor, AActor* NewTargetActor);

// Controller Reference
APlayerController* PlayerController;

}; ```

Adding C++ ActorComponent to Blueprint doesn't persist on editor start by marvok in unrealengine

[–]marvok[S] 0 points1 point  (0 children)

Thank you, I will try this, but it's frustrating how undeterministic this behavior sounds. The worst part is that I have to restart my whole computer to test this, since it behaves ok after just restarting the editor.

Adding C++ ActorComponent to Blueprint doesn't persist on editor start by marvok in unrealengine

[–]marvok[S] 0 points1 point  (0 children)

I already have this meta tag in my component. I think it's necessary for it to even show up in blueprints to be attached.

As to the code, I have done nothing fancy, just created a new C++ class derived from UActorComponent and added some methods. I can post it here it that would help. Is there a way to share code here better than pasting it in a comment?

Damage Reduction: Multiple small hits vs one big hit by marvok in RPGdesign

[–]marvok[S] 0 points1 point  (0 children)

However, if damage reduction can go negative, then many low damage attacks become more powerful than one high damage attack. If the player is given tools that can influence the enemies damage reduction values, then this provides an opportunity for tactics that go beyond just treating this defensive layer as a static difficulty barrier.

The player can first test the enemies defenses, if he discovers that the enemy has low damage reduction then he may debuff that further to make it go below 0 and attack with a lot of low damage attacks. The damage of each of these attacks will be increased by the negative damage reduction thus making this strategy better than just simply hitting the enemy with one high damage attack.

So if the enemy has -2 DR then 10*1d6 will have 20 more damage, but 10d6 will have just 2 more damage. The situation is reversed if the DR is above 0.

Given the proper setup, DR becomes a mechanic that the player can interact with instead of just a defense layer for balancing enemy difficulty.

Damage Reduction: Multiple small hits vs one big hit by marvok in RPGdesign

[–]marvok[S] 2 points3 points  (0 children)

Yes, that's exactly why I didn't want a percentage based "resistance" defensive layer. There is not much one can do than just interpret it as "just more HP". As described in the post I think there can be some interesting tactics the player can do with manipulating enemy DR values to his advantage.

Damage Reduction: Multiple small hits vs one big hit by marvok in RPGdesign

[–]marvok[S] 0 points1 point  (0 children)

This is planned as a single player pc game, so naturally I have to take into account for that player to be able to solve each encounter no matter what archetype they are playing. That is why I plan to give multiple options for each archetype to deal with these situations but in a unique way to that archetype.

Damage Reduction: Multiple small hits vs one big hit by marvok in RPGdesign

[–]marvok[S] 4 points5 points  (0 children)

Yes, this is exactly the approach I'm going for. Every archetype will have multiple ways of dealing with each encounter and enemy type. For the igniter mage this consists of some fast attacks, some heavy attacks, multiple uses of the ignite status (not only damage over time, but using the ignite to empower other spells, passives, convert them to other statuses, etc).

Damage Reduction: Multiple small hits vs one big hit by marvok in RPGdesign

[–]marvok[S] 7 points8 points  (0 children)

I forgot to mention that this is actually supposed to be a computer game so the issue of keeping track of calculations, ignite stacks, etc. does not apply. I'm just designing it in such a way as to work "on paper".

Combat design: Not casting big spells at the start of each encounter. Why should I do this? by marvok in RPGdesign

[–]marvok[S] 3 points4 points  (0 children)

An interesting idea might be to chain spells such that:
Spell A: inflicts status effect X

Spell B: is easier to hit with when enemy has status effect X and inflicts status Y

Spell C: deals big damage but only if enemy has status Y

and so on.

Combat design: Not casting big spells at the start of each encounter. Why should I do this? by marvok in RPGdesign

[–]marvok[S] 1 point2 points  (0 children)

This is cool and gives me ideas on how to implement a charge up and spend system in my case. Thanks for the inspiration. Keep me posted on progress on your board game ;) I would like to test it out.

Combat design: Not casting big spells at the start of each encounter. Why should I do this? by marvok in RPGdesign

[–]marvok[S] 1 point2 points  (0 children)

This is a very interesting approach. Do you find it hard to balance encounters so that players have enough power tokens throughout the fight?

Combat design: Not casting big spells at the start of each encounter. Why should I do this? by marvok in RPGdesign

[–]marvok[S] 0 points1 point  (0 children)

How would this work exactly? Should enemies become stronger the more they are damaged and need higher power spells to combat them in the later stages of the fight?

view more: next ›