>>834 Neat. Not sure what exactly but you've certainly got something here. Turn-based tactical RPG? Tell us more about what you're trying to make. What's going on in the second video? Is that graph/mesh thing supposed to be the overworld map?

>>801 Game I'm working on. >>803 I was sitting in the bath, drunk as all fuck thinking about how I could add some pizzaz to a simple get safe code followed by a open safe event and tried putting the idea into game code. It worked perfectly on the first try.

>>836 What's the game?

>>835 >Turn-based tactical RPG? Slight chess inspiration like Into the Breach. With a twist on status effects. To be under any of the 3 "locks" inhibits you in combat, but will benefit you if you stick with it. >Is that graph/mesh thing supposed to be the overworld map? Yes, like a pirate's treasure map, each zone stays consistent. >Not sure what exactly but you've certainly got something here. The idea is a bit highfalutin and probably needs to be described with art, but basically that it's okay to be a skeleton.

>>829 Update. Getting ready to do some block-out/gray-boxing in order to get a feel for player scale, zone size, and the like so I can refine the character controller (move speed, turn speed, FOV, jump height/length, etc.) as well as add NPC pathfinding, visibility/line-of-sight, and stuff like that. In the final game, in addition to just walking around, I would like to have jumping (clearing small gaps and low obstacles/ledges), swimming (free movement in 3D space while within a water volume), crouching (for moving through low/tight spaces not designed for humans) and climbing (ladders - not interested in scaling cliffs and shit). So I need to get an environment in place to test all of this. Was doing some research and came across a good resource on level design. ht tps://book.leveldesignbook.com/process/blockout/metrics This section in particular talks about what I'm trying to do now and the importance of getting it done early. See these pages too for similar good reads: ht tps://book.leveldesignbook.com/process/layout ht tps://book.leveldesignbook.com/process/blockout Also reminds me that we need a game dev literature thread. Got a hold of some low-poly human figures from ht tps://quaternius.com/packs/backgroundposedhumans.html and got them into blender to replace my 60x60x185cm box I was using. They needed to be scaled down to the proper scale and the soles of their feet go below the floor about 1cm but that was a few minutes fix. Also inset some faces and added eyes to the one standing male, couldn't tell which way he was facing before when flat shaded. I'll be using these guys to set up doorway height/width, table/counter height, room size, and such. Take for instance, a tavern room with one long counter and 2 employees behind it, plus room for 3 tables that can each sit 4-6. Rather than just eyeball it and make some vaguely shaped room, I can drop placeholder tables and people sitting around them, then actually walk around the space. Can I get from the doorway to the bar OK? Is anyone sitting so close to the fireplace that they'll catch fire? That sort of shit. Once the size of homes and buildings is established and I have a few examples of each, cities and towns can be blocked out using those, and the world and dungeons proportional to those. I worry though, that my block-out dude is not as anatomically correct as he could be - might want to grab something from makehuman or whatever if I want to make objects "shoulder-high", "knee-high", "waist-high", etc. I got some of those 1-meter grid prototyping textures from Kenney: ht tps://kenney.nl/assets/prototype-textures I took one of the "dark" themed ones, scaled it down to 256x256 and added more readable text in the upper-left corner. Going to make a few more in different colors for grass, dirt, stone, water, wood, etc. Had to set up "triplanar texture mapping" in blender to get proper texture scaling and alignment. Searched around and found a niggit post with this pic that basically did the trick ht tps://i.imgur.com/lhWopKh.jpg I think he's using 2.8 or something though because it's a little different from mine (3.5). Fun shit. Beats grinding out network code at least.

>>838 Interesting. Sounds very "gamey" though. Is there an in-world explanation for these "locks"? Are they magical effects? Combat stances? >Yes, like a pirate's treasure map, each zone stays consistent. I don't really get it. What made you go with that instead of your classic RPG overworld map? >The idea is a bit highfalutin and probably needs to be described with art I'd like to hear more about it. Is this something currently in active development? >it's okay to be a skeleton. As a live, flesh-and-blood human I'm literally shaking right now.

