I've set up some support for "molecular effects" in my fork. Without going into too much detail - molecular effects allow for complex combinations of atomic effects, much like how talents function, but under the near-guise of a regular atomic effect. (The main difference is that molecular effects generally return a list of effects, instead of a single calculated effect.) I don't know how useful this will be, or if my method is really the best approach, but it could at least cut down on some redundancy.
I also added an idea on how to drive gameplay and support a procedural plot - essentially, roguelike Risk. See the full description on the IRC meeting page.
Edit: The original post could stand some refreshing - major links, a project summary, and so on. Yufra - would anyone using that copy of the engine need to change the version number in init.lua? Probably should be noted. There seems to be a core of about 6 who are interested in the project, perhaps we write little bios about ourselves on the wiki (background, technical experience, level of involvement, focus) to get a better idea of what roles need to be filled. I'm not sure where the code should go next; there's a lot that can be done with what is already implemented, so if someone has a system (equipment, combat, whatever) they would like to test-play, Yufra or I could probably work up a demo.
Our community module
Moderator: Moderator
Re: Our community module
Sorry about all the parentheses (sometimes I like to clarify things).
Re: Our community module
Hey bricks. I haven't had a chance to look at your code or suggestion yet, but I have allotted some time tonight to clean up the meeting notes summary. I think we need to remind ourselves of what the outstanding issues are so we can get back to brainstorming/discussing them on the wiki.
EDIT: Oh and yes the init.lua file will need to be updated. If you can confirm that dropping those engine files in a clean b37 makes the module work, I will do that in the master fork. Cheers!
EDIT: Oh and yes the init.lua file will need to be updated. If you can confirm that dropping those engine files in a clean b37 makes the module work, I will do that in the master fork. Cheers!
<DarkGod> lets say it's intended
Re: Our community module
Alright, I have updated the meeting summary. I also updated the Todo wiki page to reflect what needs to be done. The most pressing issue in my mind is to figure out the role of long-term resources and confirm consensus on the "talents on parts, unlocked by part level" design. If you can please post on the wiki todo page under those headings we can start moving again. Cheers!
<DarkGod> lets say it's intended
Re: Our community module
One really important design philosophy point I forgot to put on the meeting agenda - what is the gameplay like? Are we going more for ToME's talent-heavy system, or something more traditional - a bread-and-butter damage method (bump attack or similar), plus a bunch of skills based more around utility?
Sorry about all the parentheses (sometimes I like to clarify things).
Re: Our community module
How about this: allow the player to set macros for attacks; this would work like a queue, cycling parts/talents from the list as energy/turn/stamina allows.
Example:
A player has the following part configuration: right arm (1x Semi-Auto Plasma Rifle Module), left arm (1x Plasma Blade Module), rear body: (2x Neutron Mortar Module).
Player configures bump-attack macro to { 1st (left arm : standard attack), 2nd (right arm : standard attack) }
Player then makes a distance attack macro: { 1st (right arm : standard attack), 2nd (rear body : 1x standard attack) }
So now the player bump-attacks: first the blade is used, then if enough stamina/energy is left it will fire a shot from the rifle.
The turn rolls over, and we'll say for this example that the blade was temporarily disabled by the enemy. The player attacks...
Blade is unusable, so it passes over and fires the rifle.
Example:
A player has the following part configuration: right arm (1x Semi-Auto Plasma Rifle Module), left arm (1x Plasma Blade Module), rear body: (2x Neutron Mortar Module).
Player configures bump-attack macro to { 1st (left arm : standard attack), 2nd (right arm : standard attack) }
Player then makes a distance attack macro: { 1st (right arm : standard attack), 2nd (rear body : 1x standard attack) }
So now the player bump-attacks: first the blade is used, then if enough stamina/energy is left it will fire a shot from the rifle.
The turn rolls over, and we'll say for this example that the blade was temporarily disabled by the enemy. The player attacks...
Blade is unusable, so it passes over and fires the rifle.
Re: Our community module
This actually sounds like something that DGrey mentioned on the Roguelike Radio episode for ToME. It could definitely be useful.
<DarkGod> lets say it's intended
Re: Our community module
I'm back, sorry that I missed the IRC meeting, it looks like a lot of progress was made in forming the game's framework. After reading through the log, I have a couple of comments to add:
Pushing progress forward: I think that the idea of collecting some macguffins to escape being the plot/goal could work well. One way to push the player into faster progress would be to have each of the items (5 of them?) give a different significant bonus to your character to make them desirable, and have them being battled over, traded and captured by progressively more powerful forces to make them more difficult to get the longer you wait (not sure how to use time for this). Example illustrating this:
Bob LXXVI crash lands on the planet Grida, and must collect the stabilizing rocket, cargo arm, capacitor, heart valve, and wing plating (randomly chosen artifact items?) of his damaged spaceship before escaping again. He has approximate locations of each part, so decides to go after the capacitor first. Through many trials, he finds it guarded by a large pack of slimes who dragged it into their cave. He defeats them all, and recovers the capacitor. He then goes after the crane arm, but it is guarded by a pack of cyberwolves, who he is not equipped to deal with yet. He leaves, and easily recovers the stabilizing rocket from a sentient mould carpeted forest. Meanwhile, the cyberwolves have been attacked and killed by the neighbouring village of mutants, who now have the arm in their village. This could go on until the parts are in fortress like locations that cannot be defeated by other enemy forces. Note that fighting and killing all of the enemies is not necessary, stealth is a definite option. Also note that there is no reason that one part couldn't start out in a fairly strong location, but it would be a small chance.
Long Term Resources: I'm not sure that I understand how unity/sync works. For example, let's say that a new character gets 1000/1000 sync. After equipping a lvl 1 smashtech hammer arm, they would have 900/900, but would only have 800/800 for a lvl 10 version of the same part. Would using a tech talent then reduce your sync to 790/800 (as well as costing some high throughput resource)?
----------
And lastly, an idea for an integrated sight, stealth, critical hit, accuracy, aiming, and cover system that would give some tactical depth to the environment. It would basically be my proposed systems for vision and accuracy, with a few tweaks, as well as added integration with cover. Tweaks:
Tiles and monsters have a "size" rating between 0 (open air) and 100 (fully filled). This is used for both cover and chance to hit.
Vision would affect targeting, such that detection below 5 (cannot see basic type of enemy, even to tell the difference between a stump and a rat) would make all attempted attacks untargeted, negating the effects of precision. Detection between 5 and 19 (Can see type/subtype, but no more) would allow you to target the body, but not prioritize different parts of the body, such as head shots. Detection 20 and up (can see monster name, as well as more info) would be unchanged.
Accuracy would be changed from having a "miss zone" (of tiles away^2 * 5) to having a "target area" (of tiles away^2 * 5 + 25), which allows for 100% accuracy against large foes at close range, as well as being generally better IMO. It would also need to be changed from a integer calculation as I imagined it to floating point (or simply to 0.01).
Cover would affect vision by reducing detection by the cover amount (eg. under 70% cover at a range that would usually give 30 detection, the character would see the hidden monster with detection 9). It would affect shooting, shrinking the size of the target by the amount under cover (eg, for a humanoid enemy under 60% cover it would have a headshot range of 0-0.4, and a hit range of 0-15 instead of 0-1 and 0-25, respectively). In both of these cases it is a nearly identical effect as can be gained from being farther away from the enemy.
Now that the basics are defined, it's time to throw the tactical wrench into the works. This part of the idea still needs work, especially with the issues outlined at the bottom. For the purposes of cover, both the player and enemies ignore most things that are adjacent to them. This simulates the ability to peek through windows, shoot around pillars and corners etc... Examples:
1. The player is at a window (70 size), and a bandit is near a pillar (50 size). Because the window is adjacent to the player, it is not considered for the bandit's cover calculation. The player is under 70% cover, the bandit is under 0% cover.
2. The bandit ducks behind the pillar. As the pillar is adjacent to the bandit, is is not considered for its calculations when attacking or detecting the player. The player is still under 70% cover, the bandit is under 50% cover.
3. The player retreats. As the window is no longer adjacent to the player, it hinders his attempts to see and hit the bandit. The player is under 70% cover, the bandit is under 85% cover (70% + 50%, it stacks multiplicatively)
The player faces a row of 8 bandits (size 25). The first bandit is under 0% cover from the player, the second is under 25%, the third is under 44% cover (25% +25%), the fourth is under 58% cover (25% * 3), fifth is 68%, sixth is 76%, seventh is 82%, and eighth is 87%. The bandits all have a slight advantage over the player (except the front one), as they can ignore the cover that would have been gained by the bandit directly in front of them.
1. The player is facing a HippoTANKomus (size 70) and a tactical drone (size 15) in a corridor. The player is under 0% cover from the "T" and 0% cover from the "d". The "T" is under 0% cover from the player, the "d" is under 70% cover.
2. The player is closes on the HippoTANKomus. The player is still under 0% cover from the "T" and 0% cover from the "d". The "T" is under 0% cover from the player, the "d" is now under 0% cover as well. This allows the player to quickly kill the low HP high damage drone, while risking melee attacks.
---
While this looks quite good to me in straight lines, corners can pose problems that need to be addressed. The most glaring example is below (left to right are what it is, what it is calculated as for the player, and what it is calculated as for the monster, respectively):
As you can see, as the bandit moves to two squares from the corner, all effective cover disappears from the player, which is not as I intended it to be, and has significant gameplay ramifications.
Pushing progress forward: I think that the idea of collecting some macguffins to escape being the plot/goal could work well. One way to push the player into faster progress would be to have each of the items (5 of them?) give a different significant bonus to your character to make them desirable, and have them being battled over, traded and captured by progressively more powerful forces to make them more difficult to get the longer you wait (not sure how to use time for this). Example illustrating this:
Bob LXXVI crash lands on the planet Grida, and must collect the stabilizing rocket, cargo arm, capacitor, heart valve, and wing plating (randomly chosen artifact items?) of his damaged spaceship before escaping again. He has approximate locations of each part, so decides to go after the capacitor first. Through many trials, he finds it guarded by a large pack of slimes who dragged it into their cave. He defeats them all, and recovers the capacitor. He then goes after the crane arm, but it is guarded by a pack of cyberwolves, who he is not equipped to deal with yet. He leaves, and easily recovers the stabilizing rocket from a sentient mould carpeted forest. Meanwhile, the cyberwolves have been attacked and killed by the neighbouring village of mutants, who now have the arm in their village. This could go on until the parts are in fortress like locations that cannot be defeated by other enemy forces. Note that fighting and killing all of the enemies is not necessary, stealth is a definite option. Also note that there is no reason that one part couldn't start out in a fairly strong location, but it would be a small chance.
Long Term Resources: I'm not sure that I understand how unity/sync works. For example, let's say that a new character gets 1000/1000 sync. After equipping a lvl 1 smashtech hammer arm, they would have 900/900, but would only have 800/800 for a lvl 10 version of the same part. Would using a tech talent then reduce your sync to 790/800 (as well as costing some high throughput resource)?
----------
And lastly, an idea for an integrated sight, stealth, critical hit, accuracy, aiming, and cover system that would give some tactical depth to the environment. It would basically be my proposed systems for vision and accuracy, with a few tweaks, as well as added integration with cover. Tweaks:
Tiles and monsters have a "size" rating between 0 (open air) and 100 (fully filled). This is used for both cover and chance to hit.
Vision would affect targeting, such that detection below 5 (cannot see basic type of enemy, even to tell the difference between a stump and a rat) would make all attempted attacks untargeted, negating the effects of precision. Detection between 5 and 19 (Can see type/subtype, but no more) would allow you to target the body, but not prioritize different parts of the body, such as head shots. Detection 20 and up (can see monster name, as well as more info) would be unchanged.
Accuracy would be changed from having a "miss zone" (of tiles away^2 * 5) to having a "target area" (of tiles away^2 * 5 + 25), which allows for 100% accuracy against large foes at close range, as well as being generally better IMO. It would also need to be changed from a integer calculation as I imagined it to floating point (or simply to 0.01).
Cover would affect vision by reducing detection by the cover amount (eg. under 70% cover at a range that would usually give 30 detection, the character would see the hidden monster with detection 9). It would affect shooting, shrinking the size of the target by the amount under cover (eg, for a humanoid enemy under 60% cover it would have a headshot range of 0-0.4, and a hit range of 0-15 instead of 0-1 and 0-25, respectively). In both of these cases it is a nearly identical effect as can be gained from being farther away from the enemy.
Now that the basics are defined, it's time to throw the tactical wrench into the works. This part of the idea still needs work, especially with the issues outlined at the bottom. For the purposes of cover, both the player and enemies ignore most things that are adjacent to them. This simulates the ability to peek through windows, shoot around pillars and corners etc... Examples:
Code: Select all
..#....... ..#....... ..#.......
.@w....pO. .@w.....Op @.w.....Op
..#....... ..#....... ..#....... 2. The bandit ducks behind the pillar. As the pillar is adjacent to the bandit, is is not considered for its calculations when attacking or detecting the player. The player is still under 70% cover, the bandit is under 50% cover.
3. The player retreats. As the window is no longer adjacent to the player, it hinders his attempts to see and hit the bandit. The player is under 70% cover, the bandit is under 85% cover (70% + 50%, it stacks multiplicatively)
Code: Select all
##########
@.pppppppp
##########Code: Select all
##### #####
@..Td ..@Td
##### #####2. The player is closes on the HippoTANKomus. The player is still under 0% cover from the "T" and 0% cover from the "d". The "T" is under 0% cover from the player, the "d" is now under 0% cover as well. This allows the player to quickly kill the low HP high damage drone, while risking melee attacks.
---
While this looks quite good to me in straight lines, corners can pose problems that need to be addressed. The most glaring example is below (left to right are what it is, what it is calculated as for the player, and what it is calculated as for the monster, respectively):
Code: Select all
...p... ...p... ...p...
######@ #####.@ ##...#@
....p.. ....p.. ....p..
######@ #####.@ ###...@ Re: Our community module
Er, why would the higher level part have less Sync? I'm not sure if there has been other mechanics put forth - my intention was that every part more or less had a fixed Sync contribution. I.e; the player starts with 0 if they have no parts equipped, and the limit goes up with each piece. I can't claim that I'm comfortable with what I've proposed, though. It's workable but it may be very strenuous to balance.lukep wrote: Long Term Resources: I'm not sure that I understand how unity/sync works. For example, let's say that a new character gets 1000/1000 sync. After equipping a lvl 1 smashtech hammer arm, they would have 900/900, but would only have 800/800 for a lvl 10 version of the same part. Would using a tech talent then reduce your sync to 790/800 (as well as costing some high throughput resource)?
Sorry about all the parentheses (sometimes I like to clarify things).
Re: Our community module
Higher numbers = good, or Higher numbers = bad? My previous post assumed that high numbers were desirable, and that equipping more, higher level parts would make your Sync worse.bricks wrote:Er, why would the higher level part have less Sync? I'm not sure if there has been other mechanics put forth - my intention was that every part more or less had a fixed Sync contribution. I.e; the player starts with 0 if they have no parts equipped, and the limit goes up with each piece. I can't claim that I'm comfortable with what I've proposed, though. It's workable but it may be very strenuous to balance.
Re: Our community module
Ah, yes. That could have been clearer. I was looking at it as a fraction of the total. In the current module, 100% Sync -> 100% "effectiveness," 0% Sync -> 20% "effectiveness."
I'm not particularly committed to Sync/Fidelity, so much as I'd like the "energy"-style resource(s) to more or less as I've described. It'd be better to not design these things in a vacuum.
I'm not particularly committed to Sync/Fidelity, so much as I'd like the "energy"-style resource(s) to more or less as I've described. It'd be better to not design these things in a vacuum.
Sorry about all the parentheses (sometimes I like to clarify things).
Re: Our community module
Here is my idea of how parts, talents and the long term resources interact. Lets look at the Pneumatic arm already in the repository. There are 4 talents, and the number to the side is the sync value at which the talent becomes available. Your current sync value can be affected by atomic effects (say an EMP attack) as well as perturbing your system by adding a new module to the arm. The sync would slowly increase towards its maximum value through use of the corresponding parts, representing an increasing integration. The player would "advance" by increasing this maximum value, which would allow for two different paths. The first is to unlock the higher tier talents for the current biological parts. The other would be to surgically replace a biological part, which you can imagine would be quite a shock and would significantly lower the maximum value of the sync resource.
<DarkGod> lets say it's intended
Re: Our community module
Hmm, that's very different. I can't imagine how that would play.
I added a page on the plot to the wiki, and wrote down a summary of a possible plot. I think it integrates the basic ideas pretty well - it includes survival, exploration, and rescue; there is an inherent conflict between life and technology; the planet is a living thing (something like a Man o' War); and the world changes as the plot develops.
I added a page on the plot to the wiki, and wrote down a summary of a possible plot. I think it integrates the basic ideas pretty well - it includes survival, exploration, and rescue; there is an inherent conflict between life and technology; the planet is a living thing (something like a Man o' War); and the world changes as the plot develops.
Sorry about all the parentheses (sometimes I like to clarify things).
Re: Our community module
The plot is very well written! And actually engaged me a lot.
The cybernetic part of the gameplay I guess will come from the military side? Or the underground colonies?
It's pretty epic the tale of the living planets vs the rest of the known universe. I do feel drawn to the planet side already.
The cybernetic part of the gameplay I guess will come from the military side? Or the underground colonies?
It's pretty epic the tale of the living planets vs the rest of the known universe. I do feel drawn to the planet side already.
Re: Our community module
Haha, glad you liked it. I'm never very confident with my creative writing attempts. There's very little there that is truly original, apart from the perspective and the composition, but with sci-fi titans like Asimov and Clarke originality is already such a challenge. It's good to hear that you feel drawn to the planet-side of things. I don't want one side to appear crazy or evil; both sides are in a desperate position and the techno-cultural differences prevent reconciliation.
Yes, the cybernetics would mostly come from the military side of things, but if there is a distinction between "soft" upgrades (cybernetic augments) and "hard" upgrades (bionic prosthetics), I don't see any problem with use of the former by the locals. The same could be done with genes. I can see reason to hold back on access to the "hard" upgrades (prosthetics and grafts) until the second act (around the time you discover both sides' motivations).
I don't want the final conflict to be a "press A or B to choose the fate of the universe" situation, since it's so hackneyed. Instead, I imagine the decision being at the beginning of the final act, which then determines your position and targets for the last part of the game. If you side with the military, you'd be going up against super-evolved monsters and humans; if you choose to defend the planet, you'd be fighting the military's best techno-enhanced soldiers along with cybernetic versions of the planet's fauna.
One last note. Reaction towards the name rEvolution seemed tepid, from what I gathered reading over the IRC log. I think it does fit the plot I've proposed rather well, since it ultimately comes down to the question - where does humanity go next? Are we to become machines, or should we embrace symbiosis with a greater form of life?
Yes, the cybernetics would mostly come from the military side of things, but if there is a distinction between "soft" upgrades (cybernetic augments) and "hard" upgrades (bionic prosthetics), I don't see any problem with use of the former by the locals. The same could be done with genes. I can see reason to hold back on access to the "hard" upgrades (prosthetics and grafts) until the second act (around the time you discover both sides' motivations).
I don't want the final conflict to be a "press A or B to choose the fate of the universe" situation, since it's so hackneyed. Instead, I imagine the decision being at the beginning of the final act, which then determines your position and targets for the last part of the game. If you side with the military, you'd be going up against super-evolved monsters and humans; if you choose to defend the planet, you'd be fighting the military's best techno-enhanced soldiers along with cybernetic versions of the planet's fauna.
One last note. Reaction towards the name rEvolution seemed tepid, from what I gathered reading over the IRC log. I think it does fit the plot I've proposed rather well, since it ultimately comes down to the question - where does humanity go next? Are we to become machines, or should we embrace symbiosis with a greater form of life?
Sorry about all the parentheses (sometimes I like to clarify things).