4th Age

[J1M]

Could Radiant be made white and Necrotic black? If so, you could then move Radiant's yellow over to Lightning, move Lightning's current blue over to Force, and move Necrotic's purple over to Thunder.

Acid's color is appropriate, but it looks deceptively close to Poison's color, at least to me on my monitor. Maybe that's something that can be tweaked with brightness.

I don't want to use white or black for a specific damage type because you usually put text on a dark/light background for legibility and you need a color for other text. (Or both in the case of text that has an outline around it.)

Agree the colors need to be tweaked a bit, especially the blues. This was more about assigning them relative to each other. Will think about shifting lightning to yellow. I probably have the blue association from games like Warcraft 3.

There's also probably room for another shade of orange and yellow. A little odd that this one has no intermediary choices between red, orange, and yellow. Have seen some people use orange for acid, but personally I associate it more closely with green.

[WhiteShark]

I don't want to use white or black for a specific damage type because you usually put text on a dark/light background for legibility and you need a color for other text. (Or both in the case of text that has an outline around it.)

I was picturing Radiant as black text on a white background and Necrotic as white text on a black background, though that could be reversed depending on how much background there is relative to the text size.

[J1M]

Revision 2. For now I will be avoiding use of white/black for damage types, but it's easy enough to change in the future. I associate radiant damage with sunlight, which is why I like having it tinted yellow.

[J1M]

Everything's placeholder at this point, but here's an idea of what it currently looks like. Unfortunately, the font is being scaled down and aliasing strangely. It is probably related to the character tokens being 1024x1024 textures that are scaled down by scaling the object instead of using texture scaling properties (allowed lots of zoom without blurriness). This was easier than dealing with the edge case related to the scaling of the overlay clipping the edges of the character's square artwork. Pleasant fonts are very important to me so I'll fix that at some point later.

Also changed how the camera zoom worked so the field is zoomed with the center of the screen as the origin instead of the top-left of the map.

This screenshot shows a skeleton taking ongoing 5 fire damage, one archer regenerating 2 HP per turn, and another archer taking two types of ongoing damage while also prone.



Here's a rough idea of how I was thinking of visually informing the less important temporary buffs/debuffs. A counter for each. For example, you have a +5 to your next attack and a +1 to all saving throws until the end of the encounter. It shows the green icon with a '2' on it on the character token (probably in the top corners instead of mixed with the condition indicators).

[J1M]

There's an interesting aspect to modifiers in 4e (Rules Compendium, page 27) where bonuses and penalties have separate types. This was probably required due to the stacking rules they wanted.

So in theory all of the debuffs I want to highlight are of the Penalty type or Ongoing type, and all of the buffs are either Power or Untyped bonuses. Unfortunately, the Untyped category is very broad and I will probably have to split it into two types, one for buffs that should be highlighted and one for buffs that shouldn't (like a Monster passive, but I might be able to get away with treating those as Feat bonuses). It wouldn't affect the stacking math, but it would be a potential source of bugs during data entry.

I need to do a pass through all of the effects defined so far to ensure they have the proper bonus type. For example, becoming Prone shows up as a buff in this screenshot when it would be considered a debuff except in very specific circumstances. The dog has 4 buffs because it used Total Defense.

[J1M]

Split Untyped bonuses into UntypedBuff and UntypedHidden. The stacking math is unchanged, but this controls if the UI considers an effect a buff or not.

Got a little carried away and made the buff indicator for Phalanx Soldier dynamic. The (+1▲) buff indicator only appears when the +2 AC is active due to being next to another hobgoblin. Will probably regret this when I get to the more sophisticated player class abilities.

Also found a bug caused by units walking through each other when they are allies, which will probably require me to support multiple units per grid square in order to fix it.

[rusty_shackleford]

@J1M any progress?

[J1M]

@J1M any progress?

► Show Spoiler

My WHM is lvl 54 in FFXI.

I would like to get back to this. According to my todo list, I need to add some on-screen feedback for damage numbers.

[J1M]

4e is back on the menu.

Added floating damage text (color indicates damage type).

[J1M]

Added a status icon for bloodied.

Hidden Content

This board requires you to be registered and logged-in to view hidden content.

[WhiteShark]

Hidden Content

This board requires you to be registered and logged-in to view hidden content.

[Acrux]

Hidden Content

This board requires you to be registered and logged-in to view hidden content.

[Stack of Turtles]

Added a status icon for bloodied.

Hidden Content

This board requires you to be registered and logged-in to view hidden content.

Hidden Content

This board requires you to be registered and logged-in to view hidden content.

[Kalarion]

Hidden Content

This board requires you to be registered and logged-in to view hidden content.

[J1M]

I still have a couple of significant changes I want to make before I call the first roadmap item done. First, fixing how things are handled when two units end up on the same tile. Second, preventing powers that rely on line of sight from being executed when line of sight is blocked.

But I took a diversion from that today to cross off some other details and created this tutorial screen.

Hidden Content

This board requires you to be registered and logged-in to view hidden content.

[Acrux]

Hidden Content

This board requires you to be registered and logged-in to view hidden content.

[J1M]

Looking for a second opinion. This is a snippet of the Rules Compendium regarding line of effect. I don't understand how the token that is indicated to be line of effect blocked can be considered blocked given that a (red) line can be drawn between the corners of the tiles.

To me, this just looks like a mistake in the book and the token should have been one tile down for the illustration. Am I missing something about the diagonal rules?

[Tangerine]

