One Day, We May Yet Learn To Forgive dev thread
Moderators: Bob the Hamster, marionline, SDHawk
Re: One Day, We May Yet Learn To Forgive dev thread
awesome! Can't wait to play it.
- Hedera
- Slime Knight
- Posts: 175
- Joined: Tue May 17, 2011 11:38 am
- Location: a dying forest (all forests are dying)
Re: One Day, We May Yet Learn To Forgive dev thread
I just want to work on graphics stufffffffffffff
- Attachments
-
- and try to do what the first two ecco the dolphin games did with caves and stuff; the "tree roots" are a low priority to get looking nice, unfortunately
- ODWMYLTF0033.gif (79.91 KiB) Viewed 3518 times
- Hedera
- Slime Knight
- Posts: 175
- Joined: Tue May 17, 2011 11:38 am
- Location: a dying forest (all forests are dying)
Re: One Day, We May Yet Learn To Forgive dev thread
The ba'Rebeca twins and their dog, henceforth known as N/S/A, have a Light spell that when used in battle, gives everyone the Blind status. Outside of battle, they bring a scroll of Light as an item. When this item is used, any and all secret passages are revealed and turn into Rainbow Road. N/S/A doesn't need to be in the party for the scroll to be used.
This scroll needs to be used again every time the player character goes through a door.
This scroll needs to be used again every time the player character goes through a door.
- Attachments
-
- the arrows tell you where doors are, blinking ones are where the story progresses; they point toward the exit because this is the tutorial dungeon
- ODWMYLTF0034.gif (3.01 MiB) Viewed 3512 times
-
- What happens when you use the Light Scroll outside of maps with secret passages.
- ODWMYLTF0035.png (1.98 KiB) Viewed 3512 times
- Hedera
- Slime Knight
- Posts: 175
- Joined: Tue May 17, 2011 11:38 am
- Location: a dying forest (all forests are dying)
Re: One Day, We May Yet Learn To Forgive dev thread
BUT WAIT THERE'S MORE
* Liza ba'Tabitha is working on a Teleport spell. Her prototype allows the player to teleport to the beginning of dungeons.
* The minimap brings up a map layer, hidden behind a backdrop, that maps to where the player can and can't walk... with the exception of secret passages, of course. It also shows you where doors link to, and where the exit of the map is.
* Liza ba'Tabitha is working on a Teleport spell. Her prototype allows the player to teleport to the beginning of dungeons.
* The minimap brings up a map layer, hidden behind a backdrop, that maps to where the player can and can't walk... with the exception of secret passages, of course. It also shows you where doors link to, and where the exit of the map is.
- Attachments
-
- Eventually there'll be a tree here.
- ODWMYLTF0032.gif (663.39 KiB) Viewed 3506 times
-
- yes it looks janky as hell, but fixing it's low priority at the moment
- ODWMYLTF0036.gif (105.82 KiB) Viewed 3506 times
- Bob the Hamster
- Lord of the Slimes
- Posts: 7684
- Joined: Tue Oct 16, 2007 2:34 pm
- Location: Hamster Republic (Ontario Enclave)
- Contact:
Re: One Day, We May Yet Learn To Forgive dev thread
These are cool spells!
- Hedera
- Slime Knight
- Posts: 175
- Joined: Tue May 17, 2011 11:38 am
- Location: a dying forest (all forests are dying)
Re: One Day, We May Yet Learn To Forgive dev thread
There's a content warning/18+ only warning that displays when you first play the game.
- Attachments
-
- This .gif is a message... and part of a system of messages... pay attention to it!
- ODWMYLTF0037.gif (274.17 KiB) Viewed 3496 times
- Hedera
- Slime Knight
- Posts: 175
- Joined: Tue May 17, 2011 11:38 am
- Location: a dying forest (all forests are dying)
Re: One Day, We May Yet Learn To Forgive dev thread
the light spell now persists across doors and saving/loading; it shuts off when you enter an "outdoor" map
- Attachments
-
- Really hope Alici's visible against dark brown environments...
- ODWMYLTF0038.gif (3.93 MiB) Viewed 3479 times
- Hedera
- Slime Knight
- Posts: 175
- Joined: Tue May 17, 2011 11:38 am
- Location: a dying forest (all forests are dying)
Re: One Day, We May Yet Learn To Forgive dev thread
Today in implementing new graphics features: buildings disappear when you walk behind them and reappear when you walk back in front, allowing you to see more in towns. Credit goes to Artimus Bena for helping me out a ton with this.
- Attachments
-
- this debug example is with 20 * 20 px tiles; it'll actually be used for 10 * 10 px ones
- ODWMYLTF0047.gif (989.75 KiB) Viewed 3470 times
- Hedera
- Slime Knight
- Posts: 175
- Joined: Tue May 17, 2011 11:38 am
- Location: a dying forest (all forests are dying)
Re: One Day, We May Yet Learn To Forgive dev thread
coming back to things that you did several months ago and didn't comment properly sure is a feeling, as is knowing you'll need to pare back in order to meet a deadline
- Bob the Hamster
- Lord of the Slimes
- Posts: 7684
- Joined: Tue Oct 16, 2007 2:34 pm
- Location: Hamster Republic (Ontario Enclave)
- Contact:
Re: One Day, We May Yet Learn To Forgive dev thread
Code: Select all
# good comments are a love letter to your future self
- Hedera
- Slime Knight
- Posts: 175
- Joined: Tue May 17, 2011 11:38 am
- Location: a dying forest (all forests are dying)
Re: One Day, We May Yet Learn To Forgive dev thread
^ were attack descriptions introduced in hrodvitnir, I only just now started using them and it's a much better way to organize things in the attacks menu than naming things "STMSW1CRHT"
So. One of the things I wanted to implement in my game was for dead enemies to leave corpses in the field, which is done through transmogrification. Unfortunately, while the dead versions of enemies can't be targeted by the player, attacks made against an enemy that dies before the other attacks are resolved still occur. Since I don't want to recreate the "Ineffective" attacks bug/feature from the NES Final Fantasies, each attack made on enemies has two dummy attacks that go before it: the first is for the player to choose their target directly, and uses chaining to either the actual attack, or if the enemy's dead, to a second dummy attack that randomly chooses another target. If the attack hits all enemies, then the second dummy attack is still there, but it prevents the actual attack from hitting the dead enemy.
Why does that work?
Also, why did I make it so that the first attack in the chain deletes stored targets, but later on in the chain it stores the target.
So. One of the things I wanted to implement in my game was for dead enemies to leave corpses in the field, which is done through transmogrification. Unfortunately, while the dead versions of enemies can't be targeted by the player, attacks made against an enemy that dies before the other attacks are resolved still occur. Since I don't want to recreate the "Ineffective" attacks bug/feature from the NES Final Fantasies, each attack made on enemies has two dummy attacks that go before it: the first is for the player to choose their target directly, and uses chaining to either the actual attack, or if the enemy's dead, to a second dummy attack that randomly chooses another target. If the attack hits all enemies, then the second dummy attack is still there, but it prevents the actual attack from hitting the dead enemy.
Why does that work?
Also, why did I make it so that the first attack in the chain deletes stored targets, but later on in the chain it stores the target.
- Attachments
-
- every enemy has their own death transmogrification, because battlescripting doesn't exist and as such there are no subscripts/subroutines/functions that could do that for multiple enemies
- ODWMYLTF0041.gif (472.89 KiB) Viewed 3415 times
-
- the backdrop made from upscaled wall and floor tiles is temporary.... if I have enough time to draw something better
- ODWMYLTF0048.gif (1.74 MiB) Viewed 3415 times
-
- What are "PriWpnType" and "SecWpnType"? Don't worry about it.
- ODWMYLTF0049.gif (488.43 KiB) Viewed 3415 times
- Hedera
- Slime Knight
- Posts: 175
- Joined: Tue May 17, 2011 11:38 am
- Location: a dying forest (all forests are dying)
Re: One Day, We May Yet Learn To Forgive dev thread
Two new features:
- Don't feel like fighting enemy encounters in dungeons? There's an option for making them not occur.
- Immediately before boss fights, "the flames of destiny" appear to give you a quick opportunity to heal up, change your equipment, and save. It also prevents you from running away. It also also means pre-boss cutscenes don't have to replay every time you reload the game! Talk to the boss again and the fight begins.
- Don't feel like fighting enemy encounters in dungeons? There's an option for making them not occur.
- Immediately before boss fights, "the flames of destiny" appear to give you a quick opportunity to heal up, change your equipment, and save. It also prevents you from running away. It also also means pre-boss cutscenes don't have to replay every time you reload the game! Talk to the boss again and the fight begins.
- Attachments
-
- the glimmers were shortly afterward changed to rainbow ants
- ODWMYLTF0051.gif (3.68 MiB) Viewed 3378 times
-
- current placeholder animation is done by NPCs confined to one tile and set to wander. NOTE TO SELF at some point learn enough slices to use kiefkrack's animation handler they offered you
- ODWMYLTF0055.gif (123.86 KiB) Viewed 3378 times
- Hedera
- Slime Knight
- Posts: 175
- Joined: Tue May 17, 2011 11:38 am
- Location: a dying forest (all forests are dying)
Re: One Day, We May Yet Learn To Forgive dev thread
Enemy difficulty (read: how high their stats are) can now be changed at any time in the options menu.
- Attachments
-
- also enemy stats for non-bosses are slightly randomized
- ODWMYLTF0056.gif (3.98 MiB) Viewed 3361 times
- Hedera
- Slime Knight
- Posts: 175
- Joined: Tue May 17, 2011 11:38 am
- Location: a dying forest (all forests are dying)
Re: One Day, We May Yet Learn To Forgive dev thread
A very unfortunate graphical glitch has been found, involving the light scroll and entering/leaving a battle. Essentially, what happens is that if the light scroll is used, it makes a map layer (here, layer 6) go invisible; by using it and then fighting a battle, layer 6 reappears and for some reason layer 1 disappears. When this happens, the game still thinks the light's still active, so using it again gives you the "it's already lit" message.
Furthermore, if you run away in the battle, layer 1 doesn't disappear, but layer 6 still reappears and you can't recast light. If enemy encounters are off completely, the glitch doesn't occur at all.
Finally, if the glitch occurs and you go through a door on the same map (haven't tested it with a door to a different map), the glitch goes away and everything looks normal again. Why? Who knows.
Here are the relevant (maybe?) scripts.
This is all in vanilla Hrodvitnir, by the way. I have no idea if running this in a nightly would change anything. Update: ran it in the june 28 nightly and it still happens, exactly as in hrodvitnir
update 2: this still happens when enemies are fought as random encounters, using sets of formations and the walking back and forth. it's definitely the battles themselves
why is this happening. how do I prevent it from taking place.
Furthermore, if you run away in the battle, layer 1 doesn't disappear, but layer 6 still reappears and you can't recast light. If enemy encounters are off completely, the glitch doesn't occur at all.
Finally, if the glitch occurs and you go through a door on the same map (haven't tested it with a door to a different map), the glitch goes away and everything looks normal again. Why? Who knows.
Here are the relevant (maybe?) scripts.
Code: Select all
plotscript, light scroll, begin
switch (current map)
do (
case (0) show text box (71) # "There's no need to cast Light here."
case (1) show text box (71) #
case (2) show text box (71) #
case (3) casting light (6) # turns the map layer invisible by changing its tileset to an invisible one
case (4) show text box (71)
case (5) show text box (71)
case (6) casting light (6)
case (7) casting light (6)
)
end
plotscript, casting light, dummy map layer, begin
switch (check tag (104))
do (
case (false) change tileset (19, dummy map layer)
set tag (104, true)
case (true) show text box (73) # "you already casted it nerd"
)
end
plotscript, light already cast, dummy map layer, begin # autorun script for indoor maps
if (check tag (104)) # has light been cast?
then ( #
change tileset (19, dummy map layer) # then recast it as needed
)
end
plotscript, light goes out, begin # autorun script for outdoor maps
if (check tag (104)) # has light been cast?
then (
set tag (104, false) # then shut it off
)
end
plotscript, the pillar worker enc, begin
wait for mm close
enemy random stats (16, 19, 13) # base enemy = tame version, add 1 or 2 to get wary/fierce versions
from enc group (3, 5, 41)
end
plotscript, the pillar soldier enc, begin
wait for mm close
enemy random stats (16, 19, 13)
enemy random stats (25, 26, 22)
from enc group (6, 9, 41)
end
plotscript, enemy random stats, dummy enemy range lb, dummy enemy range ub, base enemy, begin
# This script takes the stats from a base enemy, and gives them to the versions of that enemy that appear in battle.
# Health and Tech are randomized between 1x the initial value and 1.2x + 1; the other stats are either randomized
# between 1x and 1x + 2, or not randomized at all. "multdiv (base #, 6, 5)" is used for health because "base # * 1.2
# + 1 doesn't work, because something something floating point.
variable (i) # dummy indices
variable (j) #
variable (k) # insert quaternion joke here
k := base enemy # "base enemy" refers to the tame version
if (check tag (2) == true) # if tag 2 is off, then it uses the tame stats
then ( #
switch (check tag (3)) #
do ( #
case (false) k += 1 # tag 3 off => wary
case (true) k += 2 # tag 3 on => fierce
)
)
for (i, dummy enemy range lb, dummy enemy range ub)
do (
for (j, 0, 1, 1) # Health and Tech are randomized between 1x and 1.2x
do (
set enemy stat (i, j, random (get enemy stat (k, j), multdiv (get enemy stat (k, j), 6, 5)))
)
set enemy stat (i, 2, random (get enemy stat (k, 2), get enemy stat (k, 2) + 2)) # Primary's random
for (j, 3, 5, 1) # Hit %, Secondary, and Critical % aren't
do (
set enemy stat (i, j, get enemy stat (k, j))
)
set enemy stat (i, 6, random (get enemy stat (k, 6), get enemy stat (k, 6) + 2)) # Skill is
set enemy stat (i, 7, get enemy stat (k, 7)) # Defense isn't
set enemy stat (i, 8, random (get enemy stat (k, 8), get enemy stat (k, 8) + 2)) # Speed is
set enemy stat (i, 9, get enemy stat (k, 9)) # Item % isn't
)
end
plotscript, from enc group, dummy lower bound, dummy upper bound, dummy formation background, begin
# This script is for alternating groups of enemy encounters. Enemy NPCs on the map appear based on whether tag 8 is
# either off or on, depending on the group. When the battle's triggered, it switches from one group to the other.
variable (dummy randnum) # This is to ensure that the same random
dummy randnum := random (dummy lower bound, dummy upper bound) # number's used for both set formation
switch (check tag (8)) # background and fight formation.
do ( #
case (false) set tag (8, 1) #
case (true) set tag (8, 0) #
) #
resume npcs #
if (check tag (9) == false) # This is to see if you're even fighting
then ( # enemy encounters
set formation background (dummy randnum, dummy formation background)
fight formation (dummy randnum)
)
end
plotscript, wait for mm close, begin
# This is so that battles aren't triggered should an NPC move into an adjacent tile while the main menu's active.
if (npcs are suspended == true)
then (
wait for menu (find menu id (0))
)
end
update 2: this still happens when enemies are fought as random encounters, using sets of formations and the walking back and forth. it's definitely the battles themselves
why is this happening. how do I prevent it from taking place.
- Attachments
-
- The glitch, in all its glory.
- ODWMYLTF0058.gif (1.6 MiB) Viewed 3349 times
-
- Ending the battle by running away stops layer 1 from disappearing
- ODWMYLTF0059.gif (1.36 MiB) Viewed 3349 times
-
- Not actually going into battle doesn't trigger the glitch?
- ODWMYLTF0060.gif (1.85 MiB) Viewed 3349 times
-
- Going through a door on the same map undoes the glitch
- ODWMYLTF0061.gif (2.3 MiB) Viewed 3349 times
- Bob the Hamster
- Lord of the Slimes
- Posts: 7684
- Joined: Tue Oct 16, 2007 2:34 pm
- Location: Hamster Republic (Ontario Enclave)
- Contact:
Re: One Day, We May Yet Learn To Forgive dev thread
Do you have an "after battle" script trigger? You could check the tag 104 in the after battle script, and if it is on, then you fix the layers