>>824 They're a handy little trick. Ours are done with a shader so that they can be easily adjusted without any need to suffer the effort of tampering with the source sprites: shader_type canvas_item; uniform vec4 line_color = vec4(1.0); uniform float line_thickness = 1.0; void fragment() { vec2 size = TEXTURE_PIXEL_SIZE * line_thickness; float left = texture(TEXTURE, UV + vec2(-size.x, 0)).a; float right = texture(TEXTURE, UV + vec2(size.x, 0)).a; float up = texture(TEXTURE, UV + vec2(0, size.y)).a; float down = texture(TEXTURE, UV + vec2(0, -size.y)).a; float sum = left + right + up + down; float outline = min(sum, 1.0); vec4 color = texture(TEXTURE, UV); COLOR = mix(color, line_color, outline - color.a); }

Some life stuff going on, so just some animation updates today.

>>847 Looks nice Anon

Don't want to spoil too much by showing but I'm about half way through filling out my level with first pass. One or two more mechanics I want to add yet but excited for how quick it's coming together.

>>871 Looking forward to seeing your progress Anon.

FINAL 5 DAYS FINAL 5 DAYS FINAL 5 DAYS

>>815 >>824 >>847 Looking good.

Please enjoy this short video of a bunnygirl adventuring among placeholder assets.

>>883 Lol. What's the problem Anon? :) >>885 That's looking really good Anon. Fun mechanics.

>>885 Looks like fun exploration!

Put aside doing much more unique level art in service of more testing, features and polish. Just need to wrap up the title screen, sound effects and some particles, a few bits of juice, most everything else is done. Don't want to spoil too much so just showing the start and BGM here along with new mechanic I added where you can place a checkpoint-style totem that you can warp back to. But to move it you need to pick it up. That way you can practice new areas you get to but to move your checkpoint forward you'll need to bite the bullet and do it without a safety net to fall back on. Cheating a little and reusing settings and controls rebinding screens from previous game.

>>893 Excellent. Looking forward to the final result Anon. Drive on! :)

>>893 Impressive. As for the checkpoint thing, where is the risk in carrying the checkpoint if you remove dying? Do you drop the totem if you touch spikes? Does it warp back to the last checkpoint location?

>>898 Spikes have a pretty big knock back and stun. When stunned you need to hit the ground a few times to recover and regain control. So in certain areas it could mean getting knocked down all the way to the first floor. >>894 Thanks anon!

>>910 wew

Lots of fun progress yesterday: >Added all the sound effects with a fair chunk being remixed/edited from FreeSound >Playing SFXs are now tracked in a table with their active channel, when a SFX attempts to be played again it checks if its already playing and if so restarts that sound chunk on its channel - so no longer get sound explosions if multiple things play the same SFX (although I do have basic attenuation if lots of sounds are playing at once) >This also let me easily add a stop_sfx which I needed for if you release the totem button before you place/pick it up >Added particles >Added hit stun if you donk into things while swinging

So a month later and here we are! Thank you Newt for hosting the jam and providing an engine, this was good fun and I think I learned some things along the way. If any anons have problems running my game then let me know: https://archive.org/download/19100-drmagma/drmagma.zip Finally, if anyone has particular resources they would recommend for learning more about game development it would be great to know. Here's to /agdg/, I look forward to playing everyone's entries!

Alrighty gents, the big day is here (depending on your timezone at least) - let's see what you got. >>913 Hey, this is kick-ass. I'm glad to see that you were able to make something out of that mess and that you learned something too. Calling it an engine is too flattering though lol. I was able to run your game on linux no problem, did not test the windows build yet though. Little tip to anyone else who plays it: holding jump (B button, down button, whatever) after you jump and while you contact an enemy, causes you to do a long/high bounce off of them, which you will need to finish the game. I almost got stuck near the beginning until I figured that out. Was that in the README? IDK. I may just be retarded too, because the last boss is kicking my ass. >Finally, if anyone has particular resources they would recommend for learning more about game development it would be great to know. This board, just stick around. It may look dead but, post your questions, concerns, dreams, shower-thoughts, whatever you got about game dev and people will engage with you if you're passionate about game dev and dedicated - which releasing a game shows that you are.

>>912 >https://freesound.org/ Thanks, looks like a good resource. What software are you using for your remixing/editing? Sound and music is still a weak spot for me. I used audacity in the past but apparently they went closed source and botnet or something so I'm looking for an alternative. >sound manager Definitely good to have but yeah, I skimped on that for the platformer code I released, instead having the various classes manage their own sounds. What library are you using for loading and playback by the way? >particles Gotta tell us how. That's one issue I gotta tackle with my RPG project - there's going to be a lot of sparkly spells and flames and shit going off all over and I need to come up with a good system to manage their resources, position/color/alpha updates, lifespans, etc.

