>>688 >(please clap)

>>688 >how is this gonna work? First, I want to get everyone set up to begin. I have to preface this though, by saying that I am only experienced with software development on Linux (for linux and windows targets), and any specific building instructions, plus other shit like software I use, is going to be for Linux. That said, I would love it if a Windows dev could help out and support building on Windows. So I would say the first thing anyone should do, if they don't have one already, would be to set up a linux box, a linux VM, or that linux on windows thing. Trust me, you'll thank yourself later. Next thing you're going to want to do, if you haven't already, is to get a C/C++ compiler toolchain installed and set up (added to your $PATH or whatever you need). I use GCC. It just werks. Install GDB while you're at it, it can sometimes help pinpoint the line in your code that's fucking up when you get segmentation faults and your debug prints aren't even printing. If you want to build for windows from linux, get Mingw, should be in your repos: just do a 'sudo apt-get install mingw-w64' or pacman or whatever and you should be all set. Need any help, just ask in the thread. Next, and this is the big one, install raylib. Go to the github page: ht tps://github.com/raysan5/raylib get the source code, and build for desktop. Follow the instructions for your OS (linux ones found here: ht tps://github.com/raysan5/raylib/wiki/Working-on-GNU-Linux) and make sure you build the static library version, not dynamic - 'make PLATFORM=PLATFORM_DESKTOP'. Once installed, you should be able to include the 'raylib.h' header and link the object files from anywhere. For windows it's a little different apparently, you need to include 'raylib.h' and a couple other headers in your project directory somewhere, plus provide the windows version of the raylib libary, raylib.dll, etc. Familiarise yourself with the library - bookmark or download the cheatsheet: ht tps://www.raylib.com/cheatsheet/cheatsheet.html This contains the entirety of the library, plus it serves as the primary documentation - there is no wiki or man pages or anything. If you need to peek under hood, and you will sometimes, for instance to get the names of struct members or whatever, there is raylib.h - the single header file that contains definitions for all library functions and structs: ht tps://github.com/raysan5/raylib/blob/master/src/raylib.h Between these and the examples: ht tps://www.raylib.com/examples.html you have everything you need to get started with games programming.

>>691 Forgot my 'cont.' >but more specifically though, what do? One, try to get something compiled. Try one of the simpler raylib examples like "basic window", raylib's "hello world" so to speak. Then, you may want to check out the (very short) demo game that I made for this. Binaries for windows and linux can be found here: ht tps://anonfiles.com/a1O5w0vfz4/06062023_binary_zip Just extract and run the executable for your OS. Check the readme inside if something isn't working right for you. I forget how I left the config.ini file set up, it's probably some tiny resolution with weird video options on. The default controller keybinds may not work for you either. You can take a peek at the source here: ht tps://bitbucket.org/anon-s-first-platformer/anon-platformer/src/main/ (git repo) or ht tps://anonfiles.com/G4Mazav5ze/anon_platformer_zip (.zip) but don't expect too much; it was made with a deadline. Compromises were made and corners cut. That's development though. I'm going to use this game jam as an opportunity to try to address those issues and make something a little easier to follow, robust, and extensible. You can also check out the old planning thread for some discussion and documentation of my struggles, it may be interesting to you >>603. Next, let us hear about what you want to make, what you're interested in. Bing bing wahoo? Side-scrolling shoot-em-up? Terraria clone? The "platformer" theme was intentionally left as vague as possible. I want to hear people's ideas. What are fun mechanics? What are some of the development challenges involved? What have you played that you liked? How did they implement this feature or that? In the meantime, I'm trying to get some excuses documentation for my code written up. Coming Soon. p.s. Someone recommend me a code repository that isn't github and doesn't suck.

>>693 >p.s. Someone recommend me a code repository that isn't github and doesn't suck. Gitlab doesn't, AFAICT.

>>693 >>694 Is https://gitgud.io/ still considered OK? LynxChan's repo is hosted there: https://gitgud.io/LynxChan/

>>694 It looks like they've gone non-free? Or do I have the wrong site? Got a link? I used them in the past for another project without any problems but it looks like a lot has changed since then. >>695 Looks good, I'll check it out.

>>696 >It looks like they've gone non-free? I certainly seems so yes. I just checked and both of the accounts from our board that used it are there, but I don't know how long they are going to last now that it looks to be (((financed & vibrant))). I retract my recommendation I guess.

