P2d open source engine

A.) Ah, okay. Makes sense.
B.) Would “numStandingSprites” be an acceptable renaming of “spr_array_standing_length”, with similar changes for the related variables? The “standing_length” part of it is unclear.
C.) Okay. I’m used to importing the whole sheet and using frame coordinates, but either way works. I seriously hope we don’t do this for many other objects, though; it’s absolutely necessary that we use encrypted external resources with room-based management, or we’ll never get a full game working. Speaking of rooms… We’re going to be horribly stuck once we have more than one. Should we build a state-remembering system for certain objects like Samus before continuing?
D.) Yeah. Actually, none of the in-game objects would even allow that (including Samus) if we’re going to include visors and other effects. I’m assuming we’re going to include visors, right? :stuck_out_tongue:
E.) Does Game Maker reset those every time a new room is loaded, or could that be made one-time-only when Samus is first loaded? After all, that code would be done at the start of every room, for every Samus sprite.
F.) Yay.

Also, I was wondering if we planned on having any in-engine cutscenes. As in, Samus freezes and the camera pans to show something happening. If so, we need to keep that in mind in the horizontal movement function (which could be simplified a ton, by the way).

Space/Moonjump done…
http://timaster.googlepages.com/mp2d_open_engine_v002.gm6

Some of the numbers need to be played with, definitely, but all the code is there.
Neat features:
You can’t space-jump at all if you’re falling faster than a certain speed.
Your jump speed is added to your old speed, instead of replacing it.

And yes, I suck at commenting. I’ll add some later.

EDIT: Oh yeah, here’s the .exe. http://timaster.googlepages.com/mp2d_open_engine_v002.exe

I take it the jump height isn’t final, because we’ll be running into problems every room on the environment building side of things if a single jump can clear five tiles.

That aside, …nifty. :slight_smile:

A.) Samus shouldn’t be able to space jump after moving off a ledge.
B.) Not sure if I like the sudden jolt after releasing the jump key.
C.) Ghetto jump? Yes? No?
D.) There are sometimes random super-boosts of speed. I believe this is because it’s possible to both press and release the jump key in the same frame. Apparently the yspeed increase takes priority over the yspeed halt.
E.) Executing the above (part D) can launch you through ceilings if timed right. Yes, I just got into the SW.
F.) Because Samus performs miniature hops while running down ramps, it is possible to get a space jump on the first key press. If part A were fixed, this would mean no jump at all.

I’ll, um, work on… engine-related stuff. <_< >_>

A.) I hate you.
B.) I hate you.
C.) I hate you.
D.) I hate you.
E.) I hate you.
F.) I hate you.

>:[

But actually, I added A on purpose. I thought that’s how it was in Prime…? I haven’t played in like 3 years though. I should go do that today, after I’m done reveling and being so full that I have pilov squirting out my throat.
I can fix that easily enough though.
And uh… well I’ll continue the list. Forreal.
B.) I don’t either. But I think the jump will be slower in the final version, which will make it negligible.
C.) N…no? Should there be? >.>
D.) You are quite a smart person. I think prioritizing the halt over the increase should be good enough to fix that though.
E.) !
F.) I think our ramp physics need work then.

Where’d everyone go…? D:

EDIT: http://timaster.googlepages.com/mp2d_open_engine_v002.gm6
http://timaster.googlepages.com/mp2d_open_engine_v002.exe

Fixed A and D (and thus E).

Still too high.

I’m all for adding a slight ghetto effect for jumping against slanted surfaces; don’t know about everyone else.

I don’t want to play with numbers yet. I think our next step should be fixing slope physics up a bit more, and then we’ll take a break to get all of the numbers right… jump speed, sizes of various objects, gravity, whatever.

After I finish this ducking/morph ball bit, I mean.

Nice to see some work is getting done :slight_smile:
I’ll have a close look at the engine and code this weekend, got zero energy right now…

Heh, I’ve been trying to post this for a while now and always get too busy.

I would really like to work on this engine, even though I’m unable to be on here often. So, while in isolation from the rest of the team, I’ve been sequence-breaking a little: I made an external resource manager.

I don’t know if you want to stick it in the engine now, or wait until it would be assigned… But I do plan on making more. Sorry if this is a little troublesome, but I am trying my best to design them to be high-quality, easy to use, and able to be incorporated into any sort of engine.

In other news, I figured out how to compile DLLs with my C++ compiler and how to use them with Game Maker. Soooo… that opens up an enormous amount of possibilities. OpenAL for sound, anyone? We could also get around slowdown issues by sticking the offending features into a DLL, which would be much faster than GM’s script interpreter.