Phew! https://ev-dev.itch.io/sdgu Thanks for the jam! It knocked me a bit out of my rut and has got me antsy for a real project again. I wish I hadn't burnt through the first week and got more mechanics in but it is what it is. I hope anons have fun! >>916 I'm using an older version of Audacity, it's a bit clunky but I'm used to it. For sound/music it's SDL2_mixer. I just have a pretty light wrapper around it for convenience and handling channels. Particles are really just a separate sprite pool I have that automatically apply velocity, rotation and scaling (if set) and expire either once the sprite's animation is done or scale below a threshold. I use pools (https://gameprogrammingpatterns.com/object-pool.html) for anything transitory, so sprites, collision shapes and so on. You can check out the code for those (MiniSound and MiniRender) with the source code for Irradiant on my Itch.

>>913 I had fun! The very tight air control took some getting used to and I had a little bit of trouble on falling platformers where I would need to hit jump then move, otherwise the jump wouldn't register. Only real criticism is the sound effects were rather loud but good stuff! Are you new to gamedev, since you're asking about resources for learning?

>>915 Thanks Newt. >I almost got stuck near the beginning until I figured that out. Was that in the README? Ah, I didn't mention that in there. >the last boss is kicking my ass. Yeah I probably should have made him telegraph his next movement, he's randomized which definitely throws you off without that. >This board, just stick around. You bet, I've been watching all the goings on recently, very interesting stuff! >>916 >I used audacity in the past but apparently they went closed source and botnet or something They got bought out by Muse Group (who also owns Musescore) which is a shady org that embraces FOSS for greedy monetization practices, for Audacity they introduced a CLA which allows them to do proprietary versions and added telemetry (can be disabled at compile time though). If you liked Audacity you can use pre-Muse forks like Tenacity. >>917 >242 Oh fuck I'm sorry. >>918 That looks super cool anon, I would be happy to test a Linux build if you wanted to make one. >>919 Thanks! >I had a little bit of trouble on falling platformers where I would need to hit jump then move Whoops, I thought I fixed that, thanks for letting me know. >Only real criticism is the sound effects were rather loud Ah, sound options are a must next time. >Are you new to gamedev, since you're asking about resources for learning? That's right, outside of some minor modding this is my first time.

>>920 >That looks super cool anon, I would be happy to test a Linux build if you wanted to make one. I should get the source code and build instructions up tonight or over the weekend so Linuxfriends can compile locally to play. I can never work out how to correctly dynamically link and bundle shit for Linux. I think you did a really good job as your first game. Platformers have a lot of hidden complexity to consider and sometimes require being fuzzy with player actions. For example, I'm catching jump inputs for a small window before you hit the ground and you can jump briefly after falling off a ledge. Stuff like that makes jumping feel more responsive and lenient (which I needed since no air control and difficult platforming are already frustrating enough). Lots of decisions affect the game feel too, which to me are some of the harder parts of game dev. I hope you keep at it!

>>918 Hey, who let the pro in? Just kidding. You really have a knack for art though. Damn good sprite work and the pixel-art splash screen too. Haven't yet given it a proper playthrough as I'm still trying to get a gamepad working with it in wine, I'm getting an error related to some kind of windows.input.gamepad or something like that. I'm having trouble progressing with keyboard because of the lack of air control, can't seem to fine-tune my jump distance. >sound Ah, so it looks like it's Audacity then, at least an old version or fork. I don't need anything fancy right now, just sound levels, pitch shifting, equalizing, etc. >particles Oh yeah, I remember seeing that link somewhere before. Object pool it is then. Since the memory allocated for each object has to be the same, I guess you handle polymorphic behavior in the update() code then? Flames move up, shift to red and fade out, sparkles flip through animation frames as they go, Sparks move in an arc with gravity, etc. and each particle has a type or whatever. >source code Saw you mention that elsewhere and I've been meaning to check it out. Hope I can make sense of it.

>>922 Thank you! I'll try and get the source up tonight so people don't have to fight Wine. >I guess you handle polymorphic behavior in the update() code then? Even simpler than that: you just set whether a particle scales, rotates or has velocity when requesting one is added. Anything more intricate than that (thing goes up and down or shakes or whatever) I typically just bake into the sprite animation. Then the update loop for that pool skips any that are unused and applies those effects along with updating the source rect on the texture atlas if it's time to change frame. Although I do use that sort of thing for objects. They have a ThingType enum field and then when I update those I have a switch case for any type specific logic (like cloud platforms moving back up, rotating spike balls around origin, etc). >Hope I can make sense of it. Nim has very little obscure syntax so it should be readable. Some of the MiniRender code might be a bit ugly with the casting since I tried to squeeze down the struct sizes, what with having preallocated pools and all. If anything is unclear I'd be happy to try and elaborate!

