Platform Engine essentials

[csanyk]

I'm starting to plan out a 2D platform engine. What features are essential to include in a flexible, general purpose platform engine?

Moderator Edit: Topic moved to Game Design

 

[Ninety]

Firstly this is in the wrong forum. Post in Game Design.

Secondly,

• Double jump
• Wall jump
• Enemies that can be jumped on
• Ladders
• Moving platforms, horizontal and vertical
• Spikes

 

[KurtBlissZ]

I have no idea, but It's defiantly easy to list everything I would want...

So I say for the "essentials."

• Delta Timing
• Acceleration / Friction

Extra Movement features

• Limit Air jumps (Single, Double, Tripple Jump, etc)
  • Variable that you set on how many times you can jump in air.
• Control how high you jump by how long you hold the jump button.
• Smoothly walk up and down slopes, maybe terrain.
• Wall Jumping
• Wall / Ladder climbing
• 
  
• Moving platforms in a specific direction or path.
• Jump up through certain platform and drop through them.

Extra Misc Features

• (Auto) save and load feature
• Checkpoints
• 
  
• Touchscreen controls, Buttons, and Gestures
• Compatible with YYC, HTML5
• Local Multiplayer w/ Gamepad support (Maybe analog, vibration support)
• Movable Camera (Look up and down, Look around with mouse, Follow player or multiple player)
• Fast Projectile Collision
• Enemy path finding

 

[Widget]

Controller support. No matter what type of platformer it is, make sure you have that.

 

[Paolo Mazzon]

• Delta Timing

^^^
This is not seen often enough in GM games, and if you're making an engine, now is a good time to implement. I would also agree with everything else KurtBlissZ said.

 

[Siolfor the Jackal]

How exactly does delta timing work, and how hard is it to impliment?

 

[csanyk]

How exactly does delta timing work, and how hard is it to impliment?

It isn't too hard. There's tutorials explaining how to do it if you look for them. In a nutshell, delta timing takes a precise measurement of the time elapsed since the last frame was rendered, and uses that to adjust the speed of movement and other execution timing, so that the game appears to run more smoothly, even if it's dropping frames due to lag. In smaller projects it's not really needed, but if you have a lot going on in the game such that you're taxing the CPU, it's very handy.

 

[L0v3]

Basically everything this articale also talks about you want to be able to customize for players.

http://www.gamasutra.com/blogs/Yoan...w_to_avoid_limpness_and_rigidity_feelings.php

Air acceleration, analog movement n jumpin, tolerance, delay, and deffintly controller support. Platformers are meant to be played on controller.
Would also love some slopes, ladders, wall jumping, pushable objects, basic ai example which can easily be expanded upon, variety of optional weapons and attack types to be expanded upon, n even perhaps multiplayer support. I would want animation states for all the movement to easily change sprites, n thats about it I'm lookin for I guess.

 

[Nux]

Something I might add (along with the other features) is the ability to pick up items or blocks like in super mario to throw at enemies or to build towers to reach higher places

 

[Paolo Mazzon]

How exactly does delta timing work, and how hard is it to impliment?

Super easy to implement if you do it at the start, it is really just multiplying a few numbers by a global delta. Of course, there will also be some game logic that would need to be done a tad different, however.

 

[greentiger]

Well it's very hard to cover all scenarios but if it's strictly going to be a platformer game-maker then I would think of what does Mario offer and extending it (Mario is the console king after all) ...

