Open datahead8888 opened 9 years ago
We could use ladders. I feel that they'd work fine in the current graphics scheme.
For reference, here's an in-game vine:
I wouldn't say we can't use vines at all going forward. They do need to look different than the vines in Mario games.
We probably don't want vines shooting up out of boxes after Alex hits one with his head. @Luiji's suggest of using ladders would work really well here -- it could be an extending ladder moving upwards instead.
Has this been replaced already? I noticed there are already some different, rather nice looking vines in /pixmaps/ground/jungle_1/
While it's not a fix for Mario also having vines, just replacing pixmaps/ground/green_1/kplant.png with pixmaps/ground/jungle_1/vine_middle.png, as well as replacing pixmaps/ground/green_1/kplant_head.png with pixmaps/ground/jungle_1/vine_middle.png is a 10 second change that still works, and gets things looking less like Mario. I suggest looking at this screenshot at full size:
As a replacement, how about using ladders? They're not Mario-esque at all; I've seen them used in places from Kirby to Final Fantasy.
If you want something more unique, you could use some kind of rope or a pole with horizontal sticks in front (for climbing).
As a replacement, how about using ladders?
I think ladders would work all right. I mainly suggested this as a quick interim hack, to be swapped out when someone (Bugsbane whistles and looks around the room for any other artist) creates a ladder graphic. IMO, this is a perfect Junior (artist) job.
you could use some kind of rope or a pole with horizontal sticks in front (for climbing).
Funny you should suggest that. I was actually thinking the same. I think it would be less obvious that it was for climbing than a ladder, but it would change the visual look of the levels less, which keeps the level designers intent intact more. I was still thinking ladders are probably the way to go, just for clarity, but I could be convinced either way.
I think vines are fine, but: 1) They should look different than Mario games 2) They probably should not shoot out of blocks
Thus shooting ladders out of blocks you hit with your head is a good idea. Vines could then be static objects that add variety elsewhere in levels. We might think about what other climbable objects would work in the game, but they will not be a priority for de-Marioization efforts.
I'm inclined to agree with keeping vines already in the game, but replacing ones coming out of blocks. The only issue is that currently both use the same tileset unless I'm mistaken, so this will need some code change as well as graphics.
For the moment, could we just get those two files copied over? It's a 10 second commit (for someone who remembers how to do commits!), that still makes an improvement towards de-Marioization. When we have code separation between pre-existing vines and block-generated vines, I can create a ladder / climbing pole graphic very quickly (it would be a very easy one).
so this will need some code change as well as graphics
We could just add "Feature" to this ticket to signify the need for coding.
@Bugsbane and @kirbyfan64 - join us in IRC - #secretchronicles on freenode.net
Test with a ladder:
This ticket has been marked "Feature" to signify the code change needed for having ladders come out of boxes and vines that are only static.
Ladder svg Ladder top svg If someone wouldn't mind committing these (they replace /pixmap/ground/green_1/kplant.png and kplant-top.png from memory)
Cooooooool. @Luiji, could you please add Bugsbane’s graphics to the repository in the devel
branch? I’m busy with university, and datahead is on the doom larries currently.
Vale, Quintus
I do think it's important though that we implement what Datahead said about not just replacing all vines with ladders, but specifically the ones growing out of boxes.
For places where level designers have specifically chosen to add a vine, turning it into a ladder changes the whole visual look of the ladder, and we're better of using the pre-existing jungle vine graphics from comment https://github.com/Secretchronicles/TSC/issues/333#issuecomment-116320257
Bugsbane notifications@github.com writes:
I do think it's important though that we implement what Datahead said about not just replacing all vines with ladders, but specifically the ones growing out of boxes.
The graphics used for both are the exact same. The boxes are just implemented by scripting code using those graphics, so if you only want to change one of the graphics, it’ll require editing the level’s script code.
That’ſ only a fact. I do think that the idea is pretty good to resolve the issue exactly like that: Replace the old static Mario vines with the jungle wine, and add the ladder sprites as new graphics into the game, then adapt the level’s script codes accordingly (should be an easy search&replace). The old Mario vine can then be deleted completely.
Vale, Quintus
Quintus has since suggested changing the required Ruby file (std/climbing_box in the Standard Scripting Library) for vines that come out of boxes. This file can be used by all level scripts that want this feature. https://github.com/Secretchronicles/TSC/blob/devel/tsc/data/scripting/std/climbing_box.rb
Regarding my earlier confusion, I had thought that SMC 1.9 already had vines that comes out of boxes, but this was apparently wrong. Quintus has confirmed it is a new feature for release 2.0, only accessible through scripting.
Aren't vine-boxes a bit too Mario-y?
@Luiji - you are correct - this change would be to make ladders come out of those boxes instead of vines.
@datahead8888 I'll try to get this commit today.
@datahead8888 I'll try to get this commit today.
Thanks, Luiji. I haven't been able to find much TSC time the last couple weeks myself with some stuff that came up.
I'm having some trouble getting the TSC environment working again (did some system changes recently that seem to have broken CEGUI...) so I won't be able to get this together right away.
Are you using the devel branch? You should be able to dump any other changes you were working on into a new branch. Otherwise post your errors so everyone can see and maybe help.
@datahead8888 I don't have any non-committed changes. In fact, I didn't have a checkout. It's building the new checkout that's not working, and that's because my local copy of CEGUI isn't working. I'll get it figured out (as I've done before) but I need to dedicate more time to this task than I initially expected.
Got TSC development environment working again and am installing Inkscape.
EDIT: Environment broke when I switched from release-2.0.0 to devel because CEGUI's download is a 404. I'll have to fix that before I move on.
EDIT: Appeared to be a problem with parallel make. We're back on track.
I need a bit of help now. I've got everything ready, but I don't know the policy for how to update graphics. Should I simply overwrite kplant/kplant_head with the new graphics? Should I add these new graphics and delete the old ones, while sed
ing the level files? Should I add an alias to the source code so that old levels files don't need editing?
Luiji Maryo notifications@github.com writes:
I need a bit of help now. I've got everything ready, but I don't know the policy for how to update graphics. Should I simply overwrite kplant/kplant_head with the new graphics? Should I add these new graphics and delete the old ones, while
sed
ing the level files? Should I add an alias to the source code so that old levels files don't need editing?
There isn’t really a policy in this regard, we have done both in the past (turtle graphics for example were overwritten, the moon graphic was deleted and cookie got a new file name). I think that if a graphic isn’t just an improved version of something (with more detail or so), it should receive its own new filename and compatibility code should be added.
Ladders aren’t plants, so overwriting seems a little weird. I suggest to delete the old kplant images, add the new ladders under an appropriate filename, sed(1) the level files, and add compatibility code in level_loader.cpp.
Compare also #77. That issue should actually be closed, seems like @brianvanderburg2 forgot to close it.
Vale, Quintus
Ladders aren’t plants, so overwriting seems a little weird. I suggest to delete the old kplant images, add the new ladders under an appropriate filename, sed(1) the level files, and add compatibility code in level_loader.cpp.
Don't forget to make the old static vines show up as jungle vines as we discussed above. This is a little bit long of a discussion to read through, so I just thought I'd put out a reminder. Ladders would be for boxes then.
Compare also #77. That issue should actually be closed, seems like @brianvanderburg2 forgot to close it.
That issue is not done. We are still waiting until Bugsbane gets a chance to redo the turtle boss graphics.
That issue is not done. We are still waiting until Bugsbane gets a chance to redo the turtle boss graphics.
My bad. That was the wrong issue, I meant issue #60, and it should be closed.
Vale, Quintus
Agh, something came up and then I forgot about this. I should really get that old GNOME sticky notes program up again. Wasn't it called something like Tomboy or something weird? (Looked it up, it's indeed called Tomboy.)
Anyway, I'll get back onto this.
I made it so that the ladder head is climbable instead of passive because it works better in that context. Whereas the vine head is a flower, the ladder head is more ladder, just with a cap.
All that should be left is going through levels and seeing which instances of vine we want to replace with ladder, since @datahead8888 indicated that we're leaving vines for some instances, just not boxes.
How about if we just assume for now that any vine not coming out of a box uses the jungle vine images (as it's a vine already), and if we want to change things to a ladder later, we can. This would just let us pretty quickly close this issue and be rid of the Mario-like vine.
The jungle vines have other dimensions, they’re a little larger. This might cause graphical glitches in situations where the vines have been placed exactly on an edge.
Vale, Quintus
This might cause graphical glitches in situations where the vines have been placed exactly on an edge.
If we can get a list of levels where the vine tile has been used, I can go through and check if any levels do this.
If we can get a list of levels where the vine tile has been used, I can go through and check if any levels do this.
Here you go. Beware that some levels might just use the vine’s head tile as a decoration flower.
% grep -lr 'green_1/kplant' *
david_1.tsclvl
dj_kirby_1.tsclvl
flan.tsclvl
ita_2.tsclvl
jungle_1.tsclvl
keywest_1.tsclvl
lvl_10.tsclvl
lvl_2.tsclvl
lvl_4.tsclvl
lvl_5.tsclvl
lvl_6.tsclvl
lvl_7.tsclvl
mountain_trials.tsclvl
night_sky.tsclvl
pasol_1.tsclvl
quintus_3.tsclvl
sauer2_12.tsclvl
sauer2_5.tsclvl
sauer2_7.tsclvl
scaley.tsclvl
stephan_1.tsclvl
stephan_2.tsclvl
stephan_4_1.tsclvl
stephane_1.tsclvl
undergroundsurprise.tsclvl
wn_01.tsclvl
yuki2000.tsclvl
Vale, Quintus
Currently we have vines that grow out of boxes when you hit them with your head. As @sauer2, pointed out, this is a clear Mario-ism.
Here are some options:
We could also look at mechanics changes in version 3.0 if desired.