IndianaBones
Member
Reviews and Rankings posted:
https://forum.yoyogames.com/index.p...cal-gmc-jam-8-voting-topic.48061/#post-296836
https://forum.yoyogames.com/index.p...cal-gmc-jam-8-voting-topic.48061/#post-296836
That's very strange. I get no crashes with the player flashing when damaged, and that's with both the version included in the zip with the other entries, and with the executable I created from the gmz you provided. I had GMS closed while playing, and I played plenty long, testing it out, taking and giving damage. Flashes but no crashes.
My version of GMS1 is 1.4.1788 (not the latest) and I targeted Windows (YYC), but this might not be worth mentioning, since even the original jam entry works fine for me.
@Ziberteck @penguin533Possible that GM is bypasses/auto-correcting an error at compile time that doesn't get fixed in the actual build. I've never seen it happen before, but I can only guess that's what's happening because of this line:
You're using an int in your fragment shader here -- vec3( > 1 < , 0.9, 0.9 ) -- but afaik, you're required to use floats when declaring a color. The logic of the shader seems fine, but this type of syntax error usually keeps my program from even compiling even in the IDE, so it's interesting that you somehow got past this. Change it to be '1.0' and see if the build still crashes?Code:gl_FragColor.rgb = vec3(1,0.9,0.9);
EDIT: wait, I just tested this out in my own shader and got no errors in the IDE or the build, so actually it seems I'm wrong about the requirement of floats when declaring a component of a color. Sorry!
Assuming you meant the time rewinding, it was a combination of two things. Some elements were made deterministic, so that we could calculate what their position should be solely based on how much time has passed (e.g. x = speed * time, rather than the more normal x += speed). For more complicated objects, we stored position, health, etc. for each frame in a wrapping buffer, and then we just read through the buffer backwards while rewinding.How did you program that?
Awesome, that makes sense. By wrapping buffer you mean a ds_list or ds_stack?Assuming you meant the time rewinding, it was a combination of two things. Some elements were made deterministic, so that we could calculate what their position should be solely based on how much time has passed (e.g. x = speed * time, rather than the more normal x += speed). For more complicated objects, we stored position, health, etc. for each frame in a wrapping buffer, and then we just read through the buffer backwards while rewinding.
No, literallyBy wrapping buffer you mean a ds_list or ds_stack?
buffer_create(4800, buffer_wrap, 8)
Your game was awesome.Damn, so close to the top three.
Anyways, Congratulations to the winners, and to everyone for participating!
dittocongrats to everyone I hoped for a top 20 but 25 is pretty nice and a lot way better than my last 41th position I hope to get better on the next jam, congrats to all the amazing games the quality of this jam was higher than the usual I think and Im really impressed by all those that keep getting amazing games every jam... I hope one day being like you guys!
Your game was very cool. I think in any other jam it would have been #1. There were just sooo many good entries. But yeah, I could have easily picked yours for first.Congrats everyone! I will make videos for the top 6 (because I was 5th, and I can't play that one), because I couldn't do reviews before.
WE got 5th place and Best use of Theme, which is the best I've ever done on a game jam (that I programmed for. Doing music for JacobV last jam doesn't quite count. It was awesome, but I'm a programmer, and just sometimes a composer).
Very generous of you! Thank you very much.Ok so I've decided to throw in another prize for everyone!
I've made all my assets on the marketplace free until Friday so download them if you want:
https://marketplace.yoyogames.com/publishers/534/coded-games
Many thanks. I'll probably never use them, but I might check out the inventory stuff. I have this weird thing about not wanting to use other people's code assets, due to a fear of not knowing the code as well as I'd like, having the assurance of knowing exactly what my game logic is doing.Ok so I've decided to throw in another prize for everyone!
I've made all my assets on the marketplace free until Friday so download them if you want:
https://marketplace.yoyogames.com/publishers/534/coded-games
Hope more people follow your leadOk so I've decided to throw in another prize for everyone!
I've made all my assets on the marketplace free
Oh wow, that's awesome! I will wear this loud and proudI can get a lot done on a lunch break. so until an official version exists:
And thank you for your efforts.
..I definitely did not misspell your name, either. >.>
Thanks! Glad you like the banner.Oh wow, that's awesome! I will wear this loud and proud
And congrats on a second-place finish!
Yeah, it sucks that a minor technical issue got in the way so much. It was still a really nice game though....Sorry you had UI troubles with Boss Beats, BTW.
Thanks!I am SO sorry for the delay... He's the "official" trophy banner... Apologies
Joke game or not, the voters have deemed it to be a more entertaining / higher quality entry. Being a joke game isn't an automatic disqualifier; if it provides tangible entertainment value and exhibits some degree of polish, then there's no reason it shouldn't earn a decent place.Not gonna lie, a little salty about placing under drop the bass. It was a joke game.
Well it be fair with a lot of the reasons that people don't understand my game was user error. Apparently reading a 5 line read me was to taxing, lol.Yeah, it sucks that a minor technical issue got in the way so much. It was still a really nice game though.
Thanks!
Joke game or not, the voters have deemed it to be a more entertaining / higher quality entry. Being a joke game isn't an automatic disqualifier; if it provides tangible entertainment value and exhibits some degree of polish, then there's no reason it shouldn't earn a decent place.
Last Knight wasn't a bad game. But you didn't tell the player any of the controls, or any critical details to playing the game at all, which meant many reviewers couldn't properly enjoy the game. I saw another Jam reviewer say somewhere (sorry I don't remember who): If you program 13 amazing bosses, but I can't make it past the first one, then I'm going to judge your game as if it only had one boss.
Any of us can have oversights, both devs and users/players. I don't think you should be so quick to claim user error.Well it be fair with a lot of the reasons that people don't understand my game was user error. Apparently reading a 5 line read me was to taxing, lol.
-Nocturne said:if your README file is necessary to play the game (e.g. it includes the instructions not available in the game), call it README_PLEASE; if README is not required to play the game, please use the regular README
I can and do confidently say that the user error was the issue. I had people play the game without any of my input or coaching and they figured it out pretty quickly.Any of us can have oversights, both devs and users/players. I don't think you should be so quick to claim user error.
-
Firstly, if your readme is necessary, it's a good idea to follow the suggestion which is given in the first post of the games topic:
-
Secondly, a game dev can easily unknowingly assume potential players will think as they do in certain regards, but this is a mistake which can really hurt a game in a lot of ways.
Why?
Because each of us (devs, gamers, everyone) have over time built up deep patterns of thought, which come from the information and experiences we've had as we've grown up. Each person grows up around different things and gets different information and experiences, so all of our brains vary in not just information but in actual thought processes which determine how we deal with the information we take in. This is also the reason for "culture shock" being a thing, just to give an example to think on which demonstrates what I've said here.
Now, closing in on the point, how we think determines how we view things and even how we act. This is where we can start applying it to understand how gamers will play your game and why it's a mistake to not acknowledge that other players can try to play your game in a very unexpected manner.
This is a big reason why player feedback is potentially priceless. I say "potentially", because if we're not conscious of the above described phenomena, we can write off other people's thinking or actions as faulty when it doesn't follow our own patterns of thought, thus nullifying the feedback, instead of taking a real proper look at the situation, trying to understand why a person thinks as they do and to be objective about changing the game to make sense from all these other perspectives as well.
I should probably sum this up because it's getting long and I'm probably spending too much time writing it (my day is going away and I have tons left to do today..).
-
I guess what I'm trying to zero in on is that good game design must take into account the varying thoughts and approaches of the target audience. If the game doesn't, I'd argue it's a flaw with the game, not the users, since it hasn't properly catered to the audience. You have to meet people where they're at.
I wish I was better with words, but I'll just leave it at that and hope it comes across in the clear and positive manner I'm wanting.
That's a really stupid philosophy.It kind of sucks what this topic has turned into, but one super important lesson I hope that @Ziberteck can get out of this is that regardless of whatever you are designing; the user is ALWAYS right.
User error does not exist. If someone runs into a problem, it is the designers fault.