next »

[Belimoth]

ＮＯ  ＫＩＮＧＳ
ＳＴＲＡＴＥＧＹ  ◇  ＭＵＬＴＩＰＬＡＹＥＲ  ◇  ＳＴＵＦＦ


Latest build.

Latest screenshot.


Mockups by 08.

Been working on a roguelike tactics game for the last few months.

It's going to be great but I have no evidence.

Here's a screenshot of the prototype so far:



See? No evidence.

[Belimoth]

I've got an idea for a pretty cool fog-of-war line-of-sight system, but coding it has been a nuisance.

First draft of the algorithm:

MISSION FAILED

[Belimoth]

MISSION ACCOMPLISHED

If anyone's curious, you can play with it here.

It's a little janky around 1 block-thick diagonal walls and 1 block-wide doorways, but I don't intend to have those features in the level geometry.

[AzureKing]

I am working on this as well.

[SundownKid]

It looks very Monaco-esque. It has the potential to make the game more stealth-oriented than the typical tactics game.

[Games Inquirer]

Creative.

[Belimoth]

It looks very Monaco-esque. It has the potential to make the game more stealth-oriented than the typical tactics game.

I wouldn't say stealth since it's symmetrical, but I do want to cultivate a sense of uncertainty.



I am currently in the process of coding the battle mechanics. In the meantime I will outline them here.
Hopefully talking it out will help me clarify for myself how I should go about the implementation.

First some basic principles:

• Units are generic and die easily. There are no RPG elements at the unit level.
• There is no initial setup. Units are spawned in groups at friendly control points.
• This occurs throughout the battle. This is one example of where I've leaned more towards strategy games.
• It is nearly impossible to win a battle without losses.
• Stats are highly simplified, on the order of single-digits.
• Interactions between units are completely deterministic.
• The occlusion shown above is a central mechanic and can't be turned off.

Some other design choices:

• You don't ever choose a direction for a unit to face, at least not in the traditional way. More on this later.
• Move distance is not a major differentiating factor between unit types.
• Units can't move through other units, even friendly ones.

Contrary to the good advice of everyone who has ever made a tactics game, I am designing this as multiplayer-first. There will be a singleplayer campaign but I am more concerned with balancing the game for human-to-human interaction.

More flavorful information coming soon.

1000th post

[Belimoth]

An example unit type:

Knight ♘♘♘♘
HP/SP: ▽○
MP/AP: □□□□△
CP: ☆
Move: □
Attack: △
☆Block: ○
☆Riposte: ○△

Each unit type has five stats:

• Health Points ▽
• Shield Points ○
• Movement Points □
• Attack Points △
• Counter Points ☆

In addition, every unit has four skills which can be either active or passive.
Active skills cost points to use and come in a variety of flavors. More on that later.
Passive skills modify how the unit interacts with the world/other units.

If a unit's health points are reduced to zero, it's dead.

A unit's points regenerate at the start of their owner's turn, with the exception of health points.

A skill that includes △ or ∅ in its cost end that unit's turn.

Each unit also has a rank, which is shown here by the ♘♘♘♘.
This means that the unit is of  SOLDIER rank and spawns in a group of four.



Everything subject to change as playtesting demands, etc.

[mushbuh]

name it Flame Badge

[Belimoth]

Okay.

[poe]

name it Water Badge

[mushbuh]

name it Water Badge

shut up


also this looks cool

[cragwind]

Hope you can keep it lean and minimalist! How big a factor are spawn group sizes in gameplay? The first thing I think of with the stats/groups is Master of Magic, although in your case each unit is an individual.

[Belimoth]

Hope you can keep it lean and minimalist! How big a factor are spawn group sizes in gameplay? The first thing I think of with the stats/groups is Master of Magic, although in your case each unit is an individual.

Me too! I've spent more time removing things from the design than I have adding things.
We'll see how it works out.

The main reason I have units spawn in groups is so that I have a variable that I can change to balance units against one another. Basically it will be a choice between having a large group of weaker units or a small group of stronger ones.

EDIT, WEEKS LATER: Also there will be some actions that units can work together to do.

[Belimoth]

Using Oryx's Ultimate Roguelike Tileset for placeholder sprites.

[Conker534]

i dig it

[Belimoth]

Getting pretty close to a playable build, still a few rules left to implement.

For now, some more info on the rules:

Types of Actions

• Regular actions: active actions that do stuff other than damage.
  
• Attack actions: active actions that target enemies and do damage.
• ☆Counter actions: responses to attacks that mitigate damage.
• ☇Trigger actions: actions that activate when an enemy steps on a designated tile.
• ☠Death actions: actions that activate when the unit dies.

Attacks and Counters

Most units will only have one counter, and they activate automatically in response to incoming damage.
If a unit has two counters, the most expensive one will activate first.

Most attacks have some movement to them, for example the most basic one (appropriately named Attack) will push back its target if there isn't anything behind it. Like this:


...


If there is something behind the target, the attack will still go through sans displacement, but there can be implications for whatever counter the target uses. For example, in this situation:



The counter Block will still succeed in mitigating damage, but the counter Dodge will fail.

In-game, Dodge is shown by the target backstepping a moment before the attack would connect, but technically the attack is still responsible for the backwards movement.

[Belimoth]

Playing Chilvary has given me the idea to do a Defend the Royal Family mode. Could be cool?

EDIT: aaand we've come all the way back around to chess.

[Belimoth]

Adding terrain modifiers like corpses and flames.

[Belimoth]

I've gotten accessories working sooner than expected so I'll explain how they work.

Accessories
Some units spawn in with accessories that give them additional points. For example, the Slave:

Slave ♘♘♘♘
HP/SP: ▽
MP/AP: □□□□△
CP:
Move: □
Attack: △

Accessory: Torch

+Torch
HP/SP: +○
MP/AP:
CP:
+Torch: △
+Throw Torch: ○△

The Slave unit comes equipped with a Torch accessory that grants him two additional moves, in addition to a bonus ○.

Accessories will grant either ▽ or ○, that destroy the accessory when spent.
Other points can be granted, but these don't result in the destruction of the accessory when they are spent.

So, for example, the Slave can use the Torch action as much as he likes, but when he uses Throw Torch, the ○ is spent and both of those actions become inaccessible.


I'll be using accessories to represent special tools/weaponry, and also things like the mounts that cavalry use/some other stuff.

I've gone through a few different systems for this purpose, and this was the simplest I could think of.
Maybe it is too complex to be worthwhile?