TIGSource Forums

Download: http://mattmakesgames.com/matt/GrandmaEngine.gmk

Hopefully this will help some people out.  It's only v0.910 right now, bit definitely usable and a good foundation.  I'll slowly add stuff to it as I have time.

It's based on the Jumper Three engine, but with all J3-specifics striped out and the remainder heavily commented.  I also included an An Untitled Story-style room system because I've gotten a lot of requests to explain how I did that.

It's free to use for freeware/commercial, I just ask for a mention and link in your readme/credits.

Looks interesting. Was this the engine you started on in flash?

No I just finished my Flash engine, but I'm not confident enough in it to release it publicly since I just started with Flash and haven't even finished a platformer in it yet. 

My Flash engine uses a lot of the same concepts, but there's no real way to "port" a GM engine to Flash (if that's what you meant by this being the Flash engine?).

:handthumbsupL: ;D :handthumbsupR:

This reminds me... I've gotten lots of requests/questions from people regarding room/screen movement. I should take a day or two to write a thorough article on some of the various methods I use as well.

I like your approach script -- very convenient.

Matt, I totally incorporated your engine into what I've been working on, and it works like a dream. If I ever get what I'm working on to a playable level I will of course give you a shout-out.

Right, I've downloaded this and will be giving it a pretty thorough once-over this week or the next.  I'm currently trying to decide on a nice groundwork engine to built on (instead of just trying again to do one from scratch) and this may work great.  The only thing I'd worry about is that I had pretty bad framerate slowdown on my laptop while playing J3 (I don't have my own desktop right now either), so hopefully that's not due to the engine.

This is awesome, Matt.


I tied it on my laptop which slows down with J3, and this runs at 60 fps.

Oh perfect; that's a relief.  :)

Thanks guys - I'm currently sorting out an improvement to the movement engine.

As Chevy kindly pointed out, fractional speeds currently do nothing (ie: something with a constant hspd of 0.4 will never move, because this will get rounded down to zero at every movement step).  This will be fixed in v0.920, and there'll be some other new features as well.

Hey Matt, I think I may have found a little bug.

If you build a slope and jump into it, the vspd doesn't reset to 0. In the engine it gets stuck at -0.30 .

