I have a personal set of if/then statements when it comes to a bug: Is it an entertaining bug? If no, then try to patch it. If yes, then does it break the game too much? If no, then keep it. If yes, then does this bug require complex skill to achieve and feel rewarding to abuse? If no, then try to patch it. If yes, then does it break the balance of a game? If no, then keep it. If yes, then try to patch or at least nerf it. I live by these rules, and I shall die by them.
This is an amazing rule set! Exactly how a lot of "features" were added some games like Team Fortress and TF2 that are now modern staples like rocket jumping. Also makes me think of bunny hopping in older game engines like quake but they didn't necessarily have the means to patch bugs for some older games.
I had this in the background whilst playing Celeste to learn a little more, and oh my GOSH the mention of Celeste as an exception threw me for a loop, lol. Thanks for the content, and taking your time to teach us all a little something we may not know!
There is one thing you should add to openkcc and that is camera lerping. Basically make the camera position a empty gamemobject and make the camera always keep to it = smooth camera movement
Yes, I wrote a basic ~~keeping~~ _camera follow_ script already but it uses frames and delta time to lerp so it varies with frame rate a bit. I want to write an extension to work with CinemaMachine program from Unity to support a really customizable camera :) I couldn’t get some of the keeping to work well without the camera clipping through walls but I could extend the current script to include lerping in the target position to make it a bit more smooth!
I can't justify putting in the amount of effort for automatic testing when I am developing "creative" ideas. Those tend to change so drastically that it would make all tests redundant all the time, and just waste time. But I do appreciate them in my job where we do more streamlined stuff and still we only stick to testing main C# classes. I just hope that new game developers, who have not even made a first project, are going to see this and immediately think you need to make tests. It could be a nice learning exercise, but I cannot justify this for smaller projects especially when you are new to this field. Also automated testing is never going to test all cases unless you spend 10x time in dev (at which point you could have just tested it manually and find these bugs anyway). But I do understand the value for yourself when you are developing mature package for others to use. People should know the context a bit more.
I love this insight, thanks for the thoughtful comment. I completely agree that most games and project don't need exhaustive testing and manual testing can work fine especially when you want to iterate quickly. However, thinking only complete or library projects require testing is missing some context. Every game unless it's just composited pre-made assets will have some degree of custom code. If you are using well known design patterns, you will have some boilerplate or structure code in your project. So, for example, if you have a game with tile maps you might need some custom pathfinding adjustments for different types of movement or graph traversal. While you won't need to test every part of this, you want to make sure your core features for pathfinding and UI interactions are tested because if they break the product may become unusable. So, while reaching for something like 100% code coverage is unreasonable for almost any project, automated testing of core features and designs is important to ensure product stability. I would have liked to talk about this more in the video but differentiating between core features and how automated testing works versus manual testing and how this is integrated into an agile development workflow is a much bigger topic than I could fit into a short video. Might but a fun future topic though! Unity also is capable of recording and playback input to turn a manual test into an automated test, but I haven't messed around with it as much.
Once I was playing the first Assassin's Creed on PS3 and I jumped on a horse and immediately fell through the ground and died. Intangible horse for the lose.
You talked about the stair script, i also noticed that you used a position changing script to move the character, why not use velocity instead to make for more fluid movement and for the stairs just make the collision box a slope? (Im no game developer but its just an idea)
Yep, I completely agree. I’m 3 years in on this OpenKCC project and have a lot left to go! Part of why I’m making these videos to document and share my work so others can help provide feedback and reviews of the project.
Why stairs are a pain is a whole video topic in itself, more stuff acts like stairs than just a set of stairs and a ramp can’t solve every edge case. But for most cases it does work fine. I’m planning on making a future video about the topic.
The Mario backwards staircase is more iconic than a bug
It’s a “feature”. Too bad Nintendo patched it out of later releases :’(
Thats why we look toward emulation
It's an iconic bug
I have a personal set of if/then statements when it comes to a bug:
Is it an entertaining bug?
If no, then try to patch it.
If yes, then does it break the game too much?
If no, then keep it.
If yes, then does this bug require complex skill to achieve and feel rewarding to abuse?
If no, then try to patch it.
If yes, then does it break the balance of a game?
If no, then keep it.
If yes, then try to patch or at least nerf it.
I live by these rules, and I shall die by them.
This is an amazing rule set!
Exactly how a lot of "features" were added some games like Team Fortress and TF2 that are now modern staples like rocket jumping.
Also makes me think of bunny hopping in older game engines like quake but they didn't necessarily have the means to patch bugs for some older games.
I love playing tea for two
I like this, so I hope you don’t mind me taking a screenshot to save as a reminder.
I had this in the background whilst playing Celeste to learn a little more, and oh my GOSH the mention of Celeste as an exception threw me for a loop, lol. Thanks for the content, and taking your time to teach us all a little something we may not know!
I like these videos very listenable
Thanks!
There is one thing you should add to openkcc and that is camera lerping. Basically make the camera position a empty gamemobject and make the camera always keep to it = smooth camera movement
Yes, I wrote a basic ~~keeping~~ _camera follow_ script already but it uses frames and delta time to lerp so it varies with frame rate a bit. I want to write an extension to work with CinemaMachine program from Unity to support a really customizable camera :)
I couldn’t get some of the keeping to work well without the camera clipping through walls but I could extend the current script to include lerping in the target position to make it a bit more smooth!
I can't justify putting in the amount of effort for automatic testing when I am developing "creative" ideas. Those tend to change so drastically that it would make all tests redundant all the time, and just waste time. But I do appreciate them in my job where we do more streamlined stuff and still we only stick to testing main C# classes.
I just hope that new game developers, who have not even made a first project, are going to see this and immediately think you need to make tests. It could be a nice learning exercise, but I cannot justify this for smaller projects especially when you are new to this field.
Also automated testing is never going to test all cases unless you spend 10x time in dev (at which point you could have just tested it manually and find these bugs anyway).
But I do understand the value for yourself when you are developing mature package for others to use. People should know the context a bit more.
I love this insight, thanks for the thoughtful comment. I completely agree that most games and project don't need exhaustive testing and manual testing can work fine especially when you want to iterate quickly.
However, thinking only complete or library projects require testing is missing some context. Every game unless it's just composited pre-made assets will have some degree of custom code. If you are using well known design patterns, you will have some boilerplate or structure code in your project. So, for example, if you have a game with tile maps you might need some custom pathfinding adjustments for different types of movement or graph traversal. While you won't need to test every part of this, you want to make sure your core features for pathfinding and UI interactions are tested because if they break the product may become unusable. So, while reaching for something like 100% code coverage is unreasonable for almost any project, automated testing of core features and designs is important to ensure product stability.
I would have liked to talk about this more in the video but differentiating between core features and how automated testing works versus manual testing and how this is integrated into an agile development workflow is a much bigger topic than I could fit into a short video. Might but a fun future topic though! Unity also is capable of recording and playback input to turn a manual test into an automated test, but I haven't messed around with it as much.
2:47 he's joking. We don't have any friends
Na, if I've learnt one thing from AAA games of today, it's that you just let the modding community fix it!
0:58 this guy is playing with a left handed view model on the right side?
Hehe, didn’t notice that.
Stock footage intensifies
Once I was playing the first Assassin's Creed on PS3 and I jumped on a horse and immediately fell through the ground and died.
Intangible horse for the lose.
You talked about the stair script, i also noticed that you used a position changing script to move the character, why not use velocity instead to make for more fluid movement and for the stairs just make the collision box a slope? (Im no game developer but its just an idea)
Awesome video. I've started writing tests in my own game last week. It's taking a long time but hopefully it's going to pay off.
Always hard to add tests to a project but once you have them there it’s much easier to maintain over time. Best of luck, you got this!
I like the new video clips!
Thanks!
Pro tip from years of pain: A good, generic CC is a huge problem to solve. Like creating an AI package. Or a network library.
Yep, I completely agree. I’m 3 years in on this OpenKCC project and have a lot left to go! Part of why I’m making these videos to document and share my work so others can help provide feedback and reviews of the project.
Bunny!!!!! 🥰🐇
His name is Clyde, he is very cute and loves blueberries!
What I do in my games is put a death trigger in the walls so if you managed to get in then your back at the latest checkpoint
That’s a good idea to prevent players clipping through walls :D
If they can clip through the wall, then what's stopping them from clipping through the death trigger?
@@FalconFetus8the same thing that usually stops them from going through collisions
This was a great video!
Thanks, glad you enjoyed it!
Why don't you just give the stairs a sloped hitbox?
Why stairs are a pain is a whole video topic in itself, more stuff acts like stairs than just a set of stairs and a ramp can’t solve every edge case. But for most cases it does work fine. I’m planning on making a future video about the topic.
2:50 "to avoid social embarrassment..." ...just get more self confident ;)
Thanks! Hope you have a good day too.
Promo sm 🤦