>>840 >Are they magical effects? Like curses, preventing using abilities/tools or turn you into a skeleton. >I don't really get it. What made you go with that instead of your classic RPG overworld map? By dividing the world into "zones" you can quickly write any encounter you want. Kind of like fallout. Eventually I want "penciled in" landmarks. >I'd like to hear more about it. Is this something currently in active development? Nothing right now, I want to get an artist eventually, if my time doesn't get too divided. All I can do is describe. vid related. These things get put on hold for something else. >As a live, flesh-and-blood human I'm literally shaking right now. It's a "painless" instant process in-game.

>>841 >fallout Now I get it. Like a point crawl from tabletop games. >Nothing right now, I want to get an artist eventually, if my time doesn't get too divided. All I can do is describe. So you're leaning into flavor text to set the scene, I see. Nothing wrong with that, just gotta brush up the UI to support it. >These things get put on hold for something else. Tell me about it. You working on a few projects at once or just don't have the time to commit right now? Would be cool to see you take this further if you have the passion for it and a proper design in mind to make it fun and stand out from other tactics-style RPGs. I tried and failed to make a joke about being triggered by your skeleton remark, like "it's ok to be white."

>>842 >So you're leaning into flavor text to set the scene, I see. Nothing wrong with that, just gotta brush up the UI to support it. The shop UI is messy, but I don't think adding anything to the dialogue UI is top pri >spoiler Heh. Well it will be important later.

>>842 >"it's ok to be white." Literally shaking r/n

>>848 >Literally shaking r/n

>>850 >2nd pic Lol

>>850 2spooky4me >>839 Update. So I said before I was getting started with some block-out type work in blender, right? And I found a nice shader to let me do triplanar mapping inside blender, so I can see a 1m grid overlaid on the world. Well everything was going fine until I imported the meshes into my project and... there's of course there's no UVs. Turns out the triplanar shader works on the world coordinates of the meshes, and doesn't affect their UVs at all, unlike what you would get in a Quake-style editor like Radiant or Trenchbroom where you can lock the texture UVs to the faces or to the world, and the information is exported with your map. Well, fuck me. Did a bunch of panicked searching and almost gave up and went with Trenchbroom for blocking out before I remembered that if blender could do triplanar mapping with a shader, then so could I, in theory. Took a few hours and it was extremely painful but I did manage to get something working. The way the z-axis texture is oriented is different than how blender does it but fuck it. What matters most is that the "1 METER" text is upright and reads left to right but... I have no way of verifying that the proportions are correct on non-axis-aligned slopes/angles because of perspective skewing and it's driving me crazy but whatever.

>>854 Blender has a lot of mapping options, including UV, local object and global (sometimes global is called "generated"). Also you can just use appropriate scale in blender for everything, its one of the main rules. You can simply export default blender texture. Also you might want to switch to 2x2m objects, because I use them. Also I use 2x2 "cage" to see scale of things. Texture is not really okay way to measure object size, especially when they are using UV mapping, and whole thing is just handmade, not adjusted to realscale in any way. If you move a vertex, it will move UV coordinates. You can probably do it with code, but it is annoying to do/learn for a very little benefit. Worst case you can use a couple of gradient shaders with ZYX coordinates for input, or some simple shader which draws a white line when XYZ has integer value.

>>855 Triplanar texture mapping doesn't use UV coordinates; the world coordinates determine the texture mapping, with 1 blender unit (1 meter default) equaling 0-1 in UV. Right now, in both blender and in my project, the "1 METER" texture is grid aligned, at least on the primary axes. So I can slap down any arbitrary geometry and it'll get textured properly according to the face normals. This whole grid texture block-out thing is pretty standard, look at something like Unity probuilder. As far as texture baking goes, I did see that suggested as a fix elsewhere and it was the next thing to try should I had I not gotten this shader working. Hopefully the UVs get baked too? Who knows. I'll deal with that when I go to bake lightmaps.

>>859 You export UV as part of the model, depending of file format. OBJ export gave me perfectly working model with working UV, however you need to unwrap object first. You dont really need to bake anything for it.