Happy for some /agdg/ activity! Is it okay to use another language/framework and take part? >>695 I've used gitgud in the past, don't think anything has changed with them.

>>697 I don't know how free as in freedumbs they are these days but the site made it look like I get a 30 -day trial before they start trying to grub my shekels so I said fuck it. >>698 Absolutely. I only highly encourage C++ because of its ubiquity, the excellent selection of external libraries for it, the possibility of sharing code/collaborating, and my ability to provide some support with it. What are you using?

Finally got around to adding dependencies? to the Makefile. I was really getting tired of having to 'make clean && make debug' on every little header change, especially when I use class headers to define constants and need to tweak them, but couldn't find the time to look into it. Turns out it's really easy.

>>700 Pushed to gitgud: ht tps://gitgud.io/AGDGNewt/anon-s-first-platformer

>>699 >What are you using? I usually use Nim and SDL2.

>>702 Cool. Welcome aboard.

I am so confused. Game jam is when everyone makes a game based on a theme, but it looks more like you're writing out a tutorial.

>>704 Don't be, I'm just working on stuff while waiting for people to show up. I plan on writing up a tutorial to explain how my code works and the reasons for the design decisions made. The jam is for everyone, experienced or not. That's why I made a little game to 1: show that you can make a little platformer with raylib and C++ in a month and 2: act as a potential starting point to those who have no or little experience don't know where to begin, of which I think there may be a few. For those anons, "here, look at this code" isn't really going to cut it. What about you? What are you interested in doing?

>>704 I think it's a neat idea to give less experienced folk something to start from. Starting from scratch can be intimidating.

>>700 Nice, noticed that earlier and it's great to see it fixed.

>if this is your first time at game jam, you have to make game Alright faggots, roll call. Who's in? Who's lurking? Trying to feel out what we're working with here.

>>708 Hey Newt, I'm the C(++) newbie from the other thread, been poking at things for the first day and started to lay the foundations. My plan for week 1 is to have entities and mechanics in place, hopefully shouldn't be too much trouble with a modest scope.

>>709 Cool. You finding your way around the code OK? It's hacks upon hacks upon hacks, but I can answer any questions you might have. What kind of mechanics did you have in mind? I'm working on a generic LevelObject class right now, to inherit from to use as a base for refactoring the coins and similar, plus adding moving platforms back in like I showed off in the old thread.

>>710 >You finding your way around the code OK? Yeah, I'm finding what I need so far, mostly just working from existing parts. >What kind of mechanics did you have in mind? Basic platformer stuff really (most of it is already accounted for), the next thing to do is checkpoints and respawning. The general gameplay idea is sequential bouncing between temporary platforms and enemies, with checkpoints as respite. >I'm working on a generic LevelObject class right now, to inherit from to use as a base for refactoring the coins and similar I thought the coins code seemed a little janky. ;^) Great to know you're improving things.

>>708 Team of two here. We'll be making a fast-traversal platformer where you have to escape a pursuer. We aim to include some original character sprites and at least one piece of original music.

>>711 Good to hear. >The general gameplay idea is sequential bouncing between temporary platforms and enemies, with checkpoints as respite. Sounds challenging, I like it. >I thought the coins code seemed a little janky. It's total ass for sure. Those and the treasure chest were added and finally working bug-free at like... 4am of the 6th.

>>712 Awesome. Keep us posted. What kind of style are you going for? Tile-based or something more free-form? >original character sprites Tell me about it. My man Luigi makes a decent placeholder but an original character would be nice. Gonna have to come up with something. No artist though - editing these sprites I found on itch.io is about the limit of my current abilities.

