/agdg/ - Amateur Game Development General

xbox.jpeg
[Hide] (20KB, 494x435)

ps3.jpeg
[Hide] (98KB, 1200x941)

logif310.jpg
[Hide] (41.9KB, 904x566)

chink_sfc.jpg
[Hide] (32.1KB, 1025x1000)

test-2023-05-12.mp4
[Hide] (305KB, 804x638, 00:16)

>>603 (OP) 
Working on gamepad handling code at the moment. Gamepads will be supported in the code base. I don't know about everyone else, but I can't stand playing a platformer on the PC on in a browser with the keyboard. Anything more complex than the original Mario Bros, shit like holding run and jumping while shooting diagonally upwards can fuck right off. My fingers don't move that way. Anyway, Raylib claims support for the XBOX 360 and PS3 controllers out of the box but since it uses GLFW for gamepad input, which apparently reads from SDL's gamecontrollerdb.txt, most any controller out there just works™. I don't own either the xbox or ps3 controllers, but I do have a Logitech F310, which works fine, and a pair of chink USB SNES controllers, which while detected fine, had the face and shoulder buttons mixed up. Maybe it's not in the DB? I don't know. Anyway, I added gamepad key binding to my ini parsing code, and made a little test program to verify the bindings were correct. Eventually I will expand it to use the default keys for your detected controller, and if they're not correct, allow you to change them via the config.ini file, or maybe an interactive key binding screen (press "D-PAD UP", press "D-PAD DOWN", press "A", etc.).

example config.ini:
; config.ini
; TEST CONFIGURATION FILE

[screen_size]
width = 800
height = 600

[video_options]
fullscreen = false
msaa_4x = true
vsync = false

[keybinds]
dpad_up = 1
dpad_left = 4
dpad_down = 3
dpad_right = 2
middle_button_left = 13
middle_button_right = 15
face_button_up = 6
face_button_left = 5
face_button_down = 7
face_button_right = 8
shoulder_left = 11
shoulder_right = 12


See Raylib gamepad example if you want to test your controller or just take a look at the gamepad code: ht tps://www.raylib.com/examples/core/loader.html?name=core_input_gamepad
SDL's gamecontrollerdb.txt: ht tps://github.com/gabomdq/SDL_GameControllerDB

>>608
I forgot to mention that keyboard will also be supported, in case anyone prefers it or doesn't have any kind of controller.

720.png
[Hide] (48.9KB, 1284x758)

1080.png
[Hide] (57.6KB, 1920x1080)

Testing resolution up-scaling for tile-based games. First, I made a mock-up screen in GIMP using a 16 x 16 pixel tileset I found somewhere. I chose a screen size of 27 x 15 tiles, because it's close to the height of SNES games that used 16x16 tiles (a 256x224 resolution SNES/SFC screen would be 16 x 14 tiles), and while not integer divisible into 1280x720 or 1920x1080, it isn't too horribly off. This was then rendered to a 432x240 pixel surface, grid lines rendered on top of that, then scaled and rendered to screen resolution. Not too complicated, relevant render code looks like this:
BeginTextureMode(scale_texture);
            
    ClearBackground(BLANK);
            
    DrawTexture(mock_texture, 0, 0, WHITE);
            
    // draw grid
    Color grid_color = {0, 0, 0, 100};
                
    BeginBlendMode(BLEND_MULTIPLIED);
                
        for (int x = 0; x < 27; x++)
        {
            DrawLine(16 * x, 0, 16 * x, 240, grid_color);
        }
                    
        for (int y = 0; y < 15; y++)
        {
            DrawLine(0, 16 * y, 432, 16 * y, grid_color);
        }
            
    EndBlendMode();
            
EndTextureMode();
            
DrawTexturePro(scale_texture.texture, (Rectangle){ 0, 0, (float)scale_texture.texture.width, (float)-scale_texture.texture.height },
    (Rectangle){ 0, 0, (float)GetScreenWidth(), (float)GetScreenHeight()},
    (Vector2){ 0, 0 }, 0.0f, WHITE);

Screen shots are 1280x720 windowed and 1920x1080 fullscreen.

screenshot000.png
[Hide] (60.7KB, 1280x720)

screenshot001.png
[Hide] (60.8KB, 1280x720)

screenshot002.png
[Hide] (60.8KB, 1280x720)

>>614
Very basic axis-aligned bounding box collision testing. Naive implementation where every frame, the player character AABB is tested for intersection with every AABB on the map - in this case, 91 in total, which is still a trivial amount. Larger maps with more geometry or maps with large numbers of enemies, pickups, and projectiles will need some kind of organization and coarse testing to reduce the number of checks per update, for instance, quadtrees or horizontal or vertical slices depending on level orientation. There are other methods of collision detection I would like to address later as well, such as per-pixel and convex volume, since not every platformer uses old-school low-resolution character and world sprites.

dont_walk_left.mp4
[Hide] (1MB, 872x680, 00:22)

>>616
So while detecting AABB collisions is basically trivial, correctly resolving them is apparently anything but. May end up integrating box2d physics if I can't come up with a reasonably simple (correct, easy to grasp, and extensible) solution to this in the next day or too, unless someone knows a smaller and simpler physics library, I'm open to suggestions.

big_duk.jpeg
[Hide] (773.3KB, 2060x1546)

>>617
Alright I gotta talk this shit through, it's driving me nuts. My approach should work in theory, but is failing in practice (of course).

aabb1.png
[Hide] (18.9KB, 1038x874)

aabb2.png
[Hide] (18.9KB, 1037x879)

aabb3.png
[Hide] (18.8KB, 1042x879)

aabb4.png
[Hide] (19KB, 1035x875)

aabb5.png
[Hide] (18.4KB, 1033x868)