Looking for a second opinion. This is a snippet of the Rules Compendium regarding line of effect. I don't understand how the token that is indicated to be line of effect blocked can be considered blocked given that a (red) line can be drawn between the corners of the tiles.

To me, this just looks like a mistake in the book and the token should have been one tile down for the illustration. Am I missing something about the diagonal rules?

I would suspect the red line is considered to be touching blocking terrain, hence invalid.

[J1M]

Line of effect for targeting! Nice how this worked out. Was worried it would be a pain after losing the context for the line of sight work done months ago.

Hidden Content

This board requires you to be registered and logged-in to view hidden content.

[J1M]

Looking forward to working on the character creator again tomorrow. I still have a goal of creating one that allows you to edit choices in any order, but it's definitely a real challenge with regards to preventing exploits that involve temporarily meeting prerequisites for something like a feat. Wondering if anyone else is bothered by character creators that make you pick things in a strict order, or if that feature would just be for myself?

[J1M]

Decided to replace my tooltips implementation, which involved a lot of UI controls, with a RichTextLabel + bbcode approach. Rendering entirely in text makes it possible to add entries to the in-game codex for powers and talents. It can also just be rendered into a box as a tooltip.

The drawback is that I'm limited to the bbcode features in terms of presentation so I switched to using tab stops instead of horizontal alignment. Might regret not having easier control over background color later. On the up side, no longer using centered text is more flexible in terms of resizing UI elements.

Now that I have some of the character choices populated with codex entries, it really makes the ones that don't have it look out of place. So ensuring those are in place will be part of demo v2, which will allow the creation of level 3 characters from a choice of 3 races and 3 classes.

Hidden Content

This board requires you to be registered and logged-in to view hidden content.

[WhiteShark]

Looking for a second opinion. This is a snippet of the Rules Compendium regarding line of effect. I don't understand how the token that is indicated to be line of effect blocked can be considered blocked given that a (red) line can be drawn between the corners of the tiles.

To me, this just looks like a mistake in the book and the token should have been one tile down for the illustration. Am I missing something about the diagonal rules?

"or touches" is the bit you're missing. The line touching the corner of the blocking terrain is enough to prevent Line of Effect.

[WhiteShark]

Hidden Content

This board requires you to be registered and logged-in to view hidden content.

Hidden Content

This board requires you to be registered and logged-in to view hidden content.

[J1M]

Looking for a second opinion. This is a snippet of the Rules Compendium regarding line of effect. I don't understand how the token that is indicated to be line of effect blocked can be considered blocked given that a (red) line can be drawn between the corners of the tiles.

To me, this just looks like a mistake in the book and the token should have been one tile down for the illustration. Am I missing something about the diagonal rules?

"or touches" is the bit you're missing. The line touching the corner of the blocking terrain is enough to prevent Line of Effect.

I think where I feel there is an inconsistency is this rule in the cover section.

Rules Compendium, page 219
Determining Cover: ...(A line isn’t blocked if it runs along the edge of an obstacle’s or an enemy’s square.)...

Corners block, but edges don't? You don't have line of effect along an edge, but it also counts as a clear shot for determining cover? Or is there a distinction between blocking terrain that fills the full grid cell versus blocking terrain that has rounded corners? The last one in particular rubs me the wrong way, since it is never called out as a separate "rounded blocking terrain" game element.

A picture to illustrate. Is the highlighted grid square correctly in line of effect or should that shot be blocked?

[Acrux]

Hidden Content

This board requires you to be registered and logged-in to view hidden content.

[J1M]

Updated tooltips for units and powers.

[WhiteShark]

I think where I feel there is an inconsistency is this rule in the cover section.

My reading is that the rules for whether a line is blocked or not are different depending on whethering you're determining Line of Effect or Cover.

Rules Compendium, page 219
Determining Cover: ...(A line isn’t blocked if it runs along the edge of an obstacle’s or an enemy’s square.)...

You don't have line of effect along an edge, but it also counts as a clear shot for determining cover?

Correct. Though it does not say so explicitly, the implication of edges' not counting for cover is that corners also do not count for cover. This is different from the "no touch" rule when determining Line of Effect.

A picture to illustrate. Is the highlighted grid square correctly in line of effect or should that shot be blocked?

Assuming you're drawing from the green guy (since you would otherwise simply pick a different corner from which to draw), he has no Line of Effect to the highlighted square because all lines pass through or touch blocking terrain.

Lack of LoE renders the question of cover moot in this case, but, supposing that he did have LoE anyway for some reason, his target would only have partial cover because a line can be drawn from that corner to two of the target square's corners without passing through (only passing alongside) blocking terrain.

Or is there a distinction between blocking terrain that fills the full grid cell versus blocking terrain that has rounded corners? The last one in particular rubs me the wrong way, since it is never called out as a separate "rounded blocking terrain" game element.

I'm not aware of any such distinction in RAW.

[J1M]

Thanks for your take. I was not expecting line of effect to be stricter than cover for these purposes. Somewhat annoying that they are different, in terms of a digital implementation.

Extrapolating, I guess that edge rule for cover calculations is about making it harder to achieve superior cover. Not about preventing the shot entirely.

[J1M]

Looking forward to watching this when I have time later tonight.

The first change I would make would be to change the role of the Rogue from Striker to Martial Controller. I feel like this was the original intent before focus testing.

[Kalarion]

I fired up the demo last night but had to put it aside almost immediately. I'll try to devote an hour or two to it tonight.