Want to talk about my level format for a minute, which is otherwise completely undocumented. I use a set of layers, with fixed names for each. Changing that or adding more isn't hard, you would just need to update the Level class and Level::load() and Level::unload(). For collision, I ended up going with float-coordinate AABBs drawn with the polygon tool in Tiled, then adding a custom property "aabb_type" to them to indicate normal level geometry, damage volume, death volume, etc. Copy-pasting those helps block out a level fast, using grid snap, or pixel snap to match to something not grid-aligned, like the thinner platforms in level 2. Not the most elegant solution, however. When I get around to refactoring that whole thing, level geometry colliders will be their own class, while other volumes will go with the other level objects - coins, health pick-ups, items, moving platforms, goal, save points, whatever. The code to convert from Tiled polygon objects is nasty, but that can't be helped. Tiled has their coordinate system starting in the upper-left, the coordinates are in pixels, whereas I use floats with 1 tile being 1.0x1.0, plus the fucking polygon points are given relative to the object origin, which also happens to be where you started drawing from, not a set corner. I currently support 1 tileset per level, it can be any size though. I would like to change that to support multiple tilesets, so that a level can mix and match tilesets of different "themes" without them needed to be on the same sheet, eliminating duplication. There are a few custom properties set on a per-level basis: map background music file name, player start x and y, and completion time limit. That's all pretty self-explanatory. You can set all sorts of parameters here if you want, like flags for which way the level scrolls, whether it auto-scrolls or not, if it's an underwater level, whatever. Coins were created using a 'tile object' with the 'name' parameter filled in to distinguish it from other objects. Tile objects though, have the drawback of being dependent on a tile graphic out of one of your tilesets for display, which fucked me up briefly when I tried to copy-paste a coin object from level 1 to level 2. I should really change those to 'point objects', which I find to be a lot more flexible, if not as visually pleasing in the editor. Speaking of which, coins and spikes are placed in Tiled, but currently I have MOBs being placed via a separate XML file. Even though MOBs could be handled with point objects in Tiled, using custom properties to fill in all the data I need for instantiation - position, jump speed, gravity direction and strength, phase, etc.etc. I couldn't find an elegant solution to list up all of the graphic and sound assets that needs to be imported for them, so I just whipped up a second XML doc for MOBs. Currently, in order to read it in on level load, the file name needs to be in the format (level name)_mobs.xml. Inflexible, but it works. Like a ghetto database of sorts.

>>714 >What kind of style are you going for? Tile-based or something more free-form? Has to be tile-based; no way are we going to be able to do otherwise in a month with the other goals in place. >>714 >limit of my current abilities. Ours too, at least at this end of the production. Deep end's for drowning!

>>716 >Has to be tile-based; no way are we going to be able to do otherwise in a month with the other goals in place. Hear that. Keep us posted with what you work out for a map format and stuff like that.