Actually clean up was really minimal, so the Itch.io page now has the source code!

>>921 >>923 >>924 Compiled and ran just fine. I enjoyed the visual polish, the character art is really good! The gameplay was neato, swinging is cool and it was fun damage boosting in various places. What I would say is that it would be nice to have just a little bit of air control for insurance, it didn't quite feel right for a character that doesn't have the weighty, deliberate animations of a Mudokon or Prince of Persia to have a completely fixed velocity. Being able to ledge grab would also make swings a bit more forgiving. Overall though I'm looking forward to seeing more from you anon, good stuff! >Platformers have a lot of hidden complexity to consider Those are good tips, things to keep in mind. >I hope you keep at it! For sure, working on the game has given me thoughts on how to write something like it from scratch.

In spite of some very nasty last-minute build disasters wherein strange engine regressions only appeared when built for release, here we are scraping in at the last minute! Windows-only, we're afraid - targeting Mac yielded a segfault when run and we didn't even try Linux. https://files.catbox.moe/x1tk7k.zip Controls in the README. This is our first attempt at a game, and indeed most things that go into a game. Looking forward to trying out everyone else's games after a bit of sleep!

Congratulations, /agdg/ ! Really nice outcomes, well-done. We hope you do this every year, BO. Cheers. >t. /robowaifu/

>>926 What a lewd intro! I like the music and vibe and the mix of movements. Was pretty ambitious to include dialogue and portrait art! I would say my only critiques would be: when different characters talk it would be clearer if you dulled the other or highlighted the one speaking to be easier to see which it is. An interact prompt for the tunnel covers would make it a bit more obvious for the first one you encounter. Initially I thought you could just slide into them to knock them out of the way. >This is our first attempt at a game, and indeed most things that go into a game. It's a great first attempt, good job! >>927 I hope we get another jam sooner than that!

>>928 Thanks! We’d planned for refinements on the dialogue and some tutorial prompts but simply ran out of time. I agree those would definitely be an improvement. >>913 Loved the little elements of humour in this one. Good job! I will admit I haven’t managed to finish yet but the gameplay seems solid if not a little brutal. I’m not one for precision platforming though so I know the game’s not really for me. But I did get a sense of accomplishment when passing a section that was giving me lots of trouble and I still enjoyed what I’ve played so far though. >>918 I love your splash art and character sprite/design! (The floating goggles were a touch distracting, I’d recommend moving them with the hair). The teleport mechanic is a stroke of genius. Often found myself really wondering if I was ready to risk moving the item further up or not. The answer was normally not. Great job overall, it’s clear you’ve done this before. I haven’t played the whole way through but I too found I would have liked a little air control or forgiveness. That may also come down to level design though. Early on there were some single block platforms that were really difficult to hit in a row due to lack of familiarity with the game. My feedback would be to ease people in a bit more. I found some of the damage boost stuff really fun (love the shocked look on the sprite) but almost quit before even getting to it cause I had trouble landing jumps early on in the game.

>>913 I love the title, and your character's little grin. I also liked how the ghost blocks provided a little island of stability but also made any jump off them a 100% commitment. I also loved the sudden way you drop us into that first boss; some would find it jarring but I thought it was the right thing. I felt that the game didn't respond properly to my inputs sometimes. That wasn't the case, but this is why ledge forgiveness is surprisingly important - it bridges that little gap between hand and eye and makes the game feel more responsive relative to the player's perception. That aside, it felt pretty good to control, though I thought the difficulty ramped up quite quickly. >>918 Confession time: I super gave up. I really liked the tension and risk that needing to carry the totem forward gave, and I thought the character sprite and title screen were very nice indeed. I also thought the level design was excellent. I tried it with both keyboard and controller, and although I did improve, I could never quite nail exactly where my character would end up, even after an hour of play time. Every jump being a commitment works very well for this kind of design, but there's a certain point at which inputs decouple effort from result and make the player feel that they don't have much control at all. Giving us an (optional?) very limited ability to air steer would have gone a long way, just to provide that little bit of extra correction without removing the challenge. The section where you initially leave the ground floor was surprisingly tough compared to the next section, which was all about damage boosting. I thought it was nice how you gave a switched-on player a chance to skip some of that if they realized they could damage boost through the first two spiked balls. >>928 Thank you very much. The point about characters needing to indicate who's speaking is well taken; I noticed it myself, but alas - no time. Another thing that fell to time constraints and the release fires were tutorial control prompts, which hopefully would have fixed your little problem with the grate covers. Now that you've mentioned it, it seems obvious a player would expect to have to slide into grates to dislodge them, given how we introduce them. >>926 Sorry, Linuxbros: We tried exporting a Linux version, but it segfaults without explanation the moment that the player character grabs a ledge. So much for Godot's portability. We fought through the bugs and jank during development without any complaint, but the degree to which exported versions differed from what ran error-free from the editor, as well as from platform to platform, was frankly shocking given the docs' proclamations that releases were merely game data bundled together with the same engine that ran the editor. But all this is a different discussion, perhaps best kept for if and when we debrief. Great work everyone, and great thanks to Newt for coming up with and running this jam! Being forced to ram a complete game through under a deadline was educational, to say the least, and I'm very glad we participated.

