Our community module

[yufra]

I hadn't considered having humans already on the planet, but that could definitely work. In regards to name, we could also go the acronym route like ToME, call it Adapt or Die (AOD) or whatever the acryonym junkies can come up with. I personally prefer a catchy single name, but it is a weak preference.

I have chatted with both Reenen and tiger_eye about my proposed part/talent/resource system, and it sounded like bricks wasn't quite sure what to think about it and wanted to mull it over a bit more. Am I correct in thinking that?

I think that bricks and I need to chat a bit more about handling "molecular effects", and once that decision is finalized I think that we should really push to start whipping together some biological parts, genes, and some basic items. I would like to emulate DG's "release early, release often" strategy so the sooner we can get a single zone with just a few enemies wandering about in it the better. I've added that to the Medium priority todo list and did a bit of voting on it, too. It looks like we pretty much have consensus on the gameplay type being flexible depending on player decisions, so making a passive-heavy bump attack or a multiple activate talents are both viable.

[bricks]

Yeah, I think I'm just a little confused. I get how Sync is damaged by swapping parts and certain types of damage, but I don't understand how it recovers (just passive regen?) or why the max is damaged on swapping parts (how is the max recovered/increased?). Is it functioning like experience? AKA, swapping parts is equivalent to de-leveling your character? If so, that's pretty interesting, though awfully penalizing if you just want to try something out.

As far as molecular (or whatever) effects go - my foremost desire is that whatever we go with act identically the same as atomic effects. Both my (half-finished) system and your system would work, I think. I probably would prefer your method simply because it's a little less sprawling and doesn't require a lot of weird code.

[yufra]

Yeah, I think I'm just a little confused. I get how Sync is damaged by swapping parts and certain types of damage, but I don't understand how it recovers (just passive regen?) or why the max is damaged on swapping parts (how is the max recovered/increased?). Is it functioning like experience? AKA, swapping parts is equivalent to de-leveling your character? If so, that's pretty interesting, though awfully penalizing if you just want to try something out.

Sync could increase towards its maximum value passively, and the maximum increase through use of the bio/cyber parts. That does function a bit like experience, which is what I thought several people wanted after the IRC meeting, a feeling of advancement. You are right, it would be awfully penalizing to try out a different body part, but I think it fits thematically. We also shouldn't assume that body part replacement (and the accompanying "deleveling") is voluntary. We may lose a limb in the course of a game ("Luke, I am your father and I will now cut off your hand"), so the deleveling is occurs prior to the decision of what part to add back (cyber, or exotic biological, etc).

As far as molecular (or whatever) effects go - my foremost desire is that whatever we go with act identically the same as atomic effects. Both my (half-finished) system and your system would work, I think. I probably would prefer your method simply because it's a little less sprawling and doesn't require a lot of weird code.

Alright, I'll whip something together so that people can start putting together talents and effects. I will still be tweaking the interface, but the actual definitions should be unaffected by those changes.

[Canderel]

Yes! During fight parts/limbs get hurt. Adapt or die. The living planet atmosphere makes either splicing your genetic code with local fauna, even flora, a quick process, albeit painful. You realise this early game as you've lost a limb early game and either the lical community doctor, or someone in the community who still believes in humanity teaches you this info about the world.

[bricks]

Losing a limb as part of an early-game story event sounds cool, and a good way of introducing the arm upgrades. Just so long as it's only a story event - I don't want to have my arm blown off every other fight.

There seems to be consensus on how items/equipment will generally work. Let's see if I can collect and consolidate these ideas (and work them into the story).

The player starts out as a regular human. Both genes and modules (I'm calling these "augments") can be equipped, as can "usable" items (I'm going to call these "tools"). Tools will serve most active functions in the early game, whereas augments provide mostly passive bonuses.