Added a license to my code (CC0) and added the licenses for raylib, mINI, and pugixml, if anyone cares about that sort of thing. Change pushed to both bitbucket and gitgud repos but I will no longer be posting any code to bitbucket - it's a pain in the ass to manage two repos and I prefer gitgud's (gitlab's) interface to BB.

>>718 Please let us know how your gitgud experience goes. I've shied away from it b/c of the 'Sapphire' account thing.

>>708 /robowaifu/ lurker. i'm interested to see what you guys come up with. Good luck! :)

>>702 >Nim https://bestofcpp.com/repo/greenfork-nimraylib_now

Day 2, checkpoints and respawning seem to work, next up is some tweaking on Luigi and ideally a new enemy.

>>719 >'Sapphire' account thing To me, that came off as one the typical "company runs a few different websites, doesn't want to keep track of more accounts/PWs than it needs to, so calls it a 'feature' things. I use JLCPCB and LCSC for work sometimes, and they have the same sort of thing - one account for their eEDA? or something online CAD thing, LCSC, and JLCPCB. Never gave me any red flags, despite them being the usual jews of the East. I used a new email for it anyway so whatever. I just like that they use the gitlab code base so shit actually works. >>720 Thanks. >>721 Supposedly raylib has binding for something like 50+ languages. >>722 Looking good. Nice to see a new feature slapped on without everything breaking. >tweaking on Luigi Yeah... he's not the best. The class is a mess, too. I'll do a write up in a bit explaining a little about the character controller idiosyncrasies and such.

So let me talk about this guy. His movement, behavior, animations, etc. are handled by a Finite State Machine. Maybe you know what those are but hear me out anyway. A FSM is a design pattern (not necessarily an object on its own), that says that he has a set of different states that he can be in, and can only be in one state at any given time. Those states are enumerated in the Player class header: enum class PlayerState { GROUNDED, JUMPING, FALLING, CROUCHING, KNOCKBACK, END, DEAD }; Now, like all design patterns, there are strengths and weaknesses to it, trade-offs and whatnot. What a FSM does best, is reduce combinatorial complexity to something manageable. Instead of having to check/set/clear an ever-growing set of flags to figure out what the character should be doing or able to do at any given time, you define states that the character (or whatever you're making) can be in, what they are able to do when in that state, what needs to be checked/updated while in that state, and what states they can move from that one. The downside to this pattern is code duplication. Some states will overlap in terms of what they can do or what needs to be updated, and there is no real way around simply doing the same thing in multiple states. FSMs are great for game dev though in general, and you'll see them all over the place. My particular implementation is not the best, however. In retrospect, I feel that CROUCHING should not be a state, but rather just a flag, that way, you could be CROUCHING and JUMPING (like in SMB), or CROUCHING and DEAD, or whatever. I plan on fixing that if I get the time. The END state was added last, and does nothing but make Luigi do his victory pose and stop updating velocity and position and such, basically freezing the character so we can fade and roll credits. You'll also see a lot of FSM implementations have explicit functions for transitioning between states, or for leaving a state, usually where they set and clear flags relating to the state they're entering or leaving. I don't, but may implement something like this then - it would help me manage some of the Class-level flags and inter-state communication. Anyway, you'll see the FSM machine in action in the update() method. First, there are a couple of things handled that are common to all player states: whether you're holding the run button or not, and whether you've just taken damage and are invincible and blinking. These are handled at the top of the method. Next up is a big switch/case that decides which update function to call based on the current state. It's pretty self-explanatory: switch (player_state) { case PlayerState::GROUNDED: { update_state_grounded(frame_time); break; } case PlayerState::CROUCHING: { update_state_crouching(frame_time); break; } case PlayerState::JUMPING: { update_state_jumping(frame_time); break; } case PlayerState::FALLING: { update_state_falling(frame_time); break; } case PlayerState::KNOCKBACK: { update_state_knockback(frame_time); break; } case PlayerState::DEAD: { update_state_dead(); break; } case PlayerState::END: { update_state_end(); break; } } Within these update_state_xxx methods you'll find code specific to that state. For instance, only in the grounded state do we check for a press of the jump button. Only in the jumping state do we check if the jump button is held (to extend the jump length). Only some states have gravity applied. We can only hurt an enemy in the falling state (coming down on its head). I need to fix this though, since you should be able to kill an enemy if it jumps up into you from below. At the end of the update() method I call these two functions: update_aabb(); update_contacter(); just to be sure that if the player's position changed, their axis-aligned bounding box and 'contact sensors' moves along with him. cont.

About those contact sensors. Sometimes, you need to know whether an entity (player, MOB, etc.) is not colliding with something, but rather just touching it. For that, I took some inspiration from other games and a couple dev blogs and implemented "contact sensors" - a set of points (Vector2 x,y) at set positions relative to the player's AABB that, when intersecting a volume, tell us that we're currently on or up against something. See first pic for what that looks like and the others for similar. What I used looks like this in code: struct Contacter { Vector2 sensor_left; Vector2 sensor_right; Vector2 sensor_top; Vector2 sensor_bottom; Vector2 sensor_bot_left; Vector2 sensor_bot_right; }; in utility.hpp because I figured that I would use it for a variety of things, not just the player. You've got 3 'sensors' on the bottom, 1 in the middle of each side, and 1 up top in the center. I am currently only looking at the bottom 3. I used those to determine whether we are still grounded on a platform and not falling. For some, the 2 bottom corner sensors may be sufficient, but I added 1 in the middle so that we can stand on platforms/objects that may be less than 1 character width wide, and also to possibly check whether we've come down directly on top of/in the center of something or not. The rest are unused, but have plenty of potential uses. The top center one can be used to make sure blocks are not just collided with but hit from below and roughly in their center (like how the old Mario games work). The side sensors, if their position was adjusted, could be used to detect and move up steps automatically. For instance, if you are moving left/right, collide with an AABB on that side, BUT, your side sensor doesn't, then you could pop the character up to the AABB's top and have them climb the steps or whatever it is. See last pics for how that would work. See the Kirby pic too, for how you could use the bottom middle sensor to walk on slopes. cont.

Think I've got an idea of what I want to do, will do some sketches after work.

Here's my gaem. https://barfdeth.neocities.org/vidya Tell me if I win.

>>729 That looks like old Newgrounds, good job anon! >Tell me if I win. That depends on whether you remade it from scratch in the last 3 days. ;^)

Update 3, Luigi is now more nimble and we have our first obstacle, I think some temporary platforms are in order next.

>>724 >>725 Thanks for the explanation, very informative.

>>708 Lurker here. Would have participated, but too busy this month unfortunately. Good luck to every one on their projects and looking forward to the results.

>>729 >Tell me if I win. Rewrite it in something that isn't Fisher Price code so it isn't jank floaty ass and you might.

While we get our mechanics worked out, here are the initial sprite-proportioned designs for the player character and pursuer.

luv me platformers >>708 me nothing planned yet

>>731 Looking good, anon. Have you come up with a good solution for bouncing off of things or are you treating those round things as regular (if temporary) platforms? >>736 Damn, nice character sprites. Didn't take long either. Using them at 64x64 size, what does your screen look like, proportion-wise? Sticking with the 480x270, 16x16 pixel tiles like I did or something else? >>737 Good to have you. Feel free to spitball ideas and such here, thread isn't just a dumping ground for progress. What kind of background are you coming from? Programming experience? Have you looked at/played the janky little platformer I made?

>>740 >Using them at 64x64 size, what does your screen look like, proportion-wise? Sticking with the 480x270, 16x16 pixel tiles like I did or something else? We’re targeting 640x360 at the moment. As for tile size, we’re thinking either 24x24 or 16x16, but we’ll need to test and see how the mechanics shake out before we settle on one or the other.

>>740 Thanks. The mob bounce was already in the player class (I added extra velocity for holding jump though), the drones are just a modified copy of the Frog class. On the subject of platforms, here's a basic one that doesn't do anything special yet, mob and level collision are more unified now too.

>>742 Cool. I'd be interested in seeing that code sometime if you don't mind sharing. I tend to, or at least try to, work from the specific to the general when adding features - if two or more features become similar/overlap or share enough functionality, I'll roll them into a more unified object/system/parent-class, what have you. I didn't have the time to do that this time around so there are a lot of things I'd like to try to improve going forward with this.

>>743 Sure, I'll include the sources with the game. It's not much, just rolling things together as needed like you said.

Only had chance to collect some thoughts so far. Work really took it out of me this week.

>>723 >JLCPCB >LCSC >eEDA I have no idea what this jargon means, but I get your general point Anon. Anyway, please let us know at the end of this game jam what you think of it. >>745 Some nice work Anon, good luck with everything! :)