>>618
So the problem here is this: the world is composed of a whole bunch of AABBs (axis-aligned bounding boxes). They represent all the things (for now, map tiles) that are not passable - walls, floors, ceilings, platforms, etc. The player is also, in this case, represented by an AABB, this represents his shape and size (bounds) - the bottom edge is at his feet, the top edge at the top of his head, etc. You can see what that looks like looking at my last couple of posts, but for now, I'm just going to draw the boxes themselves. The red represents world tiles that can be collided with (are solid). In this case, we have something like a horizontal platform. The green box represents the player. The arrows represent velocity - direction of movement, the length of them representing the speed or distance moved in the time interval we're working with, don't worry too much about that. 

These 5 images show a classic 2D collision problem. The first pic shows the player falling down towards a platform. Maybe he jumped and is coming back down, maybe he fell from a higher platform, it doesn't matter. The second pic shows the collision. After the update interval, where velocity is integrated with the time delta to update the player position, the player has ended up in a position inside of one or more of the world colliders (AABBs). Since our red blocks are meant to be solid, this is an undesirable situation. The player can be said to be currently "colliding" with the blocks. We need to "resolve" the collision, by moving the player back outside of the block, as well as setting his velocity's y-axis component to 0.0, as he has "landed" firmly on the platform. The correct resolution is shown in pic 3. The small red arrow shows the direction and amount the player was moved to resolve the collision. Pics 4 and 5 show a common error in resolution, where the collision for block 3 is handled first and incorrectly, pushing the player to the right of it, followed by a vertical correction from the collision with block 4. Sometimes, if your resolution code checks and corrects collisions from the right first, you'll find your character being push right from block to block until he falls out the right side or straight off the screen. In order to correctly resolve collisions, you need to take into consideration all currently colliding AABBs, order of collision, and direction of collision as well (from the top, from the side, from an angle, etc.). This is where things get tricky (and where I'm currently stuck).

solve1.png
[Hide] (13.4KB, 1469x876)

solve2.png
[Hide] (13.5KB, 1473x868)

solve3.png
[Hide] (14.7KB, 1471x877)

solve4.png
[Hide] (13.6KB, 1466x873)

solve5.png
[Hide] (14.4KB, 1467x870)

Let's talk about direction of collision. Take a look at the first pic here. It may seem, at a glance, to be just like the last post, where the player has fallen and intersected one of the map AABBs (shown simplified to one AABB here) from above. But in reality, there is no way to know that from position data alone. You need to consider the velocity vector that the player is currently moving at at the time of collision (the instant we check and notice the overlap). Velocity, usually represented by a 2-dimensional vector like
Vector2 p_velocity = {-4.4, 1.2};

The first value represents the x-axis component and the second, the y-axis component. In this case, the x component is negative, so our player is moving left, while the y component is positive - moving up. So the player in this case is moving diagonally up and to the left. I show the actual player velocity in pic 2. As you can see, the player has not fallen down from above and collided with the top surface of the platform, he has actually hit it from the right side, moving at a speed as to almost put him all the way through the AABB (which is a whole other problem on its own). Now, I don't want to get into all the ways that you can fuck up resolution at this point, even though I've probably done most of them, I'm just going to list my latest and almost-working approach. To resolve this situation, I need an important bit of information - which side of the AABB the player collided with. To find that, I make a copy of the current player aabb, then "back it off" by some fraction of the current velocity. Something like
player_aabb_copy.x -= player.velocity.x * GetFrameTime() / 16;
player_aabb_copy.y -= player.velocity.y * GetFrameTime() / 16;

The "-=" bit is what moves our aabb in the opposite direction, and the "/ 16" gives us a sufficiently small step to move back. After each "back off" step, the new player AABB position is tested for collision against the colliding map AABB and repeated until no longer colliding. Pic 3 shows those "back off" steps in action, and pic 4 shows the final position of player AABB copy once it is found to no longer be colliding. Now, I look at where this final position is located with respect to the map AABB. In this case, it is to the right side, thus, traveling at the velocity he was, the player has collided with the right edge of our map AABB. So far so good. We could stop here if we wanted to. The player is no longer overlapping the map AABB and, he has been moved to the correct side of it according to the way he was moving. The problem with that though, is that he will "stick" to the wall. We moved the player position back in both the x and y directions, so both his horizontal and vertical movement has come to an unnatural halt. That and, if his velocity remains constant, he will collide again and again in the same spot, and be "stuck". To avoid this, we use the direction of collision, in this case, from the right, in order to only correct the overlap on the x-axis. The final pic shows the "correct" in so far as I understand it, resolution: the player's x-axis position is moved back out of the map AABB by the overlapping amount, the x velocity is set to 0.0 from the impact, and the y-axis movement is left alone - the player "slides" up the wall a bit from his vertical momentum. 

Let me know if I'm doing something horribly wrong with my approach. My code is fucked somewhere but I think my algorithm is sound. It definitely fucks up with multiple colliding AABBs though, usually popping to the top of a block collided with from the left or right.

cont1.png
[Hide] (12.6KB, 1047x807)

cont2.png
[Hide] (13.1KB, 1041x847)

Let me take a moment, while I'm thinking about this, to mention continuous versus discrete collision checking. So far, I've been using discrete checking, that is, looking at the AABBs only on discrete intervals, inside the update loop. The problem with this though, in the case of objects moving quickly or just with certain unlucky trajectories, is the possibility of missed collisions due to the objects passing through another in between update (collision checking) intervals. First pic shows an object moving fast enough to pass completely through a blocking AABB in a single interval. The second pic shows an object, not moving particularly fast but, at such as angle as to skip over the blocking AABB within an interval. This can be solved by not just checking for collision at the end position of the movement phase but rather, keeping a snapshot of the last position, getting a vector for the difference in position between that and the current position, then checking for collision N times while moving along that vector, in distance intervals of vector / N. The collision is then resolved the same way as in the discrete method, which taking into account the "left over" movement that needs to be handled to bring us back to the present, object position-wise (slide along surface, collide with another AABB, etc.). While it seems like this method increases the total number of collision by N times, you can check in two passes: first, a "coarse" collision check phase where you can use either an expanded AABB for the fast-moving object (AABB size * 2, * 3, or maybe proportional to velocity) or, by using center to center distances to check for POSSIBLE collisions, then, the "fine" continuous check on the smaller list of possibly colliding AABBs.