>>860 >You export UV as part of the model, depending of file format. I know that. I'm saying that this is a shader, a procedural texture if you will - you don't UV map the model. These videos: >>817 and >>821 have a UV-mapped and textured .obj as the terrain. Textures generated inside blender need to be baked to be used outside of blender, unless you can do the same material/shader set up in your engine, which is what I did here - world coords to texture coords shader in blender -> world coords to texture coords shader in raylib, no UV mapping involved. Because I'm trying to block out test environments quickly. If you follow.

>>861 >I know that. I'm saying that this is a shader, a procedural texture if you will - you don't UV map the model. Actually they can use whatever as input, especially UV, but I get what you meant. However fucking with textures to make a global grid, used for size reference, seems like a strange idea to me. Why not just make a huge grid mesh, and keep it around, while you still need it? >>839 Also here texture coordinates in blender for image texture set "object" and image textures almost always use UV. Or instead of grid just 2*2 boxes placed every 10*10 meters, very easy to make. Now that I think about it, 10m tall object is a good reference because it should take a second to drop 10m.

>>863 >a grid Not the worst idea, if your world is mostly flat. Raylib comes with a grid drawing function (though the y-axis is up). void DrawGrid(int slices, float spacing); // Draw a grid (centered at (0, 0, 0)) but you could do the same thing with the line drawing function too: void DrawLine3D(Vector3 startPos, Vector3 endPos, Color color); // Draw a line in 3D world space But my world is going to be everything but flat and I'm also not just trying to measure this and that. Did you take a look at the e-book I linked about design? The block-out, "metrics", and playtesting bits especially. See pics if not for an idea of what I'm talking about. Odds are I'll be running, jumping, swimming, swinging swords, and throwing fireballs inside this "1 METER" grid space for a very long time. Least I can do is make it easy to iterate on and to grasp feeling of space and movement and the such.

>>863 >10m takes 1 sec to fall Never mind, I feel bad after I though about it for a second.

>>867 Don't worry, I got what you meant - after falling for 1 second, you will be traveling at 9.81m/s. Another reason why it's nice to be able to work in meters and not something like Quake units - you have a basis to work from. A human male character can be ~1.85m tall, with eye line (camera height) at 1.75, which gives you a starting point to start playing with character speed and field of view. I've been using a tape measure a lot too recently - measuring furniture, room sizes, doorway width/height etc. They'll all need to be adjusted of course, usually made larger, but it's a starting point.

An idea of what I'm working with atm. Ignore the first "house" - was taking way too long to do with proper topology and triangulation so I gave up. The "building" next to it was done proper block-out style in a couple minutes by copying and pasting a wall section - kind of like that gif I posted here >>866 . The block-out in that gif was done with Trenchbroom by the way, something I'm still considering incorporating in my production pipeline somewhere.

>>870 Added a skybox and fixed a bug with the camera up/down.

>>873 Nice, great to see each stage of the development.

>>874 Thanks. I been meaning to make my own thread but I'm being lazy. Here's a video with an interior cave-like space being lit with point lights. I'm working out ideas for the lighting model at the moment so I whipped up a little test space in the corner here.