* hit point system (multiple hits for some enemies, one for others, etc; along with insta-death and invulnerability flags)
* pathing behavior for enemies (move forward, walk back and forth, walk forward, jumping back and forth, jumping forward, stay stationary)
* jump, multi-jump (single, double, triple, etc jump)
* dash along land
* air dash
* total air control vs. limited air control (directions mid-air)
* icy footing, environmental hazards (fatal, poisonous, non-fatal like "drunk mode")
* built-in trap types; squisher, shooter, moving
* built-in platform types: vertical dumbwaiter, horizontal dumbwaiter, vertical looping, horizontal looping, train moving along points
* powerup-apply-effect with possible built in types: shoot bullet, shoot fire, shoot ice, shoot poison, increase/decrease damage, invulnerability (tanooki), invulnerability (star power)
* wall jump system
* melee attack system (dress it up as a racoon tail or samurai sword it's still a melee attack)
* easy drag and drop editor (Super Mario Maker)
* scene/room warp system
* a way to link levels either by overworld or link system (a la metroid)
* items to save your progress in a level
* items to save your progress in a campaign
* sprite/strip built-in definitions of idle, move, attack by power, attack by melee, hit animation, burn animation, sick animation, die animation
* fall back options for missing textures and missing sprites

 

[csanyk]

* easy drag and drop editor (Super Mario Maker)
* fall back options for missing textures and missing sprites

Drag and Drop level editor is a great feature, but that's not the engine, it's a utility to support development with the engine.

What did you mean by "fal back options" exactly? Can you give me a concrete example of how that would work? I take it you're assuming the engine will read textures and sprites from external files... what should it do if those are missing?

 

[Charyb]

If you're looking to raise your FPS by a lot, try swapping out solid objects for data structured data.

I've noticed block objects will cause a ton of FPS problems if I put a lot in my room.

Recently made an engine based off of this and it works great. I'm also using less code for collisions
than I would if I used the native GM functions (place_free, collision_rectangle, etc).

 

[csanyk]

If you're looking to raise your FPS by a lot, try swapping out solid objects for data structured data.

I've noticed block objects will cause a ton of FPS problems if I put a lot in my room.

Recently made an engine based off of this and it works great. I'm also using less code for collisions
than I would if I used the native GM functions (place_free, collision_rectangle, etc).

How many is "a lot"? What build target? What kind of hardware? And what exactly do you mean by "data structured data" -- could you describe your approach in more detail? Is your engine publicly available?

 

[Roa]

ledged grabbing

 

[Paolo Mazzon]

If you're looking to raise your FPS by a lot, try swapping out solid objects for data structured data.

I've noticed block objects will cause a ton of FPS problems if I put a lot in my room.

Recently made an engine based off of this and it works great. I'm also using less code for collisions
than I would if I used the native GM functions (place_free, collision_rectangle, etc).

I agree, don't use solid objects unless you have a good reason. For 90% of applications, collision grids will do just fine in a platformer and are waaay faster. No matter how many walls you have in a collision grid, the time it takes to check a collision will always be the same (Excluding short circuit evaluations, but that's basically nothing).

 

[Robert]

I disagree Delta Timing is a PAIN IN THE BOOTY!!! No really, it is... I had basically developed my entire prototype without it so when I came back to redevelop the game for real I wanted to implement delta timing, but it changes EVERYTHING, and if you are using physics you can just forget about delta timing altogether.

However, here are a few tips to help you with implementing delta timing once you have your global delta variable going:

Normal Speed Modifiers
speed = 10*global.Delta_Time;

Friction Speed Modifier
speed *= power(0.1, global.Delta_Time);

Alarms and Timers
alarm[0] = 30 / global.Delta_Time

When using delta time you can no longer just apply a speed once, so if you would normally just create an object and then apply speed to it that will not work properly since when you apply something at that moment the delta time might be off which means that whatever speed that got set is also off. So, the right way is every step make sure you update speed variables or really any variable that changes over time to constantly get updated with the current delta time. Actually it doesn't need to be every step it just needs to be somewhat frequent so that you can prevent big fluctuations of the delta time from impacting your objects negatively.

Particles, oh boy if you use particles your in for a treat! Especially if you need things like pausing and more advanced particle functions. Like mentioned above you will need to constantly update the particle properties like life and speed or else you will have problems. To make things even more difficult you also have to restrict the flow of particles to an alarm because you cant just emit a particle every step or when the frame rate is really high then your emitters will shoot out millions of particles a second, so instead you have to set it to a timer where 10 times a second the emitters spit out a particle. Also, you will have to manually draw the particles as well, I can't remember why off hand but I remember I had to manually draw them. It's a total pain.

So yea I'll just leave it at that, but adding delta timing is far from easy, in fact I would even go as far as to say it's been one of the most difficult and challenging things I have actually come across in GM, at least doing it right that is. Its much more than simply applying var*delta_time, much more.

 

[Charyb]

How many is "a lot"? What build target? What kind of hardware? And what exactly do you mean by "data structured data" -- could you describe your approach in more detail? Is your engine publicly available?

