Legacy roadmap

Fixed. My script files had names that were too long it seems. The scripts are now compiling correctly.

Now, a question for the community.


Party Behavior

One of the most prevalent complaints about Legacy was how party members would often get lost and would flail about trying to follow the party leader. Further, they would often get stuck inside walls or other places where they shouldn't have been getting stuck. I decided against using the built-in caterpillar party because the player should be able to talk to party members. The only way I could figure out how to do this before was to have party members as NPCs set to "Follow hero". Unfortunately, while it technically works, it doesn't work well.

I've been thinking of new solutions, and have come up with a few that I believe are within my ability to make.

Solution 01 - Use menus to talk to party members
In this solution, only the leader of the party is visible. An option is provided on the default menu to interact with party members. Something like: "Party Management → Equip, Order, Swap, Interact" which would bring call the default dialogue script.

The advantage of this is that it completely does away with the need for a follow script. It will also free up screen real-estate by removing three NPCs which would otherwise be blocking up some of the area.

What I don't like about this is that it adds more steps to talking to party members than I would like. It also, for me, breaks immersion and doesn't seem to be a very intuitive way of doing things.



Solution 02 - Make player movement and game interaction mouse-driven
Think Ultima VII. I've already scripted a* in my terrain generation project, so it shouldn't be too hard to script a* for player movement as well. Clicking on a part of the map would tell the player to move towards that point. With this, party members could use the built-in caterpillar follow method. Upon double-clicking on a party member (how that'll work I have yet to figure out) the standard dialogue script would be called. Menus would also be mouse-driven, in order to allow for a more fluid UI.

The advantage of this is that it'll look really cool.

The disadvantage of this is that it'll be really hard.



Solution 03 - Script a new following mechanism
In this solution, I basically keep the way things work now, but rather than use the built in "follow" of NPCs, I instead script a new way for NPCs to follow. I would either use a* or perhaps a hacky/kludgy method that would be easy to write, but inelegant to view.

The advantage of this is that I'll be able to keep some of my old code related to when the NPCs should move and when they should stand still. If I use a*, it should also theoretically work a lot better than the built-in follow while still retaining the basic mechanics that are already in place within the game.

The disadvantage is that it might get a bit complicated and it might slow the game down. Also, I believe that it'll be even more complicated to script than solution two. Doable, but complicated.



So, what does everyone think? Which option should I go with? Or should I just get rid of party interaction altogether?

---

Being from the third world, I reserve the right to speak in the third person.

Using Editor version wip 20170527 gfx_sdl+fb music_sdl

Solution 1 sounds the easiest, but you are right, it breaks the immersion. If other things in you game breake it as well, than it should not be such a problem, but if you don't want the immersion broken or lost, than better don't use it.

I don't know how large your maps are and if this is practical, but for solution 3,
maybe you could use zoens to tell the NPCs where to walk and where not to walk? (So, that they don't run and stuck into walls etc?)

How about a 'warp NPC near Hero' script if they are to far away from the hero?

Shall the player be always able to talk to party members?
Maybe you could just make spots (like rest places) where the whole party shows up, you can talk to them and when they travel on, the NPCs return to catapillar mode.
(I had this in mind for Kim and Jose some time ago. But I like your ideas better. )

I already use zones telling the NPCs where they can or cannot be. Problem is, the game sometimes gets stuck in an infinite loop in certain areas where it can't figure out where to place the NPC because the allowed areas are too narrow.




I have something similar in place, but the NPCs don't warp near the hero. Rather, they warp to an edge the hero but just outside of the view range in order to prevent NPCs suddenly appearing out of thin air. Hehe, I suppose it didn't work quite too well.

---

Being from the third world, I reserve the right to speak in the third person.

Using Editor version wip 20170527 gfx_sdl+fb music_sdl

Option 1 could be softened by a group backdrop showing your party members in a group portrait style as if you were talking to them. This is what DQ 8 on the PS2 did. It would still probably be rougher on Immersion than the other methods though.

Example from google: http://superybertv.webs.com/apps/photos/photo?photoid=173103835

---

"a manticore asks a wizard whether it, only being 10% human, has a soul like they do. The answer is that the mere act of wondering whether one has a soul is proof of having one."
-Found on TVTropes

What about this? Use the normal default caterpillar party, but when you choose the menu option to talk with your party, they form a circle.

If there are walls in the way preventing them from forming a circle, they can just come as close to forming the circle as possible, and face the leader.

You could even make it so that once you are in the talk-to-your-party circle, you talk to them like NPCs, and when you walk more than 3 tiles away in any direction, they return to formal walkabout mode.

This scripts to do that would not actually be very complicated, and I think it would look pretty cool too!

I'll be honest, I don't think option 1 breaks immersion much at all. I mean, everything else the player does with the party is menu based, and dialogue is menu based. What's wrong with having dialogue-starting being menu based? At the end of the day, asking the player to feel immersed in a game where communication is text, and actions are done by selecting actions from a menu, is not hurt by asking them to do this for one more thing (in this case, talking to their companions). DQ8 worked fine this way.

I also think there's no reason to suspend caterpillar in this option. Why does it matter? No one complains that you can walk through your own party members when caterpillar mode is on, even though this is inconsistent with behavior with NPCs. Why would they complain that there are other special circumstances (ie, talking to them requires entering a menu first) in regards to party members?

---

I am Srime

Personally, I'm of the mind of "What does it matter if they walk through walls?" Nothing about caterpillar parties or parties in general are particularly realistic, so you may as well do with them whatever your vision demands. Of all the flaws that Legacy has, I thought the party members walking through walls was the least troublesome. I'd rather they get temporarily stuck in a wall than block my path, especially since they'll unhook themselves from the wall as soon as you move far enough away from them, and if you "fix" anything, it should be to ensure that they move out of the way if you're pushing against them. Plus, I like the "milling about" gimmick they have. I'd rather you focus on Legacy's other problems for now than worry about party movement. It's really not that big of a deal.

What I would advise you do is give the player the option to "freeze" the nearest NPC for a few seconds (through hotkey) so that he has time to trigger a conversation if you go with the retreat on approach method.

---

Place Obligatory Signature Here

That's not a bad idea, I'll give that a shot.




Hey, I like that idea. And you're right, it wouldn't be that complicated to script either. I'll look into doing this.






Good point, I never quite looked at it that way.






Aye, I'm working on all of the things I learned during the HotOHR. I'm working on things bit by bit, starting with the easier ones first though. Battles will take a lot longer so I might be doing those last. Dialogue is pretty modular, and I've got a spreadsheet that scripts everything for me so it's just a matter of rewriting a lot of stuff. But because there's a lot to rewrite, that might take a while.

---

Being from the third world, I reserve the right to speak in the third person.

Using Editor version wip 20170527 gfx_sdl+fb music_sdl

Random question, is there a way to check the color of a pixel at a specific X, Y?

---

Being from the third world, I reserve the right to speak in the third person.

Using Editor version wip 20170527 gfx_sdl+fb music_sdl

Nope.

Righto.

---

Being from the third world, I reserve the right to speak in the third person.

Using Editor version wip 20170527 gfx_sdl+fb music_sdl

Why?

Had this crazy idea of using large enemy sprites as maps. I would draw them out in black and white and grey. Then I'd have something look at it pixel by pixel to automatigically create a map. Prolly be more trouble than it's worth though :P

---

Being from the third world, I reserve the right to speak in the third person.

Using Editor version wip 20170527 gfx_sdl+fb music_sdl

Im sad you cant. but i found how you can store that information in a string. Its a lot of work tho.
i know this isnt what you had in mind but it works for 80*80 too and you can adjust it for your needs, i know it. you dont need the in game 80*80 sprite unless you were going to provide a mini map or something. It took me 5 min to type the string so your looking at close to an hour for an 80*80. But test this out anyway, i worked hard on it
INCLUDE, PLOTSCR.HSD
PLOTSCRIPT, PROGRAMSTART, BEGIN
$1="0000000000000000000000000000000000000000000000000000000000000000000111111000000000000111111111100000000011111111111100000001111111111111100000011111111111111000001112221111222111000011222221122222110000111222111122211100001111111111111111000001111111111111100000011112211221111000000011222112221100000000022211112220000000002222000022220000000222200000022220000000220000000022000000000000000000000000"
variable (loop, loop2, current, count)
setherospeed (me, 20)
count := 1
for (loop, 0, 19) do ( #for the y axis
for (loop2, 0, 19) do ( #for the x aixs
current := asciifromstring (1, count)
switch (current) do (
case (48) do ( #if current number = 0
writemapblock (loop2, loop, 0)
)
case (49) do ( #if current number = 1
writemapblock (loop2, loop, 1)
)
case (50) do ( #if current number = 2
writemapblock (loop2, loop, 2)
)
)
count += 1 # so it checks the next number
)
)
END
# copy and paste code
# make sure there is no dead space in the string
# open new project
# compile code
# resize map zero to 20*20
# set plotscript to map zeros "autorun"
# edit maptile colors (0 = grey, 1 = black, 2 = white)
# test game
# smile

Hehe, neat.

I've actually done the opposite, storing sprites as tilemaps (for the DoomRPG flames intro), as well as storing maps in strings (for Blockworks).

If you're going to be storing stuff in strings, you should use some code to create them. For example you could draw a map in the editor, write a script that reads the map and constructs a string, prints it to g_debug.txt with "trace", and then copy paste that string into your scripts. Or write a script in Python or another language which reads from an image file.

Another possibility to consider is that you can use "save map state" on one map and then "paste" that saved state onto another map which has the same size with "load map state".

Anyway, the reason I was asking why is that I was considering implementing reading pixels from sprites and from the screen. Reading from a sprite is easy, but if we move to using hardware accelerated graphics reading from the screen may be trouble.