progress.mp4
[Hide] (1.3MB, 1284x758, 00:22)

Progress, maybe. Collisions are more-or-less handled properly, even at low framerate (30fps) and (relatively) high speed. Now have the issue of getting stuck against walls, not just because of the previously mentioned problem of moving backwards in both the x and y directions when I should only move in one or the other, but because when jumping while walking into a wall, I both attempt to move upwards and attempt to move into the wall. And because of the order of the AABBs in the vector I have, I'm checking collision against the uppermost tile first and colliding into that tile from the bottom, moving me back down and killing my y velocity, before handling collision with the tile directly next to me, moving me back to the side and killing my x velocity (which is the desired behavior). Not sure how to handle these impossible collisions; it's not just a check order problem. With a strict tile grid structure, I can query the grid to see if I'm blocked in certain directions - can't hit a tile from the bottom if a tile occupies the space below it. I'd rather not take that approach, one like you would see with an NES or SNES game or similar, because I'd like the system to be usable with arbitrarily located and possibly overlapping AABBs in float coordinate space. Gotta keep plugging away at it.

wew.mp4
[Hide] (2.5MB, 1284x758, 00:32)

>>622
Still didn't fix the wall bug but fucked around a bit and tuned the jumping/movement code some. Good enough for today.

>>623
This may be a dumb suggestion but wouldn't it be easier to check for collision with the new position before moving the object for real?

>>624
Not a dumb suggestion - that's what is actually happening. At least, depending on how you define "for real". For me, moving the object for real means updating it's position, displaying it in its new position, then moving on to the next update/display interval. Checking before moving really only applies to grid-based games with grid-based movement, like one where tapping 'A' on your keyboard once moves your character one grid space to the left. With those games, there is no "collision checking" per-se, you can simply query the map grid to see if the space you would like to move to is occupied or not, and then either do the move or don't do the move. For games with more freedom of movement in space, especially where the player character or other objects are being subjected to outside forces (gravity, riding on a moving object, sliding down a slippery slope, etc.), it isn't really possible to determine where the player/object will end up once you've integrated the various forces and interactions, short of actually doing it and seeing what happens. "Walking back" the result of that trial doesn't mean it's fucked and you reset the player to where he was before this time interval, it just means moving him out from inside of solid things and putting him in the correct final position if for instance, he contacts an angled surface and slides along it, or bounces off it if he's rubber, etc. If that makes sense.

>>625
I should have mentioned too that, the typical (greatly simplified) game update loop for a platformer might look like this:
while (true)
{
    get_inputs(); // handle button presses, etc.
    integrate_accelerations(); // get current velocities for player/objects under acceleration
    integrate_velocities(); // get current positions for player/moving objects
    collision_check(); // what I'm working on now - resolve collisions and determine final player/object positions
    draw(); // display resulting scene
}
So even after moving the objects there is still time to "fix" their positions before drawing.

fix1.png
[Hide] (16.3KB, 1269x877)

fix2.png
[Hide] (17.8KB, 1461x874)

working.mp4
[Hide] (1.3MB, 1284x758, 00:18)

Alright, now we're in business. Got everything working alright. The problem was, when trying to walk against a wall and jump, I was getting incorrect collisions against the bottom edge of tiles in the wall. This was caused by the order in which I was resolving collisions with multiple colliding AABBs, which was, due to the the way they were arranged in the data structure, from top to bottom, left to right. This worked out fine though, for walking on floors and bumping into ceilings. If the order of resolution was the reverse, I would be able to jump up against walls, but bump and stutter across floor tiles. The solution, and I had to find this somewhere, was to resolve all collisions in the order of largest AABB overlap area to least. I can't think of a logical proof for why this works right now, but whatever, it does. Pic 1 shows the order of resolution when jumping against a wall. The first AABB collision resolved is the one in the middle, which is a collision from the right so the player is moved back to the right, x-velocity is zeroed, and y-velocity is left alone. Next up is AABB 2, for which nothing is done because it is no longer colliding, same with AABB 3, and we're done. Next pic shows walking into a corner, another situation that was jamming my shit up now and then. When walking left here, the character "falls" down into the floor a bit due to gravity (this may be avoided by using flags/state machine etc. to apply gravity when not on a surface but eh, I'll get to that sort of thing later when I play around with stuff like ladders) as well as intersecting the left wall tiles. Unlike the previous case, we need to resolve movement on both axes, and order isn't particularly important. I just mention it because it's a common edge case. I have the number 2 on here twice because their area looks the same to me, and it doesn't matter which is resolved when, just that the important ones are. Good shit.

ded.mp4
[Hide] (2.9MB, 1284x758, 00:45)

better.mp4
[Hide] (1.5MB, 1284x758, 00:24)

Tried implementing a moving platform. Had some issues when it's moving downwards, mainly with jitter when riding it down (platform move speed is faster than fall speed by gravity - fix would probably be setting player velocity to the velocity of the surface he's currently contacting), but also with jumping up through it from the bottom for some reason. Also enters an infinite loop and freezes at the end with an un-resolvable collision between two parallel surfaces. First video shows that janky action. Second video shows result of setting player velocity to match platform's on collision when platform is moving down. Better, but still not perfect.

