A downloadable asset pack

Buy Now$19.99 USD or more

This Platformer Engine is designed to be everything you need to create any platformer game. The engine has a long list of features which will be added to continuously as it is developed.

The code is clean and well commented, explaining how each part of the engine works.

Features (v1.0.0):

  • Pixel-perfect collisions & movement
  • Wall jumping
  • Variable jumping
  • Fallthrough platforms
  • Moving platforms/blocks
  • Circular moving platforms
  • Bouncy platforms (bounce when entities jump on them)
  • Crush entities with moving blocks
  • Falling platforms
  • Lift platforms
  • Modifying platforms (e.g. ice/mud blocks)
  • Modifying zones (e.g. increase speed in certain area)
  • Gold, items & chests
  • Example enemies (jumping, walking, flying)
  • Line of sight detection
  • Entity health system
  • Sprite-based health bars
  • Parallax backgrounds
  • Weapon system (weapon logic stored outside of player object)
  • Example weapons (bow, axe, whip)
  • Springs & spikes

Features (v1.2.0):

  • Ladders
  • Crushing blocks (Fall when player is below, then reset)

Features (v1.3.0):

  • Controller support
  • Local Multiplayer example
  • Water physics
  • Ledge grabbing

Features (v1.4.0):

  • Support for my [Pathfinding for Platformers] asset
  • Slopes


    StatusReleased
    CategoryAssets
    Rating
    Rated 5.0 out of 5 stars
    (9 total ratings)
    AuthorWill Lewis
    GenrePlatformer
    Tags16-bit, 2D, engine, framework, Pixel Art, platform, Retro, Side Scroller

    Purchase

    Buy Now$19.99 USD or more

    In order to download this asset pack you must purchase it at or above the minimum price of $19.99 USD. You will get access to the following files:

    PlatformerEngine-1.4.5.gmz 1 MB

    Download demo

    Download
    PlatformerEngine1.4.3.exe 2 MB

    Comments

    Log in with itch.io to leave a comment.

    Hey I really like the look of this engine but I've got a few questions:

    Does this use GMS1.4 physics?

    Does this support tilemap collisions?

    Either way feels really solid!

    He released a statement that he wasn't supporting this any longer, but I can answer: no physics, but the code works great for movement; no tile map collisions, it uses objects, but this can be converted; it is really solid; I have been using this engine for years and it imports nicely into the new versions of gamemaker studio and can be edited and updated (as I have done). People have issue with the window size, but it can be changed, I can assure you; you just need to take a look at resolution tutorials, etc.

    I'm thinking of buying it. Can you please elaborate on changing the resolution as this puts me off as a beginner coder. Is it easy? Also, my sprites need to be 128x128. Is this easy enough to change? I've tried other engines where they didn't really adapt well to different mask sizes as this broke all the collision code. Thanks!

    (2 edits)

    Sure, but remember this isn't a boiler plate solution because you will have to tailor and tweak the code:

    Many GM games use a setup or "initialization" room; in this room they put objects that run code necessary to tweak some settings; a less code heavy approach would be to setup a view and room size for this room and the rest of the game tends to match those settings. What I do is use an object, placed in the setup room, that runs code in its create event:

    // resize game surface

    surface_resize(application_surface,res.w,res.h);

    // resize window

    var _w=res.w*res.s;

    var _h=res.h*res.s;

    window_set_size(_w,_h);

    // set video applied settings time

    alarm[0]=1;

    This code resizes the game drawing surface in order to scale the game without funky artifacts. The lines that reference res.w*res.s and res.h*res.s is just an enum that I made to contain the size of the window (width=w, height=h) which is multiplied by how much you want to scale the window (scale=s); making enums for this purpose is easy, but make sure you define the enum BEFORE this code, you can even put it right above the code that I'm currently explaining (in the create event of the object); my enum for the window size looks like this:

    enum res

    {

    w=352,

    h=224,

    s=4,

    }

    Width (w) is the width of the window at 352 pixels (unscaled); height (h) is the height of the window at 224 pixels (unscaled); these two numbers are multiplied by the scale (s) which is four; this results in an actual window size of 1408x896. Remember, this code is placed before the code previously mentioned (or at least called before it).

    window_set_size will actually set the window's new size (referencing the _w and _h variables which were used to hold the scaled window dimensions. This function won't take effect right away, which is why the next line sets an alarm in the same object; the code in the alarm event is:

    window_center();

    // start game

    room_goto_next();

    This code is simple: the window is centered on your computer screen and then the next room is loaded. Having an alarm delay after the window is resized and before the game progresses to the next room ensures that the window is setup and centered properly before the actual game starts.

    Lastly, in order for the change to be usable in-game, you have to setup a view; you can either do this in the room editor or in code; I like to do it in code because it makes me feel big and powerful. I make a camera object and either leave the sprite blank or make it invisible. In the camera object's create event I setup the view:

    // create view camera

    var _camera=camera_create_view(0,0,res.w,res.h,0,id,-1,-1,res.w/2,res.h/2);

    // setup view

    view_enabled=true;

    view_visible[0]=true;

    // set view to camera

    view_set_camera(0,_camera);

    In this code, a camera is created using the enum values that I explained previously (creating a camera this way means that you will only have to change the enum values in order for the entire system to be affected) and is stored in the _camera variable. Setting view_enabled to true enables the use of views for the current room, in which the camera is present. Setting view_visible (for view "0", which is the view to which the camera is attached) will enable the camera's view. Lastly, view_set_camera attaches the camera (which is stored in the _camera variable) to the view (in this case view "0").

    Remember, with this code, the view follows the camera object only, so you have to make the camera object follow the player; you can do this easily by just setting the camera object's x and y position to the player's x and y position in the step event of the camera object; if you encounter unwanted lag or choppy movement, experiment with begin step and end step in addition to the normal step event.

    You can create the camera object instance in the player's create event or set the camera object to persistent and place it in the setup room (be mindful of referencing the player object before it is created; I usually just put all player referenced code in an if "player exists" type comparison to be safe).

    Lastly, delete your camera with camera_destroy(view_camera[0]) when changing rooms or ending the game, otherwise it will cause a memory leak which will slow your game, due to repeated test-playing, until it eventually crashes and you have to reboot your computer.

    Also, if you have weird position based drawing artifacts such as vanishing pixels on object sprites, in your scaled game you can round the drawing position in the drawing event of the object; this keeps the game from attempting to scale pixels when the object's position doesn't quite match up with the display position in a scaled room. This isn't a problem that everyone has.

    Check your GM manual for explanations of all of the functions that I have written about, this will give you insight into their various parameters (especially since I didn't give a more in-depth explanation of why I threw in random -1 parameters and such). Take this process one step at a time; this seems way more difficult than it actually is.




    Thank you for your detailed reply! This is super helpful. Cheers :-)

    You're welcome; you asked for detail lol.

    Hi, is there anyway u would resell  [Pathfinding for Platformers] asset? Thanks you in advance 

    Before I make this step, I would like to make some basic questions

    - Exported games can run on Android

    - Is possible to switch the charater sprite

    - Shop system allowing to buy items

    - Perk page / skills

    I would pay you for such features, add  me to further discussion

    Thanks

    Andre

    (-1)

    me too

    hello Rupeck. Can you upload to itch.io the platform runner engine?


    (1 edit)

    Hey Rupeck! Great job on this engine, it's really one of the best! But where's your runner engine? Uploading it on itch.io as well would be great!

    (1 edit)

    This is amazing!  Highly recommend this.  You can edit this to fit your needs very easily. This engine will save you so much time and let you tweak it to fit your needs.