And, as a final sort of P.S. note, I recommend sticking all rendering code into the draw event, and all non-rendering code in other events, because it’s possible to add a frameskip to GM if it’s organized that way. Because the draw event is not guaranteed to be called every frame, even something like an animation update should not be in the draw event (like anim+=1), or else when a rendering pass is skipped, the animation will slow down or animate unexpectedly while the rest of the game runs at normal speed.

damn, troid, you’re a smart :astonished:

All I Got To Say Is Cool…<.<

What compiler do you use, curiously?

Well, I got the DLLs to work with Dev-C++, but I typically find myself switching between that and Code::Blocks, which I sometimes set to use the VC++ compiler.

It shouldn’t matter, though, as long as the code is adjusted for GM 6.1. (All reals are doubles, no more than 11 arguments in one function, no strings allowed if there are more than four arguments)

I was just able to get the code, and I’ve been looking at it. It seems a bit hard to follow and daunting to look at, even though the theory behind it is relatively simple. I think it would be good if the code were restructured so that it was easier to use.

For example, collision checking.

Here are the various collision checks:

//Right wall
collision_line(bbox_right+m_hspeed,bbox_top,bbox_right+m_hspeed,bbox_bottom,obj_block_parent,true,true)
//Left wall
collision_line(bbox_left+m_hspeed,bbox_top,bbox_left+m_hspeed,bbox_bottom,obj_block_parent,true,true)
//Ceiling
collision_line(bbox_left+m_hspeed,bbox_top-1,bbox_right+m_hspeed,bbox_top-1,obj_block_parent,true,true)
//Floor
collision_line(bbox_left,bbox_bottom+m_vspeed+1,bbox_right,bbox_bottom+m_vspeed+1,obj_block_parent,true,true)

Now, I don’t see anything wrong with these per se, but it seems like they can be combined into a function that can be more easily managed:

//Collision detection rough design (non-slope)
//Precondition: Object's X and Y coordinates exist on the map, and the object
//to check for a collision with is on the map. As well, the first object has a known
//bounding box and horizontal movement of some sort.
//Postcondition: If a collision would occur, a true will return, else false

//Argument 0: First object's ID, so the bounding box can be determined.
//Argument 1: Second object's ID, for the same reason.
//Argument 2: Which side to check on (0, 1, 2, 3 for top, right, bottom, left respectively)

obj1 = argument0;
obj2 = argument1;
sideToCheck = argument2;

collision = false;

switch (sideToCheck)
{

 &nbsp; &nbsp;case 0: //Top case, so the top of the object collision code goes here

 &nbsp; &nbsp; &nbsp; &nbsp;if (collision_line(obj1.bbox_left, obj1.bbox_top + obj1.m_vspeed + 1, obj1.bbox_right, obj1.bbox_top + obj1.m_vspeed + 1, obj2, true, true)) {
 &nbsp; &nbsp;
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;collision = true;
 &nbsp; &nbsp; &nbsp; &nbsp;
 &nbsp; &nbsp; &nbsp; &nbsp;}
 &nbsp; &nbsp;
 &nbsp; &nbsp; &nbsp; &nbsp;break;
 &nbsp; &nbsp; &nbsp; &nbsp;
 &nbsp; &nbsp;case 1: //Right case, so the right side of the object collision code goes here
 &nbsp; &nbsp;
 &nbsp; &nbsp; &nbsp; &nbsp;if (collision_line(obj1.bbox_right + obj1.m_hspeed, obj1.bbox_top, obj1.bbox_right + obj1.m_hspeed, obj1.bbox_bottom, obj2, true, true)) {
 &nbsp; &nbsp; &nbsp; &nbsp;
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;collision = true;
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
 &nbsp; &nbsp; &nbsp; &nbsp;}
 &nbsp; &nbsp; &nbsp; &nbsp;
 &nbsp; &nbsp; &nbsp; &nbsp;break;
 &nbsp; &nbsp; &nbsp; &nbsp;
 &nbsp; &nbsp;case 2: //Bottom case, so the bottom of the object collision code goes here
 &nbsp; &nbsp;
 &nbsp; &nbsp; &nbsp; &nbsp;if (collision_line(obj1.bbox_left, obj1.bbox_bottom + obj1.m_vspeed + 1, obj1.bbox_right, obj1.bbox_bottom + obj1.m_vspeed + 1,obj2, true, true)) {
 &nbsp; &nbsp; &nbsp; &nbsp;
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;collision = true;
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
 &nbsp; &nbsp; &nbsp; &nbsp;}
 &nbsp; &nbsp; &nbsp; &nbsp;
 &nbsp; &nbsp; &nbsp; &nbsp;break;
 &nbsp; &nbsp; &nbsp; &nbsp;
 &nbsp; &nbsp;case 3: //Left case, so the left of the object collision code goes here
 &nbsp; &nbsp;
 &nbsp; &nbsp; &nbsp; &nbsp;if (collision_line(obj1.bbox_left + obj1.m_hspeed, obj1.bbox_top, obj1.bbox_left + obj1.m_hspeed, obj1.bbox_bottom, obj2, true, true)) {
 &nbsp; &nbsp; &nbsp; &nbsp;
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;collision = true;
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
 &nbsp; &nbsp; &nbsp; &nbsp;}
 &nbsp; &nbsp; &nbsp; &nbsp;
 &nbsp; &nbsp; &nbsp; &nbsp;break;

}