>>745 The fact that you're starting with gameplay rather than a shopping list of technical details makes it look like you know what you're doing. You the Nim guy? Looks pretty ambitious, looking forward to your progress. >>746 Not jargon, web site names. Just an example of sites sharing an account system. >Anyway, please let us know at the end of this game jam what you think of it. Will do.

>>746 Thanks anon! >>747 I am yeah! It's more notes than I usually start with but hopefully I'm not biting off more than I can chew.

Falling platforms seem to be working, there's definitely holes in my implementation but it should work OK probably.

>>751 Looks fine to me. Are you just toggling gravity on after collision with player (plus maybe a short delay?). They do stop after going off screen and not just accelerate forever, right?

>>752 When the player lands on top the platform switches to the falling state. When a mob fades out or goes off screen it enters a NOP state so it's still there for respawning.

>>753 Oh right, FSM. Cool.

Found some time yesterday to make a start. It was actually really good to start testing my quad tree implementation some more. Found some bugs and areas to improve, now it's working a lot better. This is just me messing around getting collision system up and running, it's usually pretty quick from there to extend. Will try and hammer out the fundamental pieces of gameplay this week. It's been a long time since if I've done more than a simple camera, so that should be interesting. If anyone is interested I could talk about how my code (feels a bit ostentatious to call it an engine) is structured as a fun comparison with OP's? I've not settled on a theme or aesthetics yet. Probably won't bother pondering too much on that until I've got the base gameplay loop together.

>>759 Looks very smooth. I'd be interested to read what you have to say about your code, Anon. Like, what's a quad tree and why do you want one?

>>760 I'll try and find time later to write something up! Quad trees are a data structure where you have space and when you put more than N things into it you split it into four (hence quad) and move those things into the appropriate child regions, and this can repeat for whatever arbitrary maximum depth you set. So now, when I want to check if the player is colliding with a wall or enemy or whatever, instead of needing to check every single one, I can query the quad tree for quad(s) nearby and limit the number. So 100 walls and 200 enemies could go from 300 checks vs the player to just a handful for example.