>>920 >Yeah I probably should have made him telegraph his next movement, he's randomized which definitely throws you off without that. I wanted to mention that. While randomness has a certain appeal to it, for a fight like this one, it would probably be more rewarding? less punishing? for the player to have set patterns, used in a set order. That way they could feel themselves making progress, that they were able to get further on this attempt because they saw a pattern they never saw before, and shit like that. Even if the movement patterns themselves were more difficult or more numerous than they are now. Being able to skill up on and memorize the patterns would go a long way. Also, I believe sometimes when he moves diagonally upwards that if you're not already going the same way that you aren't able to reach him in time. Bounding boxes were pretty brutal too - it seemed like anything besides a direct hit from above would kill you straight out. >Muse Group Oh right, that's the fuckers. I remember reading about that a while back. Good to hear there are forks out there at least, gotta look into it again. >242 I blame alcohol and that one time I tried to take a screenshot of the last boss ;^)

>>923 Got ya. I'll give that a try - giving particles flags or something that determine the behavior. I got billboards working now, so one of these days I'll try my hand at spell-casting glowing particles or something like that. >>924 I was able to get it built as well, big thanks for that one. Was pleasantly surprised too as how the toolchain set up and the project built without problems. >>926 Kick ass. I was able to run it with wine, although it seems to require at least windows 7. My gamepads worked as well, except no button seemed to map to "interact" - I had to hit "e" on the keyboard to use objects. Really nice work on the sprites and animations, music is catchy too. Must have been a lot of work too, tuning the dialog scenes and screen pans when opening locks and whatnot. I haven't beaten it yet, I got a little lost at one point, glitched up into an elevator I wasn't supposed to be in yet, then crashed with a nasty error message (which itself seems to have a race condition in the console print lol): at: (platform/windows/display_server_windows.cpp:2120) triggered on coords (131, -113) Detected grabbed tile (131, -113) erased: Transitioning to falling. Fatal error. om managed code. attempted to call a UnmanagedCallersOnly method fr ackFrameHelper, Int32, Boolean, System.Exception)sInternal(System.Diagnostics.St ystem.Exception)gnostics.StackFrameHelper.InitializeSourceInfo(Int32, Boolean, S eption)ystem.Diagnostics.StackTrace.CaptureStackTrace(Int32, Boolean, System.Exc at System.Diagnostics.StackTrace..ctor(System.Exception, Boolean) at System.Exception.get_StackTrace() at System.Exception.ToString() at Godot.NativeInterop.ExceptionUtils.LogException(System.Exception) ot_variant_call_error*, Godot.NativeInterop.godot_variant*)dot.NativeInterop.god 00fc:err:eventlog:ReportEventW L"Application: Reach and Grasp.exe\nCoreCLR Version: 6.0.1823.26907\n.NET Version: 6.0.18\nDescription: The process was terminated due to an internal error in the .NET Runtime at IP 000000000BF64B10 (000000000BE30000) with exit code 80131506.\n" Gonna give it another go though. I see you guys are calling it a demo though, what do you have planned for the full release version?

>>927 Thanks. I was surprised by the quality of everyone's games myself. >every year I'd like to do them every 3 months if possible. I figure 1 month planning/preparation, 1 month jam, 1 month rest/reflection. May be too ambitious though, who knows.

