/agdg/ - Amateur Game Development General

Just Like Make Game

SAVE THIS FILE: Anon.cafe Fallback File v1.1 (updated 2021-12-13)

/agdg/ - Build a Platformer (First AGDG Game Jam), June 6 to July 7

Want your event posted here? Requests accepted in this /meta/ thread.

Max message length: 20000

Drag files to upload or
click here to select them

Maximum 5 files / Maximum size: 20.00 MB

Board Rules

(used to delete files and postings)

6/6 GAME JAM Planning / 2D Platformer Research Thread Newt Board owner 05/11/2023 (Thu) 10:31:58 No.603
Alright faggots, as I mentioned in the meta thread recently, I would like to start doing board game jams on a regular basis. Unlike other jams that just give you a theme and a ridiculously short deadline and then you're on your own, the game jams here will come with a ready-to-go, runs out-of-the-box codebase so that any participant will have a working, playable game from day one (however bare-bones and exactly like everyone else's it is). You may choose to use the provided code base if you want, but you're free to bring your own as well. Think the code is ass? Does something you don't want or need? Rewrite it then, I don't care. The provided code is simply to bring as many people up to speed as quickly as possible, as well as to provide a common ground for collaborating with and assisting one another. The first /agdg/ Game Jam game will be making 2D platformers - no theme or gimmick restriction, it can be whatever. The provided game skeleton will use Raylib for graphics, sound, and input, and be written in an easy-to-grasp subset of C++ (nothing fancy or hyper-efficient). The Jam will officially start on June 6th, 2023 (6/6) and run until July 7th, 2023 (7/7), one month. By start, I mean a thread will be created and the code base, along with building instructions will be provided on that day. You are free to do whatever prep you like in the meantime, of course. 7/7 will be a "demo day" of sorts, where everyone uploads their games for others to play, and an informal competition will take place to decide the best game. I say "competition" but it's just for fun, maybe we'll come up with something stupid for the winner though. >why? For fun and practice. Do I expect any masterpieces in a month? No. Will anyone make a "real" game to put up for sale or something? I highly doubt it. What I would like to see though, is everyone at least trying - hence lowering the barrier to entry as much as possible. Can't program? Learn, you've got a whole month. All code provided will be straight-forward and well-documented as to which lines are doing what, start by tweaking that. Can't draw? See itch.io and similar for free assets. Can't do sound or music? Again, itch and the like. Do I want to see a whole bunch of Super Mario-clone asset-flips? No. 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. In this thread I will be gathering ideas for what constitutes the "barebones platformer", and posting my research on that, experiments, and other progress on this project. I would also like to see the thread used for general 2D plaformer discussion. What's out there? What have you played? What's state-of-the-art? What are some cool mechanics you know of? Styles - low-res/pixel, high-resolution, limited-palette, tile-based, pseudo-3D, you name it.
Open file (19.97 KB 494x435 xbox.jpeg)
Open file (98.06 KB 1200x941 ps3.jpeg)
Open file (41.94 KB 904x566 logif310.jpg)
Open file (32.10 KB 1025x1000 chink_sfc.jpg)
Open file (305.09 KB 804x638 test-2023-05-12.mp4)
>>603 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.
Open file (49.34 KB 1284x758 720.png)
Open file (57.99 KB 1920x1080 1080.png)
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.
Open file (60.70 KB 1280x720 screenshot000.png)
Open file (60.76 KB 1280x720 screenshot001.png)
Open file (60.82 KB 1280x720 screenshot002.png)
>>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.
Open file (1.01 MB 872x680 dont_walk_left.mp4)
>>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.
Open file (781.26 KB 2060x1546 big_duk.jpeg)
>>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).
Open file (19.37 KB 1038x874 aabb1.png)
Open file (19.36 KB 1037x879 aabb2.png)
Open file (19.23 KB 1042x879 aabb3.png)
Open file (19.40 KB 1035x875 aabb4.png)
Open file (18.79 KB 1033x868 aabb5.png)
>>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).
Open file (13.81 KB 1469x876 solve1.png)
Open file (13.88 KB 1473x868 solve2.png)
Open file (15.12 KB 1471x877 solve3.png)
Open file (13.99 KB 1466x873 solve4.png)
Open file (14.84 KB 1467x870 solve5.png)
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.
Edited last time by nviridescens on 05/14/2023 (Sun) 07:22:16.
Open file (13.02 KB 1047x807 cont1.png)
Open file (13.51 KB 1041x847 cont2.png)
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.
Open file (1.28 MB 1284x758 progress.mp4)
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.
Open file (2.47 MB 1284x758 wew.mp4)
>>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.
Open file (16.75 KB 1269x877 fix1.png)
Open file (18.22 KB 1461x874 fix2.png)
Open file (1.26 MB 1284x758 working.mp4)
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.
Open file (2.89 MB 1284x758 ded.mp4)
Open file (1.51 MB 1284x758 better.mp4)
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?
>>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.
>>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.
Open file (169.92 KB 1920x1047 tiled_shapes.png)
Open file (148.70 KB 640x480 nonrectangular.jpeg)
Open file (105.29 KB 1200x681 drawn1.jpg)
Open file (621.85 KB 1400x700 drawn2.png)
>>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.
Open file (55.34 KB 250x250 what are birds.gif)
>>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).
Open file (3.59 MB 1284x758 platform.mp4)
Open file (61.43 KB 544x623 bcR0A.png)
Open file (7.78 KB 111x106 8tzvN.png)
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.
Open file (431.09 KB 1284x758 anim.mp4)
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.
Open file (42.90 KB 1191x746 mute.png)
>>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?
Open file (33.46 KB 892x328 settings.png)
>>655 FUCK, pic related here
Open file (57.80 KB 462x687 encode.png)
>>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.
Open file (174.93 KB 650x1000 dungeon crawler.jpg)
>>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.
Open file (6.56 MB 804x638 output.webm)
>>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!
Open file (914.48 KB 3548x4096 excited.jpg)
>>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.
Open file (131.05 KB 2784x1720 screenshot.jpg)
>>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
Open file (5.79 KB 1280x720 specialthanks.png)
>>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

Report/Delete/Moderation Forms

no cookies?