(http://img.photobucket.com/albums/v320/AlienQuark/grandma1.png)


It messes with some of my animations (I've worked around it) but I'd say it could be a little annoying to work around.

If I'm not mistaken, this should fix that.

Go into the player's step-event code and find PLAYER INPUT EVAL...


And add "vspd = 0;" where I put it in there.

Looking at it now, though, I'm wondering why the vspd is doing that... I can clearly see that Matt set it up to call horizontal and vertical wall collisions using the user events 0 and 1, and the vertical one clearly stops the vspd...

I also can't reproduce the bug, and I'd hate to put a redundant vspd = 0; in the step event unless I absolutely have to.  Hmmm... I'll keep searching for it tomorrow.

Easy to reproduce. Just build a long slope, and keep moving right as you jump up it. It doesn't occur in any other situation, so I'm thinking that perhaps it happens when you land on the ground before your vspd is > (-.5) but still < (.5).

(http://properundead.com/random/grandmabug.png)

Here's v0.920!  Same download link.


I couldn't repro the slope bug in this version, but if it's still there let me know.

Great! Thanks for this, I'm trying to understand how it works now. (I'm still learning the ropes)

I just discovered a little quirk.

If you jump (without performing a double jump) into a new room, without letting go of the jump key, the player will double jump by itself shortly after entering. A small bug but deadly if you were making a masocore-type platformer.

Yeah, the slope problem is fixed now. Switching to the counter-based movement must have fixed it :)

Thanks, I'll add that to my list for the next version!

Ok, so if I was working from v.0.910, what would i adjust to make the slope problem gone now? I don't want to go through and re-download if I can just as easily move things around and not worry about renaming variables etc.

Okay, save a backup version of your game, and I'll see if I can walk you through it.


In the step event for all objects that have obj_moveable as a parent, delete this line:
It is no longer needed, because the physics object's events are going to be moved to the Begin-Step and End-Step events, where they will automatically be inherited. Only if the object is already using the Being/End-Step events will you have to add the event_inherited() line to that event's code to make sure that it's performing the code of its parent.


Next, go into obj_moveable. In its creation event, initialize the following variables:


I don't know if you changed obj_moveable at all, but now we are going to break it's step event into the begin-step event and end-step event. So create those events, and in the begin-step, put the following:
And your end-step event will now be this:
Make sure you scroll down to get it all. You'll notice a large comment in there that explains how the counters work.


Now we have to do is go into all moveable objects' step event and rename all instances of the variable pm_d to on_ground. If you go into your code editor, you'll see this button at the top:
(http://properundead.com/random/switch.png)
Click on that, and you can automatically replace all "pm_d" in the code with "on_ground".


Also, this line must be added to the top of all moveable object's creation events:
And the following lines deleted from it:
Because those variable initializations are now handled by obj_moveable, and will be created when event_inherited() is called. Also, pm_d no longer exists.


And that should be it. What this does is makes so you can set your moveable objects with a hspd or vspd that is less than 1, and they will move at that rate. So if your object's speed is .5, it will move 1 pixel every two steps (before, it would have just rounded this to 1 and moved 1 pixel ever step, and anything lower would have rounded to 0 and not moved at all).


Hopefully that all works for you. If this fails, feel free to PM me your GMK to me and I'll fix it up for you.

Thanks Chevy!

Yeah, I should've warned people that the fundamentals of the engine could still change before v1.00.

I made a slight edit, to call event_inherited() in the creation event.

I didn't account for the room tranfer issue that you apparently ran into, as I'm not sure what you changed to fix that.

OK, I've played around with it and I can officially say it makes me proud to be an Albertan.  Yeah Matt!  :handthumbsupL: ;D  :handshakeR:

Also, I realized that you can just draw any solid shape, set the parent to the floor object, and if the slope is never more than 45 degrees the character can walk up it (I'm 100% sure Matt/Chevy know this, but I thought I'd mention it for whoever else might not).

But yes, this is awesome, and I'm already significantly fucking with the character code to turn it into a bird.  (jump=flap wings; slow glide down; walks slowly; etc.)

Fantastic Job. :gentleman:

As can be seen in Feedback, I've begun work on a game using this.
It's basically how I learned the GM coding language, as well. That and rampant decompilation of Games I had lying around. It's fun to get a look at how things tick.

Great job, keep an eye out for my game, and thanks for helping me learn GML, to sum everything up.

I'm really glad this is helping you learn GM!

Coming in the next version:
-A standardized, reusable menu
-Pausing (which uses the above menu as well)
-An alternative player object which will demonstrate how to do ledge grabbing

This would of been extremely useful when I was trying to do the room transitions.
Mines a bit big code wise and has many flaws/bugs. So I hope you don't mind me looking at this for interest sake.
 :panda:

Not at all.  Feel free to steal my code even :gentleman:

I'm worried about managing to apply these updates to my current game. Sounds like it's gonna be annoying. I would like pausing, though.

On the subject of edge grabbing, why not wall jumping? That should be a lot simpler, and it's in all 3 jumpers. in fact, I'm perplexed by why certain things were removed when you changed the J3 engine into this. Mainly springs and wall jumping. those seem pretty useful to me. I've already made springs, but...

Pausing is easy. You can add it to virtually any game without disrupting the current content at all. If you study YMM's code for it, you'll discover that it's easy to apply if you just separate out the pause system from the rest of it, because it's designed to work independently of everything else. Or at least that's what I assume.

Yeah, I think you can easily add some code that freezes all instances in a room except the "controller" object.  You don't have to change other stuff to add that, you just have to have a controller object that's "above" pausing and unpausing.

The link for this is no longer working, can someone please rehost it? I moved and now have a new computer, and I want this thing.

http://willhostforfood.com/files4/9/7/8/9780749/GrandmaEngine.rar

last version I downloaded, hope it helps.

Thank you!

Ok,I have a problem, but I'm not sure whether this is due to my GM skills being rusty or the engine's coding. I want to create destroyable floor blocks, and I want them to stay destroyed when you come back to the room later. I did the destructible part, but whenever I leave the room and come back, they just reappear. If I make them persistent, the blocks that I haven't destroyed also appear in the room I transition to, and all destroyed blocks are restored when I return to the original room. Help!


EDIT: I solved it. Turns out that I should set room_persistent = true during the stage_init script.

I've been playing around with this engine for a little while now. It works great, but I've noticed a small bug and I don't know enough about how the keyboard_check functions work to supply a fix. If you hold 's' while changing screen it thinks you've pressed 's' again and jumps or double jumps accordingly.

I see the file is a .rar, sorry if I sound stupid, but how do I open those?

Use winrar's trial version.
http://www.rarlab.com/ (http://www.rarlab.com/)

Or 7zip, which is free.
http://www.7-zip.org/ (http://www.7-zip.org/)

Thanks   ;D

With Will Host For Food down I can't seem to get a hold of a copy. Could anybody rehost this, it'd be much appreciated.  :gentleman:

I second this, I will be happy to host it if someone sends it to me somehow.

Here's a temporary hosting for you guys. I'll get Matt to upload a new one to his server next time I talk to him. There doesn't even seem to be a topic on his forum or download on his site, so I don't actually know if he's supporting it anymore. I'll give you guys this for now, but I'll take it down if he doesn't want me hosting it:

http://flashpunk.net/downloads/GrandmaEngine.zip

Finally got the download link working again.  Sorry about that everyone (and thanks, Chevy).

Thanks a bunch  :gentleman:

(the download link in the first post also works again, if my post wasn't clear)

wonderful engine for who, like me, loves to make platformers!! thank you very much Matt! we hope to see new release soon! :-)

Thank you, Mr. Thorson, for this great engine! I was developing an engine to use with my games, but at one point I saw this engine and found that my engine left a lot to be desired, so I re-made my engine, incorporating some of the concepts from yours! My friends and I use this new engine now, and it's been great! We will definitely credit you in our games.

The main faults in the original build of my engine were

1) it allowed for non-integer positions,

2) it used a for loop instead of a repeat loop in such a way as to allow objects to "overshoot" wall objects at high speeds, and