>>759 Nice work Anon. Speed is king.

>>>759 Looking good, what are you working in?. Yes, I would like to see your code. While I hope that some fun little games can come from this jam, the real legacy will be the experience gained and lessons learned and sharing those here can benefit those who couldn't participate as well. >quad-trees Nice. One of the first optimizations you'll see in a 2D game. Just make sure you aren't prematurely optimizing - 300 AABB checks per frame and a handful per frame are both a rounding error in the eyes of modern CPUs. I left them out of the OP game as an experiment to measure performance without them. The result with 200+ AABB checks? 2000+ FPS, so I said fuck it. Take the following, basic implementation of an AABB-AABB collision check: bool is_collide_aabb(const AABB & first, const AABB & second) { bool colliding = false; // compiler should be able to skip evaluating the rest of these when any one of them is false if ((first.ul.x < second.br.x) && // first aabb left edge is left of second aabb right edge (first.br.x > second.ul.x) && // first aabb right edge is right of second aabb left edge (first.ul.y > second.br.y) && // first aabb upper edge is above second aabb lower edge (first.br.y < second.ul.y)) // first aabb lower edge is below second aabb upper edge { colliding = true; } return colliding; } It seems like a lot of checks until you realize that the compiler can skip execution of long logical expressions if the result cannot possibly be changed. Here, the two AABBs are passed as constant references, skipping the copies involved with pass by value, and signaling to the compiler that they won't be affected by the code inside the function. The 'create bool, change value, return bool' is also often return value optimized away to simply 'return bool' in modern compilers. The first two checks inside the function are whether we are to the left of an AABB or to the right of it, which is the case for 99% of AABBs at a given time in a side-scrolling level. So not pushing a bunch of data around and being able to break out after one or two of these 'float greater or less than float' comparisons results in an utterly trivial computation. I'd be surprised if 10's or 100's of thousands per frame at 60+ FPS wasn't possible. But hey, that's AABBs. For arbitrary geometry collision involving dot products and square roots and shit it may be a different story.

A few new things to end the first stretch: fireballs, collapsing platforms and a WIP boss fight. I wanted to have the gameplay elements in place for week 1 and that's basically the case, should be able to start making levels this week. >>759 Welcome to the jam anon, those quad trees look very interesting.

>>763 Follow-up: I may have been quick to dismiss quadtrees since I forgot the best use case for them: for when you need to check collision for every entity, with every other entity. 10 entities? 100 collision checks (not really, if you checked A vs B, you don't need to check B vs A but you get the idea). 100 entities? 10,000 collision checks. In that case, you will definitely want to spacial partition them. Then, 100 entities checking against each other becomes say, 25 groups of 4 entities checking against one another which is 150 checks vs ~10K. I was able to avoid this by only having the PC check for collisions with environment and mob AABBs, and the 'frog' enemy check against environment AABBs for navigation. Max 4-500 checks/frame maybe. >>765 Coming along nice.

>>763 Is it possible in C++ to directly return a boolean expression's result? Like: bool is_collide_aabb(const AABB & first, const AABB & second) { // compiler should be able to skip evaluating the rest of these when any one of them is false return ((first.ul.x < second.br.x) && // first aabb left edge is left of second aabb right edge (first.br.x > second.ul.x) && // first aabb right edge is right of second aabb left edge (first.ul.y > second.br.y) && // first aabb upper edge is above second aabb lower edge (first.br.y < second.ul.y)); // first aabb lower edge is below second aabb upper edge }

>>767 Yes, you can return any expression's result directly. Even nasty shit like this (god only knows to what degree it would be optimized though): int add_one_three(int num) { return num + 1; } int add_one_two(int num) { return add_one_three(num); } int add_one_one(int num) { return add_one_two(num); } int result = add_one_one(1); I only wrote it the way I did for readability and because the compiler doesn't punish you for doing it that way. Write the best code that you're able to understand and maintain.

>>763 I'm in the Nim+SDL2 guy. This is the first time in a long time I've actually tried to optimize my collision stuff because like you said, it's usually trivial for little games. Last game just wasn't big enough to need it and NSS just brute forces it and stays very fast since I use pre-allocated pools to be very cache friendly but late in a run it can still end up being in the region of tens of thousands of checks per frame. I'd like to really ramp up the enemy count for this one to give player a sense of being overwhelmed, which was my goal for adding it. We'll see how it works out! I've been using this different AABB collision check and resolution details recently (although I use that bounds comparison method in quad tree queries) that I think is pretty interesting: proc collides(a, b: ptr Shape): Hit = let delta = b.position - a.position let px = (b.size.x * 0.5 + a.size.x * 0.5) - abs(delta.x) if px <= 0: return result let py = (b.size.y * 0.5 + a.size.y * 0.5) - abs(delta.y) if py <= 0: return result result.collision = true if px < py: let sx = sign(delta.x) result.delta.x = px * sx result.normal.x = sx result.position.x = a.position.x + ((b.size.x * 0.5) * sx) result.position.y = b.position.y else: let sy = sign(delta.y) result.delta.y = py * sy result.normal.y = sy result.position.x = a.position.x result.position.y = a.position.y + ((b.size.y * 0.5) * sy) return result >>765 That ghost platform is a neat idea! >>766 Yep, exactly! Hopefully not a distracting discussion since it's probably unnecessary complication for most.

>>767 >Is it possible in C++ to directly return a boolean expression's result? Not is it possible, it's preferable. The compiler can do a better job of optimization (copy elision, move construction, etc) such as >>768 's example chain when they are combined that way. I your more straightforward example, even a full copy is entirely trivial (in C++ , bool's are a real type, derived from the int family). And yes, the so-called 'short circuiting' of Boolean operations is definitely part of C++ 's statement evaluation mechanisms.

