Adding some new game preferences could help give a good first impression and first-step usability with the engine. For example, when creating a new game, instead of just generating a .rpg file in some specified folder, creating a new folder with a .rpg file, a saves folder, a .hss shell file, etc. all packaged together.
I know that file management is a very personal thing, and that users should create and follow their own conventions, but 1. not everyone has file management skills or cares to put in the time, and 2. as a new user, I didn't know what files were even involved in creating a new game. When folders like the saves, autobackups, etc. get generated automatically as custom runs, it's not immediately clear where or when they showed up. Creating a new game folder holding all the necessary stuff, rather than just an rpg file, could help organize everything.
Nathan's comment over in the RGC thread about not needing to include plotscr.hsd anymore got me thinking that generating a .hss file at creation could help plotscripting be a less daunting activity. The file could have a comment with the game name and author at the top, and an empty plotscript. That would help those unfamiliar with plotscripting get a headstart, and make creating a new game less tedious for everyone else.
Plus, all of this could be optional, as preferences when selecting the Create New Game option when opening custom. Like a checkbox for "generate plotscript file."
OHRRPGCE feature requests/suggestions
Moderators: Bob the Hamster, marionline, SDHawk
- Attachments
-
- shell hss file example
- Screen Shot 2019-03-30 at 12.05.37 PM.png (13.46 KiB) Viewed 2240 times
-
- file structure example
- Screen Shot 2019-03-30 at 12.08.04 PM.png (14.29 KiB) Viewed 2241 times
Last edited by kylekrack on Sat Mar 30, 2019 7:17 pm, edited 1 time in total.
My pronouns are they/them
Ps. I love my wife
Ps. I love my wife
Anything to make it easier to get up to speed is a good thing. I'm very glad that we now have a few default walkabouts.
Creating a folder for a game is quite reasonable. Although there would initially only be two files in it: the .rpg and .hss, you're right to point out that a lot of other files will end up there as well, so having a folder would be tidier.
A nearly-blank .hss like that helps, but I wonder whether there are any example scripts that could be put in it as a demo, like a run script. Particularly for someone who has never written a script before. Maybe a "show textbox" in the newgame script.
Relatedly, in future I want to support storing graphics in external files, which will be very useful to people using external graphics editors or collaborating on a game.
Creating a folder for a game is quite reasonable. Although there would initially only be two files in it: the .rpg and .hss, you're right to point out that a lot of other files will end up there as well, so having a folder would be tidier.
A nearly-blank .hss like that helps, but I wonder whether there are any example scripts that could be put in it as a demo, like a run script. Particularly for someone who has never written a script before. Maybe a "show textbox" in the newgame script.
Relatedly, in future I want to support storing graphics in external files, which will be very useful to people using external graphics editors or collaborating on a game.
I'm glad you like the idea! There are all kinds of options with a blank hss file to start the user out with. I think that comes down to user-testing and what people actually find useful.
I will say, collaborating is already loads easier. Gaplan drew the sprites for PvPRPG, that we just made for the RGC. Importing those into Custom was pretty darn easy, and updating them when Gaplan made some adjustments was pretty painless.
I will say, collaborating is already loads easier. Gaplan drew the sprites for PvPRPG, that we just made for the RGC. Importing those into Custom was pretty darn easy, and updating them when Gaplan made some adjustments was pretty painless.
My pronouns are they/them
Ps. I love my wife
Ps. I love my wife
-
Nathan Karr
- Liquid Metal Slime
- Posts: 1215
- Joined: Fri Jan 25, 2008 3:51 am
- Contact:
We have indications for when a given hero can wield a piece of equipment on the shop screen, but no such indication if it's a spell-teaching item that specific characters can learn from. How about an option to display this on the shop menu with the characters who can learn doing their stepping and then casting animations, the way those who can equip them use their attacking animations? And for items that both teach spells and can be equipped, either having these two sets of hero graphics stacked up or having it alternate between the two.
I say option in part because some game designers might want players to be a little bit in the dark about this, expect them to experiment a bit and not be entirely sure who can use what.
I say option in part because some game designers might want players to be a little bit in the dark about this, expect them to experiment a bit and not be entirely sure who can use what.
Remeber: God made you special and he loves you very much. Bye!
- Target Setting: Front Row
Can switch target between all enemies that don't have another enemy in front of them.
This could be expanded so that you can attack the one behind the front row if the front unit have been hit with a status effect that makes him unable to act.
Or damage the whole row / or wide attack, also hitting nearby enemies in front.
Block effectiveness options:
Should a unaligned enemy that slightly covers 2 count as a block, or does that make all of them targets?
Big sprite protected 1 small, or must the small ones fully block the big one for him to not be a target?
- Do not make effects of usable battle buff items stack
.. unless the effect got a duration to them? But I don't think they do?
For example a potion that increase defense or dodge for a battle, if you take another one then it should only keep the effect that was strongest of the two, instead of taking the stats through the roof.
So drinking a potion that gives
[+1 def, +10 dodge] and then another one which got
[+2 def, +5 dodge], should result in the character having
[+2 def, +10 dodge] in the end
Can switch target between all enemies that don't have another enemy in front of them.
This could be expanded so that you can attack the one behind the front row if the front unit have been hit with a status effect that makes him unable to act.
Or damage the whole row / or wide attack, also hitting nearby enemies in front.
Block effectiveness options:
Should a unaligned enemy that slightly covers 2 count as a block, or does that make all of them targets?
Big sprite protected 1 small, or must the small ones fully block the big one for him to not be a target?
- Do not make effects of usable battle buff items stack
.. unless the effect got a duration to them? But I don't think they do?
For example a potion that increase defense or dodge for a battle, if you take another one then it should only keep the effect that was strongest of the two, instead of taking the stats through the roof.
So drinking a potion that gives
[+1 def, +10 dodge] and then another one which got
[+2 def, +5 dodge], should result in the character having
[+2 def, +10 dodge] in the end
Last edited by TailBit on Thu Apr 04, 2019 12:02 am, edited 1 time in total.
Hmm! A 'front row' target class would be a lot of fun! That's a cool suggestion.
However there are a lot of questions about how it should determine the front row. Potentially which slots are in front of which other slots even be defined in the formation editor... but that's too much complexity.
Hmm, maybe just one adjustable parameter per formation, an enemy size multiplier. Combining it with a way to preview which enemies are in front, you can adjust it or their positions until you get the desired result.
The front row should also depend on which direction the heroes are attacking from... but what if the heroes are in the middle and the enemies on the left and right? Ugh! I want to add a setting to the hero formation editor to define on which side the heroes are, which would affect the flee direction and also this. (I'm not sure how to flee from a heroes-in-the-middle ambush!)
As for stacking of buffs, whether buffs stack is determined by what damage settings you use. For example if you set an attack to reset the target stat to max before the attack then it won't stack. However a damage option to only modify the stat if the new value is more (or less) than it was before would be a nice feature to have in general.
As for shops: learnable items is I think not the only information missing? The cast animations is a clever way to display that though! I think the heroes should alternatve between attacking and casting if both are applicable.
Unfortunately the graphical indication of which heroes can equip an item is very inflexible. What if the hero sprites are too large or the resolution too small? What if there are more tan 4 heroes in the active pary (we want to allow that). What about reserve heroes? What if an item can be equipped in multiple slots, varying by hero (we want to allow that too). I think we need an alternative way to present this information... most basically just letting you define all the text in the shop, not just the item description.
I do need to do some work on shop descriptions, as part of a HotOHR request.
However there are a lot of questions about how it should determine the front row. Potentially which slots are in front of which other slots even be defined in the formation editor... but that's too much complexity.
Hmm, maybe just one adjustable parameter per formation, an enemy size multiplier. Combining it with a way to preview which enemies are in front, you can adjust it or their positions until you get the desired result.
The front row should also depend on which direction the heroes are attacking from... but what if the heroes are in the middle and the enemies on the left and right? Ugh! I want to add a setting to the hero formation editor to define on which side the heroes are, which would affect the flee direction and also this. (I'm not sure how to flee from a heroes-in-the-middle ambush!)
As for stacking of buffs, whether buffs stack is determined by what damage settings you use. For example if you set an attack to reset the target stat to max before the attack then it won't stack. However a damage option to only modify the stat if the new value is more (or less) than it was before would be a nice feature to have in general.
As for shops: learnable items is I think not the only information missing? The cast animations is a clever way to display that though! I think the heroes should alternatve between attacking and casting if both are applicable.
Unfortunately the graphical indication of which heroes can equip an item is very inflexible. What if the hero sprites are too large or the resolution too small? What if there are more tan 4 heroes in the active pary (we want to allow that). What about reserve heroes? What if an item can be equipped in multiple slots, varying by hero (we want to allow that too). I think we need an alternative way to present this information... most basically just letting you define all the text in the shop, not just the item description.
I do need to do some work on shop descriptions, as part of a HotOHR request.
I do find it interesting that you want to set the front already in the formation editor instead of doing it after an attack is selected, looping through the enemies and checking if their boundary box is cast over each other ..
But yeah, with different sizes and rotation, then the front get harder to define ^^;; good luck.
Maybe even custom target classes could be a thing, if you want to take it that far.
But yeah, with different sizes and rotation, then the front get harder to define ^^;; good luck.
Maybe even custom target classes could be a thing, if you want to take it that far.
But how much of an overlap should be allowed? There will be a lot of ambiguous situations, and I need to make sure I don't over-engineer a solution; giving the user a single crude knob and a preview of the results is a good compromise.
Actually I do want to allow custom target classes defined by either enemy or formation slot properties like "high ground", "under water", "fish", "near", "metal armor", "weak", "stunned". Creating battles could be so much more fun..
Actually I do want to allow custom target classes defined by either enemy or formation slot properties like "high ground", "under water", "fish", "near", "metal armor", "weak", "stunned". Creating battles could be so much more fun..
I could make a test in JavaScript for the "front row" code, if you would want that..
This is how I see it for me:
required cover would be the previous size and >0 for the smallest ..
in my logic one size should be guarded if he got the 1 size smaller fully in front of him, if another stage smaller then he would need 2-3
(I did consider casting a shadow that splits into parts which then gets checked individually, but I think I will have to make the test for that first .. it made little sense if there is a stack of small guards in front on one big ^^;;)
This is how I see it for me:
Code: Select all
- sort enemies after closest to player
loop{
- cast a shadow over the the targets further away (going in the grid direction, not directly from player)
loop{
- if casting shadow on smaller size, then it counts if he covers 30% of the one below (giving max cover value)
- on bigger ones then 30% of its total shadow needs to hit, then tell the below one that its cover += size * shadowCover%, and tell this one that it is guarding
}
- if cover < requiredCover and guarding = true, add to target list
}in my logic one size should be guarded if he got the 1 size smaller fully in front of him, if another stage smaller then he would need 2-3
(I did consider casting a shadow that splits into parts which then gets checked individually, but I think I will have to make the test for that first .. it made little sense if there is a stack of small guards in front on one big ^^;;)
-
Bob the Hamster
- Lord of the Slimes
- Posts: 7660
- Joined: Tue Oct 16, 2007 2:34 pm
- Location: Hamster Republic (Ontario Enclave)
- Contact:
I like this idea of cover, and it makes me wonder about how other RPGs handle it.
The one that comes first to my mind is Romancing Saga 1. For all the gameplay and balance problems that game had, I think that rows and cover in battle is something they really got right
I don't think they used any type of cast shadow-- instead, I think they probably divided the battlefield into vertical stripes, and then checked whether or not a stripe was occupied to determine if it gave cover to the stripes behind it.
They would also animate the heroes and enemies moving closer to each other each time a front row stripe was emptied, but that is another thing.
The one that comes first to my mind is Romancing Saga 1. For all the gameplay and balance problems that game had, I think that rows and cover in battle is something they really got right
I don't think they used any type of cast shadow-- instead, I think they probably divided the battlefield into vertical stripes, and then checked whether or not a stripe was occupied to determine if it gave cover to the stripes behind it.
They would also animate the heroes and enemies moving closer to each other each time a front row stripe was emptied, but that is another thing.
I was imagining that if there was a tiny enemy right in front of a large one, the large one would not be considered as the "front row" -- that's what those words suggest to me! (Basically that larger enemies maybe provide more cover, but don't require more.) With different wording you get different intuitions. Having cover (protection from ranged attacks) is completely different from being the in 'front row'. Potentially "front row" and "not covered" could be separate target classes.
Thanks for the concrete suggestion.
So how would people actually want to use these?
Thanks for the concrete suggestion.
So how would people actually want to use these?
Last edited by TMC on Mon Apr 08, 2019 1:14 pm, edited 2 times in total.
Yeah, what I mean is that the front one blocks you from targeting the one behinds it, but if you stun/sleep/kill all the blockers, then it is added to the target pool until their stat changes or or new enemies are spawned ..
It is pretty much so meele fighters get an attack choice that doesn't make them seem like a ranged unit.
So loop through the same facing enemies sorted by distance to player, ready an array for the lanes, filled with empty arrays, and populate the empty arrays for every lane they occupy, if on is added to an already populated array, then it is guarded..
I would like to see the bigger enemies needing most of their lanes guarded to not be a target, but I have seen Lost Odyssey use every character in front as a full guard, even by a small minion guarding a boss sized enemy, so everything works.
If everyone would count as a guard, then a checking if there are any enemy behind is enough and the editor would just have to highlight every enemy that would overlap selected enemy's position horizontally and vertically.
(I do want to make some tests of these, but are in no condition to code today)
It is pretty much so meele fighters get an attack choice that doesn't make them seem like a ranged unit.
If the battlefield is split up in horizontal and vertical lanes/stripes then the editor can easily display this chess grid positions at the edges or even display what tiles that are used, and it will make sense when the whole thing is rotated.Bob the Hamster wrote:...
I don't think they used any type of cast shadow-- instead, I think they probably divided the battlefield into vertical stripes, and then checked whether or not a stripe was occupied to determine if it gave cover to the stripes behind it.
They would also animate the heroes and enemies moving closer to each other each time a front row stripe was emptied, but that is another thing.
So loop through the same facing enemies sorted by distance to player, ready an array for the lanes, filled with empty arrays, and populate the empty arrays for every lane they occupy, if on is added to an already populated array, then it is guarded..
I would like to see the bigger enemies needing most of their lanes guarded to not be a target, but I have seen Lost Odyssey use every character in front as a full guard, even by a small minion guarding a boss sized enemy, so everything works.
If everyone would count as a guard, then a checking if there are any enemy behind is enough and the editor would just have to highlight every enemy that would overlap selected enemy's position horizontally and vertically.
(I do want to make some tests of these, but are in no condition to code today)
Hmm, strips does have the advantage that it's simple and easy to indicate in the formation editor.
It's also worth considering how arranging the heroes into first and second rows would work. Often back-row hereoes aren't portrayed strictly behind the front heroes, but just moved back a bit, so that the party doesn't take up too much of the screen. Strips could accomplish that.
It's also worth considering how arranging the heroes into first and second rows would work. Often back-row hereoes aren't portrayed strictly behind the front heroes, but just moved back a bit, so that the party doesn't take up too much of the screen. Strips could accomplish that.