3) for some reason it doesn't work correctly in GM8...

Your engine helped me to fix these problems. Thanks again!

I won't post the engine, though... It's kind of messy. :P

By the way, the game in my sig does NOT use the new engine; it was made way before I knew GML well enough to be thinking about developing engines! Its sequel will be made with it, though. Stay tuned!

Thanks for putting this out! I've been looking for a starting point like this - getting reliable collision is tough when you're just starting out.

I'm finding it tricky to use any of Game Maker's normal functions with it, though. I have an ability that needs to use the 'Move towards point' action on the player, but that gives him some hspeed which never decays, because all the existing code affects his 'hspd' instead. He bounds through walls and eventually off the screen.

Is there any way around this, or do you have to script all your own actions to use the new object properties?

Also, is there any way to view or change the 'User defined event's that determine horizontal and vertical collision?

Cheers!

It might be a good (and in my opinion fun) exercise to make some code of your own that serves a purpose analogous to the 'Move towards point' function, using trigonometry functions and the variables introduced in the engine.


I think the user defined events are part of the events that you can change in an object's properties.

Heh, fun for smarter men than I, I fear. I'm fine with the maths side, but I'm an absolute novice coder - I err on the side of mathematically simple expressions that are enormously inefficient on the CPU.

Thanks for the advice. I had one last go at starting from scratch with a collision handler designed specifically for my purposes, and finally got it working robustly. It's probably not very efficient, but I think my game is going to be pretty simple in other respects.

I could see the user defined events in the object properties, and view the code they execute when triggered, but not view or change what triggers them in the first place. Maybe they're called by some script somewhere - nevermind.

Yup! They're meant to be called by the user; hence "user defined".

Though I realize I'm a bit late to the party, I started working with this engine a couple weeks ago. I really love the way room transitions work, one of the things that really stopped me from trying to work with Game Maker was not understanding a good way to do that.

After using it a bit though, I wonder if anyone else has noticed this little "bug". Taking out the backgrounds on a room, you'll see the player leave behind a trail of sprites. I noticed this on the game I was working on, then opened the regular engine to confirm and it's the same.

Though it doesn't seem to have any real effect on fps, after adding details to a room I assume it might. Anyone else notice this? Is it easily fix-able or not even a problem? Just bothers me because I don't have a great grasp on optimizing for speed or efficiency.

By "taking out the backgrounds", do you mean removing both background color and background image? If so, this is probably not specific to the grandma engine. Start a new test project (not with the grandma engine) with 1 sprite that you can move, and remove both backgrounds from the room and see if your results are not the same.

That's not a bug; that's just how Game Maker works. Every step, the program draws every sprite and background on the screen without "erasing" things drawn in previous steps. When you have a background color or background image, then, the images from the previous steps are merely being covered by the (typically screen-encompassing) backgrounds. The trail of sprites is still there, you just can't see them.

At least, that's how I think I heard it works, once...