>>768 >Write the best code that you're able to understand and maintain. This. Most newbs have learned from their 'smart' peers to create the most convoluted, obtuse code possible for a given situation, because that's 'clever'. In fact it's a hot mess; definitely makes the maintainer's life harder, and usually results in less-performant code. >tl;dr State your intent directly and clearly in code. This will often turn out being high performance from the compiler too.

>>771 >Not only is* >In your more*

Progress status: fucking around with swinging?

>>776 We Donkey Kong now. How are handling getting on and off the "rope"? Are you colliding with an invisible line and then pivoting that around the red center point? Or are you shooting a line from player to point spider-man style?

>>777 Just attaching/releasing on button press and release. I did a quick doodle to maybe explain it better. Goal was to be more consistent and reliable rather than physically accurate. Current idea is that the player will lock on to nearest "hook" in the direction they're facing, within a certain range. Think I'm punting the tower survival angle and might just focus on some pure platforming. Maybe like Jump King and that ilk where you have one long difficult level you're expecting to complete in one go.

Bunny+fox game duo here reporting that things’re coming along. Most player traversal moves are now in and animated - jump, run, ground slide, wall slide/jump, ledge grab+mantel, and a midair boost dash that’ll probably end up cut in favour of a simpler double jump system. Still needs tuning, but it feels a little like a game now. Hoping to be able to grab some footage to post this weekend. >>776 >>779 That looks great. Very smooth. Might steal the technique; swing ropes are great fun.

Bit more progress. Embracing full on teeth gnashing style platforming, so now there's no mid-air adjustment, You'll have to nail jumps and when to let go during a swing. Smacking into a wall stuns you and makes you fall. Next up is probably camera and starting on different obstacles. >>780 Thanks!

Anyone has any tile requests? I would need general dimensions, like 1x*4y, and more specific directions. Full mockup with everything you need would be the best option for me. Technically I can do some 3d models too. Like this>that.

>>784 I don't know about Nim anon but I think everyone is going for more of a hand-done pixel look (16x16 pixel tiles).

Week 2 update, gameplay done and 8/10 levels completed, once the last levels are finished it's just some sprite work and finally packaging the game.

>>790 It was just an example of how a request should look like, using my current available stuff. I can do other shit too.

Been dealing with Some Life Things®️ past few days but before that I did get a camera going. I'm hopeful will find time this weekend for a big progress push and start doing some sprites.

Is building Raylib for Windows from Linux as simple as compiling a static build with Mingw GCC?

>>794 Yes. I could have sworn I wrote up something about it before but I can't find it now. Get it working yet?