>>935 >My gamepads worked as well, except no button seemed to map to "interact" - I had to hit "e" on the keyboard to use objects. We'd originally included gamepad support, but the trashfire that was the release build prevented our testing it so we never updated the control mappings to include interacting. >Really nice work on the sprites and animations, music is catchy too. Thank you, the sprites and other visual assets were a big chunk of what we wanted to include. Never managed any original music unfortunately, but the CC and otherwise free tracks we put in did the job better IMO. >Must have been a lot of work too, tuning the dialog scenes and screen pans when opening locks and whatnot. They were a bit of work, yeah, but not as much as expected - GDscript's good for smooshing stuff like that together. >I got a little lost at one point, glitched up into an elevator I wasn't supposed to be in yet There are a couple of easter eggs in the game, but that's neither of them. No idea what that error indicates, though I'm sorry it ruined your fun. >I see you guys are calling it a demo though, what do you have planned for the full release version? Depends if we choose to go any further with it in this form given the difficulties encountered, but the plan for future evolution was to fold out into a larger setup where the player switches between controlling Reach and Grasp, Lost Vikings style. We called it a "Demo" because it's not really a game at all, just a little vignette that shows off some mechanics.

>>926 >>932 Got it running fine with Wine. I liked the ongoing narrative and hints at a larger story, the music was a good fit too. It was fun exploring little areas to progress and the core moveset felt flexible. The only things to mention are that when wall jumping I would often dart backwards since I was still holding the direction for a moment, maybe a brief delay before giving air control? Also the window size didn't fit my display (1366x768) and I didn't see any kind of options/configuration. I'm interested to see more from you guys, good luck with the full game! >I did get a sense of accomplishment when passing a section that was giving me lots of trouble and I still enjoyed what I’ve played so far though. Thank you, there's certainly meat grinders in some places, something to be considerate of in the future. >>933 >I love the title, and your character's little grin. Thanks, I was going for sort of a Commander Keen/Jimmy Neutron thing with the premise. >I also liked how the ghost blocks provided a little island of stability but also made any jump off them a 100% commitment. That's exactly what I had in mind with the general gameplay, no going back! >but this is why ledge forgiveness is surprisingly important Yeah, definitely going to make sure to have that wiggle room going forward. >>934 >While randomness has a certain appeal to it, for a fight like this one, it would probably be more rewarding? less punishing? for the player to have set patterns Probably should've used a seeded RNG that resets on death, the unpredictability can really mess you up sometimes. >Bounding boxes were pretty brutal too - it seemed like anything besides a direct hit from above would kill you straight out. I did have to get a bit hacky with that unfortunately, collision direction detection would sometimes give the wrong result and I couldn't figure out a proper fix, with more learning and practice hopefully I can develop enough understanding to implement and debug these kinds of fundamentals myself. >I blame alcohol You mean pro gamer juice? ;^)

>>933 >>932 Thanks for the thoughts. I like ball busting platformers so I was kinda expecting comments about it being too tough but I could've been a bit more accommodating or made the difficulty curve shallower. It's all a learning experience for next time!

So now that we've posted our hard work and had a chance to play everyone's games, perhaps it's time to debrief to figure out just what the fuck we learned from our own and everyone else's experiences? Here's some questions that might help get started, feel free to use them or debrief in your own way. This is an anonymous imageboard, not a corpo struggle session, so do it however your heart pleases. What were you trying to accomplish? The obvious answer is "just, like, make game", but what specifically were you aiming for? Back in the planning thread, our illustrious BO put it like this: >Can't program? Learn, you've got a whole month. ... Take the time to try to do something new or do something well. Can program but can't do art? Spend the month developing your art skills and pipeline, even if it means a barebones game program-wise. Are you an artist but can't code? Take the month to learn to code or collaborate with someone who can. Can do everything? Awesome, show us something new then, a novel gameplay mechanic, setting, original character, whatever. I want to see everyone push the boundaries of their skills, using the provided code as a springboard if they like. So: Did you want to figure out Raylib, or experiment with a new language, or try out a new mechanic? How did you originally envision your game - what was it supposed to have in it, what pieces did you want to try out? Try to remember what you set out to do or the questions you wanted to answer for yourself as clearly as possible, and tell us about it. Where did you hit or miss your objectives? If you were able to clearly answer the previous question, this one will be fairly straightforward. Were you able to do what you originally set out to do? If you had to change course and set new objectives during development, were you able to do those? What caused your results? No plan survives contact with reality. This is the real meat, so try to dig beyond the obvious, first-level answers here - keep hitting things with "why?" and see if you can't get down to the roots of things. Note that this applies equally to cases where you hit your objectives or otherwise did good. Figuring out why things went right is just as important as finding out why things didn't. What should you start, stop, or continue doing? I dunno about the rest of you, but I wanna keep just, like, making game. So what does what you uncovered with the previous question mean for you? What should you do next now that you know what you know?