Still waiting to hear some ideas by the way, as to what constitutes the absolutely bare-bones, but still expandable, platformer. My plan so far is to have:
>A player character controller with animations and finite state machine (on_ground, running, jumping, etc.) + collisions
>gamepad and keyboard input
>Loadable/progressable? levels
>A map scrollable both horizontally and vertically
>Tiled map and tileset importer
>A monster with basic move/attack pattern
>Pickups (health, coins, keys, etc.)
>A damaging/lethal trap (spikes, lava, etc.)
>Death condition (fall off world, touch trap, touch monster, etc.)
>Win condition (reach goal, collect all things, etc.)
What am I missing? Firing projectiles? Movement on non-axis-aligned surfaces like Sonic?

e7e47f8ede46cc30050d4f67f6115e1b9486205127fd7977ea67fcef70661eae.png
[Hide] (6MB, 3900x2300)

>>629
It really depends on what gameplay possibilities you want to load into the base toolkit you're creating. Get too specific and participants end up constrained without any room to stretch, too general and the less able participants pancake against the very start of the difficulty curve.

>A player character controller with animations and finite state machine (on_ground, running, jumping, etc.) + collisions
Very good thing to include because it prepackages a common problem that helps participants focus on what those states are instead of how to do them.

>gamepad and keyboard input
Definitely.

>Loadable/progressable? levels
This starts to get into too-specific territory, but I think including a basic implementation would go a long way towards getting people started.

>A map scrollable both horizontally and vertically
A good idea because it solves a basic problem but gives participants the opportunity to customise it if they want.

>Tiled map and tileset importer
A must.

>A monster with basic move/attack pattern
It'd be especially good if the monster used the same state machine system as the player.

>Pickups (health, coins, keys, etc.)
>A damaging/lethal trap (spikes, lava, etc.)
>Death condition (fall off world, touch trap, touch monster, etc.)
>Win condition (reach goal, collect all things, etc.)
All excellent things to include in the example.

Maybe you already addressed this, but what about sound and music? Including and using simple SFX and a music track in the base package will show people how to do it, and from there they can go hunting for their own shit from Itch or Freesound or whatever.

I know you don't want to do a theme beyond "maek platfoemr" but I think it might be a good idea. Themes are great because they take care of the blank page problem and turn everyone's creativity to ways that they can respond to the theme; counterintuitive as it seems, a theme can often make people more creative rather than less.

Really admire what you're doing here, by the way. I'm fully bogged in the jungle quicksand of my own game but perhaps I'll find time to make a little thing for this too.

Picture unrelated, but I think it's nice.

cave_johnson_invented_tide_pods.mp4
[Hide] (789.2KB, 480x268, 00:16)

>>630
>>629
Sorry, forgot the most important part:
>Firing projectiles?
They need not be projectiles, but having examples of the create/move/do-something-on-collision/remove cycle would be a good thing. Projectiles happen to be a very simple case, so perhaps they're a good thing to include in the standard example.

>Movement on non-axis-aligned surfaces like Sonic?
I think this goes way into "too specific" territory, and also provides more to go wrong.

tiled_shapes.png
[Hide] (169.5KB, 1920x1047)

nonrectangular.jpeg
[Hide] (148.7KB, 640x480)

drawn1.jpg
[Hide] (105.3KB, 1200x681)

drawn2.png
[Hide] (621.4KB, 1400x700)

>>630
>>631
>Get too specific and participants end up constrained without any room to stretch, too general and the less able participants pancake against the very start of the difficulty curve.
For sure, there is definitely a balance to aim for somewhere between "hello world" and a complete game.

>It really depends on what gameplay possibilities you want to load into the base toolkit you're creating.
I really don't want to constrain anyone's gameplay possibilities. That's one reason I'm trying to keep the criteria as broad as possible. I haven't even defined what a 2D platformer is. As long it's from a side view and you move around a 2D screen, I don't really care what people make. Sonic-like? Metroidvania? Shooting game like Alien for the SNES or Jurassic Park for the Genesis? VVVVVV-like puzzler? Game with vehicles? Terraria-clone? Go nuts.

>levels
>This starts to get into too-specific territory, but I think including a basic implementation would go a long way towards getting people started.
You think? It's actually kind of involved, loading a level, its map, graphics, enemies, pickups, level-specific logic or scripting, and then unloading it all (without memory leaks) to move to another level. My idea was a Level() object that would be loaded from xml, with 2 or 3 of them to show how to handle that. A basic "game" could then be: new game -> load world 1-1 -> beat that -> load world 1-2 -> beat that -> load world 1-3 -> beat that -> game over. congratulations. A "level" would only be 2-3 screen lengths (or heights) long and can be whipped up in Tiled in minutes. What did you have in mind?

>It'd be especially good if the monster used the same state machine system as the player.
Can't guarantee it'll be that generalized but I can try. I'd like to think the player state machine would serve as an example for implementing enemy or level/world state machines in case I wasn't able to.

>Maybe you already addressed this, but what about sound and music?
I did not, though I had thought of it. I'm still looking around for good stuff but year, BGM will play (maybe level-specific), and sounds will be used where appropriate (on jumping, collecting something, attack/explosion, death, etc.).

>I know you don't want to do a theme beyond "maek platfoemr" but I think it might be a good idea.
The goal was to keep it sufficiently broad, while still keeping everyone mostly "on the same page." I'd like it if people were able to share both high-level approaches and algorithms as well as implementation details, hence constraining the game type and framework (Raylib). Both are optional, though, if you really want to do something else or are more comfortable with a different framework. I figured some small subset of people might be turned off by those constraints, and adding a further one - theme, might turn off yet more people. But who knows. It's the first time, I have no idea how many people will participate and no idea how it'll turn out. I just hope the jam can garner some interest and be fun and educational.