So I mentioned I'm working out a lighting model for the game world. I will be leaning heavily on good old-fashioned "vertex lights" like we saw a lot of up until the advent of pixel shaders and per-pixel lighting around the time of Half-Life 2 and Doom 3 and similar. Vertex lights can look nice if your geometry supports it - no triangles the size of the screen, make sure your vertex normals are smoothed where they should be smoothed and split where they shouldn't be, and watch how stuff clips through one another. The best thing about vertex lights: they're stupid cheap and because of that, practically unlimited. In addition to those, I'd like to bake lightmap textures, even if relatively low-res. Vertex lighting can also be baked (vertex colors), and may be an alternative if lightmapping doesn't have the look or performance I want. No reason to render static lights on static geometry every frame like I was doing in the last video - that sort of stuff gets baked. Baked vertex lighting also has the advantage of not standing out when compared to lightmapped surfaces, if anyone remembers back when doors and other moving objects stood out from background static geometry because of that. It has the disadvantage of not capturing fine shadow detail though. That said, the lightmap could be disabled while the object is in motion or otherwise not in it's original place. Will have to experiment. I'm also working on a day-night cycle using a directional light that rotates around the zone, light direction facing the center of rotation. The light will change color and intensity based on time of day. Dawn/dusk - dimmer/orange-ish, midday - brightest/white-est, night (moonlight) - very dim and blue-white. That's easy enough to implement, I just need to choose what meshes are affected by it and which aren't, hence the interior/exterior space testing (the inside and outside are two separate meshes). Right now, I'm not able to do any kind of fade between interior/exterior, but I'm going to try using a point or maybe a directional light at the entrance to simulate light coming in from outside. How that will work with doors opening and closing, I don't know yet. Dynamic lighting will be done by having a list of light sources held by each mesh. On every frame, each mesh will update its list depending on distance to dynamic lights (mesh bounding sphere to light radius collision) and pass those values to its lighting shader. Sphere to sphere collision checking with squared distances (no sqrt) is the fastest 3D collision check, so a fancy spatial partition scheme may not be needed. May be a different story if I end up with 100s or 1000s of meshes per zone like I mentioned before; we'll see. So far I've got planned for lighting: >Directional "sun/moon" lights for zones fully or partially outdoors. >a lot of dungeons will be dark, like real fucking dark. Bring a light. >baked static lighting (vertex? >dynamic vertex lighting (player light sources, spell effects, flames/lava, etc.) >players may "glow" Dark Souls style if they have a light source equipped >NPCs may give off light, if they're made of fire or lava or some shit >moving objects will be vertex-lit only >dynamic shadows are being looked into. Shadow maps look the easiest, compared to stencil shadows or other fancy stuff Pics are me playing around with some crude interior lighting. First pic is the default lighting shader from the one raylib example: ht tps://www.raylib.com/examples/shaders/loader.html?name=shaders_basic_lighting ht tps://github.com/raysan5/raylib/blob/master/examples/shaders/shaders_basic_lighting.c Notice there's no fall-off/attenuation. The light travels infinitely in all directions, changing intensity only with angle of face to light source. Next pic shows the same with proper fall-off. This is with a light radius of 4 meters I think, and a linear fall-off. Next pic is looking further into the "cave". I wasn't too happy with the way the light seems to end pretty abruptly like in the 4th pic, so I changed the fall-off to quadratic instead of linear. Basically just intensity (0.0 to 1.0, calculate with "min(0.0, (1.0 - distance / radius))") * intensity again. Gives a much smoother result.

>>875 >>876 Interesting. Will that cave become an example of your world chunk idea? >if anyone remembers back when doors and other moving objects stood out Oh yeah, that's a common problem in Quake mapping with the baked lightmaps. >So far I've got planned for lighting Sounds flexible, should allow for building a strong atmosphere.

>>876 Nice explanations Anon. Thank you very much.

>>877 >Will that cave become an example of your world chunk idea? No. I just needed some geometry to let me test different lighting styles. The world chunking thing is still in the works. Obviously collision is in place, as I can walk around these blockout spaces. Chunking will be "Outdoor" zones will still contain caves, tunnels, building interiors and the such, and a naive skylight implementation will end up penetrating into those. So the idea was to split interior meshes from outdoor ones, then do something for the transition zone to make it less jarring. For instance, opening a door to a building could enable a point light in the doorway, that affects only the building's interior meshes. The point light color would be the current zone "sunlight" color (though maybe brighter to account for fall-off, which directional lights don't have). The ambient light value of the interior meshes could be changed as well, from say... {0.05, 0.05, 0.02} to (0.12, 0.12, 0.12} or something, then reset to default when the door closes again. Just thinking of things that may come up and how I might tackle them. >Sounds flexible, should allow for building a strong atmosphere. I hope so. As far as atmosphere goes, and I may have mentioned it before, I'm going for the level geometry of Everquest, which you can view here: ht tp://www.ulftek.com/eqscout/ Check out old sebilis, crystal caverns, or lower guk if you want to see some god-tier dungeons. Combined with the level geo/lighting of Metroid Prime, which you can check out here ht tps://noclip.website/ Tallon Overworld and Chozo Ruins being good examples of "fantasy" environments. Ambitious? Maybe. These are games from 1999/2001. Tried my hand at doing the whole "sunlight coming into interior space" thing. Eh. Better, but not quite there. Think I'll worry about it about it again when I get around to dealing with light baking.