>>933 >I super gave up. Damnit, that was gonna be my pun. I also super gave up - I really can't seem to hit the right jump distance. Single block-width platforms and varying distances between them is the end of me. Is jump distance based solely on length of button press? Or is it based in part on character velocity (a varying velocity would imply acceleration though, which I can't see any of). >if they realized they could damage boost through the first two spiked balls. Lol I thought that was a bug, given the size of the gap between them. >thanks to Newt for coming up with and running this jam! Being forced to ram a complete game through under a deadline was educational, to say the least, and I'm very glad we participated. I'm glad you got something out of it. Wish I could say I did more "running" of the jam though - I feel I could have been a little less hands-off during it. I was expecting more absolute newbs though, and had planned to have to work with them every step of the way. The one guy who worked off of my code didn't seem to have any issues with it, which surprised the shit out of me. As far as mechanics and technical stuff, everyone seemed to know what they were doing for the most part. So I took the opportunity to work on my 3D project.

>>944 >Is jump distance based solely on length of button press? Y velocity is set on button press but it's halved when you release the button.

>>945 Seems strange to me. What sets the Y velocity? Is it fixed? How did you come up with that solution? For my game, I used a minimum jump speed (height) and a max jump speed. Holding the button would increase your jump speed from min up until max, depending on push duration. I think I did a simple formula like current_jump += (max_jump - min_jump) / time_to_max (250ms or something, I forget) * frame_time; clamping to max_jump, of course. With some flags in there too, to not allow any more jump height increase if jump button released, until you hit ground again. My horizontal speed determination was simple, maybe too simple: if you were running, you jumped at run_speed, if you were walking, you jumped at walk_speed. I used a flag to determine which speed the player was moving at when they jumped, to only allow that much air control. Before I did that, you could walk, jump, then hold run in air for more horizontal air control, which looked retarded. In retrospect though, I probably had too much air control and might have benefited from halving movement speed if you try to move in the opposite direction that you jumped in. If that makes sense.

>>942 Great post, weird it's not getting a lot more response. Answer the man, ya faggots. >What were you trying to accomplish? My situation was a little different. I wanted to create more engagement with the board and tried to draw lurkers out and get them dev'ing. I made the little platformer with luigi and the frog enemy and shit to show people that a beginner could, in fact, make a little game in a month if they just put their mind to it, with the help of a cool library (raylib) that handles the lowest level window-creation/rendering/input handling/etc. code, while still leaving it up to you to implement all of the "game" code - state machines, collisions, character controller, level format, enemy "AI", game state handling, etc. etc. Some fag in the planning thread called me lazy like I had it done already and just rehashed it or something for the jam but the truth is my experience with both raylib and C++ were extremely limited, and work on the platformer demo started after announcing the jam - I had never done platformer development before. Another goal was, of course, to learn just like everyone else - what I ended up making was actually my most "complete" game I've made up until now. I am by no means a professional dev or anything but I do believe in leading by example. So if I'm gonna be the BO of this board, I don't want to be the faggot that says "come on you guys, just like make game..." I want to be the guy who says "Check out the cool shit I'm making. You can make cool shit too, if you just like make game." >Where did you hit or miss your objectives? We had a good turn out. For an up until recently abandoned board on the webring, we had 3 people participate (4 if you include myself) and everyone released something. That's pretty good. Where I missed though, was in thinking that total newbies would get involved. I spent a good deal of effort on making my demo code easy to grasp and modify, and was fully prepared to absolutely spoon-feed and hand-hold anyone who needed it, to change it in whatever ways they wanted to and to make it their own, or even to do their own thing using whatever engine. That no one like that showed up was a factor in me taking a more hands-off approach midway through and focusing on other projects instead. I would like for more absolute beginners to participate in the next one. It's not a competition, it's about learning, practicing, and pushing our limits. Even if you've never written a line of code or drawn a jank-ass sprite or texture in GIMP before, GTFI here. I had also wanted to improve my demo code, to replace a lot of the hacks with proper solutions. I ended up not doing that, nor did I expand the project like I had planned to: additional levels, new mechanics, new enemies, etc. I was a bit burned out with it, since I had to crunch a bit at the end to make it in time for the jam. At the same time, I made some advances with 3D in raylib that made my RPG project feasible, so I pivoted to that. If anyone was hoping for a bigger and better "Luigi's completely not endorsed by Nintendo adventures" at the end of the jam, I'm sorry for not delivering. As far as hitting objectives go, I am proud of the way that I got the release out the door on time. Defining the features I wanted and the scope, how many levels, how many enemies, etc. then managing the time to meet those goals was pretty satisfying to be honest. Not that I've never done it though, at my last job I wore many hats and basically worked alone from concept to product delivery (hardware stuff), but it's probably the first time I've committed to doing it for a "hobby" project. The scale of my current RPG project is 1000x the size though, and while I progress a little every day, having nebulous scope and time to delivery can be demoralizing at times. to be continued.