return collision;

When I implemented this, it worked fine, using function calls such as (note I was just testing this theory, thus the name test_theory):

test_theory(obj_samus, obj_block_parent, 0)
test_theory(obj_samus, obj_block_parent, 1)

It should be theoretically possible to use this basic code for any two objects colliding provided they have the variables required. It would even be possible to define constants to TOP, RIGHT, LEFT, and DOWN to make the third parameter in entry something like

test_theory(obj_samus, obj_block_parent, LEFT)

Any thoughts? I was just bored and wanting to try and help in any way, and when I tried to use the code I was a bit waggledehooed, so I figured eh, maybe this would be helpful.

shrug

Alright, I think I have a ducking system mostly complete. The one thing I didn’t do was rolling down the slopes, because I’m not exactly sure where in the free_movement to put it. The slope code is a bit convoluted so I was having trouble finding a good place to put it. Could someone who knows more about that implement it? Else, I’ll just do it, I guess.

Anyway, here’s the source and the exe:

http://web.mst.edu/~mtvn83/MP2D/mp2d_open_engine_v003.gm6
http://web.mst.edu/~mtvn83/MP2D/mp2d_open_engine_v003.exe

Thoughts, comments? One thing I didn’t do (besides the slope stuff) is change the bbox, but I figure that goes in with changing the sprites, which we haven’t done yet. So, yeah.

btw

//Change Sprite subroutine
//Easily change a sprite to another one

//Argument 0: Object to change sprite of
//Argument 1: Sprite to change to

objChange = argument0;
sprChange = argument1;

if (instance_exists(objChange))
 &nbsp; &nbsp;objChange.sprite_index = sprChange;

that is how i would handle the sprite changing.
that way you don’t accidentally change the sprite of a non existent instance as it would be pointless.

… object.sprite_index not bloated enough for you?

When I made that shell I didn’t realize it was just one function that would do that, so thanks for the snide comment.

Anyway, any comments on the ducking system in particular, and any thoughts on how to implement the angle falling of the morphball? I’m not experienced in this stuff, so any input would be nice since it seems to be pretty stagnant.

Alriight well, here are some things you may want to take care of:

  • Unmorphing always puts Samus straight into standing mode. Not sure that this is a huge issue, but it’d be nice to go back to ducking first.
  • If you press left or right while holding down (after ducking), Samus still exits ducking mode. You may want to allow standing up only if down is no longer being held, as it could cause players to perform some unintentional movements, methinks.
  • Samus can “duck” in air. Ruahhhh >(. J/k about the angry face xD but I think that pressing down in air should either do nothing, or make Samus morph. And vice-versa, if the latter case; Samus should morph out if she’s in the air as a morpball and you press up, but…
  • For the above case and morphball-rolling-down-hill-ness… Well, really, I don’t know that you should worry about it just yet :stuck_out_tongue:. I believe that the only request on the most recent list is ducking, so even scripting morphing was a step further than was requested (however, they kind of go hand-in-hand). If you really want to give it a go, you might take a look at DF’s slope detection script, wherever that may be. Also, there are a functions in GM to return the change in x and y necessary to move # amount of “pixels” in DEGREES direction. Check the first section of the GML help :slight_smile:.

Also, to whoever did the space jumping (sorry, too lazy atm to check who it was e.e;), it’s decent - the different space jump height according to where Samus is in her first jump seems to work well, but I don’t know about the spacebar release (of all jumping). True, a player should be able to have control over how high Samus jumps, but I don’t think that an instant vertical stop when the player lets go looks or feels very natural :stuck_out_tongue:. This might just be how it was even before space jumping was added, but it’d be nice if someone tried to make the jump release a little more fluid.