That said, I'm open to suggestions. Did you have a theme in mind? What do you think would be fun to do? 

>Really admire what you're doing here, by the way. I'm fully bogged in the jungle quicksand of my own game but perhaps I'll find time to make a little thing for this too.
Thanks. What are you working on?

>Picture unrelated
Nice fox butt.

>They need not be projectiles, but having examples of the create/move/do-something-on-collision/remove cycle would be a good thing. Projectiles happen to be a very simple case, so perhaps they're a good thing to include in the standard example.
Sure, that was the idea. Spawning something, updating/tracking it, doing something if it interacts with something, and destruction of it. 

>I think this goes way into "too specific" territory, and also provides more to go wrong.
You may be right. I wanted to get away from my very-specific Mario-like that I've been playing around with and to a more general platformer framework, one that could support both old-school pixel/tile types as well as newer ones, with freely-placed objects and non-grid aligned colliders and graphics. I grabbed some pics of games that I'd consider not-tile-based, at least not wholly-rectangular ones. That's why I'd like to have examples for other collision types besides AABB - AABB. Tiled supports drawing collision shapes over maps as well, so I'd like to show how to import those and collide with them, provided they're properly convex. See first pic for what those triangles look like in the editor. In the exported XML they show up like so:
 <objectgroup id="6" name="Object Layer 2">
  <object id="8" x="160.043" y="159.957">
   <polygon points="0,0 15.913,15.9565 -0.0869565,16"/>
  </object>
  <object id="9" x="176.063" y="176.063">
   <polygon points="0,0 32.0625,15.9375 -0.0625,16"/>
  </object>
 </objectgroup>
You can add custom properties to these with values that get exported in the map file as well, so you could tag a volume as damaging, or collision shape as slippery, or whatever. I'll write up something about that then. But yeah, balance. Trying to make the skeleton of a game here, not necessarily a game engine. Appreciate the input and hope we get some more coming in eventually; I'd like to hear more about what people are interested in doing too, whether it's themes or mechanics or styles or whatever.

what_are_birds.gif
[Hide] (55.3KB, 250x250)

>>632
>I really don't want to constrain anyone's gameplay possibilities.
I think it's important to distinguish between building something in and cordoning something off. Sometimes it's the same thing, but because you're making an example on top of a general engine a more able participant is still free to chop off some or all of what you've done and build in a different direction.

Still, what you build in makes a big difference. It's obvious that different combinations of built-in capabilites allow different gameplay angles for the less programming-inclined participant. For example, choosing to not build in scrolling levels or projectiles means that someone who finds code intimidating won't be as likely to experiment with designs that include those things. Changing the effect of a projectile by changing an existing working example is very different to working the whole thing out for yourself, especially when you're of a skill level where that gap feels insurmountable. It also changes how the project feels to get started on, which is important for encouraging participation.

>It's actually kind of involved, loading a level, its map, graphics, enemies, pickups, level-specific logic or scripting, and then unloading it all (without memory leaks) to move to another level.
That's a very good point, and when put like that it definitely comes under plumbing - the stuff that everyone uses without thinking about how hard it is to get right. That's exactly the sort of thing it'd be helpful to include, it being a huge difficulty spike for the creator.

>Did you have a theme in mind?
Not at all, I just wanted to point out that sometimes little constraints like themes can be more helpful than a hindrance, encourage participation rather than discourage it.

On reflection, the themes here are "platforming" and "2D", and that might be enough to get some responses sparking.

>What are you working on?
A dungeon crawler focused on exploration and short, sharp, satisfying bursts of tactical combat.

>I wanted to get away from my very-specific Mario-like that I've been playing around with and to a more general platformer framework
It's up to you. In the end, the main criteria for something like this is how easy and fun it is for someone to pick up and get started with, and how well it will tolerate beginners' nonsense (of which I know plenty, being one myself).

platform.mp4
[Hide] (3.6MB, 1284x758, 00:39)

character_bounds_v0.5.png
[Hide] (6.6KB, 600x400)

bcR0A.png
[Hide] (61.4KB, 544x623)

8tzvN.png
[Hide] (7.7KB, 111x106)

So I finally got moving platforms working right (more or less), at least a vertical one for now. I was running into a whole bunch of problems when contacting a moving platform, such as jumping up through it when colliding with it from the bottom while it was moving down, since colliding with it would set my y velocity to zero, then the next frame it would move down faster than gravity pulled me down, causing me to collide again, except this time with a negative y-velocity, which, when reversed, would move me upwards, through the descending platform... Anyway, I added a little something I had seen mentioned in a few places: "contact sensors" - points located around the usual player AABB. These points are collided with the surrounded geometry like the player AABB is, but unlike the AABB, instead of pushing the player away so the points are no longer colliding, their collisions are simply registered as "touching" the colliding surface, which allows us to set flags that change the player's position and movement temporarily. Take this ascii doodle from my comments for how mine look now:
    *
 |``|
 |     |
*|     |*
 |     |
 |_|
 *  *  *