At some point (1/3 through the game?) the player loses an arm for plot-related reasons. At this point the goal will be to find someone who can replace the arm. One option is to get help from a military doctor, who can provide you with a cybernetic arm; alternatively, you can receive a grafted arm from a colonist surgeon-priest. (Together, I'm calling these parts.) Parts have their own talents, and many of them can't use tools (no "hands" in a normal sense). Cybernetic arms can only accept modules, and grafted arms can only accept genes (rational for the latter being that modules are designed for human nervous systems and anatomy). However, the effects are much more powerful for augments used with their appropriate parts - a gene that confers fire resistance for a human may add fire damage to attacks with a grafted claw arm.

Replacing parts is extremely "expensive" and won't occur often, but after a point, it can be done at the player's discretion. How new parts/augments/tools become available is still up in the air. Having them simply drop off normal enemies seems inappropriate, but I can see how killing a certain type of enemy over and over could provide "research" that would go towards developing a new item.

[Canderel]

Research! I'm liking this game more and more already.

Though some of the thinking was really to lose the limb pretty early. But I can see a normal soldier for 1/3 way vibe working out well. (Reminds me of Quake4 actually... You get caught and get better legs.)

With quests for the "researcher" for instance. "I need a certain flower from the mountain south of here."

[bricks]

Really, I could go for either. Make it part of the very beginning of the game - you crash-land and lose an arm. I was thinking of introducing it later so the first 1/3 of the game would be spent learning mechanics; however, roguelikes typically throw everything at you at once, so perhaps immediately is better.

[yufra]

That is a nice summary of what I had been envisioning, bricks, but I must warn you I am having second thoughts about it. I was chatting with tiger_eye at length last night and he pointed out that this mechanic basically controls the rate at which you can swap parts by enforcing a temporary disadvantage (the lowered maximum resource). That is actually how I had intended it, but tiger_eye wasn't sure that it would be that fun.

Something that he did point out, though, is that if this is indeed a long-term resource then we don't really need to worry about it in the short-term. Reenen has already cleaned up the todo list and created a separate design page. She rightly put "Get a runnable module that doesn't generate lua errors for anything" as the top item, and "Design some talents, items, parts, monsters, perhaps gene stuff so we can start playing" as the second and I couldn't agree more. Remember, inscriptions didn't replace potions/scroll until pretty far in the ToME beta process.

As a first step why don't we get a basic, completely organic humanoid up and running. This can be the initial state of the player, as well as the other survivors and local residents. For that we need some...

Parts

1. Legs
2. Arms
3. Torso
4. Head
5. Eyes
6. Hands

Just make these placeholders for now.

Items

1. Melee weapon (knife?)
2. Ranged weapon (laser pistol?)

Talents

1. Unarmed attack (punch)
2. Armed melee attack (swing)
3. Armed ranged attack (shoot)

We already have the acid attacks, which plays into...

Genes

1. Acid glands (gives acid attacks to the organic head)

Monsters
We already have some placeholder "mercenary" NPCs, so lets just run with that for now.
I need to update their AI so that they know to look for talents on their parts.

EDIT: I'll start work on some of this tonight, but if anyone else wants to do something just say the word.

[bricks]

I'll probably fiddle with a little of this today, shouldn't take long. A musing; parts should be able to grant equipment slots. Basic arms would grant "tool" (weapons, etc) slots. Bionic arms grant additional module slots. Super-torsos could allow additional arm or leg slots (and some torsos may not have legs at all, like a slug body).

The mercenary NPCs are fine, but data files are so easy to create and modify that I don't see a problem with creating lots of enemies right now.

As far as the Sync mechanic goes, I'm inclined to agree with tiger_eye. I think it would be better to limit part-swapping to specific areas (settlements and the home base). For now, perhaps, we should stick to a single resource (Bioenergy) and discuss resources to balance skill use later.

One thing we should add quickly is a working world map. ToME seems to have a lot of limitations in this department, so I imagine we should look into that before things get too complicated.

Other hand-held items I'll think about adding: hand-held teleportation device, shield projector, med kit, turret deployer. Maybe a rifle (to test weapons that require both hands).

[yufra]

I'm also tinkering with this today, maybe we should both be on IRC to chat?

[bricks]

Didn't really accomplish anything yesterday, apart from fiddling with fun teleport effects, but Yufra's work on equipment and parts looks really good. I think I'm going to have to add in some sort of mutant centipede NPC just to show how awesome it is.

Lukep, I think your cover system sounds really fun, and with tactical options (even if that's just "running") it should make for a helluva game. Corners are definitely the tough part; I can think of some geometric calculations that might make it workable, but even so I don't really know what to expect.

Edit: Damage reduction formula I'm thinking about:

Code: Select all

Actual = Damage / ( 1 + Reduction / Damage )

R/D   % Reduction
0     0
0.5   33
1     50
2     67
10    91

Where R/D = Reduction / Damage.

Should scale well (it's all ratio-dependent) and it has natural diminishing returns. Intuitive, too - damage reduction equal to damage always means 50% actual damage.

[tiger_eye]

Regarding cover, I'm strongly of the opinion that it should be binary: either you are under cover from an enemy, or you are not. Adding intrinsic variability to cover adds unnecessary complications at this point imo. Binary would easier to represent and allow the game to be played more quickly/fluidly without the need to check particular numbers. Variability with cover can come from different actors having different bonuses while under cover. I'm nearly finished with savvy fov, so hopefully we can all play around with it soon.

A few features of savvy fov regarding cover:
(1) corners can serve as cover, and cover is not symmetric (so hiding beside a pillar is tactically useful).
(2) a grid can be covered but not blocked, so everything behind it is under cover.
(3) being on covered terrain can provide cover.
(4) it is possible for cover to be ignored if it's adjacent to you.
(5) it is possible for an entity to provide cover behind itself, but not the tile is it on. For example, this could be used to have hostile actors provide cover for actors behind them (but you can still target the enemy in the front normally).

Even open areas could become more interesting. For example, there could be a wheat field or whatever that provided cover for everything except what is adjacent to you, which would encourage fighting at melee range.

[bricks]

I really don't like how my suggested sync/fidelity system works (it's hard to balance and even harder to play), and I don't want our module to play like a one-resource game. Since we seem to be going for a more ToME-like skill set, cooldowns on skills is probably appropriate. As an extension of ToME's cooldown system, I think using a part-linked talent should activate the cooldowns for all talents on that part (either as long as the used talent's cooldown or the other talent's cooldown, whichever is shorter). I think this offers practical and sensible risks in using long-cooldown talents. It also gives the impression that each part is using some separate resource (sync with the user's neurons, genetic stability, etc.) without directly representing it. I would still like for the two categories of parts to interact positively - that is, using lots of genetic parts is in some way encouraged - but I have other thoughts on how that could be accomplished. Sustained talents are more complicated, but can probably be handled on a per-case basis.

An example:
Player has a bionic machine-gun arm equipped. In the arm is installed a grenade launcher module and a shield generator module. The talents:

Shoot (activated, 0 cooldown)
Launch Grenade (activated, 5 cooldown)
Generate Kinetic Shield (sustained, 10 cooldown)

The player uses Launch Grenade. Now:

Shoot (0/0 cooldown)
Launch Grenade (5/5 cooldown)
Generate Kinetic Shield (5/10 cooldown)

Five turns pass, and the player uses Shoot. Since Shoot has no cooldown, the scheme is now:

Shoot (0/0 cooldown)
Launch Grenade (0/5 cooldown)
Generate Kinetic Shield (0/10 cooldown)

The player then chooses to activate the kinetic shield.

Shoot (0/0 cooldown)
Launch Grenade (unavailable)
Generate Kinetic Shield (sustained)

Since Shoot has no cooldown it is not affected by the active Generate Kinetic Shield sustain. Launch Grenade, however, is. The logic here is that Shoot is a basic action and can be used while other modules are active, while the grenade launcher module's activity is restricted by the active kinetic shield. Some turns pass, and the player deactivates the shield. Here's the following turn:

Shoot (0/0 cooldown)
Launch Grenade (5/5 cooldown)
Generate Kinetic Shield (10/10 cooldown)

There are some special cases that may pop up down the road that I think could be handled by a property (basic_action = true or similar) in the talent definition. Instead of a machine gun arm, consider a rail gun arm. Because this is a powerful weapon, we may want the basic "shoot" action to have a short cooldown, like 3 turns. With the same two modules, however, it would be very hard to ever fully utilize the weapon's alternative attacks. So we designate the Shoot talent as basic_action= true. Now, it's cooldown isn't ever tied to the cooldowns of other talents for that part. The player can both sustain a kinetic shield and fire the railgun.

This system also provides a small motivation for the player to retain a basic arm (those that can utilize items/provide a "hand" slot) since the item's cooldown wouldn't influence any talents intrinsic to the arm part. Thoughts? Is my explanation/example clear?

[Rectifier]

An interesting suggestion bricks. Very interesting...

[yufra]

That is indeed an interesting idea, and I think very worth testing. I still haven't quite managed to get the rewrite of the inventory working so a specific slot knows its parent, etc, but I can modify PartTalents.lua to do what you are suggesting fairly easily.