>>794 Actually, I think I ended up downloading the binaries off the raylib releases page here ht tps://github.com/raysan5/raylib/releases Then, since I'm on linux, I couldn't, or didn't want to install them to the usual usr/local/lib or whatever folder, so I followed someone else's directory setup and makefile, which you can find in the projects files here >>691 Let me know if you still don't get it working.

Had fun yesterday putting together an in-game editor so can quickly iterate and test. Messing around also revealed a few collision issues that I've fixed. Need to slap together a quick level format to save and load from and ability to swap between placing different things. Then can focus on building things out and doing some art.

>>795 >>796 Thanks. I've made a demo build, if someone could test the Windows version I would appreciate it: https://archive.org/download/19100-drmagma/drmagma.zip >>797 Nice, that looks very quick and intuitive, good job!

>>797 Looks very nice Anon, good job!

>>798 >>800 Thanks anons! I made more progress yesterday. Now I can place different objects types in the editor and there's saving and loading the level. Along with saving the level file it saves a PNG of the level layout that I'll use as a reference to draw static art on top of. Also started implementing different objects, have springs and spikes so far. Should be pretty quick to get the rest done. I thought it would be interesting to not have a death state, instead spikes and other harmful objects will just knock you back (most likely further down the level). I've got a rough idea of the rest of the obstacles and they shouldn't take too long to get in. There's a proper hook finding system too now instead of previous hardcoded one. Not much more to go before I can focus on just the level design and art!

>>802 Looking badass. Apologies if I didn't comment on your other updates - I've been busy with some IRL shit and another project. Does this approach of yours usually work out for you? I notice that instead of jumping into content creation, you seem to focus on tooling and asset pipelines, which I'm guessing lays the groundwork that allows you to crank out a lot of content in a hurry at the end. I see that approach a lot too among traditional studios and teams - having basically nothing but placeholder art and a whole lot of tooling and backend code for years, then suddenly 3 months from launch implement all the content. If so, maybe you can say a little something and give the rest of us some pointers there.

>>804 Thank you anon! I think it works well for me. I've not really done a level design focused game in a long, long time (I think I tend to do better at general game or system design, like mechanics) so part of my focus on wanting to do a simple editor that lets me test super quick is to hopefully be more efficient. Being able to test a section over and over and make little tweaks, see player jump arc etc without the need to jump into another tool, save, reload, seems like it will give me better chance of making it hard and fun in the timeframe. On my last few games doing animations, sound effects were usually the last big push so maybe it is common? Although I like to get static sprites in pretty early to start getting a feel for how things look. (I'm actually behind on doing that since I wasted time on that tower survival idea that I ended up not liking.) Not sure if that was useful or not, I find it a bit hard to articulate specifics. I've kinda fallen into a routine in how I approach them and seems to work out!

Here's some progress following on from >>736 using a filler background and tileset.

>>815 Great to see it coming together! The slide and ledge grab look fun.

>>815 Awesome work with the animations. If I gotta nit-pick though, bunny's back leg is looking a little stiff in the jump animation, seems to not change from the idle pose while the leading leg does. Can I ask how you're recording/encoding these? Impressively small filesizes.

>>816 Thank you! Hopefully we manage to turn all this into something that's fun to play. The pursuit idea's looking less achievable given the time we've got left and the other content we want to get in there, but at least there's a "platformer" to work from now. >>818 Sharp eye - you have us dead to rights. Hoped it'd look less clumsy in motion than it actually does, but I guess some corners aren't meant to be cut. Footage is nothing fancy: Recording's spat out as raw AVI by Godot's so-called Movie Mode, which is then run through Handbrake with FPS set to 60, encoding presets set to slow, and quality set to RF 30. I was also pretty surprised at the output size.

>>819 >I was also pretty surprised at the output size. Compressed video codecs store the changes between each frame instead of the full image, the large blocks of solid color in your videos mean that generally a much smaller number of pixels need to be stored for a frame.

Started fleshing out my character, little adventure guy with big fluffy hair. Luckily the rest of the states should be easier than these. Think I know what music I'm going to throw in, which has helped me get a better mental image of what I want things to look like. >>819 Snap, I dig doing white outlines too!

Final update before the 7th, almost finished with sprites which I think have come along OK, would look better with integer scaling but it will do. >>815 >>824 Looking great anons!

>>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.