There's a game or two out there that actually employs this feature to its advantage; I'll post a link if I can find it!

wasn't it a venbrux game?

So it was! Thank you for your help in tracking the game down, Tanner!

http://www.yoyogames.com/games/48522-you-made-it

Cool. I'll poke around and see what hard lessons I can learn from it "less hardly." I can see how the 0.3 vspeed wrapped with the "round" command would make that rather pointless to quibble over; unless fractal speeds *are* factored in, but a simple "round" check upon initial collision should be able to take care of that, even with fractal speeds enabled elsewhere.

As for the jumping, you may consider simply moving the command from "Key" to "Key Press." If that doesn't work, there may be something in GM itself that causes a "repress" upon creating/entering a new room. Also consider disabling autotype within the program (not sure how to do that).


Having a "player" parent object with 8 distinct jump-related powers, I've got a lot (likely 800+ commands) of jump-handling in my project so far, and it's not even to the playable point yet. How would you suggest handling sliding/passage-rolling, similarly to MegaMan 3+; and collision-checking for that? It's one of the things I'm kinda tripping over, atm; along with a fair number of my project's "L-Powers." I'm also planning to add in Super Arm (ala GutsMan/Chip'n'Dale) influence, and possibly Telekinesis (remote manipulation of appropriate blocks like that, within a range limit).

Interesting, I never knew about this, I'm glad to see it's something I didn't mess up. Thanks for responding, I really like this engine and even little things like that I get obsessed over when I can't fix them. :P

I'm trying to edit the button used for jumping from S to Spacebar.

Is "key_jump" a variable? And if so, where is it declared?