>>951 >Seems strange to me. What sets the Y velocity? Is it fixed? Yep, there's a JUMP_SPEED constant that the player shape's Y velocity is set to on jump. Each frame gravity is added to give the jump its arc. By modifying the Y velocity on release (x0.5 in this case but you could go lower for snappier control or higher for less control) you give the impression of "hold to jump higher" without the fiddly logic or extra velocities. Here's a snip for the entire bit. >How did you come up with that solution? I'm sure I saw it somewhere before but I don't recall now. There was some frog platformer I took a lot of inspiration from years ago that had wall jumping that felt good, I might've gotten it from that. >>942 >What were you trying to accomplish? A teeth gnashing platformer. I didn't have a strong idea in my head after I shelved the tower survival idea so I ended up just throwing some different mechanics together and tried to make them work. >Where did you hit or miss your objectives? I probably over succeeded in the teeth gnashing aspect. While some anons were kind and commented they liked the level design, that was the most rushed aspect (about one day) and I committed on it too soon. I did have a few friends play test and saw there were some early difficulty spikes but at that point I felt like I wouldn't hit the polish I wanted burning a day or two more. When it came down to concessions made in the remaining time I opted for effects and things instead of level design which in hindsight is a bit of a failure. As one café patron put it 'it's a well put together game but really frustrating'. In general I need to do a better job of either setting expectations or being more serious about interpreting how friends trying it feel. Not to sound like I'm after a pity party or anything! Overall I'm happy with what I got done in the time and it gave me things to think about for next projects. >What caused your results? Easy: I wasted the first week meandering with ideas which I'm very inefficient with. I seem to do best just starting and going from there. Unfortunately life things didn't sync well with the start of the jam so I felt I had to do something to stay invested. >What should you start, stop, or continue doing? If I don't have a strong concept in mind I need to just dive in and figure out as I go instead of having decision paralysis. Lucky for me I have a really strong vision for what my next (non-jam) game is going to be!

>>942 >What were you trying to accomplish? My aim by joining the jam was to both try something I hadn't before and to get my feet wet with C(++). I decided to keep the scope simple to make sure things were achievable with my lack of experience. >Where did you hit or miss your objectives? The game is fundamentally as I imagined it, all my specific targets were met. Of course there are things that I want to resolve and improve in the future. Certain implementation details and bugs weren't fixed, the falling platforms and boss battles are the most janky in that respect. I also didn't get the difficulty curve completely right, with some big spikes in there that can easily turn into slaughter houses. Providing more configuration options, preferably in-game is something worth doing also. Finally it would've been better if the sprites were integer scaled, uneven scaling definitely hurts the game's appearance. >What caused your results? Leading up to the jam I went through some surface level C & C++ tutorials, this allowed me to get straight to work without being obstructed by unfamiliar syntax. Using Newt's template provided the jumping off point I needed as a beginner and allowed me to make fast progress, though in the future I want to try working from scratch. My simple scope meant that I didn't have to refocus my efforts, which cut down on project time not spent getting towards the end. I tried to have particular objectives for each week and stayed focused on the area being working on, this meant that I didn't get sidetracked in different aspects of the game until it was specifically time to work on them. The mistakes I made can be attributed both to my general inexperience and my hesitance in delving too deep into the underlying codebase, if I had been more willing to break and fix things I could've resolved at least some of the issues. >What should you start, stop, or continue doing? In the future I need to be more willing to work on the important structural parts of a game, I also need to integrate the feedback I've received into future projects. Going forward there's always more to know and I must keep trying to learn new things and put them to practice.

