|
TooMuchAbstraction posted:Ugh...maybe? But it'd be barely better than "rearchitect the entire thing", now we're talking "refactor the entire thing and make a bunch of stubs". The core game loop isn't actually running, of course, but there's a lot of game components which are compatible with the editor, by having widgets for visualization, editable parameters, and the ability to be discovered during the load/save process. Every one of those would need to be converted into an editor-only stub, which would need to be made strictly compatible with the actual game. From the way you're wording it, with the core-loop and the stubs, it sounds like it might be easier to just make a level editor run in game. You've already got everything for displaying the maps and moving the camera in game, so is there value to backing out to an external editor?
|
#
?
Apr 6, 2024 17:58
|
|
|
|
| # ? May 6, 2024 02:13 |
|
|
M_Gargantua posted:From the way you're wording it, with the core-loop and the stubs, it sounds like it might be easier to just make a level editor run in game. You've already got everything for displaying the maps and moving the camera in game, so is there value to backing out to an external editor? I'd have to write in-game UI for everything, make a browser for picking ships, buildings, etc., a camera controller and picker for placing, rotating, and scaling things, and on and on. Absolutely not worth it. I ended out stubbing out all of the game code that the editor relies on, as y'all were suggesting. It's not fully-functional yet, but it's getting closer.
|
|
#
?
Apr 7, 2024 18:31
|
|
|
The other day i tried to see how long it'd take me to make a dungeon crawler kind of thing using repurposed bits from my fighting game engine. Not too long at all, it turns out. I got everything but the lighting running in two evenings. Ten more days and here we are. Now instead of the hacky lighting I sued for the fighting game, which really only needed one directional light for projecting character shadows, I've got a nice unified solution that supports point, directional and spot lights (although I've still got some VSM light bleeding to solve). https://imgur.com/rBjiGxu.mp4
|
|
#
?
Apr 7, 2024 19:43
|
|
|
got another small, little tiny brainworm and wanted to play around with oldschool voxel rendering using the "obligatory" comanche maps since the input is just a heightmap and a color map i wanted to see if i could just make a mesh in blender and convert it to a voxel representation and it was a success https://i.imgur.com/hTFMhpQ.mp4 then i realized, if i can convert my own meshes like this there's no reason i can't convert other people's meshes as well  https://i.imgur.com/lrA5cWH.mp4
|
|
#
?
Apr 9, 2024 09:37
|
|
|
It might not be very flashy but I'm proud of my cute little dialogue script system  code:It also tries to automatically simulate "natural" delays between words and punctuation, instead of the usual "display one character at a time", but I'm not sure how it feels. I like it?
|
|
#
?
Apr 9, 2024 10:55
|
|
|
Moskau posted:It might not be very flashy but I'm proud of my cute little dialogue script system The markup and effects look neat but the pauses feel annoyingly similar to a choppy framerate to me. It could help if there's smoother movement visible elsewhere on the screen or if the words would print considerably faster than I can read but right now I feel it could get annoying in the long run. Your Computer posted:got another small, little tiny brainworm and wanted to play around with oldschool voxel rendering using the "obligatory" comanche maps Juicy. Any plans for the voxels beyond just having fun?
|
|
#
?
Apr 9, 2024 12:05
|
|
|
j.peeba posted:Juicy. Any plans for the voxels beyond just having fun? no plans! i just think old forgotten pre-polygon rendering techniques are neat and it's something i've wanted to play around with. it could be fun to try and make something like the abandoned voxel prototype of banjo-pilot tho https://www.youtube.com/watch?v=Km0aspnQc6I but i have NOT abandoned ratgame yet! i just struggle with level design. struggle A LOT.
|
|
#
?
Apr 9, 2024 12:29
|
|
|
Your Computer posted:no plans! i just think old forgotten pre-polygon rendering techniques are neat and it's something i've wanted to play around with. Yeah all of the rendering techniques of bygone eras that ended up being dead ends are fun. FWIW whenever I hold a lecture on level design at university one of the points I raise is that if creating interesting levels is difficult it's usually the game design's fault, not the level designer's. Optimally making new levels should come pretty naturally from just playing around with the systems of the game and combining them in different ways. Maybe you just need a layer or two of systems and game mechanics before it makes sense to really start working on playable levels?
|
|
#
?
Apr 9, 2024 12:41
|
|
|
Moskau posted:It might not be very flashy but I'm proud of my cute little dialogue script system As someone who generally hates dialogue speeds less than functionally instant, I think it's pretty good. I do think the pause for periods might be excessive as seen in the final dialogue card. That might just be an artifact of having a bunch of super short choppy sentences, but you might consider lowering the default pause for punctuation and having some kind of markup/escape code for dramatic pauses when you actually need them.
|
|
#
?
Apr 9, 2024 15:02
|
|
|
I agree with the others: make it faster, and while pauses for periods and commas are fine, they should be only slightly longer than the pauses for individual letters/words. For reference, in Waves of Steel, the default text speed is 100 characters per second, with a 0.2-second pause after a comma, period, exclamation point, etc.
|
|
#
?
Apr 9, 2024 15:25
|
|
|
Yeah it's just slow enough compared to my reading speed that it's kind of distracting and difficult to focus on, for me. Using sparingly for dramatic delivery of certain lines it's a GREAT effect though.
|
|
#
?
Apr 9, 2024 15:59
|
|
|
I would make animated text a configurable setting though, especially the colored animated stuff. I don't know the specific details of why but some people have issues reading it if it animates too fast. I don't really know what the convention is though, maybe requiring a keypress to get to the next page is good enough (which you're already doing so maybe everything is fine).
|
|
#
?
Apr 9, 2024 16:05
|
|
|
Oh yeah, for faster text, here's what I did for Waves of Steel: - If you press the Select input, all delays are 1 frame - If you press the Cancel input, the page fills immediately - Once the page is full, pressing either Select or Cancel moves to the next page - A third input can be used to go backwards in the dialog (though my dialog system doesn't handle this as gracefully as I'd like) in case you missed something.
|
|
#
?
Apr 9, 2024 18:13
|
|
|
Your Computer posted:got another small, little tiny brainworm and For some reason I'd like this to be the engine for a bolo clone 
|
|
#
?
Apr 9, 2024 22:49
|
|
|
Wow, thanks for all the feedback! It all sounds very reasonable, so it looks like it's time for some redesign and tweaks. The point about colored text and shaking is a really good one too, I want to keep accessibility in mind, so I'll be sure to add a "disable text effects" toggle. 
|
|
#
?
Apr 10, 2024 00:51
|
|
|
Chev posted:The other day i tried to see how long it'd take me to make a dungeon crawler kind of thing using repurposed bits from my fighting game engine. Not too long at all, it turns out. I got everything but the lighting running in two evenings. Ten more days and here we are. Now instead of the hacky lighting I sued for the fighting game, which really only needed one directional light for projecting character shadows, I've got a nice unified solution that supports point, directional and spot lights (although I've still got some VSM light bleeding to solve). Sick vibes already
|
|
#
?
Apr 10, 2024 03:42
|
|
|
a slime posted:Sick vibes already Thanks! I like how it looks although the actual plan is to eventually use much more colorful visuals, more reminiscent of Might & Magic 3-4-5.
|
|
#
?
Apr 10, 2024 20:29
|
|
|
Chev posted:The other day i tried to see how long it'd take me to make a dungeon crawler kind of thing using repurposed bits from my fighting game engine. Not too long at all, it turns out. I got everything but the lighting running in two evenings. Ten more days and here we are. Now instead of the hacky lighting I sued for the fighting game, which really only needed one directional light for projecting character shadows, I've got a nice unified solution that supports point, directional and spot lights (although I've still got some VSM light bleeding to solve). I swear this isn't a diss, but that reminds me of an extremely high-quality version of the Windows 98 maze screen saver, with the brick textures. The lighting looks great.
|
|
#
?
Apr 10, 2024 20:42
|
|
|
I spent the beginning of 2024 moving across the country. My warm-up for getting back into gamedev is adding support for mod-made missions to Waves of Steel...which means writing a poo poo-ton of documentation. This isn't even remotely all of it, but I stopped here to make sure my playtesters could at least do this much. Not much point building further on a faulty foundation, after all. I foresee much typing in my future  There's over 100 functions in the scripting API that will need to be documented, for example.
|
|
#
?
Apr 10, 2024 20:50
|
|
|
TooMuchAbstraction posted:I spent the beginning of 2024 moving across the country. My warm-up for getting back into gamedev is adding support for mod-made missions to Waves of Steel...which means writing a poo poo-ton of documentation. This isn't even remotely all of it, but I stopped here to make sure my playtesters could at least do this much. Not much point building further on a faulty foundation, after all. I know AI stuff gets a lot of hate but automating bulk stuff like this to a 90% state where you can go in, verify correctness, and clean things up is basically what it is ideal at doing.
|
|
#
?
Apr 10, 2024 22:44
|
|
|
I'd spend more energy getting angry at the AI than I would save by having it do work for me, to be honest.
|
|
#
?
Apr 10, 2024 22:46
|
|
|
Moskau posted:It might not be very flashy but I'm proud of my cute little dialogue script system I quite like it! I think the pauses add some impact to the text. It certainly works well for the lines you picked to demo. Does it base the pauses on the length of the words or something?
|
|
#
?
Apr 11, 2024 05:56
|
|
|
On this version I sped it up quite a bit, added transitions and a subtle effect for word popup that feels like it helps to smooth things out too, plus it serves as a tool for emphasis like you see on some of the words. Dialog can also skip to the end of the page at the press of a button. You don't see it, but there's also a scripting system in the background (which triggers the dialog after reaching a certain point). Also added signals, so dialog boxes can trigger each other back and forth! Oh, and there's also a little bit of lighting testing going on. The shader code doesn't spark joy and is not optimized at all but it works. All the little subsystems are starting to get together to throw a relatively functional party! PS. The UI art is mine, but the rest of the debug room art isn't, it's Super Castlevania IV. https://i.imgur.com/FSKhgcG.mp4 JerikTelorian posted:I quite like it! I think the pauses add some impact to the text. It certainly works well for the lines you picked to demo. Yeah, right now it's just on the length of the words and punctuation. Initially I tried to think of it in terms of syllables but that was much too complicated for no discernible benefit. There's also inline directives like #{delay:12} that allow for additional control. I'm planning to have a bunch of dialogue and text so I do want to try to have some control over the ~expression~ and add impact and emphasis a little better, instead of just firing letters and words at players. In this clip for example, the first "hate" and the final page have some extra delays for emphasis: code:
|
|
#
?
Apr 11, 2024 18:42
|
|
|
Maigius posted:I swear this isn't a diss, but that reminds me of an extremely high-quality version of the Windows 98 maze screen saver, with the brick textures. The lighting looks great. I get that comparison a lot, surprisingly! Didn't know it's so well-remembered, but I do get why. Chev fucked around with this message at 20:48 on Apr 11, 2024 |
|
#
?
Apr 11, 2024 20:38
|
|
|
My physics are rusty and 3D always breaks my brain. I'm trying to calculate the impulse (or linear velocity) to apply to a basketball such that it ends up where I want it with a given vertical angle. So shots would be at 45 degrees from the horizontal, from a known starting point and with a target end-point. I'm confident this is relatively simple but I also remember it taking me way too long to figure out in 2D. e: I think it involves solving https://en.wikipedia.org/wiki/Range_of_a_projectile for v, though even that's non-obvious to my current brain and there may be some game engine helper functions I'm unaware of. Hammer Bro. fucked around with this message at 23:47 on Apr 11, 2024 |
|
#
?
Apr 11, 2024 23:07
|
|
|
It's the same problem in 2d as it is in 3d. The projectile only moves in a 2d plane, assuming you're not modelling things like wind drift. So, solve it in the 2d plane, then transform that solution back to your 3d world.
|
|
#
?
Apr 12, 2024 01:39
|
|
|
You have a system of simultaneous equations here, because there's actually two unknowns that you're working with, velocity and flight time. Equation 1 is your horizontal velocity and flight time: horizontal distance = (horizontal component of velocity) * (flight time) Equation 2 is your vertical velocity and flight time: vertical distance from launch point to target = (vertical component of velocity) * (flight time) + (gravity * time * time) / 2 Because launch angle is 45 degrees, the horizontal/vertical components are equal, so you end up with d_x = v * t d_y = v * t + gt^2/2 Rearrange the first to isolate v: v = d_x / t Plug the first into the second: d_y = d_x * t / t + gt^2/2 which simplifies to: d_y = d_x + gt^2/2 Now we want to isolate t, as it's our unknown here: d_y - d_x = gt^2/2 2 * (d_y - d_x) / g = t^2 sqrt(2 * (d_y - d_x) / g) = t d_y, d_x, and g are all known, so you can just plug them in to get your flight time. Then once you have your flight time, plug that into the horizontal velocity formula to get your horizontal component of velocity. True velocity is horizontal component divided by .707 (which is sqrt(2)/2). Note that if the portion inside the square root is negative, then the shot is impossible. Disclaimer: I'm a bit tired, double-check my math. But I believe the approach is solid.
|
|
#
?
Apr 12, 2024 02:04
|
|
|
Hammer Bro. posted:My physics are rusty and 3D always breaks my brain. This is for Roblox but it walks you through the physics: https://www.youtube.com/watch?v=OlZk66luZYo&t=62s
|
|
#
?
Apr 12, 2024 02:19
|
|
|
I watched the video and read the comments (thanks) and they are starting to jog my brain. I should've used less-specific numbers in my examples, as I'm not looking to always shoot at 45 degrees, nor do I always have a target height at the same y as the starting height (both of which I -think- factor into the equations). The thing that's workin' best for me is https://byjus.com/trajectory-formula/ -- I think I can solve the horizontal range equation for initial velocity: dx = (v^2 sin(2 * a)) / g v = sqrt((g * dx) / sin(2 * a)) Where dx is the length of the Vector2 formed by (target_vector3 - initial_vector3)'s x and z, a is the arbitrarily chosen shot angle, and g is gravity. Plugging velocity (speed really) back in almost works: xz = Vector2(delta.x, delta.z).normalized() * v * cos(a) # How I translate from 2D back to 3D. linear_velocity = Vector3(xz.x, v * sin(a), xz.y) The only thing this doesn't account for is the height difference (delta.y). How could I account for that difference in height? I'm hoping it's a minor modification, though I'm willing to solve (or have solved) a more complex starting equation if need be. These kind of things take me disproportionately long to figure out; thanks again for the engagement and guidance.
|
|
#
?
Apr 12, 2024 05:55
|
|
|
So you've got a fixed angle, and you want to vary the power in order to make it hit a target? That's a little bit different from the usual formulation (which has a fixed power and varies the angle - if you're a real-world artillery gunner, this is the situation you're in, so that's the problem all the literature is aimed at solving). So let's think about the problem a little differently than they do. Let's say you choose the starting y velocity, dy. Your x velocity will be your starting y velocity multiplied by a value that depends on the launch angle - let's just call it k for now. Suppose say you start at y0, and end at y=0. (If that's not the case, you can slide your whole simulation up or down until it is, so that's easy to resolve). Your y position at time t is y0 + dy * t - 1/2 * g * t^2. To find when y = 0, we can use the quadratic formula, with a=-g/2, b=dy, c=y0. This gives us t=(-dy ± √(dy^2 + 2 * g * y0) / -g. Simplifying, and knowing that we're going to need the larger root, gives us t=(dy/g) + √(dy^2 + 2 * g * y0)/g Then your final x position is k * dy * t. If you have a target x position xt, that gives us xt = (k/g)(dy^2 + dy * √(dy^2 + 2 * g * y0) Isolating the radical, we get xt * (g/k) - dy^2 = √(dy^2 + 2 * g * y0) Square both sides and expand the left, dy^4 - 2 dy^2 g xt / k + (xt g / k)^2 = dy^2 + 2 * g * y0 Moving everything to the left and collecting like terms: dy^4 + ((-2 g xt / k) - 1) dy^2 + ((xt g / k)^2 - 2 g y0) = 0 This might look like we need to solve some gross quartic equation, but some closer inspection shows that it's just a quadratic in disguise! So you can apply the quadratic formula again (the coefficients are kinda gross, but all the values that go into them are known from the setup) to figure out dy^2, then take the square root of that to figure out what your starting y velocity should be.
|
|
#
?
Apr 12, 2024 06:58
|
|
|
Thanks for the detailed explanation and sorry to dominate the thread. I spent much of my morning going over this with a pen and paper to make sure I understood each step; probably lost 30 minutes to a simple algebraic error. I think you might have a simple algebraic error as well? Jabor posted:Then your final x position is k * dy * t. If you have a target x position xt, that gives us xt = (k/g)(dy^2 + dy * √(dy^2 + 2 * g * y0) I think you dropped the dy that the square root was multiplied by. Which fortunately simplifies(?) the remaining equation to solve:  (please check my algebra!) g, xt, and y0 are all known to me. Early on you said k was related to dy (what we're solving for) and the launch angle (also known to me). What's the equation for k and won't it introduce more dys into the mix? edit: I think I solved it using a different set of equations, and this time the set-up seems so simple as to likely be correct. I'll do a full write-up for posterity when I get more time, but it's basically solving the equation implied by the last post on https://www.physicsforums.com/threads/finding-initial-projectile-velocity-with-angle-and-a-point-in-the-path.431675/ (though I'm dubious of what that site suggests is the actual answer). This time I only lost 15 minutes to rad_to_deg(60). Hammer Bro. fucked around with this message at 21:10 on Apr 12, 2024 |
|
#
?
Apr 12, 2024 17:31
|
|
|
I think k is like, 1/tan θ. It doesn't depend on dy at all.
|
|
#
?
Apr 13, 2024 02:14
|
|
|
I sometimes ask ChatGPT for help when it comes to math. It's usually pretty reliable. Speaking of being dumb, I can't wrap my head around compute shaders (yet) but my biome generation was taking way too long on the CPU. So I moved it to a fragment shader on a quad, and then I grab the texture from a viewport looking at said quad. I get the raw image data for a texel metadata array and send the texture to the splatmap shader, badabing badaboom. It feels like a weird and naive way to go about things but it works. Went from a gen time of about 15 seconds to less than 0.5.
|
|
#
?
Apr 13, 2024 08:48
|
|
|
While everyone is talking video game math like cool guys, is there a best practice to render editable paths or roads as you would in a city builder? My first thought was to draw meshes along splines, but that's a shitload of geometry. My next thought was to use openGL to get pixel coordinates for curved lines of t thickness following each road's control points, bake that into a splat map, and use a pavement texture that tiles in both dimensions. But read/write operations on pixels are slow, and it comes with a lot of downsides (no lines or directional grunge).
|
|
#
?
Apr 13, 2024 19:39
|
|
|
I don't have any experience with this, but my gut instinct is to try the "shitload of geometry" approach first. Rendering is fast these days, dumb-simple techniques can actually work quite well. You only need the currently-edited portion of the mesh to be dynamic, anyway.
|
|
#
?
Apr 13, 2024 19:50
|
|
|
Omi no Kami posted:While everyone is talking video game math like cool guys, is there a best practice to render editable paths or roads as you would in a city builder? My first thought was to draw meshes along splines, but that's a shitload of geometry. My next thought was to use openGL to get pixel coordinates for curved lines of t thickness following each road's control points, bake that into a splat map, and use a pavement texture that tiles in both dimensions. But read/write operations on pixels are slow, and it comes with a lot of downsides (no lines or directional grunge). https://www.redblobgames.com/articles/curved-paths/
|
|
#
?
Apr 13, 2024 21:26
|
|
|
Oh cool, I've gone through a ton of Amit Patel's stuff but I never saw the curved paths article. I'm probably overthiking the optimality stuff but it genuinely blows my mind that seemingly most of the big-name city stuff uses splines. For some reason I was convinced they were doing it in the shader (which, to be fair, I think the first cities: skylines did?). But if that's really what the majority of dudes roll with, it's really easy to implement.
|
|
#
?
Apr 13, 2024 21:42
|
|
|
Are there any good examples of 2D games with naval combat in the golden age of piracy? Any thing that cleverly avoids the "let’s circle each other endlessly" problem? Starsector is a really good space based game that has clear analogue to this kind of combat but it also has the "let’s circle each other endlessly" problem. It somewhat gets away with it because of flashy visuals that a game set in the 1700s wouldn’t be able to lean on IMO. The only thing I can think of would be to do something FTL-like and just eliminate movement entirely from the equation.
|
|
#
?
Apr 14, 2024 19:45
|
|
|
xgalaxy posted:Are there any good examples of 2D games with naval combat in the golden age of piracy? You might want to list more examples and what you thought of them. There are a lot of games that have broadside ship combat that are generally considered fun. Assassin's Creed 4, Rebel Galaxy (not Rebel Galaxy Outlaws), Sid Meier's Pirates. To name a few I've played. Maybe also Sea of Thieves, but I haven't played that. If you want to replicate the fun of FTL combat in any capacity then good luck - you're going to have to do a lot of tricky game balance and design stuff besides just "make pirate game but you can't steer the ship".
|
|
#
?
Apr 14, 2024 21:13
|
|
|
|
| # ? May 6, 2024 02:13 |
|
|
Lowen posted:You might want to list more examples and what you thought of them. Also Sea Dogs! I should really get around to playing that again.
|
|
#
?
Apr 14, 2024 21:59
|
|