They are defined in the room creation code of room rm_intro (open the room, click on settings, then at the bottom there's a button for the room creation code).

Cool, thanks! I didn't even know you could put code in rooms...

I've kinda hit a hurdle here while studying the code. Noobie question.


Just what exactly is the meaning of this code? I've read the GM manual and tried to find an answer on the Game Maker Community but I only know that it's suppose to determine if the player meets the object, and x and y deal with the position of the sprite, but I can't wrap my mind around what is being computed here with the sign(h) added to it. Could someone explain the thought process behind this for me? Same thing when it's (x,y+1,obj_floor) or (x+sign(h),y+2,obj_floor). I guess I just don't understand x and y properly. For reference, this code is in the obj_moveable, end step event.

And thanks so much for this engine! This is my first foray into learning GML after the GM tutorials here on TIG.

sign() returns the sign of a number (positive negative or zero)
h is the horizontal speed, I believe.

since the absolute value of h is usually greater than 1, using it directly could result in some inaccurate collisions, especially at high speeds.

so x+sign(h) shrinks h down to a more precise -1, 0, or 1 and checks that place relative to the object's current x position.

so say your character is moving left with an h of -7
x+sign(h) would be whatever the character's x is -1, since -7 is a negative number.
if you're moving right with an h of 10, sign(h) = 1
it works with decimals, too, so sign(0.1) still equals 1 because it's a positive number.

and if you're standing completely still sign(0) = 0 because zero is neither positive nor negative.

Thanks! I mathematically understand what sign(h) does to x now. I'm still trying to figure why you need to do that in the first place. Why does x and y ever need to be altered? Isn't it checking the characters x and y axis position? Why would adding a number to x or y need to be done? I think I just don't understand the function in general. :facepalm: 

For most platforming code that I've made and seen, you want to check positions that the player could potentially be in before moving them.  So if you're about to move something to the right by one pixel, you first check that new position.  Something like:

if (I'm not colliding with the wall one pixel to the right of me) then
   set my x position to one pixel to the right of me.
else
   don't move me because there's a wall where I was about to move.

Sometimes you also want to check the position that is one pixel below the character to see if they are standing on a floor.

I usually do this too.

Oooh why did I not know about this engine?!

:(  "Doctor, I fall through the floor whenever I do this."
:gentleman: "Vell, don't do zat!"

I'm to proud to use this (great) engine directly, but it's made great improvements in my own platformer logic.  I did hit one snag though (you are probably aware of it already.)

When you are determining collisions with jump-thru objects, it's based on "if one is below me, and I am not inside of one," and the problem is obvious, what if you are standing on one, and you are also inside of another?  Even in your sample program, where the square is only one tile tall, if you set up a level with two jump-thru platforms stacked one tile above each other, you fall right through the lower one when you overlap them both.  Is there an easy fix for that?  Besides not building them like that, that is!

Yeah, the current fix is just don't build them like that.

If you want to really fix it you need to loop through all the platforms below the player and all the platforms within the player, then check that there's at least one below that isn't within. This is a pretty expensive thing to do in Game Maker, so I opted for the cheap method that works most of the time.

Hey, ive been playing with this engine trying to make my first crappy game out of it, but as a profesional noob, i have tons of questions.
How can i change the sprite for like, jumping or walking left and right (coding :P)?
i dont know really where to ask this kind of questions :>
ive tried image_index, sprite_index and other functions but i really dont know where or when to use it :<
any help will be thankd, even "press f1 u dumb asshole" :).

What I've generally done is handle sprite stuff in its own little separate section, handled in the object's step event.

I'll usually have some variables to keep track of what state the player is in (eg. mid-air, running, etc.); these would be updated in the part of the code that handles the object's movement.  If I remember correctly Matt's engine already has some variables in it that could be used to figure out what sprite should be displayed at the current moment.

So once you know those variables, you can just create a big if/else statement section checking the variables and changing the sprite index accordingly.  Sorta like this:


Hope that helps a bit!  ;)

Adding to what GregWS wrote:

Each object has a sprite that it is associated with. Each sprite has a bunch of frames, called subimages. Each object shows exactly one of these subimages at all times.

sprite_index: The number of the object's sprite. Set it to spr_runleft, for example.

image_index: The number of the subimage being displayed. Frames are counted starting with 0. So, if image_index is set to 2, for example, the object will show the 3rd frame of the sprite.

image_speed: The speed with which the object cycles through the subimages of its sprite. 1 means the object will cycle through subimages at the rate of X subimages per second, where X is the room speed. 0 means the object won't cycle through subimages at all, that is, it'll keep showing the current subimage.

Most of this has to do with the basic workings of Game Maker, though, so I'm not sure it's the kind of issue appropriate for this thread. Consider consulting the GM help manual; it's a nice resource!

Just wanted you to know that without the Grandma Engine, I'd never have gotten anywhere close to where I am today, coding wise. I found it just when I started GM a year ago, and it's helped me tremendously.

Thanks, man. You've done a thing worth doing.

Awesome, that's really nice to hear! It's actually weird to think how long ago I released this.

Hmm... I can't seem to fathom out how the engine deals with the obj_player colliding with the floor. I can't even seem to find where in the code it's happening.

For my game I'm trying to go down the same collision detection route where you detect a possible collision first before moving the player to the position, but it seems quite buggy. I don't want to just copy->paste Matt's engine since I'd like to first know exactly what the code is doing.

If I'm not mistaken, the engine is built so that you can tell it how to deal with collisions in user-defined events 0 and 1.

I'm a fan of this engine too!

Ah I just realised that obj_moveable is the parent of obj_player and deals with collisions. It seems to go down the same route as my own code so it's a bit annoying that my own is so buggy. Oh well, back to the drawing board. :shrug2:

Yeah I just did the inheritance thing so you can have multiple objects which use the movement engine, not just the player.

Has anyone added moving platforms, specifically vertical, to this engine?

I've made slight modifications to the original engine, including a tweak that allows the player to fall through a jump-through platform by pressing the jump key while pressing the down key. I'd like to use the jump-through as parent to the moving platform so the player can get on from below and get off by falling through.

My failed attempts, so far, have involved checks in the player step event. This has generally resulted in the player repeatedly falling with the platform (i.e. not "standing still" on the platform) while the platform moves downward, and simply falling through when the platform reaches the bottom of its travel and reverses direction upward. I have a feeling I could solve both of these problems by basing the player's movement in the current step on a look-ahead to where the platform will be in the next step. However, this would require specific code for each platform and each movement pattern. I'd rather do something more low level which would then be applicable to any moving platform without case-specific modification.

With that in mind, I assume I'll need to modify the core code of oMovable, in the end step. But that code is relatively foreign to me and I don't know where to begin modifying it. In general, I'm having trouble wrapping my head around how this should be done and any insight would be appreciated.

I made an engine partly based on this one that has moving platforms, but I ended up using what you might call a workaround. Basically, the platforms push the player around without taking into account the mechanics of the engine. If there's a better way to do it that incorporates Grandma Engine's system more, I'd like to know too!

To be more specific, the platforms themselves do use the kind of velocity featured in this engine, but they pretty much ignore the velocity of the player object (so it sorta seems to me like a workaround).

I was able to get it working the way I wanted with a similarly "brute force" approach. It's not elegant and I'm not a good coder so it's likely inefficient as well. :-\

But it works for vertical-travel platforms and should be easy to modify for horizontal-travel. The player can fall through by pressing down and jump. If too close to the edge of the platform when hitting a wall, the player will fall off to avoid any stuck-in-wall situations (assuming the player sprite's hitbox is constant between animation frames). And any object can be made a platform by simply setting its parent to the moving platform object. In case anyone is interested in the code:

Added an empty parent object oMovingPlatform.

Added scrCheckPlatform:


In the begin step of oMoveable, added this line:


In the end step of oMoveable, added this after the similar code for scrCheckBelow:


In the step code of oPlayer, I added the platform condition to this section:


Still in the step code of oPlayer, I added this section just before the code for jumping (global.FallThroughPlatform is declared in the create code for oPlayer):


And then in the user defined event for vertical collision, I added this (the offset is 4 pixels because my player sprite is 8x8 with the origin centered):

I'll have to take a good look at that code to understand it well, idoru!

So I said that I made my own engine based partly on Grandma Engine. I wanted to share it, but I've been refraining from doing so because the style of the code is a bit odd. But now I've made a new version that should be easier to look at: download from MediaFire (http://download1155.mediafire.com/h233nzpqe3gg/hiz3tvf2ths6e59/motion_engine_new_example_backup.gmk)

Note that this is a *partial* rewrite of what I'm actually using in my projects; therefore it's missing some features, such as the aforementioned moving platforms. Also, I apologize in advance for the sparseness of the comments!

Thank you again, Mr. Thorson!

Whoa this thread is getting pretty old but is somehow still active. Moving platform code looks cool, thanks for sharing that with everyone :)

I have been playing with this engine for a bit now and it is extremely useful. However, I still haven't figured out a basic concept, don't get me wrong, it's an awesome engine, and this is probably just me being a giant idiot, but I can't figure out how to make objects that act like the floor and slope blocks, as in objects that you won't just fall through when you step or fall on them, I have been putting floors behind basically every single solid thing as a temporary solution, but this is tedious and limits my options a lot.

 In short, how do you make solid objects in this engine?

Set the parent object to obj_floor/obj_jumpthrough. That should take care of it.

Ah, thanks, I knew it was something simple, I should probably read more before I ask stuff that may or may not be completely unrelated to the thread itself.

Don't have '-' in your sprite names. Your sprite/variable names should consist of letters, number, and _ only.

One of the things about GM that I dislike is that you can get away with using strangle symbols like '-' in your project, as long as your using drag&drop, or setting the sprite manually.

Once you get code, though, it all goes wrong.

No problem! :)

instead of adding another line, change the parent of o_basicarrow_hit to o_jumpthru, saves you messing up the code too much. I don't know if this will fix it, though, but chances are it will work better.

I don't know how to go about fixing that angled fallthru, though, Maybe have to hack it by making it so you can't stand on arrows that hit more than 45 degrees into the wall? seems realistic enough to me.

Hi, I've been using this engine for a while now and I pretty much know it off by heart. But for the life of me I just can't figure out how to make the player object jump down through a wall object. I've played around with obj_moveable to see if it was a fault with that part of the code. It wasn't, I managed to have all enemy sprites move through but not the player. I'm still playing with the player object to try and  work this out. I think someone else has managed to tackle this problem and if anybody could help me out I'd be very grateful.

Damian

Do you mean with the jumpthru platforms?

I added !keyboard_check(vk_down) in the checkBelow script, and it worked :)


