P2d open source engine


@PY: Yeah, but only for GM7 :stuck_out_tongue:.

@DF: Alright then, next goal it is. SM sprites will be a cinch to get.

As for the script, yeah I got it now :stuck_out_tongue:. I was being a tad blind, my apologies x). Just missed that it checks from the starting x and always progresses right.

When do you plan to have us work directionality into the code? I know it’s not extremely necessary until we work the arm cannon in, but just curious.


I had one on my old computer, and if I had known the computer would explode, I would have saved it to my flash drive. But I didn’t.

And all the ones I find don’t work. That is, I can run the Pro editor, but not actually run programs in GM7 Pro (I can just convert them to GM6, FYI).


If you know your e-mail address you used to sign up at least, contact softwrap, and they’ll get you your key back/have it reactivated. I couldn’t active GM7 when my last computer died, but hey, here it is, working again.

And when it comes to downward motion physics, sometimes all you really need is a “global.grav” variable that you set. Or just setting gravity for the character. Unless there’s more to it than that. :stuck_out_tongue:


I think the relativity of how high a space jump takes you might be a little more intricate than letting the gravity take care of it, but I’m not sure. It’d almost be sufficient to make it “m_vspeed -= 20” or whatever the jumping vspeed is, but the problem with that is that, piled immediately on top of an initial jump, that’d boost the jump vpseed to -40. -40 would probably be undesirably fast and/or high.

I could nail the fix down easily while scripting it, but that’s not my part to work on :stuck_out_tongue:.


No, you simply jump with a set vspeed, and lower that vspeed (although I should say raise, since negative vspeed is up) by a certain amount times the max downward vspeed divided by the current downward vspeed.

Let me give an example.

Let’s say we’re moving downward at 3 pixels a second. The most you could move downward is 6 pixels per second. You try to space jump. You would normally jump at 6 pixels per second if you weren’t going downward, but you are going downward. However, you have to jump at least 4 pixels per second. So, you take three divided by six, multiply it by two, and then subtract it from the overall six pixels per second. Then, you achieve makeshift physics. =P

Of course, I still don’t have pro, and I’m not going to buy it again. Maybe I’ll see if I can get this to work in lite.

EDIT: sprite_set_bbox_mode() and sprite_set_bbox()?
Is this really necessary? I mean, you could just do it in the sprite editor, it’s in the create event, and it’s the only Pro-only function in here. Seriously. Is it okay if I modify this?


Getting pro again would be worth it, if you’re going to help us on this. We may be able to do without pro-only functions now, but it will eventually be inevitable. Nearly all drawing commands that utilize alpha values are pro-only, and we’ll definitely need those for HUD effects, glows from machinery, projectiles, fire, and etc.


But all of those alpha functions work in ENIGMA right now, and I have that. =D

Although the bbox function isn’t. I’ll probably re-get pro, though.

But for now, I don’t have it.


i can supply the pro version <_<
i have the uhm… application on my laptop


is it bad that i have to use a loader in order to use a program that i paid for? because I have to use use a loader for GM7 <.< ANY way has anyone really worked on this? I’m working on it but i have no idea whats been done. Don’t want to do something some else has done as it accomplishes nothing.


So, this engine seems frozen at the moment. Perhaps this is because all of the management responsibility and pressure to keep it going remains on one person, which is sort of the opposite of what was intended. May I propose some radical changes to the development process?


I say go for it.


if you took it to a bigger forum it would get more done


What do you have in mind?



I apologize in advance for the long, example-full description that follows.

Things will go much faster if different people work on different things at the same time. So while one person might work on particle effects, another could work on the thermal visor, and yet another might start making some creatures. Then we attach these pieces together in one place and enjoy.

Of course, that would never work out on its own. Attempting to multitask as a team now would only end in a complicated mess, especially in Game Maker: creature and particle graphics would constantly have to be changed according to updates from the thermal visor person, mixing the thermal visor code in with the rest of the engine, and adding the X-ray visor later would take weeks of headaches, tangling the code further, not to mention that new programmers would have to be educated on visors and particles before making a single platform, and updating visor effects may be too much work at this point.

But situations like that can be avoided, if we plan out how each piece of the engine will be as independent as possible from other pieces.

My approach would be to first build the connections between pieces before building the pieces themselves. This is a little difficult to explain, but I’ll try.

Say we’re looking at an engine with only visor effects and creatures walking around. For the sake of this example, the pieces in this case are visors and creatures. The creatures are connected to the visor effects because their graphics will change with the visors. The visor code should not have to know anything about specific creatures or their code (therefore allowing for creatures to be created and updated later), and likewise the creatures’ code should not have to worry about how the visors operate (therefore allowing for changes in visor effects, and what they can be extended to). This can be done by building the connection between them: the functions for displaying sprites. All creatures simply would be required to display their graphics through customized engine functions, and these functions include the visor code (and probably also lighting code and such). It is impossible for these two pieces to be truly independent–after all, creatures should have heat signatures for the thermal visor–but a few values to report and specific functions to call would not tangle the engine, because they would likely not have to change with code updates.

So after creating a dummy creature that doesn’t do anything and a dummy visor effect that doesn’t do anything, connected by a few customized graphics functions, two different people can work on the two pieces simultaneously without a problem, assuming the connection has been built perfectly.