>>942 >What were you trying to accomplish? Just, like... make game. Seriously though, what we wanted was to make and release a game. You discover things, both good and bad, by going through a complete release cycle that you wouldn't be able to discover any other way. More specifically, what we aimed for as outlined in >>712 was: >a fast-traversal platformer >where you have to escape a pursuer >with some original character sprites and >at least one piece of original music So this now brings up the question of what a "game" is. I'll sidestep all the tangly stuff that can come with answering that question by simply saying what we wanted was to have a game that >worked on a "toy" level by being satisfying to control >had a win and loss condition >had characters >had a story of some kind, however thin >Where did you hit or miss your objectives? Miss: We didn't end up making a fast-traversal platformer - the final result was closer to a Metroidvania in style. Miss: There was no pursuer, nor escape. In fact, the final demo had the player character looking for the NPC who was originally supposed to be pursuing them. Hit: All character sprites and indeed all graphical assets were original. Miss: No original music. >What caused your results? We'll leave aside exceptional life stuff, of which there was plenty, because circumstances conspiring to interfere with creative work is downright routine. But we ended up having less time than we thought we would, partly from the aforementioned surprises, and partly from fighting weird shit in Godot. More on Godot later. Our sprites worked, I think, We made the mistake of thinking that tilesets would take longer than they did, so initially we decided to never attempt them and instead made character animation frames that never ended up being used. Wish we'd decided to do that earlier, so that it could have been something a little more evocative. Strange to think Might have become a little over-confident, too, because early work on the character sprites worked better and came out faster than we thought, meaning that we got a little complacent. We ended up doing level design very late in the piece because we didn't really have a strong concept in mind. Given that we were thinking about how to design a pursuit, but that the mechanics we ended up being able to get in there didn't really support it all that well, the eventual pivot to a more exploratory style meant we were groping forward without any idea of what we wanted to achieve. One of us was doing all the programming (the other not having the necessary skill level), and that programming ended up being way more time-consuming than we thought, mainly because of weird Godot shit that ended up eating huge chunks of time. (All engines have their idiosyncrasies, and we don't really have experiences in other engines to compare to, but Godot really threw some undocumented and long-standing bug curveballs our way.) The thing about unexpected bugs is that you can't predict when and how they'll hit - except perhaps in a statistical sense - nor how much time they'll take to overcome, so this meant that stuff we thought the programmer would be able to do had to be taken on by the other out of order. This comes through in details like the lack of tutorial prompts, the thin script, the arbitrary level design, and so on. In situations where you aren't able to achieve your scope, it makes sense to reduce that scope - but reducing scope only meant that our non-programmer had less to do, and did nothing to resolve the fundamental issues the programmer had to attack. Turns out that you need a whole lot of programming to make a game work. Who knew? We thought that using Godot would help - and to a degree it did, e.g. editing animations, sound effects, and so on - but in the end it didn't really take as much coding away as we thought it would. >What should you start, stop, or continue doing? Being both complacent about what you can do and over-cautious about what you think you can't do turns out to be dangerous. That's why end-to-end exercises like this jam are so important. Can't really think of a way to address this, except to try and keep attacking things as early as possible. Polish is easily up to half of the time spent on any given thing, and problems can leap out and wreck your shit at any time. You can't plan that away, unless you're both experienced and psychic - we are neither. It's easy to say in hindsight that you should have planned more. Our problem was that we didn't really know, in detail, what would be required to make the game we envisioned. How could we - we'd never done it before! But what we could have done was to pay more attention to the game's design. Like, we have no lose state (except discovering one of our easter eggs), and no real win state. What we made isn't a game, at least not according to our own definition above. It's more like... half a game toolkit built on top of Godot. Something we did do well was to secure early wins and then build on them. We tested the character concepts with rough animations first, and only once we were sure they worked did we animate the in-betweens and line everything up in code. We resisted the temptation to hard-code things; being able to change and adapt by only tweaking a few parameters was extremely useful. (It's not just the time something takes to change, but the energy and friction involved in doing so - the less changable, the less someone will be likely to experiment with changing it.) Though we ended up in a mad asset dash towards the end, I think that keeping and testing gameplay with filler assets was probably better than creating stuff we didn't end up using. So, we should start to interrogate the game idea right from the beginning. We should stop getting complacent when things are going well. We should continue building things to be changeable, so that we can shuffle stuff around without trouble as we discover more, and we should continue trying to get our bases covered early.

>>962 >Strange to think Strange to think that character animation would seem easier than background tiles, but that was just how we thought of it. >weird Godot shit One place where we were unfair to Godot: The segfaulting in the Linux export was the result of using an older machine where Vulkan was way behind. Narrowed the problem down to a particular GPU particle spawning and somehow crashing lavapipe/llvmpipe, which the program fell back to in absence of a Vulkan-compatible 3D card. Testing the Linux build on Ubuntu 22.04 with Godot 4.1 instead worked fine, likewise a macOS build taken from that version. Godot is great in many ways, provided you don't stumble into one of its skull-splittingly horrible long-standing-yet-utterly-neglected bugs or under-/mis-documentation... which, given enough time, you absolutely will. Again, no other game engine experience to compare it to, but it didn't live up to its own hype in many ways. Still, discovering that the Linux problem was the VM's fault and that the macOS build worked went a long way towards our not ditching it for future projects.