>>880 Fuck me. I forgot that players and mobs can move between outdoor, sunlit spaces and interior, unlit spaces freely. Might need something like a collision volume to partition the two, and have the point light at the entrance affect PCs as well.

Update. So while I didn't do any more than a debug print, I tried my hand at line of sight calculation today. What I'm doing is tracing a line segment from NPC eye position to player eye position, then checking for mesh triangle intersection at a distance of less than ray length. If any triangle intersects ray like that, the check ends early with no line of sight. It's easy enough, I just need to take it a step further and use the level geometry chunking system with it. Right now I'm calculating distance between PC and NPC, seeing if it's less than LOS range, then checking against every tri in the map. Getting about ~500-600 microseconds for one LOS check. Definitely going to need all the optimization I can get though, considering it will be done server-side, for all PC-NPC interactions. Next up: swimming. The plan so far is to use the water as a collision volume, which you can see in the 4th pic. Basically a bounding box encompasses the level geometry that should be underwater. For some zones, this may be one single box that extends from some z-level downwards - think islands sticking up out of a flat ocean. Different movement rules and physics will apply whether the player's collision capsule's center is in the water volume or not. Out of water volume, normal run in 2 dimensions + jump, crouch, climb, etc. In water volume, can no longer crouch or jump, but can move in all directions. Falling into a water volume from above will have the player fall normally until their center intersects the water volume where they will then decelerate quickly. Standing in shallow water, where the player center is out of the water volume, will allow movement like normal. I will also be using the player's eye position to determine the render mode. If the player's eye point is inside the water volume, the ambient lighting will be changed to match that of the water volume (probably dim and blue/green), and the distance fog will be made much more aggressive (reduced visibility). I'd also like to blend a cube-mapped animated caustics texture over meshes under the water if I can, because that looks cool. Torches, lanterns, etc. will not work underwater but other magical sources of light will. The collision check for whether one is in water or not will probably be a naive approach (check every volume against player center and eyes every frame) since point -> bounding box collision is cheap, and I can't imagine having more than a handful of separate water volumes per zone. 5th pic outlines some of the plan as it stands. I still haven't come up with an easy solution for getting the player up out of the water where it meets land at a sharp angle. In real life, you just grab on and hoist yourself up on out, like getting out of a pool, but we're working with capsule collisions here. Maybe on collision I can shoot a ray from player center point one player width long and if it doesn't hit terrain or the water volume, allow movement up onto the colliding mesh. That or put a short invisible "ladder" volume along those edges, which come to think of it, act a lot like water volumes: while colliding, you can look up and push forward to move upwards. Got to experiment some.

>>880 >Chunking will be I have no idea what I meant to write here.

>>886 This is pretty much what I was going for: distance fog for lower visibility when in water, underwater mesh brightness based on distance to surface + the usual angle to light source shading. Still have to figure something out for the water surface. I'd like to have the water's surface reflect the sky/ceiling from above, and just be semi-transparent from below (assumes above water is brighter than below water). Still gotta do animated caustics for under the water, again with intensity based on distance from surface. Should look pretty slick.

>>890 Played with swimming and the underwater shader some more. Looking into navmesh pathfinding stuff now. The recast/detour library ht tps://github.com/recastnavigation/recastnavigation seems to be the go-to solution for that, looking for resources on that at the moment.

In my other game I was making an objective marker script while in the middle of it this happened. It looked like the works of a stalker ex-boyfriend so I thought it was neat. The objectives work now.