`
So now, colliding with a moving platform from the top will set the player position to just on top of the moving platform, just like any other collision with another AABB. After that, when the "sensors" are queried, the ones under his feet are inside the moving platform (one of them at the least), and we can now match the player position and velocity to the platform's. Since the contact sensors are checked every update interval, the player is free to walk or jump off the platform at any time, at which point the flags are updated and he is free to rise or fall or whatever like normal. See the video for this in action, and the pics for images I found showing what implementations look like. Also added BGM and a sound effect, but nothing really worth mentioning there since that was all extremely straight-forward.

references:
ht tps://gamedevelopment.tutsplus.com/tutorials/basic-2d-platformer-physics-part-2--cms-25922
ht tp://higherorderfun.com/blog/2012/05/20/the-guide-to-implementing-2d-platformers/
ht tps://gamedev.stackexchange.com/questions/141218/how-exactly-do-slopes-and-edges-work-in-this-scenario
ht tps://www.raylib.com/examples/audio/loader.html?name=audio_module_playing
ht tps://www.raylib.com/examples/audio/loader.html?name=audio_sound_loading

>>635
Apparently I didn't enable audio capture. Just use your imagination for now. Check out the raylib examples for how easy it is to get sound working too, it's pretty cool.

anim.mp4
[Hide] (431KB, 1284x758, 00:14)

Not much to report on right now, still plugging away at this. A bit more work than I anticipated but should be on track to release as scheduled. Whether or not I spend the next month explaining the design decisions and code idiosyncracies is another story though, heh. I did have a huge favor to ask of someone, hopefully someone with some familiarity with raylib, or at least able to compile on windows for windows using Makefiles. I'm guessing the majority of people that might be interested in participating are running windows and using something like VS Code for editing. I'm on linux, compiling with g++ and targetting linux, so I can offer support there. I'm looking for someone who can support building on windows. I had the idea of installing windows 7? 10? in a VM and doing it myself, but I don't know if I'm going to have the time. I've uploaded an older test project here: ht tps://anonfiles.com/N4w5jdt5z9/05112023_anim_zip If someone can download that and get it compiled and running on windows, it would be a huge help. Output should look like the vid if everything goes alright. I'll answer any questions you might have the best I can; I have no real experience compiling on windows but at least I'm familiar with the code.

>>633
>because you're making an example on top of a general engine
Actually more like making a general engine. Raylib is a set of C libraries providing graphics, sound, input, file I/O, etc. The general program architecture, object classes, data structures, file formats, etc. are all on you to implement. So there's a fair bit of boilerplate. While I'm trying to keep the scope focused on "EVERY platformer will need this", inevitably there is also some "MY platformer needs this" thrown in there.

>A dungeon crawler focused on exploration and short, sharp, satisfying bursts of tactical combat.
Sounds cool. Care to write something about it? Got anything to show yet?

>>635
>>651
>no video sound again
Starting to think this board doesn't support video with audio, gonna have to look into it.

>>652
I hear music in both, that last one is some heavy metal with a fancy keyboard.
Maybe you have audio disabled in the options/settings.

mute.png
[Hide] (42.5KB, 1191x746)

>>653
Well shit. Guess the problem's on my end then. When I go to play videos back, it shows the sound being muted and I can't unmute it for some reason. See pic. 

>the options/settings
Like, my browser settings? I don't have problems with any other videos but I'll try digging around. For instance, these videos I can hear fine: >>>/retro/772 Being mp4 and on the same site I thought I had fucked my encode up or something.

>>654
That's strange
>Like, my browser settings?
I meant the settings in the upper bar, pic related, but seems i remembered incorrectly because i thought there were audio options.
If you want to confirm i suppose you can download your own mp4 and check it, personally i can attest there's audio on >>651 and >>635, but >>628 and >>627 don't have. I don't recall that kind of error happening to me, the browser sometimes puts the audio symbol in the tab and i mute it by accident but in your case the mp4 itself is the problem.
Board options also don't include audio, that's bizarre, perhaps codecs?

settings.png
[Hide] (33.4KB, 892x328)

>>655
FUCK, pic related here

encode.png
[Hide] (57.4KB, 462x687)

>>655
Yeah, not seeing anything relevant in my browser settings. Here's my encode settings: H.264 and ogg vorbis. Downloading it and playing it works fine but, opening the local file in firefox has no audio. Going to play with my encoding settings I guess.

dungeon_crawler.jpg
[Hide] (174.9KB, 650x1000)

>>651
>more like making a general engine.
That sounds like a lot of work; thank you for putting in the time. I hope others will end up using it for the jam.

>Got anything to show yet?
Afraid not - it's all blocky filler assets and beans because everything for the past few months has been coming to grips with the systems that allow the game proper to be made.

For example, the dungeon crawling sections yielded a system that allows multi-floor dungeons that can be logically represented on grid paper (important for the exploration feel) but which aren't physically constrained to a strict grid layout - for example, imagine a "flat" dungeon built such that parts of it slope or follow an undulating landscape. Tiles can include special transition behaviors, so things like hidden exits, crawl spaces, winding paths, etc. are all handled like any other tile. This means a dungeon can be built separately to its logical representation - that is, one could sculpt chunks of it as whatever meshes, animations, and decorations one pleases and then place the "tiles" that the player and other entities traverse within those meshes, tile "rooms", or whatever mix of approaches makes sense. There's also a system of tile transport such that parts of the dungeon can move around and rearrange themselves, whether on their own or in response to some trigger, and everything - entity tracking, pathfinding, etc. - seems to just work.

In all cases, the dungeon's logical representation assembles itself behind the scenes so all a dungeon builder has to do is use graphical tools. That's very important, because things are best when played with - the quicker one can change and experiment, the more chances there are to get somewhere good.

The tactical battlefield system is receiving the opposite approach; since each battlefield has to be generated and pathing has to be fast enough to keep up with player inputs, it makes sense to instead approach it as a strict grid where the assets themselves are placed and interact according to some representation behind the scenes.

>Care to write something about it?
Although there's plenty of aesthetic, setting, gameplay, and story stuff, don't want to hold forth on it until there's something solid to hang it off. The approach here is to take well-established fundamentals, extend each of them just a little bit, and then let the player come at them in a slightly different way than they might be used to.

>>651
>anonfile expired
Fuck it, I just ordered one of those ~100USD mini PCs with botnet 11 on it. Gonna be a pain in the dick with no KVM switch but I'll see about getting a windows toolchain up and running on that when it gets here.

>>655
>>656
Encoding as webm (VP8 and Vorbis) seems to have fixed it for me - I can hear it in the browser now.

>>663
That's looking great Newt, looking forward to the jam!

excited.jpg
[Hide] (914.5KB, 3548x4096)

>>663
Looks very good, getting excited.

Where will you be posting invitations to the jam? A lot of places are sensitive about spam but just relying on passing traffic here doesn't seem like enough.

>>665
Thanks. A lot of compromises were made but eh, I'm just happy it more or less plays.

>>666
Checked. Yeah, I gotta make some posts inviting people. Everyone is welcome though, you don't need to wait for me to formally drop a post somewhere to get the word out if you want to.

>A lot of places are sensitive about spam
If someone wants to get butthurt about a cross-board event invitation, let them.

👋

Update. Trying to polish this thing and get it somewhat presentable. Got a repo set up, need to push the latest version to it when I'm done with it. I need to ask everyone though: what OS are you guys on? I gotta say, I can't get shit working on this windows box. I have no idea where to start with windows development and don't know if I'll be able to support it. Since I use GNU Make and Makefiles, I figured installing MSYS2 then GCC and Make would be all I needed but it seems its not that easy. You guys have any ideas? I can do both linux and windows builds from linux easily enough. Gonna need some help with building shit on windows though if anyone can give me a hand.

>>669
I'm running macOS and can have a try at it if you like, although I suspect that the imageboard crowd will instinctively jump to the idea that first sniff of trouble will indicate that the OS I'm using (and me) are unsuitable to develop anything. Never bothered much with non-Windows development on a Windows machine because I also found it to suck beyond tolerance.

Warming up for the jam at the moment. When's the official start in timezone terms?

>macOS
Did not expect that but OK. If you have the time, do you think you can give this a download and see if you can't build it? ht tps://anonfiles.com/we6cu4vcz8/05112023_anim_zip It's just an old test program, but it requires Raylib and the makefile is essentially the same as what I'm using now. After you get Raylib installed per ht tps://github.com/raysan5/raylib/wiki/Working-on-macOS it should just be a matter of running Make (or whatever you use to build projects on MacOS). 

>suck beyond tolerance
You ain't kidding. This is my second try at this too. The first day I got this machine it bricked itself by failing to install an automatic update, then failing to roll back said update and becoming unable to boot. I ended up having to do a factory reset.

>When's the official start in timezone terms?
There is none. It'll run for a month, so no need for any kind of mad dash at the start. I'm also on Asia/Tokyo time, so I'm something like 13-14 hours ahead of US anons anyway. Nothing stopping anyone from introducing themselves, talking about their OS, editor,  dev environments, etc. dev experience, what they want to make, questions, ideas, shitposting, whatever right now either.

screenshot.jpg
[Hide] (131KB, 2784x1720)

>>671
Done. Not too hard: It built and ran fine after clang was told to use C++ 11, point to the Homebrew-installed Raylib location, and use some different library names (like "-framework OpenGL" instead of "-lGL"). The changed lines are now:
>CFLAGS=-std=c++11 -Wall -Wextra -pedantic -Wconversion -I$(SRC_DIR) -I$(EXT_DIR) -I/usr/local/Cellar/raylib/4.5.0/include
>LINKERFLAGS=-L/usr/local/Cellar/raylib/4.5.0/lib -lraylib -lm -lpthread -ldl -lX11 -framework IOKit -framework Cocoa -framework OpenGL

No guarantee that this particular edit will work with something more complicated, but now you know in principle that this works on macOS and can be made to work by someone Googling error messages.

>>672
I should also mention that building like this will create dependencies upon the Homebrew-installed package according to "otool -L", so the result won't be suitable for distribution. For that, someone would need to follow the instructions given in https://github.com/raysan5/raylib/wiki/Working-on-macOS#without-xcode---building-statically onwards, but for a quick and dirty reference point those two line edits will suffice.

>>673
Nice. I don't know how Homebrew, Cocoa, or any of that works, but that sort of resembles how I build for windows on linux: have a 'lib' directory with 'libraylib.a', 'libraylibdll.a', and 'raylib.dll' and an 'include' directory with 'raylib.h', 'raymath.h', and 'rlgl.h'. The Makefile then looks like
CC=x86_64-w64-mingw32-g++
EXE=game.exe
BIN_DIR=bin
SRC_DIR=src
OBJ_DIR=obj
EXT_DIR=$(SRC_DIR)/external
EXT_OBJ_DIR=$(OBJ_DIR)/external

CPP_FILES := $(wildcard $(SRC_DIR)/*.cpp)
OBJECTS := $(patsubst $(SRC_DIR)/%.cpp,$(OBJ_DIR)/%.o,$(CPP_FILES))
EXT_CPP_FILES := $(wildcard $(EXT_DIR)/*.cpp)
EXT_OBJECTS := $(patsubst $(EXT_DIR)/%.cpp,$(EXT_OBJ_DIR)/%.o,$(EXT_CPP_FILES))

CFLAGS=-std=c++11 -Wall -Wextra -pedantic -Wconversion -Iinclude -I$(SRC_DIR) -I$(EXT_DIR)
#LINKERFLAGS=-lraylib -lGL -lm -lpthread -ldl -lrt -lX11
LINKERFLAGS=-Llib -lraylib -Wl,--allow-multiple-definition -pthread -lopengl32 -lgdi32 -lwinmm -mwindows -static -static-libgcc -static-libstdc++

all: $(BIN_DIR)/$(EXE)

debug: add_flag all
	
add_flag:
	$(eval CFLAGS+=-DDEBUG)

$(BIN_DIR)/$(EXE): $(OBJECTS) $(EXT_OBJECTS)
	${CC} -o $(BIN_DIR)/$(EXE) $(OBJECTS) $(EXT_OBJECTS) $(LINKERFLAGS)

$(OBJ_DIR)/%.o: $(SRC_DIR)/%.cpp
	#$(CC) $(CFLAGS) -c -o $@ $<
	$(CC) $(CFLAGS) -c -o $@ -g $<
	
$(EXT_OBJ_DIR)/%.o: $(EXT_DIR)/%.cpp
	#$(CC) $(CFLAGS) -c -o $@ $<
	$(CC) $(CFLAGS) -c -o $@ -g $<

clean:
	rm -f $(BIN_DIR)/$(EXE) $(OBJ_DIR)/*.o

clean_external:
	rm -f $(EXT_OBJ_DIR)/*.o

The linker flags I took from here: ht tps://github.com/peteblank/yotsubee

>dependencies
Yeah, you're going to want to build the static raylib libraries if you're building for desktop.

>>669
>>671
Yo, I'll be using Linux so your build setup should work just fine. Nothing fancy re: dev environment, just XNedit & URXVT. Managed to go over the basics of C & C++ so hopefully I'll be able to get the gist of how the engine works. This should be fun, good luck anons!

ht tps://anonfiles.com/a1O5w0vfz4/06062023_binary_zip

Linux and Windows binaries if anyone wants to play around. Source code next.

>>676
Source code if anyone wants to take a look: ht tps://bitbucket.org/anon-s-first-platformer/anon-platformer/src/main/ I do hope it's not set to private or anything, I haven't used bitbucket in a long time. I'll be back  later today to do a proper event post.

>>677
Does bitbucket need an account to view or something? The page is blank for me, even with JS.

>>678
Loads for me. If you’re using a VPN, maybe try using a different endpoint? Some end up on blacklists.

>>679
Huh, looks like cloning works, It's just the frontend I guess.

>>678
>>680
I'll try to mirror it somewhere else. The bitbucket front end is complete ass, yeah.

>>679
I can see it as well when logged out, should be ok.

Source code zipped
ht tps://anonfiles.com/G4Mazav5ze/anon_platformer_zip

specialthanks.png
[Hide] (5.8KB, 1280x720)

>>681
>>682
Looking good here, only thing is that some folders aren't created so you need to make them manually:
Assembler messages:
Fatal error: can't create obj/Coin.o: No such file or directory
make: *** [Makefile:40: obj/Coin.o] Error 1
...
Assembler messages:
Fatal error: can't create obj/external/pugixml.o: No such file or directory
make: *** [Makefile:43: obj/external/pugixml.o] Error 1

>>683
Did you download from the repo? Looking at it now, it does appear that 'obj' and 'obj/external' have somehow escaped being pushed. Maybe because they're empty until you build? Looking into it.

>>683
Fixed.

>>684
Git doesn’t include empty directories AFAIK, so makefiles etc. usually need to assume they won’t exist and create them with mkdir -p.

>>686
Figured. Thanks, I'll keep that in mind when I get around to polishing this turd of a makefile.

6/6 is upon us lads, so new thread up here >>688

>>686
>>687
Correct, git tracks files. Parsing a file name with slashes in it as a file within a directory, and creating those directories, is an implementation detail.
It's common to place a .gitkeep file in an otherwise empty directory that you want to store in git.

I'm surprised there's 0 results ITT for
>rpgmaker
>gamemaker
>renpy
>godot
>pygame
>scratch
>phaser
>dreams
>chip8
making it seem like you've only heard of unreal, unity and sdl and think raylib is the perfect middle ground.
Sure, if your audience is embedded engineers, suggesting raylib is a decent choice. Dabble in a language that gives you a book's worth of error messages if you try to cout a list of strings.

But for a more general audience something like scratch provides far more interactivity and guidance and keeps things simple. And since it's popular and targeted at literal infants, there's a wealth of tutorials, examples and Q&As. If you want to limit people to a platformer, just point them to the right scratch example of a platformer and a youtube tutorial for all I care.

Which brings me to the other point, that you don't want a "theme or gimmick restriction" yet you literally limit the jam to a type of game. It's like you worked your way back from "I know how to make a platformer with raylib and I think that's a good starting point for newcomers, let's test the hypothesis with a game jam". If the restriction were "the theme is potato", I could've made a potato platformer, a potato dating sim (beautiful eyes , I bet you'd make great offspring!) in renpy or a puzzle game or potato golf/billiards (just an asset swap of one of those old flash games) or even a potato museum walking sim. And you could've still provided an example platformer using raylib. Except then you'd have to use a couple of poorly AI-drawn assets, like the character being a potato and the hazards being boiling oil, peelers and fungus.

Guess I'll have to make a potato platformer in scratch now.

>>783
Raylib is not that bad xD.
You're overexaggerating.

>>826
I think that anon was referring to C++ rather than Raylib in particular.

>>783
Looking forward to playing your tater jumper Anon.

>>827
Not to mention 2d platformers are a shit tier genre thats been done to death for decades now. Even Mario largely moved on from it.

>>831
You can't seriously be trying to troll /agdg/ right now

>>832
Its a good genre to learn the ropes from, but not when every faggot under the sun is flooding every marketplace with the same copy paste 2D pixelshit with a dash of actual faggotry in there.

>>831
Mario games were way better when they were 2D.

>>831
>>852
It's a fucking jam, quit overanalyzing and being a faggot.

>>852
>>Its a good genre to learn the ropes from
Now you're starting to understand.

>>856
Guy's salty about something, I just wish he'd make a point sooner or later. I'll let him air his greivances or whatever for now and bust out the dustpan and broom and clean up after him if I have to later. Maybe he's got something to contribute, who knows. We are going to have a post-mortem discussion after the jam - what went well, what didn't, what people would like to see for next time, etc.. Maybe in the meantime our guy can get some chill and think about what to post for that.

Any plans for a second jam yet?

>>969
The first jam was poggers I can't wait until the next one!

>>853
It really was.