Please watch this video and vote on the poll.
http://www.youtube.com/watch?v=7z0VMeiqwOE
Printable View
Please watch this video and vote on the poll.
http://www.youtube.com/watch?v=7z0VMeiqwOE
Option 1, Vertical Scrolling Enabled.
It was a tough choice based on your goal, but if you ever want to make more than a classic Mario-esque (such as a Mario 3-esque), you'll want vertical scrolling too.
Screen moves upward is a better choice, gives opportunities for vertical style levels, much like DKC2 and DKC3 made popular.
Like I mentioned in the comments of the video, there are some problems with ZC doing collision on the Y axis in any interval other than 16 when it comes to moving the collision. That might change in future builds, I don't know since I don't do the base coding. The X axis however, doesn't have that limitation for some reason (I think..). Another thing is, although I'm sure I can probably hammer it out eventually when I spend more than 5 minutes trying, when Link goes over the 64 mark of the Y coordinates he continues only going towards the top of the screen. Everything needs to be reset back to center of the screen, and that means reassigning all the collision, graphics, etc. to that spot.. Which is all very feasible with the way my scripts are written. I just messed up the math a little when I tried it so everything was 16 pixels off for the collision but the graphics moved only.. Then I got tired and had to call it a night because I got bored.
Although the platforms will only be at 16 block intervals on the Y axis, I don't think that's something the player would really notice that much.
Thanks for your feedback. I'll design some more content based on the Y moving idea in the near future, hopefully.
For now though.. I finally got Starcraft II!
Well, those are very good points, we may not be ready for y-axis side scrolling. Than I would suggest option 2 over option 1 in that case.
I saw vertical scrolling in ZC... I seen a full fledged Z2 and Z3 scrolling script. And I even saw the same person changed ZC's screen perspective and even with that I saw him make a functional raycast script in ZC.
In short: vertical scrolling can be done, I saw it working properly. But maybe I'm misunderstanding the problem at hand. But regardless, at least you have a horizontal scrolling script. Good job on making it work!
Heh. Cool.
I would go with #2 since the engine doesn't handle the first one as easily.
Like I said, I did already do it, I just had the collision misaligned, and gave up for the night because I was tired. It'll be done on the next day I put effort into it. :)Quote:
Originally Posted by Shane
I actually steer towards option 2 also because of the gap between the collision on the Y scrolling. 2 would be good for levels with 'less gravity' and/or a different game altogether or something, but the way that Link moves without the scrolling is actually better, because he can climb up things and is never hindered by the Y axis collision limitation at all.Quote:
Originally Posted by Gleeok
I just got Starcraft II and a controller for my laptop and started accounts on a few other games, so I am actually going to be taking it very slow with ZC for awhile. When I get back into it I'll try to make as much progress as I can and complete some sidescrolling levels and everything.
And about the overhead view Z3 scrolling and everything, I knew that too. :D
My scripts for sidescrolling could be converted to be used for overhead view in a minute or two.. In fact, overhead view is much easier to deal with because there's no movement of Link's Y coordinates when he jumps, and the edge of the screen, all I have to do is deactivate the screen's movement when Link reaches a certain point on the map.
I'm done with the Campaign on Starcraft II so it's back to ZC and multiplayer for awhile.Quote:
Originally Posted by Zim
http://www.youtube.com/watch?v=hD_4gsn4duE
Here's a quick little video of the progress I made today. It shows how the screen centers Link and the level around him when he changes elevation, and the scripts are now set up so that the levels can continue upwards for as long as desired. So some levels will be type 1 with no vertical climbing, others will be going upwards and sideways.
It's still in progress, right? I see the glitchyness when he lands. :P
Did you have to script the enemies too?
I don't suppose this could be used on normal screens, could it?
Ah, fair enough. I like to see vertical scrolling in side scroller games. It allows the world to feel less flat and stuff. =PQuote:
Originally Posted by Zim
It is still a work in progress.. There is a 1 frame delay in the platforms actually going under Links feet it looks like.. but it's no big deal.. I think the YouTube video exaggerates the problem because it seems fine in game-play.Quote:
Originally Posted by Lynker
I did make some enemy scripts that move them along with the screen to compensate for when Link moves.. Although the Y axis adjustment isn't in there yet. Even the items, like a bomb on the floor, appear to stay where they are on the floor and move with the screen when Link moves, which is great.. The only thing there's a problem with there is the minor items like bomb and rupee pickups, etc.. don't have pointers that I can adjust their positions.. yet..
I'll maybe see what I can do about that later on.
Could be used on normal screens? What do you mean by that? Overhead view scrolling? That'd be a piece of cake.. Same deal, but no change for the jumping, just scroll the screen up and down when Link presses up or down..Yeah, that'd be easy. The collision adjustment scripts I wrote would fit for that just fine too, but it might take a little bugfixing because it wasn't exactly the obvious method to get this done.. I had to mess around with some math for awhile before I got it right with the collision and Link being able to grab the sides of the platforms and whatnot.
With the script style I wrote up someone could draw a whole overworld that is one solid screen and never changes screens. It's just the collision that is the tricky part... You (or me, I, or whatever) would have to manually calculate (Or just use the debugger functions I wrote that displays what X,Y coordinates Link is at on the screen or in comparison to the entire map and run around and write down where the collision needs to be) every single place where there is a wall, and where that wall disappears on the X and Y axises. Just explaining that to someone is a lot more complicated than doing it though, because the rest of the scripts I wrote are setup to do the rest automatically once those coordinates are typed in.
I was thinking about this yesterday actually, and decided that soonish I might actually setup a script that does collision detecting of each combo on every screen as they are drawn to the screen and make some sort of interface between that and the collision adjustment functions to have the whole thing happen automatically once so that all I or someone else would have to do is draw the maps with normal combos and the scripts do the rest. It is a plausible thing to accomplish, I have been taking my time with this though because I don't really intend on having my own quest completed for another decade anyway, so I'm taking my time.
Oh my goodness, that sounds SO confusing...too bad it's so hard. I wish I could have it in one of my future quests :miserable:
Well... what if you lock Link's coordinates at the center of the screen and set up 'ghostX' and 'ghostY' coordinates for him that check against combos on individual screens. When the 'ghost' reaches its maximum, it would be set to the minimum and Link would tile-warp to the next screen over.
I've been meaning to play with free-scrolling, and that's how I intended to try it (Since I can't find anybody else's script to use as a launching point).
I don't do it like that exactly.. although it's almost the same thing. Instead of using ghost coordinates for each screen individually, the whole entire thing is mapped out from an x and y axis starting with the bottom left screen and going positively along the grid in that manner as a standard coordinate system would for the entire DMap. What I'm going to do for the overhead portion then for overhead scrolling, since the sideview style is already setup in that fashion, is make a function that checks the screen combo by combo for the collision, and converts that into a coordinate on the entire DMap scale instead of just for the individual screen. That's how the whole thing shifts over and the scripts I made know when to bring in the other screens and collision, is by doing a grid of the whole map instead of screen by screen. So when Link would be on the screen, it'd check for solidity of the combos, and the function grabs the coordinates of that solid combo's border, and prevents Link from moving that direction when his coordinates are beside it, pressing towards.
If you don't have a method of getting this done by a few months from now I will probably be posting the entire script when it's totally done and a little more user-friendly. It doesn't really have all the extra tags for directions yet.. for someone else it'd take some extra analyzing time and stuff to be able to tell what goes where. The final step is having the collision wrote down to the grand scale thing so it all happens automatically by drawing the screens, and doing the thing where the centering Link thing lets go when he's at the bordering screens so there's not a big black space covering half the screen when he reaches the end...Well I guess even that could be changeable for different places to give a difference effect.. One screen could have him be able to walk to the edge when he's at the boarder while another might stay centered but show exterior or overhead graphics to cover the screen whilst staying centered...
Right now I have to write in the coordinates for the platforms or walls... Which was sortof essential for the Mario 1-1 imitation anyway because the blocks disappear or spawn new blocks and all that so I had to make function to alter the collision or whatever.
Anyway, it'll be done soon bro, so you might not have to make your own at all once I get this thing hammered out all the way. It should end up very easy for anyone else to pick up and create with when I'm done.
Although it's not happening in the demo video I made, it is already written into the script to have the function call in any combo, and draw it to the screen when Link gets to the coordinates where it comes in, and would trigger any of the other warps, bomb, secrets, etc. when Link steps on, bombs, or whatever else ZC can do. Since collision seemed to be the main important thing though I didn't think to put that in the demo yet. There's going to be a whole different set of scripts that need to be written at that point though, because the warps will work, but they'll work like ZC does, and warp them to a screen, not necessarily the coordinates needed to be on a certain place in the overworld or sideview map according to this other method because all the coordinates outside of the first bottom left map would be outside the boundaries of 240x160 for Link's X and Y, so a custom combotype that converts the DMap and Screen choices into the other method's X and Y is in order for that. I'll just have to multiply by the amount of screens to the right or upwards by 240 and 160 respectively and have the scripts set everything based on Link being there. So the warps could be used for their original purpose and warp Link to a normal place with one room, or anything else, but to get Link to move onto one of the screens that has scrolling there will need to be a new warp type.
Update on the Overhead Scrolling portion of the maps: The overhead scrolling is done, and setup for 7 layers of graphic displaying goodness. I just need to finish writing up the function that works with the script that isolates where Link is in relation to the lower left corner screen and is for the checks for which other screens to display. As it is right now, the script checks where Link is and draws the screen he is on + all the screens immediately adjacent to it, so that those screens are preloaded before Link travels there every time. Only the bottom 2 rows of screens is done though, and the math is done for the rest of them, because it's the same number for the X of each screen on every row and I did do the 1st screen of every row to get the Ys done, but it's some copy/replacing of some lines of code and applying them to the rest of those screens to finish up the script I didn't get done yesterday. I originally set it up so that it would display the entire map all at once, no layers, and then with the entire map, all the layers, which I knew the latter method would bring some frame rate problems because that's a lot of screen drawing, 144*7 screens at once, so I wrote up this other check to bring that down to 64 screens at once. So now the design is setup for 9 screens at a time with 7 layers. That's 63 screens.
I have not started on the script for checking collision yet. So although the script is done so that it works graphically and could be used for a boss battle or something it's not ready for overworld gameplay yet.
I do know exactly how I'm going to get it done though, so it's only a matter of time and motivation before it's working great.
At this point I feel like I should just make a smaller playable demo of the game elements with some short platforming levels, platform boss, and overhead boss.