I still remember watching your streams years back where you said that you one day wanted to pursue game making. Still such a surreal experience yet I'm very happy that you're doing it!
Watching these dev logs really highlights how much I take for granted when I'm playing games. Every single aspect requires so much consideration- like the Frame A, Frame B thing. As always, keep up the great work!
I do get a lot out of these, Matthew. It's insightful, and the prospect that my favorite critic could also become one of my favorite devs gives me a lot of enthusiasm. Proceed in your endeavors and I wish you the best!
Hey Matt. The ghost/prediction thing you're working on is called Dead Reckoning. It's a common thing in multiplayer games and there's a lot of existing theory written about implementations and how to make it work as smoothly as possible. Might be worth reading into.
Wonderful video, the streams and development updates on this channel got me into ghosts and goblins and I've absolutely loved it. I loved it so much that when tasked to remake a retro game in gmk2 for school I decided to try make my own gobshite platformer. These videos provide such helpful little insights, I've caused myself a lot of problems because the way I grab data is rubbish, but hearing your explanation of it made me actually understand why I kept needing to change values and things and stuff. Keep up the good work MatthewMatosis Extra!!
It sounds like you're overcomplicating the whole frame A/B thing, and ultimately it's personal preference per action. I think that referring to fighting games would help immensely, specifically "Links" (Frame B), and "Cancels" (Frame A). Linking actions is when you perform an action immediately after the previous action completes in it's entirety, whereas canceling an action involves the player inputting another action at a predesignated cancel point. As to when/where these cancel points are is obviously up to the designer, but typically speaking it's during the active/recovery portion of the action, and possibly limited to whether or not the action made contact with an enemy. I don't think I can post direct links here, but "Infil's Fighting Game Glossary" can help elaborate on both.
I'm fine with using those terms. Still, whatever you call them, I needed to decide that I want the default behaviour to be a Link rather than a Cancel and to write the code that made it work that way. Unless I'm misunderstanding something, I don't think I overcomplicated the problem at all except for using different terminology.
@@matthewmatosisextra I suppose I misused "overcomplicating"; I don't think I fully understood your dilemma until the frame-by-frame breakdown in this video, after which the fighting game terminology came to mind and the pieces finally fell into place. I guess you could say I overcomplicated it. Regardless - It seems you know what you're doing and it's good to see that you've got things sorted out. Looking forward to seeing more.
I see. Sorry if it seemed like I was being nitpicky about the overcomplication thing, I just wanted to know if there was something more fundamental that I overlooked. Glad it all makes sense now, my stream explanations are not always great.
@@matthewmatosisextra Another great term relates to your "bullshit frame A even though your system is frame B" comment near the start: IASA frames! Interruptible As Soon As (IASA) frames: Suppose you have some 30 frame animation for some attack. If they do nothing, you want the last 3 frames to be a natural transition back to their idle pose, but you don't want to see it if they do another attack. You mark frames 27-30 as IASA frames, and apply a standard set of rules across all states instead of the normal state transition rules, while continuing to play the recovery animation if they do nothing. (These rules are going to be pretty much the same as your normal air-idle and ground-idle state transitions, but in some games, there are slight differences. Maybe you can do attacks, but not walk, for example.) This term is used in Smash games mostly. It is also explained in detail in some GDC talk from a Skullgirls animator; she wanted the jab to be fast, but it looked weird to snap right back to idle if you did nothing afterwards. So, this animator made the engine programmers add this system. The main advantage is that you don't have to add special cases to every animation, just the single number of IASA frames that gets handled the same way across multiple states.
In Atari's Transformers (2004), enemies start shooting projectiles ahead of the player's position after the player reaches a certain momentum value. The player has ~ 4 different walking speeds whose future positions can all be predicted and synchronized with projectile travel time by the enemy AI. Projectiles are also bright energy spheres whose positions are easy to read, even when 20+ are on screen. This encourages the player to change their speed or direction, jump, evade, or pull up a shield much more frequently than required for simple strafing. It's an interesting idea to have something like this or the Ganado reaction in a game with two dimensions, and would probably help build the grounded world and enemy aesthetics you're chasing too.
I like this idea especially since when I throw something (say) to a moving person, I take into account their velocity / acceleration / direction and use that to predict where they'll be. That is just part of what it means to shoot at a moving target, I guess.
Fleas are one of the most vile, irritating, evil bloodsuckers I've ever had the displeasure of dealing with. And Matthew goes and codes them in as the first enemy in his game. Well done. Jokes aside, I like these little developer vlogs. I hope you don't get too hung up on people being upset something you were tinkering with not making it to the end of development. I would like to believe that most would understand that not everything can make the cut.
46:50 Matthew over here still mad that dark souls 3 had that giant archer with homing arrows and trying to come up with something much better for his game. Seriously though it's fine if doesn't go anywhere but that prediction system could be really cool, at least for the more complex enemies, for the simple ones I don't think it would make a big difference. EDIT: as an extra, this is directly for Matthew, maybe those enemies you mention from bayonetta and RE4 are just checking the player's position + the player's speed and direction? So instead of just checking if the player is currently in range they check if the player is gonna be in range after X amount of time simply based on multiplying those values
38:00 from the way you describe the problem it sounds like you're using the hit box (when the character can be hit) as the bounding box (where the character collides with terrain). These are usually seperate things with the bounding box staying the same size across all animations to prevent clipping and the hit boxes being frame specific to match the character's pose. Usually the only animations that would have different bounding boxes are slides/crouches, which keep the same width but are just shorter.
I am. The way I see it, if you can collide with terrain at a certain point you can also get hit there. I might also add hurtboxes as a separate thing later (to have additional damage zones on larger or oddly shaped enemies I imagine) but I think either way I would want a solution to what happens if/when the bounding box changes shape. Thankfully that part seems to be done. Fingers crossed.
Glad to hear from you again. Guess I'm missing a lot from your dairies on patreon. It's good reminder for me to check those out. Game dev Matt sounding as passionate as the last update.
On the instantaneous room transition: Unless you plan to have super big rooms with a ton of instances loading them super quickly like that won't be an issue until you start having a lot of sprites in your game. The way Game Maker handles sprites by default is to cram all of them into texture pages, and by cram I mean it tries to fit sprites into transparent pixels to have as few texture pages as possible. Whenever a room is loaded, Game Maker grabs all the texture pages that will be needed in that room. The problem with this is that by default there's no designation for what sprites should go together on each texture page, so you could end up having some random enemy sprite put on a texture page with sprites used for the title screen, so now whenever you're loading that enemy you're also fetching a bunch of other sprites that you're not even going to be using. Long story short, if you make good use of "Texture Groups" in Game Maker you should be able to keep that instant transition between rooms, so long as said rooms aren't absurdly large.
Very good to see you're still kicking, and nice work here. Anything is far better than nothing, since i think we're subscribed to matthewmatosis come what may, rather than a particular series.
In regards to your predictive enemies I've definitely seen simplistic versions where enemies who shoot projectiles will lead their shots if you're moving. I'm pretty sure it happens in the final boss in Banjo Kazooie. I reckon I've seen in in a few 2D games too.
With the screen transitions, it might be neat to have different wipe directions depending on which direction the player is leaving the screen. I do like the flow happening at 11:08, where the transition movement begins on the side the player leaves, then ends on the side the player starts the screen on. Metroid has a somewhat similar idea, where after you enter a door, it'll move to where you'll be entering a room. Sort of letting the player know where they'll be appearing when the next room starts. Also, when it comes time and if you're looking for someone to do music, I would be more than happy to contribute.
That's already implemented actually. I agree that having the flow of the transition move against the player gives a nice sense of movement in that direction so the direction can be customized for each entrance/exit. As for music, I'll be trying my hand at that myself. It might be hubris on my behalf but it's something I'm looking forward to trying.
The player prediction is a really cool idea, if you can't get it too work 100% consistently you could maybe still use it to influence random behavior which is telegraphed. I can see how there could be problems with deep and shallow copies especially if you start simulating player projectile structs. Maybe having scripted enemy reactions to the player state would be better.
I think about stuff like that enemy reaction time simulation a lot. Of course it remains to be seen what sort of impact it actually has on Betelgeuse, but fingers crossed that it works out. I've gotta point out - for anyone interested - a video on my channel called "Enemy misdirection demo," (I recommend reading the description) to show how much this sort of gameplay seems like kind of a dream feature for me.
Regarding enemy predictions, you might want to look into Will You Snail, which is a recent 2D platformer, built on the idea of traps being spawned where you are supposed to go. The developer used a system very similar to yours: the AI assumes that you will keep holding the same button. One thing that he added was randomness: if you turn on the prediction path (which is actually an in-game option) you will see it branch out at the end to emulate random input and give the player some leeway. However, because of this, even in his own playthrough, the developer often stands in front of some difficult places and just tries to bait the AI. I personally find such situations very undesirable. I suppose, I am now answering a yet-to-be-asked question, but randomness is probably something to be avoided. As for intelligent enemies, the game that did it most memorably for me was the first Halo. They were done so impeccably, that one of the Elites actually became the second protagonist in Halo 2 and it felt absolutely right. I can not recommend Bungie's "The Illusion of Intelligence" talk enough. Aside from very practical pieces of advice that they gave (behaviour trees, barks, etc.) one thing that I found very thought provoking was that players found enemies with more HP and damage more intelligent. Not the most incredible idea, I know, but something to think about, making one enemy harder than the other. It would be very interesting to see what you can come up with!
on the ghost prediction stuff, for a less robust but much simpler approach you could store a small subset of actor information and project that forward in time e.g. position+velocity would give a naive prediction that would end up projecting into walls, and wouldnt deal with a player falling in an arc adding the current bounding box of that frame would give rudimentary collision detection, tracking acceleration or forces could give rudimentary tracking of arcs, etc. potentially you could calculate a few different predictions, and assign different enemies different predictions based on intelligence. an enemy estimating the time it would take for its projectile to reach the player, and then projecting forward that extra time to lead its shot could be neat realistically i dont think even a human makes predictions all that accurately. some things like a parabolic arc are pretty intuitive, but realizing that someone is going to collide with an obstruction, and accounting for it in realtime when you try to e.g. lead rockets in quake is not easy
you can, when considering projected locations, make it so that the range of possible projected locations coincides with the range of possible player locations. So you can't trick enemies into shooting a wall or something if you're running against it.
38:20 isn't that why a bunch of 2D games or 3D platformers have an animation of the pc peering over the edge or 'teetering'? I imagine in that state, the bounding box could change to lock you onto the edge and any input towards it makes you fall off and the player is visually informed they're as close as they can get to the edge
I might be wrong but in most of those older games the bounding box probably doesn't change width at all so they don't have that problem. The character teetering is most likely just a visual flourish in the vast majority of cases. Even so, that's an interesting solution to the problem. I'm curious now if there is some game where the teetering animation saves you from a fall.
@@matthewmatosisextra A variation comes up in Sonic Heroes if I remember correctly, but it's more that the game stops you from just running off ledges unintentionally with the animation being a visual indicator of being a step away from falling from the given surface. I can't think of a 2D example, unfortunately.
ah another appreciator of the Richter moveset, i actually was making a castlevania project in unity but kept hitting a wall at super basic things like animations and...basically gave up on it lol huh...the lag between loading was a thing in SotN for bosses enemy reaction time is an interesting idea
I may have misunderstood the problem behind the frame A / frame B thing but if you want to be able to react to the button press cleanly (while in the correct state which is a very good idea indeed) you could consider doing input buffering where you keep the button press for X number of frames and then consume the button press on the first frame of the next state.
I’m glad you’re choosing to handcraft these rooms rather than have them procedurally generated. There’s just something so soulless about computer generated levels.
On the subject of screen / room transitions, is Game maker capable of scrolling between rooms? It's the style used in Megaman which you alluded to, but also used in Castlevania 3 and Bloodstained CotM. I can't recall whether the project you're working on is supposed to be the one that's like "Rondo 2", but Rondo just flashes black for the screen changes which I think is a lot less gratifying. The scrolling transition has a lot of upsides IMO for this style of game if you can implement it: - provides visual continuity between rooms but also feels like a mental checkpoint / compartmentalization for the player which contributes to a sense of achievement and progress - gives the player a chance to visually register the visuals and hazards in the next room and also to the player character's new position on the screen before they're asked to react with inputs - lets you conceal / gloss over loading, which I know you said isn't an issue right now but seems like it eventually might be Megaman 2 tends to place too many of these transitions too close to each other and it gets annoying, and Vania 3's animation is a little too slow for me (maybe due to NES limitations), but Bloodstained's implementation is pretty much perfect IMO. Might be worth looking at (and a great game besides)
Have you played the remake of La-Mulana? In that game, there is no scrolling within a "room" (in quotes because this also applies to outdoors areas) and when you transition between rooms, time freezes while the screen scrolls to the new position, similar to Super Metroid except the background tiles are not blackened.
Hey mate, been getting into game design myself lately. Love seeing these updates, really gets the brain juices going. Regarding the frame calculations you mentioned, are you using frame deltas for the game at all, or planning on sticking to a fixed framerate?
I think you should decrease the height of the uppercut (more so the aerial version of the uppercut) to prevent infinites and I think the player hitboxes should be bigger to make these moves more intuitive to use.
Throughout the video, you keep referring to 'we' when talking about the game development. Do you have an actual team, or are you just using the royal we? Also, Morrowind has a somewhat similar system for predicting player movement with its projectiles.
It sounds like you're coupling the animation system to the state of the character. For the vast majority of time they will be 1:1 in sync, but for those small bits that were mentioned, they aren't. I think that's the problem.
I respect the amount of thought going into this player prediction system, but it sounds like you’re probably putting more detail into it than a player would ever notice during the game. I don’t think the player would really notice that the enemies are responding, for example, to a not-quite-accurate prediction of your fall, in the heat of the moment.
Why are you treating the predictive player simulation so rigorously? If I were to try my hand at that, rather than simulate the player character entirely (as if you're coding Rollback Netcode), you could more easily run it in vectors. Ask, "Where is the player now (absolute reference), where were they 0.5 seconds ago(absolute reference)? Invert previously assumed vector." You could *emit it* from the player as a physics object, and have it collide with geometry in the player path, so enemies know not to guess you'll be on the other side of a wall or some stupid crap. You could emit it using the same code as the effects in your previous videos. If you emit it in such a way, you can also limit how many "checks" the game engine does. Per-frame? Per-3 frames? Inherently less accurate than your idea. Does that inaccuracy make the AI more or less believably intelligent/stupid? I don't know if that's detailed enough for your intentions. Sorry for sticking my nose in.
It's a good question. For many actions this would work but there are some where it wouldn't. All of this depends on implementation of course but for the sake of example, imagine the slide. In order to get the exact motion I want without driving myself mad, it doesn't work like real life where there are specific forces applied at discreet moments. Rather there is a curve of (perhaps constantly changing) forces relating to speed/acceleration/friction. In a slide, the friction ramps up towards the end so the player character comes to a stop more quickly. If we just take the physics of the current frame and apply them repeatedly we might get a wrong answer because we're on the peak of an acceleration or friction curve. You can see how much this matters by noticing how drastically different my vault speed is depending on when I do it. The vault basically just pushes the character off the ground, removes all friction and preserves horizontal speed from before. That means an early vault will move extremely quickly compared to a later vault. In other words enemies need to have a sense of how the players actions will change over time. Otherwise they will see a massive overshoot every time the player begins a slide just because the acceleration peaks there and the friction hasn't ramped up yet. This is difficult to explain through text but hopefully I've given you some idea.
@@matthewmatosisextra Thanks for your time. I get the gist. The prediction method I said is extremely inaccurate if you consider the minute changes within even that one animation, yes. Or even the arch of a jump. I think I underestimated the actual gameplay difficulty you intend. I had assumed the inaccuracy was acceptable, as it would still be a vague enough prediction to *insinuate* enemy intelligence. But the genuine accuracy you intend would be far more important for projectile-firing enemies, or such.
@@wetigaz stop white knighting. If you don’t think 90% of his fan base are subscribed because of demons souls and dark souls you’re naive. Very few people give a shit about his retro platformer
I still remember watching your streams years back where you said that you one day wanted to pursue game making. Still such a surreal experience yet I'm very happy that you're doing it!
Watching these dev logs really highlights how much I take for granted when I'm playing games. Every single aspect requires so much consideration- like the Frame A, Frame B thing. As always, keep up the great work!
It's a nice combination of "art" and science.
This is cool shit man transitioning from critic to developer is pretty inspiring
I hope people become more aware of the second channel so they stop asking stupid questions about where you are.
I do get a lot out of these, Matthew. It's insightful, and the prospect that my favorite critic could also become one of my favorite devs gives me a lot of enthusiasm.
Proceed in your endeavors and I wish you the best!
Hey Matt. The ghost/prediction thing you're working on is called Dead Reckoning. It's a common thing in multiplayer games and there's a lot of existing theory written about implementations and how to make it work as smoothly as possible. Might be worth reading into.
Thanks, this seems like it could be a useful term for research.
Pretty badass name lol
Can't say I don't miss your Videos but I'm happy that you are making your own Video Game and can't wait to play it someday : ]
What program is he using?
@@EgoHead710 It's gamemaker studio 2 I think
@@ToastieMcMuffin Thanks lad.👍👍👍
Wonderful video, the streams and development updates on this channel got me into ghosts and goblins and I've absolutely loved it. I loved it so much that when tasked to remake a retro game in gmk2 for school I decided to try make my own gobshite platformer.
These videos provide such helpful little insights, I've caused myself a lot of problems because the way I grab data is rubbish, but hearing your explanation of it made me actually understand why I kept needing to change values and things and stuff.
Keep up the good work MatthewMatosis Extra!!
Always happy to hear from you man, hope you’re doing well. Keep it up and thanks for the box of fleas.
It sounds like you're overcomplicating the whole frame A/B thing, and ultimately it's personal preference per action. I think that referring to fighting games would help immensely, specifically "Links" (Frame B), and "Cancels" (Frame A).
Linking actions is when you perform an action immediately after the previous action completes in it's entirety, whereas canceling an action involves the player inputting another action at a predesignated cancel point. As to when/where these cancel points are is obviously up to the designer, but typically speaking it's during the active/recovery portion of the action, and possibly limited to whether or not the action made contact with an enemy.
I don't think I can post direct links here, but "Infil's Fighting Game Glossary" can help elaborate on both.
yeah this
I'm fine with using those terms. Still, whatever you call them, I needed to decide that I want the default behaviour to be a Link rather than a Cancel and to write the code that made it work that way. Unless I'm misunderstanding something, I don't think I overcomplicated the problem at all except for using different terminology.
@@matthewmatosisextra I suppose I misused "overcomplicating"; I don't think I fully understood your dilemma until the frame-by-frame breakdown in this video, after which the fighting game terminology came to mind and the pieces finally fell into place. I guess you could say I overcomplicated it.
Regardless - It seems you know what you're doing and it's good to see that you've got things sorted out. Looking forward to seeing more.
I see. Sorry if it seemed like I was being nitpicky about the overcomplication thing, I just wanted to know if there was something more fundamental that I overlooked. Glad it all makes sense now, my stream explanations are not always great.
@@matthewmatosisextra Another great term relates to your "bullshit frame A even though your system is frame B" comment near the start: IASA frames!
Interruptible As Soon As (IASA) frames:
Suppose you have some 30 frame animation for some attack. If they do nothing, you want the last 3 frames to be a natural transition back to their idle pose, but you don't want to see it if they do another attack. You mark frames 27-30 as IASA frames, and apply a standard set of rules across all states instead of the normal state transition rules, while continuing to play the recovery animation if they do nothing. (These rules are going to be pretty much the same as your normal air-idle and ground-idle state transitions, but in some games, there are slight differences. Maybe you can do attacks, but not walk, for example.)
This term is used in Smash games mostly. It is also explained in detail in some GDC talk from a Skullgirls animator; she wanted the jab to be fast, but it looked weird to snap right back to idle if you did nothing afterwards. So, this animator made the engine programmers add this system. The main advantage is that you don't have to add special cases to every animation, just the single number of IASA frames that gets handled the same way across multiple states.
In Atari's Transformers (2004), enemies start shooting projectiles ahead of the player's position after the player reaches a certain momentum value. The player has ~ 4 different walking speeds whose future positions can all be predicted and synchronized with projectile travel time by the enemy AI. Projectiles are also bright energy spheres whose positions are easy to read, even when 20+ are on screen. This encourages the player to change their speed or direction, jump, evade, or pull up a shield much more frequently than required for simple strafing. It's an interesting idea to have something like this or the Ganado reaction in a game with two dimensions, and would probably help build the grounded world and enemy aesthetics you're chasing too.
I like this idea especially since when I throw something (say) to a moving person, I take into account their velocity / acceleration / direction and use that to predict where they'll be. That is just part of what it means to shoot at a moving target, I guess.
Here you are, Matthew. It's always a pleasure.
Fleas are one of the most vile, irritating, evil bloodsuckers I've ever had the displeasure of dealing with. And Matthew goes and codes them in as the first enemy in his game. Well done.
Jokes aside, I like these little developer vlogs. I hope you don't get too hung up on people being upset something you were tinkering with not making it to the end of development. I would like to believe that most would understand that not everything can make the cut.
The position history/prediction system is fascinating. It reminds me of how prediction based rollback netcode for online fighting games works.
46:50 Matthew over here still mad that dark souls 3 had that giant archer with homing arrows and trying to come up with something much better for his game.
Seriously though it's fine if doesn't go anywhere but that prediction system could be really cool, at least for the more complex enemies, for the simple ones I don't think it would make a big difference.
EDIT: as an extra, this is directly for Matthew, maybe those enemies you mention from bayonetta and RE4 are just checking the player's position + the player's speed and direction? So instead of just checking if the player is currently in range they check if the player is gonna be in range after X amount of time simply based on multiplying those values
It's kinda crazy how far your game has come along
38:00 from the way you describe the problem it sounds like you're using the hit box (when the character can be hit) as the bounding box (where the character collides with terrain). These are usually seperate things with the bounding box staying the same size across all animations to prevent clipping and the hit boxes being frame specific to match the character's pose. Usually the only animations that would have different bounding boxes are slides/crouches, which keep the same width but are just shorter.
I am. The way I see it, if you can collide with terrain at a certain point you can also get hit there. I might also add hurtboxes as a separate thing later (to have additional damage zones on larger or oddly shaped enemies I imagine) but I think either way I would want a solution to what happens if/when the bounding box changes shape. Thankfully that part seems to be done. Fingers crossed.
Been a fan of your content for at least a decade now. Hope you’re doing well.
Glad to hear from you again. Guess I'm missing a lot from your dairies on patreon. It's good reminder for me to check those out. Game dev Matt sounding as passionate as the last update.
On the instantaneous room transition:
Unless you plan to have super big rooms with a ton of instances loading them super quickly like that won't be an issue until you start having a lot of sprites in your game.
The way Game Maker handles sprites by default is to cram all of them into texture pages, and by cram I mean it tries to fit sprites into transparent pixels to have as few texture pages as possible. Whenever a room is loaded, Game Maker grabs all the texture pages that will be needed in that room. The problem with this is that by default there's no designation for what sprites should go together on each texture page, so you could end up having some random enemy sprite put on a texture page with sprites used for the title screen, so now whenever you're loading that enemy you're also fetching a bunch of other sprites that you're not even going to be using.
Long story short, if you make good use of "Texture Groups" in Game Maker you should be able to keep that instant transition between rooms, so long as said rooms aren't absurdly large.
Very good to see you're still kicking, and nice work here. Anything is far better than nothing, since i think we're subscribed to matthewmatosis come what may, rather than a particular series.
Ah, it's like Christmas morning.
In regards to your predictive enemies I've definitely seen simplistic versions where enemies who shoot projectiles will lead their shots if you're moving. I'm pretty sure it happens in the final boss in Banjo Kazooie. I reckon I've seen in in a few 2D games too.
"We might have X" is a very dangerous phrase
With the screen transitions, it might be neat to have different wipe directions depending on which direction the player is leaving the screen. I do like the flow happening at 11:08, where the transition movement begins on the side the player leaves, then ends on the side the player starts the screen on. Metroid has a somewhat similar idea, where after you enter a door, it'll move to where you'll be entering a room. Sort of letting the player know where they'll be appearing when the next room starts.
Also, when it comes time and if you're looking for someone to do music, I would be more than happy to contribute.
That's already implemented actually. I agree that having the flow of the transition move against the player gives a nice sense of movement in that direction so the direction can be customized for each entrance/exit. As for music, I'll be trying my hand at that myself. It might be hubris on my behalf but it's something I'm looking forward to trying.
The player prediction is a really cool idea, if you can't get it too work 100% consistently you could maybe still use it to influence random behavior which is telegraphed. I can see how there could be problems with deep and shallow copies especially if you start simulating player projectile structs. Maybe having scripted enemy reactions to the player state would be better.
Cool to see the progress! Keep on keeping on!
I think about stuff like that enemy reaction time simulation a lot. Of course it remains to be seen what sort of impact it actually has on Betelgeuse, but fingers crossed that it works out. I've gotta point out - for anyone interested - a video on my channel called "Enemy misdirection demo," (I recommend reading the description) to show how much this sort of gameplay seems like kind of a dream feature for me.
Regarding enemy predictions, you might want to look into Will You Snail, which is a recent 2D platformer, built on the idea of traps being spawned where you are supposed to go. The developer used a system very similar to yours: the AI assumes that you will keep holding the same button. One thing that he added was randomness: if you turn on the prediction path (which is actually an in-game option) you will see it branch out at the end to emulate random input and give the player some leeway. However, because of this, even in his own playthrough, the developer often stands in front of some difficult places and just tries to bait the AI. I personally find such situations very undesirable. I suppose, I am now answering a yet-to-be-asked question, but randomness is probably something to be avoided.
As for intelligent enemies, the game that did it most memorably for me was the first Halo. They were done so impeccably, that one of the Elites actually became the second protagonist in Halo 2 and it felt absolutely right. I can not recommend Bungie's "The Illusion of Intelligence" talk enough. Aside from very practical pieces of advice that they gave (behaviour trees, barks, etc.) one thing that I found very thought provoking was that players found enemies with more HP and damage more intelligent. Not the most incredible idea, I know, but something to think about, making one enemy harder than the other.
It would be very interesting to see what you can come up with!
on the ghost prediction stuff, for a less robust but much simpler approach you could store a small subset of actor information and project that forward in time
e.g. position+velocity would give a naive prediction that would end up projecting into walls, and wouldnt deal with a player falling in an arc
adding the current bounding box of that frame would give rudimentary collision detection, tracking acceleration or forces could give rudimentary tracking of arcs, etc.
potentially you could calculate a few different predictions, and assign different enemies different predictions based on intelligence.
an enemy estimating the time it would take for its projectile to reach the player, and then projecting forward that extra time to lead its shot could be neat
realistically i dont think even a human makes predictions all that accurately. some things like a parabolic arc are pretty intuitive, but realizing that someone is going to collide with an obstruction, and accounting for it in realtime when you try to e.g. lead rockets in quake is not easy
you can, when considering projected locations, make it so that the range of possible projected locations coincides with the range of possible player locations. So you can't trick enemies into shooting a wall or something if you're running against it.
How much of the controls will be dedicated to camera movement?
38:20 isn't that why a bunch of 2D games or 3D platformers have an animation of the pc peering over the edge or 'teetering'? I imagine in that state, the bounding box could change to lock you onto the edge and any input towards it makes you fall off and the player is visually informed they're as close as they can get to the edge
I might be wrong but in most of those older games the bounding box probably doesn't change width at all so they don't have that problem. The character teetering is most likely just a visual flourish in the vast majority of cases. Even so, that's an interesting solution to the problem. I'm curious now if there is some game where the teetering animation saves you from a fall.
@@matthewmatosisextra A variation comes up in Sonic Heroes if I remember correctly, but it's more that the game stops you from just running off ledges unintentionally with the animation being a visual indicator of being a step away from falling from the given surface. I can't think of a 2D example, unfortunately.
ah another appreciator of the Richter moveset, i actually was making a castlevania project in unity but kept hitting a wall at super basic things like animations and...basically gave up on it lol
huh...the lag between loading was a thing in SotN for bosses
enemy reaction time is an interesting idea
Very mysterious & exciting!
27:20 free the fleas
Farming souls in demons souls emulated while listening to this... Makes the grind fun actually.
These update videos are very inspirational. It's great to see the improvements! Are the streams coming back anytime soon? I really miss them.
I may have misunderstood the problem behind the frame A / frame B thing but if you want to be able to react to the button press cleanly (while in the correct state which is a very good idea indeed) you could consider doing input buffering where you keep the button press for X number of frames and then consume the button press on the first frame of the next state.
I’m glad you’re choosing to handcraft these rooms rather than have them procedurally generated. There’s just something so soulless about computer generated levels.
Even if you don't use the trail for gameplay purposes, it could still be a cool visual effect like with Alucard in Symphony of the Night
coomed when I saw the notification
On the subject of screen / room transitions, is Game maker capable of scrolling between rooms? It's the style used in Megaman which you alluded to, but also used in Castlevania 3 and Bloodstained CotM. I can't recall whether the project you're working on is supposed to be the one that's like "Rondo 2", but Rondo just flashes black for the screen changes which I think is a lot less gratifying. The scrolling transition has a lot of upsides IMO for this style of game if you can implement it:
- provides visual continuity between rooms but also feels like a mental checkpoint / compartmentalization for the player which contributes to a sense of achievement and progress
- gives the player a chance to visually register the visuals and hazards in the next room and also to the player character's new position on the screen before they're asked to react with inputs
- lets you conceal / gloss over loading, which I know you said isn't an issue right now but seems like it eventually might be
Megaman 2 tends to place too many of these transitions too close to each other and it gets annoying, and Vania 3's animation is a little too slow for me (maybe due to NES limitations), but Bloodstained's implementation is pretty much perfect IMO. Might be worth looking at (and a great game besides)
Have you played the remake of La-Mulana? In that game, there is no scrolling within a "room" (in quotes because this also applies to outdoors areas) and when you transition between rooms, time freezes while the screen scrolls to the new position, similar to Super Metroid except the background tiles are not blackened.
Would you consider sharing your collision code? I'm doing pixel art games in GMS2 as well and would love to see how you dealt with this famous problem
He's alive?
He's alive!
🔥🔥🔥
Hey mate, been getting into game design myself lately. Love seeing these updates, really gets the brain juices going. Regarding the frame calculations you mentioned, are you using frame deltas for the game at all, or planning on sticking to a fixed framerate?
Could I inquire how you started your game making journey? I'd like to expand my library of learning resources.
matt come back making videos
We need an Elden Ring critique/commentary
Cool
I think you should decrease the height of the uppercut (more so the aerial version of the uppercut) to prevent infinites and I think the player hitboxes should be bigger to make these moves more intuitive to use.
He's said he's not going to use Richter in the final game so it doesn't matter.
Throughout the video, you keep referring to 'we' when talking about the game development. Do you have an actual team, or are you just using the royal we? Also, Morrowind has a somewhat similar system for predicting player movement with its projectiles.
I believe his partner is doing the art for this game.
@@kidnameless ohh, that awesome ✌️
Ill take whatever i can get
my commit message be like
It sounds like you're coupling the animation system to the state of the character. For the vast majority of time they will be 1:1 in sync, but for those small bits that were mentioned, they aren't.
I think that's the problem.
I respect the amount of thought going into this player prediction system, but it sounds like you’re probably putting more detail into it than a player would ever notice during the game. I don’t think the player would really notice that the enemies are responding, for example, to a not-quite-accurate prediction of your fall, in the heat of the moment.
If enemies with projectiles are able to lead their shots and hit the player more often then it will definitely have an impact
i know this might be a silly question, but aren`t you afraid that due to your small slice of fame, that your game might be judged harshly?
That Elden Ring review though, that Elden Ring review....
this is just like elden ring
abes oddysee custom maps.
really interesting stuff!!! that player prediction stuff reminds me a lot of the way rollback netcode works if you know that.
Happy Beltane
Holy shit you're alive!
Why are you treating the predictive player simulation so rigorously?
If I were to try my hand at that, rather than simulate the player character entirely (as if you're coding Rollback Netcode), you could more easily run it in vectors.
Ask,
"Where is the player now (absolute reference), where were they 0.5 seconds ago(absolute reference)? Invert previously assumed vector."
You could *emit it* from the player as a physics object, and have it collide with geometry in the player path, so enemies know not to guess you'll be on the other side of a wall or some stupid crap.
You could emit it using the same code as the effects in your previous videos.
If you emit it in such a way, you can also limit how many "checks" the game engine does. Per-frame? Per-3 frames?
Inherently less accurate than your idea.
Does that inaccuracy make the AI more or less believably intelligent/stupid?
I don't know if that's detailed enough for your intentions. Sorry for sticking my nose in.
It's a good question. For many actions this would work but there are some where it wouldn't. All of this depends on implementation of course but for the sake of example, imagine the slide. In order to get the exact motion I want without driving myself mad, it doesn't work like real life where there are specific forces applied at discreet moments. Rather there is a curve of (perhaps constantly changing) forces relating to speed/acceleration/friction. In a slide, the friction ramps up towards the end so the player character comes to a stop more quickly. If we just take the physics of the current frame and apply them repeatedly we might get a wrong answer because we're on the peak of an acceleration or friction curve. You can see how much this matters by noticing how drastically different my vault speed is depending on when I do it. The vault basically just pushes the character off the ground, removes all friction and preserves horizontal speed from before. That means an early vault will move extremely quickly compared to a later vault. In other words enemies need to have a sense of how the players actions will change over time. Otherwise they will see a massive overshoot every time the player begins a slide just because the acceleration peaks there and the friction hasn't ramped up yet. This is difficult to explain through text but hopefully I've given you some idea.
@@matthewmatosisextra Thanks for your time.
I get the gist. The prediction method I said is extremely inaccurate if you consider the minute changes within even that one animation, yes. Or even the arch of a jump.
I think I underestimated the actual gameplay difficulty you intend.
I had assumed the inaccuracy was acceptable, as it would still be a vague enough prediction to *insinuate* enemy intelligence.
But the genuine accuracy you intend would be far more important for projectile-firing enemies, or such.
Great Video Guys Lol
Elden Ring Critique?
YOOO
What kind of review is this
When are you making an Elden Ring video
Never ever
can't you see that's an annoying comment for the guy to read?
Nada
He said he isn't planning on making one, he hasn't even played it yet I think; he said he was waiting for a PC upgrade iirc
@@wetigaz stop white knighting. If you don’t think 90% of his fan base are subscribed because of demons souls and dark souls you’re naive. Very few people give a shit about his retro platformer
*yawn*