Not sure if that was your problem, but it was mine, so my problem is solved xD

 :-X Thank you. I actually have that code already. But seeing that it worked for you and not for me confused me. It seemed logical. My mistake was making new objects and parenting the object floor in my idiocy instead of the jumpthrough object. Again thank you  :coffee:

http://www.mediafire.com/?k2oddbn9tsnqf5w (http://www.mediafire.com/?k2oddbn9tsnqf5w)
Here's a backup since the link stopped working.

I'm an almost-absolute-beginner at Gamemaker, and a definite-absolute-beginner with GML. I really can't thank you enough for making this available, it's been a fantastic teaching tool.

Hey the link to this has gone bad. Is it still on the internet somewhere?

EDIT: Sorry, I just looked through the rest of the thread and found that Jawnsunn's link still works.  :gentleman:

Fixed the link again! Sorry for always forgetting about it when I change hosts haha. It's at http://mattmakesgames.com/matt/GrandmaEngine.gmk

Thanks for this, it showed me a different and simpler way to warp between rooms compared to how I used to do it. Thanks, and will give credit when I use it.  :)

Is this even still linked anywhere on your site, or is it basically just here?

---

So I've been using the methods of the Grandma Engine in GM and also in Java, leaving the core algorithm (?) mostly intact, and in my opinion the movement feels great, it's really smooth. But I've been wondering about the efficiency of the method. It does a LOT of collision-checking that other collision-checking methods may not have to do, right?