>>950 Cool. What's the game?

>>886 >>892 >pool.png You motherfucker.

>>950 >>958 Forgot to mention I also did skeleton tactics. This is an experimental XCOM type game where you can focus on just strategy layer and interception of sites. I wanted to act out the idea of multiple fights happening happening at once. Something I imagine is humanity losing grasp of a planet. You get to see that from a map view without any interruptions like going to a tactical layer.

>>958 Forgot to mention, no name yet, and ALSO BUMP

>>333 Are you still alive?

The more I do, the more I need to do, and the more things can break. Same fucking code to move "character" and move whole tileset, just a fucking t.x=v.x. It works for character, but doesnt work for ground. Managed to fix it, but it becomes apparent I need to start cleaning up testing code and useless shit. Had "my_viewport" and "viewport" and "camera", all of which (were supposed to) do the same fucking thing. Its really discouraging. But hey, at least bare minimum works. Looks like shit tho, at lower scale. So, I would either need to remake assets, or change how I render things, but maybe it will look better with more varied assets.

>>123 experimenting with writing a data-oriented vulkan renderer with branchless optimizations for potential performance gains. just seeing how fast i can open vullkan windows rn... each window can have its own attached rendering state or share a common state e.g for split-screen or something like that...

>>977 Did some random shading, just to measure how it would look. And made some (wrong) controls. I wanted to do zigzag rendering of tiles, but it seem to be impossible, due to my laziness, and not wanting to deal with complexity of transforming everything into zigzagged coordinates. Technically it is just a temporary way to render, and later I want to make a buffer for stuff to be rendered in desired order. Next is forest generation, and rudimentary light system. >>987 How does it indicate anything related to vulkan? I assume window opening is just part of winapi. From what I read vulkan is awesome, but it provides very low level access/api, so you will have to build everything yourself, and it takes a lot of time and effort, which is not something indie devs have. Still fun to see, and good exercise.

Spent a couple hours trying to figure out why the projection matrix in my compute particle system wasn't working only to realize I'd forgotten to homogenize the transformed vectors. Also accidental virtual boy mode.

>>989 >Also accidental virtual boy mode. Neat. Have an edited anon.cafe icon I made a couple years ago but never did anything with it.

>>988 >make a forest >well, I need to make texture cropper/resizer/converter >default sdl api is a bit fucked, and I have no idea how to make transparency work, so either colorkey(good way anyway) or look into libpng >and some simple "enhancements" filters would be great >and I would need working interface to use them >sdl works for now so whatever >but to make proper converter I need json loader/data manager I should look into hierarchy of the stuff I need to make, before making other stuff.

>>994 Made simple automatic texture cropper with offsets. Just need to attach them to data files, and/maybe gui. And now I can process character tiles and implement proper systems for them. And make better grass tiles. They are flat, and I rendered all of them at the same time and just cut off the mask, now I can render each tile separately, and keep blades of grass which go outside of default rhombus, and even use any kinds of image processing on them. (hopefully it will look better). But that is an improvement for later, current grass works perfectly for a placeholder.

Note to self. Dont use 1000*1000 resolution for renders instead of 1024*1024, especially when you batch rendering something on cpu. For "less precise" stuff like trees and other decorations, it might be fine, but walls and ground tiles must be precise. But on the bright side, I figured out why grass renders always had dark spots in the middle of each tile(Pic2). I simply forgot to give renderer more bounces for transparency (it was only 4 total), so everything transparent turned into black. >now I just need to pack everything >lets search for already made simple packing algorithms >here is link, everything is explained in it! >link is for 200 page scientific paper on packing anything into a box Welp, Could have been worse. So many topics are so well researched, but its practically impossible to read through all of them. Packing even has free tools for it, but adapting them for my exact needs is the same, as doing it from what I already have. Next up, is making my tileinfo.json format to be compatible with Tiled editor. And a format for character sprites. And technically, at that point, I would be able to start actual game developement.

libre Trackmania clone under CC0, in C99 with no libraries, uses own 3D renderer, own physics engine

bump for demo day