Ah sorry.

By a lot I just mean you will see a noticeable difference. It's usually for mobile devices because most PC's I've noticed can usually handle quite a lot of instances these days.
I've got a fairly new phone and the FPS does seem to drop quite a bit if I haven't optimized my game.

It really depends on how much you're doing that could potentially lower your FPS.

Okay mm so about the data structures. What I do in my platformers now is I'll use block objects and place them all in the room. And then I'll stretch them out
if I want them to cover a lot of area instead of placing multiple blocks in a row.

This is great and all but the majority of your instances are still covered by block objects which will hinder performance if you have a huge room on low powered devices.

So what I do is, I take all of the data from each block: x, y, sprite_width, sprite_height (the sprite width and height changes when you stretch it in the room editor) and then I store that data into data structures, usually a list:

//obj_controller create event
block_x = ds_list_create();
block_y = ds_list_create();
block_width = ds_list_create();
block_height = ds_list_create();
alarm[0] = 1;

//obj_controller alarm[0] event
//Some blocks might have been added after the controller so the controller may never find these unless we go 1 step in time

with(obj_block){
    ds_list_add(other.block_x, x);
    ...etc.
    ds_list_add(other.block_height, sprite_height);
}

And then for my player object, to check for collisions with the blocks I simply loop through one of the lists:

for(var i = 0; i < ds_list_size(obj_controller.block_x); i++){
    var blockX = ds_list_find_value(obj_controller.block_x, i);
    var blockY = ds_list_find_value(obj_controller.block_y, i);
    ...etc.
    //Do platform collision checking here
}

Now that I'm using data structures and not actual block objects, I have to create my own collision functions since functions such as place_free() and such will only work with objects. But this is a good thing because my collision functions will use less code than the native GM ones and thus make the game faster.

Basically you just have to use as few instances as possible. Sometimes I get lazy and throw some in but then it can be a huge factor in performance, especially on mobile and other platforms.

 

[Physix]

Anyone who talks about adding double jumps and air dashing and wall jumping and all this are buffoons. All you need is pixel by pixel iterated movement, pixel-perfect collision, pseudo-acceleration/deceleration to work on a rounded, pixel-perfect grid. Slopes, gravity, jump-through platforms. Many flexible methods of input (Keyboard, joystick/controller, reading from replay recordings of input, etc). At most, delta time. Done.

 

[Roa]

Anyone who talks about adding double jumps and air dashing and wall jumping and all this **** are buffoons. All you need is pixel by pixel iterated movement, pixel-perfect collision, pseudo-acceleration/deceleration to work on a rounded, pixel-perfect grid. Slopes, gravity, jump-through platforms. Many flexible methods of input (Keyboard, joystick/controller, reading from replay recordings of input, etc). At most, delta time. Done.

I think you missed the point that this would be one all inclusive package for any platformer.

 

[csanyk]

I've just been sitting back and listening to all the suggestions, but I didn't want anyone to think that I've lost interest. Keep 'em coming!

 

[heyimdandan]

There really isn't anything new in any platformer I've seen in the last decade with only a handful of exceptions. I'd watch game play action of classic 2D Mario, Sonic and James Pond: Robocod on YouTube for inspiration and poach bits. I've plagiarised about half of the ideas that feature in the Lava Reef zone of Sonic & Knuckles? And why not? They're great concepts that stand the test of time. You just have to look at what Sega are doing releasing a brand new 2D Sonic adventure on PS4 and XB1 for 2017.

 

[gamedev4life]

Some destructible environments, screen shake, some kind of flash effect when enemies take damage

 

[greentiger]

Drag and Drop level editor is a great feature, but that's not the engine, it's a utility to support development with the engine.

What did you mean by "fal back options" exactly? Can you give me a concrete example of how that would work? I take it you're assuming the engine will read textures and sprites from external files... what should it do if those are missing?

Like if you define your levels to have a certain texture or whatever for a tile, and then it gets deleted or corrupted, that a default texture/tile is displayed so your level might look garish (to point out the texture), at least it doesn't look like a pit or something.

And yes, being able to load external graphics without importing would be a nice feature.

You're right that drag-and-drop level making isn't an engine feature per se but it will keep your users from ripping their hair out from having to put in a tile one tile at a time.