If I remember correctly, though, I think I was able to get about 100 or 200 simple objects going without lag in GM with this method? It might even be possible to have more objects. I haven't really tested it in Java.

My apologies if this issue has already been discussed within the thread. Thoughts?

good engine ;D

@lasttea999 I'm not 100% but I think the only difference in terms of collision detection is that this engine checks for a collision before movement while GM's inbuilt collision detection checks for a collision after movement. So they are both doing the same amount of checking, it's just at different points in the code.

I don't know about GM, but I think--- based on what little I've learned about other collision-checking systems--- that some other systems do things like

-move every object *once* according to their velocities, look for collisions among objects, and then move each colliding object out of its collisions once,

whereas the Grandma engine

-moves each object floor(abs(velocity)) times, checking each time if that object collides with each other object.

So basically, with Grandma's method, the checks rapidly increase with the number of objects and the speed of each object. It seems that the only big advantages this method has over the other method I mentioned is its simplicity and the amount of control you get over the movement. I rather like this advantage, but I want to know if it's worth the loss in efficiency. And while I probably won't need a more advanced engine, for more advanced physics, the capabilities of Grandma's method seem a bit narrow.

EDIT: Oh, allow me to mention that I like how the positions of objects are always restricted to integers, which I guess is part of the simplicity of the engine.

My question was "does the actual site if you go there via the domain contain any reference to the grandma engine or that link?"

Ah, right. Sorry for the mistake.

I wonder if Mr. Thorson still uses the methods of this engine?

Figured I'd chime in since there's a few questions:

1) Does my site link to Grandma at all? Nope, it's just hidden away in that directory. I have a fear that the engine will be outdated at some point by Game Maker development. And I'm not really qualified anymore to provide any sort of Game Maker-related support, since I haven't used or thought about the software in years.

2) On the efficiency issue, and whether I still use the algorithm in my work:

Yes, it's a slow method (relative to other methods). The advantage, as has been said, is in the amount of control you gain. Game Maker normally moves the object, then does a single collision check against every other object. Grandma moves the object pixel-by-pixel, doing checks for each tiny movement. This is obviously much much slower. In deciding whether to use this method in your Game Maker project, consider the amount of objects that will be using it. In my Game Maker platformers, the player character uses this method while other moving objects use the built-in hspeed/vspeed or other simple alternatives. Player control is obviously much more important in these games than, say, how an enemy moves, because it is the player's direct interface with the game. This can be different for different games, so choose accordingly and be aware of the cost of the decision.

Give Up, Robot and Give Up Robot 2 (http://www.mattmakesgames.com/) both used this method, adapted for use in FlashPunk (first v0.8 and then v1.0, respectively). This algo also happens to be great for robust moving platform logic (integer positions simplify it a lot).

My new engines all have easy ways to get the top/bottom/left/right bounds of any given game entity, so I can simplify it to a single collision check, allow floating-point positions, and snap to the edges of hitboxes on collision. However, there is a sacrifice that comes along with this optimization: all hitboxes must be solid rectangles. Example: If I'm inside a hollow rectangle and I hit the border, snapping to the "left" of that hollow rectangle will warp me outside of it. So I still have to decide which method to use based on the needs of the game :)

Thank you very much for your feedback!

I'm having a little difficulty seeing exactly how the the edges of the hitboxes are checked (you're not checking how the various rectangular hitboxes overlap, are you?), how that reduces the collision checks, and what exactly "a single collision check" means (I'm guessing something like "once per frame per player object per floor object"?).

I realize I've already been quite forward in asking for feedback, but if you ever find the opportunity within your busy schedule, perhaps you could write up a short tutorial on some of your newer engines and methods? The Grandma engine doesn't necessarily have to end with your usage of Game Maker, does it? :)

Hey man this is a really good engine! I can see alot to be done with this!

