Pressing down in mid-air should make you aim down first. 
An instant vertical stop basically is how it was done. Itās kind of impossible to decide your jump height after you start jumping in the real world, so thatās how itās gotta be.
Aye to the first statement.
As for the second, well of course notā¦ But in most games you can - even if you canāt control direction post-jump, you can usually control height, so long as you havenāt reached the top of the possible jump height. You smooth it out by applying more downward acceleration after spacebar is released, but once the vspeed >= 0, you change it back to normal downward acceleration. That, or you decrease downward acceleration of a jump while spacebar is held until the top of the jump has been reached, or spacebar is released, which is pretty much the same concept, just executed slightly differently in code. Iām pretty sure that the games that do allow you to decide your stopping point mid-jump utilize something like this, and donāt just make the player halt all upward speed as soon as the jump button is released.
I think you should play Metroid and Metroid 2 and Super Metroid and Metroid Fusion and Metroid Zero Mission more.
Iām not 100% certain that they stop absolutely immediately, but it sure looks to me like they do. If not, they decelerate very fast.
No, seriously. I just went and loaded up every one of them just to check, just for you.
>_>ā¦ I guess this is sad then, because I have fully played and thoroughly enjoyed SM, MF, and MZM, and have probably gotten to about 70-80% through Metroid 2. Metroid 2ās physics were just plain altogether awkward, though - Iām pretty sure we can all agree on thatā¦
Anyway, I suppose I was speaking in generalities of 2D platforming games, then. Sorry for the mistake! To be honest, I play 2D Megaman games (of the like 30) more often than I play 2D Metroid games (of the like 5, minus fan games), and just for that reason - Though a game may be great, I usually donāt come back to it until maybe a year or two after the first time I beat it (unless afterward I find out about something I never saw before). So due to the sheer quantity of sidescrolling Megaman games, Iām more familiar with them xP. Blah blah, blahh this doesnāt matter okay yes.
Well caught on that first point, Iāve fixed it.
I should have noted, but in the source there is a difference between jumping and pressing up. I had to assign an up key to fulfill the goal as required (jumping goes to standing, up goes to ducking). You can use the enter key to press up, and that should go to ducking.
So, I have the latest build I worked on here, so you guys can grab it. Thatās the source.
Iām having trouble with this rolling down the slopes thing. I have a hack-ish setup that works kind of well, but it has a lot of bugs. Hereās my hack code:
Note this goes in the code for the āis there a slope beneath samusā part in the free_movement script:
MVAMT = 1
if (m_morphball == 1) {
tempHold = m_array_slope_angles[1];
if (tempHold != 0) {
x -= (tempHold / abs(tempHold)) * (MVAMT);
while (check_collision(obj_samus, obj_block_parent,LEFT)) {
x += 1;
}
}
}There are tons of issues with this set up. Firstly, you zoom off of the top of slopes when you go from the left to the right or vice versa. Secondly, if you are holding left and hit a wall on a wall, you hover a bit off the actual slope so when you let go you fall a little bit. Thirdly, in any sort of angle-angle situation that is weird, Samus will get stuck and endlessly bounce around. Itās possible to get out, but it doesnāt look great.
I donāt see the need for complex angle systems. Tim and I were talking a few days ago about simplifying the slope engine as I donāt think custom angles are all that necessary. As long as there are some core angles, most shapes necessary can be made. After all, SM didnāt have all that many and it works great.
What do you guys think? Is anyone actually here, or are they just reading? It feels like Iām the only person working on this right now.
Iāve discovered in my time working on physics engines that having one non-right-angle is just as bad as having infinity. Basically, fixing all the bugs involves some hackish code too.
How would approach this problem? Have you looked at the code any, and if so, would you suggest an overhaul? The system as it is now is pretty cool for allowing freeform, but freeform is nightmarish to deal with and DestroyerF seems to have dropped off the face of the planet.
I approach the problem with tears in my eyes, personally. I havenāt looked at the code.
Guy Perfect always suggests rotating everything about a point (basically making the terrain in question horizontal while dealing with the collisions) to start with, but I doubt youāre going to be doing that in GameMaker. I really canāt think of any suggestions that would apply no matter how you have it coded.
O.o Thats a lot of nerdness to fit in one topic people. Iām no coder, but as to the change directions in mid air, it wasnāt able to be done in Prime, unless you were holding lock on. then it would change the instant you told her to go into another direction(in the 2D games, she changed instantly, though she seemed to loose all upwards lift). Also, for the space jump, is it going to be an infinite jump mechanic? because that could help with space constraints. Just a thought. It would also explain the HUGE jump she takes at the start of the gameā¦
Edit: When Samus un-morphs, she is crouched. Thats the way it is in all of the (2D)games. Also she does aim down before she morphs while in mid air. You have to double tap down. Man Iām thinking of a zillion things. Whatās going to happen to lock on, and homing missiles? I know that these are a bunch of questions, but everything has to be answered sooner or later does it not? Also, will power grip be a mechanic? I donāt know if thats a good idea, but it went over well in Fusion and ZM. Just a though. And now I leave you to your coding.
Itās good that youāre talking about stuff like this. We need to stimulate development more.
I think that before we move forward with development, we should work on a new system for developing. Not everyone can code, but everyone can describe how things in the game work. So, letās say weāre talking about ducking/morphball:
When on the ground, and down is pressed, crouch first, then morph if down is pressed again.
When in the air, and down is pressed, aim down first, the morph is down is pressed again.
If crouched, and up is pressed, stand. If crouched and jump is pressed, jump into the air.
If morphed and up is pressed, crouch. If morphed and jump is pressed, more to stand.
If the morphball is on a slope, tend to make the ball roll down the slope.
This describes the functionality of the morphball and it was done with just observations.
From there, people that can code can implement the system and bug fix and all that good stuff, and then put the version up and have people test it, etc.
We can work together to finalize the innerworkings of systems, then the coders can get to work on making it happen.
How does that sound? I think it would allow for more people to get involved. As for the coders, I think anyone can be a coder. If you have GM6, thereās no reason to not grab the source and mess around with it! This project is going to die without community involvement.
So, with morphball, the big issue now seems to be that rolling down the slopes is weird to implement. I have a setup now, but it isnāt ideal. Iām going to do some more work on that system and then post up some final code, but the current WIP is the one I linked to earlier.
One thing I just though ofā¦ Speed needs to be affected by a few things. Water, Lava, Slopes(the greater, the slower)and those plants that slow you down. Also, boost needs to be taken into account with acceleration. That and those half pipe fixtures. And what about spider ball? wow. Iām not bringing good news to the table am I? Iāll keep thinkingā¦
Edit: ( man oh man do I hate editing this stuff) Speed also needs to be INCREASED due to enemy contact, and downhill slopes. whenever Samus gets hit, she recoils in the opposite direction for a bit. I donāt know if this is helping. Tell me to shut up if you want me to. Also, Iām working on the music for Thardus if thatās helpful at all?
Funny enough, I donāt think the speed decreased when Samus went uphill, or increased when she went downhill, in the 2D Metroid games. Well, technically, I think her speed increased in both cases by 41%. (Want the math? sqrt(1^2 + 1^2) = sqrt(2), since the horizontal speed didnāt change on the slopes, assuming my memory is treating me as well this time as it usually does.)
Of course she recoiled when hurt, but her current speed never mattered in thatāher speed was set to an exact, predetermined amount.
But this engine obviously doesnāt have to be exactly like the other 2D Metroid games.
Edit: Okay, Super Metroid acts how I said, but Zero Mission actually does slow you down when going uphill.
Hmm, I think your right, but the speed had to have changed, because she progresses along the screen at the same rate, therefore her speed is increased (just figured this out) relatively, so that it seems that she moves at the same pace, because when you go up a hill that covers the same length of ground as a flat plane, because if you timed the time it took to go along the flat plane, then ran across the uphill slope for the same time, as the same speed, you wouldnāt go the same horizontal distance. Youād go the same total distance, but horizontal is what counts in something thats 2 dimensions. Am I making any sense to you guys at all?
Your wording was a bit strange, especially with those two "because"s in there!
Further clarification just in case!
Yes, the thing in Super Metroid was that you moved at the same horizontal rate no matter what, which is why I said that her speed increased by 41% (unchanged horizontal speed + 45-degree slope + Pythagorean theorem) when going up or down a slope. In Zero Mission, however, I could clearly tell that going down a slope was faster than going up a slope, but I didnāt pay as much attention to measuring whether either was faster/slower than going across a flat area. If they paid that much attention, though, they probably did all of it the right way.
Heh, yeah I totally just noticed those! And itās true, in ZM you go up hills slower. Somewhere around the 41% if thatās easy enough to believe.(Iām not just saying that) Well, the only other thing that I can think of that I havenāt said before that affect morph ball acceleration, are morph ball bombs. And I think thatās all covered.
So, I was making a list of significant physics details as a precursor to attempting once again to make a physics engine.
Can move in any direction
Can have terrain of any angle (but not in official 2D Metroids)
Must have rigid objects
Rotate everything in any calculation so that the terrain is horizontal and, thus, easy to deal with
Can exit terrain, but not enter it (may speed up processing, simplify jumping, cancel out glitches, etc.)
When loading, touching tiles are linkedāif there is a diagonal next to a square, the lines separating them will be gone
Going downhill must keep an object attached to the terrain, unless it tries to jump
Trying to go between two diagonals should not force an object in or out or make it bounceāit should just stop
When a tile is destroyed, recalculate neighbors to see if they need more collision lines
All collision lines must have a parent object/tile ID
Attempting to resize an object makes it move in that direction, in a sense, for collision detectionās sake
Power Grip could be done with an invisible one-point object āin front ofā a falling object
What the object is sitting on is generally hard to detectābut in Power Gripās case, itās easy
Wall-jumping would be like Power Grip, except that imaginary object is shoved away from a few points on the object.
Collisions are detected by projecting a vector from each point (corner) of an object, and then projecting vectors from each point of terrain in the opposite direction of the objectās movement, but the same magnitude
When jumping, Samus moves up at a constant rate until either she approaches her maximum jump height or the player releases the jump button. In the latter case, she stops rising immediately.
Sound about right?
Sorry for lack of activity, this week has been particularly argh in terms of time to do anything.
Reading your post, it sounds interesting. Iām not sure how well attaching an object to the terrain will work unless it is designed to break out easily. That is, it sounds like you will have to implement a check to see if the ground is gone (in order to let the person fall off of the side of the bottom), which is a bit of extra code (not difficult, but extra) that is automatically handled by a system that just keeps her down.
I like the idea of using vectors, though, in order to determine where to move Samus. It would work well.
As for the current engine, I havenāt been able to open it this week, hopefully I can do a little bit today/tomorrow (probably tomorrow), but I donāt really know what weāre going to be doing next. No one really jumped at my idea of describing how things work so the coders can code, so I guess Iāll just have to design out whateverās next.
āAttaching to the terrainā basically meant that an objectās motion would be forced to match the angle of the terrain if it otherwise would make the object go into (ie. touch) it. It works with this factor pretty well:
āCan exit terrain, but not enter it (may speed up processing, simplify jumping, cancel out glitches, etc.)ā
ā¦as shown by my previous attempt at a physics engine (there are several bugs, one or two of which I could fix very easily) here:
http://dpmm.110mb.com/temp/28th.zip
(Being able to impale the box on a line is not a bug; I simply didnāt code the feature that would prevent it because I knew itād work correctly when implemented. This feature was ārotate the motion vector 180 degrees and project it from the endpoints of nearby terrain, checking with collisions for the sides of the object.ā The other bugs: It sticks to nigh-vertical walls, which I didnāt try to fix; it goes one step too far when climbing a line, as seen when crossing from the cyan one to the green one; and it climbs walls a bit.)
So what is going onā¦ any progress? on anything?