However, that’s another issue: if the connection wasn’t built perfectly, the two would have to communicate on how to fix it. CreaturePerson might have to explain to VisorPerson that there is no way to draw a rotated sprite using the engine functions, and so they would have to get that part of the connection built. Later, VisorPerson would have to explain that the required arguments for the scaled sprite function need to be changed in order for visors to work, and then CreaturePerson would have to search through all of their code to change all of the calls to that function. This is wasted time that could have been avoided had the connection been better to begin with. However, changes in connections are pretty much guaranteed, so the best we can do is limit them by planning ahead.

So, in summary, this is what I’ve said so far:

  • Engine progress will be much greater if people can work independently at the same time as others.
  • Code is easy to tangle, so careful planning would be needed to keep pieces connected but independent.
  • Connections should be built before the pieces.
  • As the pieces are built, connections may need to be updated. Connections should be high-quality to begin with to limit this.

So, that is my idea. Was that too vague? :neutral_face:
(I’m already aware that it was far too long)

So, basically what we have to do first is map out all of the engine “pieces” and how they’re connected, in terms of code and design and such. Then we work out how to connect them in a way that leaves them very independent from other pieces. After building the connections, more than one piece can be worked on at the same time.

A “piece” is defined as an engine feature, by the way. Examples include the HUD, physical objects, visors, physics/collision, resource management, rooms, sound effects, cutscenes, menu screens, etc.

So all pieces must be considered when making the core bone structure of connections. We can’t just assume that we’ll figure out a way to get certain objects to freeze during cutscenes while others still animate and others yet can still move, for example. We would have to build the connection between objects and cutscenes first–probably by setting up a few functions that objects can use to check if they can move or animate or not, and a few functions that cutscenes can use to freeze these certain objects.

It’s going to be difficult to map this all out, but once the blueprint is made, people can easily grab a piece and go with it.


If I may, I’d like to do shooting+weapon switching. I happen to be VERY good at programming weapons, as seen in FSMR.


I understand what you’re trying to do, but isn’t this to much to organise? Making a blueprint for the whole engine isn’t something that you can do in 5 minutes. This would take weeks, if not months to get it completely right.

But you’re right, this is the correct way to work. Actually, it’s a lot like we handle projects at my work:

  • start with an idea, brainstorm
  • make an analasys (or blueprint, how you call it)
  • review analasys, adjust where needed
  • give assignments to different people, start coding
  • review coding, adjust where needed
  • merge all bits of code into one new version
  • testphase, find as many bugs as possible
  • release

So I agree with the workflow you have in mind, but not with the scope. Making a blueprint for the whole game is to much to do, you can’t organise this on an internet forum. You gotta split it up into pieces, and complete one piece at the time.

That’s how I was planning this engine:
1: samus engine

  • movement & collisions
  • jumping & ducking
  • morph ball
  • shooting
  • health & death system
  • all kinds of upgrades

2: world and environment engine

  • samus view
  • room warp system
  • door objects & room transitions

… and so on.

If you make a blueprint for each piece at the time, it will be much easier to make progress.

@ Octohunter, shooting is one of the next assignments, so keep checking this topic regulary. Don’t start on it right now, the current assignments must be completed first.


…Crouching and Morphball next?


EDIT-If you add new sprites, I suggest giving each form of the sprite a global variable, kinda like this.


And this.


This way, the global variables correspond to different suit states. It makes it easier to change the sprites.


Hmm. So, like the method I mentioned, but on smaller chunks…

Alright, I’m fine with that. But still leaves all the responsibility on you, DF, to constantly provide us with the next steps. If you’re really up to it, that’s not a problem, but it looks like it’s going to be a non-stop duty for at least the next year.

I still think it would be within our reach to create the core structure of the entire engine to start with, but sections at a time could also work. They would have to be well-planned sections, though. I’m not sure if beginning with Samus is the best course, but I guess that’s just my opinion.


Alright, so I looked through what we have so far in an attempt to add the latest goals, and… I’m totally out of the loop. X_x

So, I want to make sure I understand how it works so far. Sorry if these questions have been answered a million times throughout the topic… I haven’t really looked.

A.) What kinds of variables are we starting with “m_”? Will this apply to future objects?
B.) The “spr_array_standing_length” and similar variables–are these for how many sprites are stored in the arrays of each state’s sprites?
C.) Will every Samus pose be in a separate sprite? Are these separate sprites going to be animations, or individual frames? Will this apply to other objects?
D.) Samus is being drawn automatically by GM–will other in-game objects be like this?
E.) Every standing sprite gets its bounding box set to the same size when Samus is created, right?
F.) While Samus is floating, “m_gravity” is “m_env_gravity”. While she is on the ground, “m_gravity” is 0. Is that correct?



A.) M for member variable. They’re variables specific to the object. For instance, m_gravity describes Samus’ specific y acceleration, and not the gravity of the world. m_env_gravity is the (right now) constant describing the acceleration in free fall. It’ll change depending on whether Samus is underwater, in space, or whatever. The reason m_env_gravity is a member variable is because 1) some objects will fall slower than others, so their m_env_gravity will have to be lower 2) objects can be in different environments at the same time. So m_env_gravity will be based on the global constant of gravity (1, I think, for now.), but won’t always be the same. Actually I kind of made half of that up. But that’s how I envision it working. If m_env_gravity will always be 1, there might not be any reason to make it a member variable and not a define. But eh.
B.) Yes.
C.) Dunno :frowning:
D.) I’d rather not, but I think that’s what we’re doing for now, for simplicity’s sake.
E.) Yeah.
F.) See A :astonished:

PS I’m back from vacation :smiley: Sorry for disappearing without saying anything.