I just posted some FlashPunk Platformer engine code that resembles Grandma Engine, in case anyone is interested :)

Actor: http://pastebin.com/H441PktM (http://pastebin.com/H441PktM)
Solid: http://pastebin.com/pfAnw4Qk (http://pastebin.com/pfAnw4Qk)

Am I the only one that finds all code other than GML thoroughly incomprehensible?

Thank you for the code! I'm afraid I don't really know much about FlashPunk, but is the Entity class something included with FlashPunk? And are the collision functions you're using here also included with FlashPunk? I'm wondering how the collision checking works.




Some of the syntax seems a little mysterious! Have you programmed with anything other than Game Maker?

did you seriously write
comon mannnnn

What's wrong with that? It's correct syntax. If I had typed:


That would force the compiler to coerce a Function to a Boolean. Which would be doable, but less clear to the reader imo (because it implies onCollide is a bool, and even throws compiler warning flags I believe).

ahhh I was getting it mixed up with collide(), I didn't realise it was a callback function.

whoops  :facepalm:

You should still do it with collide() if you want to write clear code. collideWith() on the other hand actually returns a bool.

Anyways, that's kinda veering off-topic, but yeah.

Hey there, I've started messing with this engine and I like it quite a bit. I've noticed something, though. In the stageGoto script, it uses a execute_string function. This seems to work perfectly for what it's supposed to do. However, I looked it up, and most people advise not using it. Also, Game Maker Studio no longer supports it. Are there any alternatives that can be used in case I need to port it to GMS?

EDIT: I found the answer to this after more google searching. The answer can be found here http://gmc.yoyogames.com/index.php?showtopic=556430

Simple, but I likes it. Thanks  ;D

This is a great engine. I've had a lot of fun tweaking it to meet my needs and I really really appreciate all of the work that went into this.

Can someone explain this section from obj_moveable's end step?

Wouldn't it be more simple just to:

or am I missing something?

it allows for subpixel movement

iirc h_counter builds up until it's greater than/equal to 1, then adds it on to the x coordinate

I'd like to elaborate on what John Sandoval said: basically, the feature GMMike brought up lets objects move at speeds that aren't whole numbers.

Imagine what would happen if we used h = round(hspd), and hsp was 0.3:

First, round(hsp) would evaluate to 0 (it would round down from 0.3 to 0).
Then, h would be set to 0.
Thus, the object doesn't move at all in the horizontal direction.

This happens every frame; every frame, h is set to 0. So even though the object would have a non-zero speed of 0.3, it wouldn't move horizontally.

Anyone managed to add moving platforms to this engine yet? There was an attached example but the link is dead now.  :(

Great engine! I don't understand most of the base code, but it's great to work with!

I found another little bug though: when you walk against a wall and you keep walking against it, your hspd will be 0.8 in one frame and then 0 the in the next. You don't see it, but it will mess up your animations.

It's pretty easy to work around, but I thought I'd let you know in case you have any intentions to do some debugging :)

Anyways, thanks for the great engine!

That might tend to happen! Doesn't the hspd oscillation (going back and forth from 0.8 to 0) problem depend on how one implements animations, though?

For example, in one of my games the oscillation wouldn't affect a player's animation because it depends not on hspd but on the keyboard keys held.

I'm working on a platformer game and this could be useful, but I can't open the files. I have GameMaker Studio. Is this engine for a legacy version? Can it be opened/used in GM Studio?

I'm chugging along with help from some YouTube videos but I'd love to try this out.

In any case if anyone know a useful GM Studio Platformer tutorial/guide, I'd love to check it out.

This was made for GM7 I believe, you can try porting it to Studio if you want (this guide (http://help.yoyogames.com/entries/24909988-Porting-GM7-And-GM8-Games-To-GameMaker-Studio) is pretty helpful).

Considering I just starting using GM: Studio, this is actually some pretty cool information (most that I knew), but the thing about the order of events was really interesting.

How would one make the jump bigger if you hold the button longer (like in Mario games or Give Up Robot2)?

Also, should use this engine/rules for enemy AI? I thought of just adding alarm based input on when to trigger movement like player does with keyboard, or is that stupid?

Thanks

I usually add friction to the vspeed if the jump button isn't held and the player is going up. Code would be this:


If the jump key is not pressed, the jump will stop going higher in a nice, smooth and fast motion. This isn't the way it's done in Mario, but I like this way better anyways ;D

Thank you, that works like a charm. :)