|
abraham linksys posted:god knows I don't want to reimplement physics and 3D collisions myself If you're just worried about player-track and player-player collisions this isn't nearly as tricky as it sounds. If you've got a function that'll tell you how far a given point is above the track, that's all you need--just push the player back above the track if they're in danger of passing through it. Or if you wanted to do something wipeouty, apply a repulsive force based on how close you are to the track. Alternately, you could store player locations in spline space, which totally solves your collision problem (until you leave the track) but will probably make turning and physics a pain in the rear end. If you still don't want to bother, that's totally understandable. You can use raycasts vs. colliders to do the same kind of thing, being careful to not slip through the track. I've also seen people roll an invisible physics sphere around a track using the engine's rigidbodies, raycasting from its center to determine where to place the car mesh.
|
#
?
May 25, 2020 04:43
|
|
|
|
| # ? May 24, 2024 23:38 |
|
|
I would literally just work backwards from the spline. "This is how far above the spline I am, and this is how far to the left or right I am."
|
|
#
?
May 25, 2020 05:02
|
|
|
Been slowly thinking over this in my head, as I slowly port my new spline logic over to Godot (currently rewriting a monotonic cubic interpolator in GDScript, since it's not like you can just find a lot of off the shelf GDScript code snippets, maybe the worst thing about using it).quote:If you're just worried about player-track and player-player collisions this isn't nearly as tricky as it sounds. If you've got a function that'll tell you how far a given point is above the track, that's all you need--just push the player back above the track if they're in danger of passing through it. Or if you wanted to do something wipeouty, apply a repulsive force based on how close you are to the track. So, the italicized bit is the bit I'm struggling with. I'm not really sure how to compare a point to the "surface" of the spline. The spline, as I have it implemented (whether in Three or Godot), is just the curve as a line. The surface only exists as a series of points representing the center and sides of the track, calculated by: * For the center spline, take the 2D "top-down" XZ spline and generate a point for every interval (which right now is just an arbitrary step, though I guess there are ways to like "generate more points where it's more curvy" or "generate points at even arc lengths I should look into). Add the height to each generated point, where height is calculated from an interpolation function that takes in the current "t" value (current_step/max_steps). * For the "edge" splines, for each of the center spline points, get the surface normal (interpolated from surface normals along the curve, which come from the predefined segment, e.g. a u-turn has a "40 degree" normal halfway through). Then, get the tangent line at a pointed crossed by this normal vector. I'm not quite sure I grok how this works, but it generates a normal vector that points horizontally "out" from the current point exactly how you'd want given the banked angle defined by the normal vector. Then I just multiply this vector by a track_width constant, and add it to the vector point from the curve. I'm trying to think through various ways of defining comparisons with this surface and coming up rather short. Most of my ideas start with the idea of storing the player's offset within the spline, which is what I would do with an "Audiosurf" style game where your position was always aligned within the spline - you just store the t along the spline and the horizontal offset (relative to the current direction of travel) along the track. This is easy to do if movement is also defined in terms of t and h-offset (or, since changes in t have varying length displacements, ideally some function that can get you move forward by an arc length" into "move forward by some step on t," which I think is easy to do with arc length estimation). If you do this, determining anything you need about the spline position is easy - if you're on t and your horizontal offset is between "+/- track width," you're on the course. If you wanna add in sick jumps or whatever that lets you go above the track, you can add in a z offset as well. The problem is, as soon as you talk about "I want pressing W to go forward in world space, regardless of the curve," then you've got to figure out how to translate from "world space" to "track space" to get those offset values. This seems like it would still involve storing that t and horizontal offset, but also storing world position/angle/whatever as normal. I saw this idea very briefly mentioned here, and it's got me a bit puzzled. I've started trying to write up how I imagine this working, like, five times, but each time I get halfway through and realize it makes no sense  So, maybe this "offset" thing is barking down the wrong tree, but I'm not sure how else you quickly calculate "where am I above and left/right on this curve." Maybe there's just more bezier maths magic I should be invoking that I'm not thinking of, or just some kind of naive brute force method along with some sort of broadphase filtering so it's only checking parts of the curve that I'm at least vaguely near.
|
|
#
?
May 27, 2020 06:56
|
|
|
I'm not sure what Godot has for built-in physics, but I'd strongly consider a heightmap based terrain system built from the spline data. To use the snowboard game example, you could generate a mountain with perlin noise. Start track generation at the top of the mountain (you can use gradient descent to find a good approximation) and "walk" down the mountain with your splines. Track slope is controlled by the heightmap's level at the center of the spline, generally preferring going downhill (so, say, pick 5 potential spline options for each step and choose the one that would be closest to some desired slope). Then modify the heightmap to meet the surface of the spline by iterating over all the vertexes in the generated track and rounding to the nearest heightmap point. You'll want to use some kind of kernel for this so the heightmap ends up smooth. This will add some time and a lot of complexity to map generation, but it will make physics easy because you can just look up the height and normal at your x/y coordinates. It also takes care of non-track terrain. If you want the ability for the track to cross itself, you'll have to think of ways to handle that, but it's a start.
KillHour fucked around with this message at 07:35 on May 27, 2020 |
|
#
?
May 27, 2020 07:32
|
|
|
If you wanted to track positions internally in spline space, but have momentum and user inputs and stuff act on world space, then you need to convert these things from world to spline space at the point you're actually moving the character. I'm assuming your spline space involves a position along the spline, and at each position you have height and horizontal position axes that are mutually orthogonal with themselves and the direction your spline is travelling. So, you've got a vector indicating the worldspace displacement you want to apply, and you have the current position in spline space. Assuming your spline is smooth and your displacement is small, you can use the current normals as an estimate for the normals at the new position, guess what the t-value at the new position will be, look up the actual spline normals at that point, and then do a few newton-raphson steps to get your estimate of t sufficiently close to the actual value. Then it's a simple change of basis to get the spline coordinates from the worldspace coordinates. Note that this mostly precludes the possibility of jumping off the spline and landing back on it at a much later point, so if you feel that is (or could be) important to your game then you might not want to go this route. -- Trying to calculate where you are in spline space based purely off worldspace position, without any concept of where you previously were in spline space, is challenging - in the abstract, you have to deal with degenerate points that could reasonably be at many different possible spline space coordinates.
|
|
#
?
May 27, 2020 08:09
|
|
|
abraham linksys posted:So, the italicized bit is the bit I'm struggling with. I'm not really sure how to compare a point to the "surface" of the spline. The spline, as I have it implemented (whether in Three or Godot), is just the curve as a line. The surface only exists as a series of points representing the center and sides of the track, calculated by: Dammit, you called my bluff! I've only ever used splines as a client, and they've always given me a GetClosestPointOnSpline() and a GetNormal/TangentAtPoint() function. Which it sounds like you're doing too, and using normal x tangent to get a sideways vector that you can multiply by the width to find the edges of the track. The assumption I'm making--which could very well be wrong!--is that the closest point is on the same cross-section as the right and up vectors, in which case you can take (playerLoc - closestPoint) dot right to get sideways distance and dot up to get distance above/below the track. quote:you've got to figure out how to translate from "world space" to "track space" to get those offset values. But that might be all you need. Getting the closest point is a handy function to have but it might involve searching the entire spline; for small movements you can remember the last closest point to make the search easier. At least yours is guaranteed not to cross itself, which is nice.
|
|
#
?
May 27, 2020 08:25
|
|
|
Hi! Due to COVID-based desires to fill my time by learning things, I took a random beginner's course on JavaScript and Python and now I'm hooked. I am genuinely considering switching careers so I can get into game development instead of being an agent. Are there preferred boot camps to get certification for these languages?
|
|
#
?
May 28, 2020 02:07
|
|
|
No Irish Need Imply posted:Hi! Due to COVID-based desires to fill my time by learning things, I took a random beginner's course on JavaScript and Python and now I'm hooked. I am genuinely considering switching careers so I can get into game development instead of being an agent. Are there preferred boot camps to get certification for these languages? There was recently a pretty good thread about getting started with programming: https://forums.somethingawful.com/showthread.php?threadid=3917712&pagenumber=1&perpage=40
|
|
#
?
May 28, 2020 02:16
|
|
|
There are absolutely great ways to learn how to become a better programmer, but definitely have a backup in that field other than "indie game developer" before you quit your job unless you're independently wealthy or enjoy homelessness. I think there's am industry thread around here somewhere?
|
|
#
?
May 28, 2020 03:09
|
|
|
If you enjoy programming, getting a regular software development job instead of making indie games is a much better idea for your career. Going "full indie" is a giant roll of the dice, and lots and lots of people have fallen into that trap.
|
|
#
?
May 28, 2020 18:56
|
|
|
Having a job in web/apps/whatever that pays the bills and doing indie gamedev on the side is pretty nice. It'll improve your skills quite fast as there is a lot of crossover concepts between something like webdev and gamedev, but they're still different enough that it won't just feel like you're coming home to the same poo poo you do at your dayjob. In my opinion, not being dependent on gamedev as your only source of income helps keep it fun and stress-free.
|
|
#
?
May 28, 2020 19:20
|
|
|
There are also entry-level professional game jobs! And I've seen lots of people who got hired as "designers who can code" pushed into increasingly programmery roles, which is good or bad for them depending on their temperament. If that's the route you want to go, you're probably better served by C++ or C#; idk if there really is a boot camp or certification.
|
|
#
?
May 28, 2020 20:24
|
|
|
Here’s the industry thread: https://forums.somethingawful.com/showthread.php?threadid=3415662 Echoing everyone else’s advice that you should be very financially stable if you want to do indie development, either full- or part-time. I went full-time indie for a year and managed to significantly deplete my life savings building a mobile puzzle game that made a grand total of $26. I decided to do this to begin with because I’m personally not someone who can write code for work and then go home and write more code even if they’re different fields, and my boring enterprise mobile app day job wasn’t leaving me with enough juice to be able to do what I really wanted. If my main source of income weren’t coding, I could have probably made it work, but before I went full-time I started feeling a bit burnt-out. I did ship a game, though, and that got me a “real” industry job at a mid-sized studio.
|
|
#
?
May 28, 2020 20:34
|
|
|
Thank you all. 
|
|
#
?
May 29, 2020 00:29
|
|
|
Does anybody know how to prevent backspacing or otherwise moving the cursor before a specific position in a TMPro_InputField in Unity? I'm implementing a console and don't want to backspace into the prompt. I think I can add a pile of state to try to intercept and undo the backspaces but it will be complicated and I'm not entirely sure I'll still wind up eating the character that got backspaced anyways. Edit: In a fit of luck, I guess the input field processes the event before I can, but it so happens my prompt has a space after the main prompt text, so I just shove that space back on and put the cursor back where it belongs. I wanted to try overriding KeyPressed in TMPro_InputField but it's not virtual so my implementation never ran. Sad Rocko over here. Rocko Bonaparte fucked around with this message at 06:57 on Jun 4, 2020 |
|
#
?
Jun 3, 2020 19:42
|
|
|
That's a bit of a hacky way to do it, and you're kind of fighting against the component there - have you considered just having the input field cover the editable part of the prompt, and adding the static parts outside of it?
|
|
#
?
Jun 4, 2020 07:00
|
|
|
Jabor posted:That's a bit of a hacky way to do it, and you're kind of fighting against the component there - have you considered just having the input field cover the editable part of the prompt, and adding the static parts outside of it? It's kind of ugly but it's one of those things where I have a region of overriding behavior that I'm just kind of commenting. Logically, it will still work even if the order gets changed; it'll just turn into two spaces turning into one instead of zero spaces turning into one. It's basically the Python REPL crammed into a Unity-friendly text component. The only other way I really considered doing it was having a separate box at the bottom for input and the results scrolling up a second region above. I didn't bother since I had decent luck with an all-in-one prompt when I was doing a Windows Form demo of the interpreter, so I figured I'd try to carry that convention over. However, I can't intercept all the input events in Unity so hilarity ensued. The interpreter already can manage prompting for additional text so I don't get much else in having a separate multiline, editable text box. 
|
|
#
?
Jun 4, 2020 07:40
|
|
|
I'm working on a dumb little top-down 2D/2.5D/iso MMORPG in my spare time. The fast, boring stuff like authentication and chat is out of the way already, but I'm trying to figure out what would be a reasonable way to do this, or what game engine possibilities exist. I'm a competent dev, but I have not written DX/DirectInput/OpenGL code before. I don't want to write a physics engine (there's not really even physics, at best you can move x tiles per second and don't collide with other players; i.e,. players can block single tile doorways) - I'm not a fan of C/C++-esque stuff - I can do it if I really have to, but I don't like it - I don't care what the netcode transport is going to be like, even websocket is OK - I assume Unreal and Unity are either overkill or not what I'm looking for - The kind of graphics I'm going with, kinda (YT links) [0][1] - As far as people have described it to me, I'm effectively building a graphical MUD, honestly - I want to store as little as possible on the client; ideally nothing but images and some client localisation -- the client should not be trusted with anything, I'm not sure how well this plays with common 2D game engines mostly used for singleplayer stuff.
|
|
#
?
Jun 7, 2020 06:58
|
|
|
I have a very similar spare time project, I've been using python + twisted reactor for the server. The client is an electron app: three.js for rendering the game world (which is 2d-in-3d), for netcode I'm just using msgpacked json over udp. I actually wrote my own bitpacking nonsense at first but it was terrible to work with so I scrapped it almost immediately. It's been a fun learning project since I got to write a lot of the stuff I didn't understand from scratch (except network loops which suck rear end). Electron is a decent "engine", the client UI is extremely easy to work with since it's basically just a webpage, three.js is also a solid library. Most importantly for me, my dev environment is just atom and electron, no effort spent learning a thick IDE like unity or godot which I've always really struggled with. You could probably swap three.js for something like pixijs since you only want 2.5d? But it's just a library for drawing poo poo, not really an engine, so you have to invent your own way of modeling relationships between game objects. That's part of the fun for me but YMMV.
|
|
#
?
Jun 7, 2020 08:13
|
|
|
That sounds reasonable. I'm not a huge fan of "thick IDE" - most of my day job is go/js/ts/kotlin/etc in vscode or vim. I'd like it to also run on mobile, and this seems like a lazy (which is good) way of doing so.
|
|
#
?
Jun 7, 2020 09:16
|
|
|
I'd take a second look at game engines (Unity, Unreal, Godot, Game Maker, etc.). You don't have to use their solutions for everything (e.g. Unity's networking support is suspect), but they've solved a ton of problems for you that are annoying to deal with otherwise. Basic stuff like loading and displaying assets, dealing with object transforms, displaying UI elements, accepting input from keyboard/mouse/gamepad, etc. There's no reason for you to be solving those problems from scratch yourself.
|
|
#
?
Jun 7, 2020 19:18
|
|
|
TooMuchAbstraction posted:I'd take a second look at game engines (Unity, Unreal, Godot, Game Maker, etc.). You don't have to use their solutions for everything (e.g. Unity's networking support is suspect), but they've solved a ton of problems for you that are annoying to deal with otherwise. Basic stuff like loading and displaying assets, dealing with object transforms, displaying UI elements, accepting input from keyboard/mouse/gamepad, etc. There's no reason for you to be solving those problems from scratch yourself. (Also, web dev stuff probably isn't going to all change out from under you in the next update like the game engines do on the regular.)
|
|
#
?
Jun 7, 2020 21:51
|
|
|
12 rats tied together posted:You could probably swap three.js for something like pixijs since you only want 2.5d? But it's just a library for drawing poo poo, not really an engine, so you have to invent your own way of modeling relationships between game objects. That's part of the fun for me but YMMV. Phaser wraps (or maybe wrapped) pixi, adding a lot of engine-type stuff. roomforthetuna posted:(Also, web dev stuff probably isn't going to all change out from under you in the next update like the game engines do on the regular.) Oh, sweet baby angel
|
|
#
?
Jun 7, 2020 22:34
|
|
|
dupersaurus posted:Oh, sweet baby angel
|
|
#
?
Jun 8, 2020 04:54
|
|
|
I finally announced my game! Spent the last two weeks just putting together graphics and copy.  Anyways, it's called Rhyme Storm, and it's a freestyle rapping rhythm game! I've worked on it since the beginning of 2018 with another goon and a bunch of hip hop producers and I'm super proud of it! I don't think there's any other games like it. I'd love to get feedback from you guys on it, here's our steam page: https://store.steampowered.com/app/1250350/Rhyme_Storm/ Website: https://www.rhymestorm.com Trailer: https://www.youtube.com/watch?v=Ce2T7M9xhzY And some screenshots:     
|
|
#
?
Jun 10, 2020 00:34
|
|
|
That's really cool! Don't think I'll be able to play it, but it's a very cool idea and I dig the production value as well.
|
|
#
?
Jun 11, 2020 22:50
|
|
|
I've been poking at my loading times, and one of the big offenders is terrain. It's taking about 11-12 seconds to load in the terrain for a single level: The relevant (kinda janky) code: code:Do I have any options here beyond breaking the terrain up into chunks which are loaded one at a time? Is there some convenient way to do that to a pre-existing terrain? The terrain is pretty big (around 8000x8000 Unity units), and while much of it is completely flat I suppose that it's probably still contributing to load times.
|
|
#
?
Jun 12, 2020 23:59
|
|
|
Why are you instating the terrain instead of just loading a scene?
|
|
#
?
Jun 13, 2020 01:54
|
|
|
I built my missions to be as transparently (to me) data-driven as possible. The mission definition file, located in my StreamingAssets folder, contains all the setup for the mission -- stuff like what ships are where, what the objectives are, and which of the available terrains to use. I use a single scene for all missions, which is responsible for reading the definition file and instantiating everything necessary. I'm not a big fan of separate scenes for each level, because I worry about having similar infrastructure that needs to be updated across each one. Additive scene loading alleviates that concern to some extent, but either I didn't know about it or it wasn't available on the version of Unity I started this project on. In any case I'm not really interested in completely overhauling my level-load logic. Everything else works well after all. Anyway I would expect that loading a scene that contains terrain would take roughly as long as loading an empty scene and then instantiating terrain into it via script. I mean, I can never discount the possibility that Unity's doing something dumb in the background, but it's the same work in either case, no?
|
|
#
?
Jun 13, 2020 02:57
|
|
|
Instantiating objects (especially something like that) is generally slow and you want to avoid it during regular play. Pre-load them during expected slow times (loading screen, initial game setup) and deal with the possibility of wasted loading if they're not actually needed. If you're trying to keep your game data-driven and not make your scenes embed the data and duplicate the infrastructure, that doesn't exclude having multiple scenes. Besides the fact that you can additively load scenes (load everything in a new scene on top of what you currently have), you can also have objects that survive scene changes (DontDestroyOnLoad), ScriptableObjects in AssetDatabase, etc. Those are what you should be using for your infrastructure anyway. Or you put your infrastructure in a core scene, and additively load/keep objects alive when you transit to any 'level' scenes (but that means scene changes no longer remove existing objects the way you'd expect). One of the reasons multiple scenes would maybe help is because you can load them asynchronously. Whether or not that would matter when it comes to this problem is unclear, because the real problem is that you're instantiating at runtime a terrain object with 34MB of data. Preloading and/or chunking and/or baking the Terrain into non-Terrain object would solve more issues in this case. Or, add a loading bar and call it a day until you have a reason to think this is a big problem.
|
|
#
?
Jun 13, 2020 08:39
|
|
|
Yes, I'm familiar with all of what you said. I've actually moved past ScriptableObjects for several of my asset types and into a CSV/JSON-based system because I had so many that managing them through the editor was getting seriously unwieldy. Because of the way my game loop works, there will always be a scene transition after each level; it goes level -> post-level-summary -> intermission menu -> (possibly go to main menu, ship designer, etc.) -> new level. None of those scenes have anything in common aside from a few bits of shared code and the Rewired input manager. I make limited use of DontDestroyOnLoad to avoid re-loading/re-calculating stuff, but since almost everything in my game is built up piecemeal out of sub-components in hard-to-predict ways, there's limits to how much that saves me. It's the terrain chunking that I was looking for assistance with. 11-second loads aren't completely unreasonable but I'd prefer to do better, if only to improve my own iteration time when working on the game. Like, I see assets like this out there; does anyone have experience with it, or would they care to recommend a different tool to solve this problem?
|
|
#
?
Jun 13, 2020 15:06
|
|
|
Hello! I don't have a ton of experience with 3D graphics / math, but I'm trying to learn by making some simple animated 3D models programmatically. I'm creating meshes just fine, but I'm struggling with using bone weights for skeletal animation. Whenever I apply a dizzywhip fucked around with this message at 03:10 on Jun 14, 2020 |
|
#
?
Jun 14, 2020 00:24
|
|
|
Total shot in the dark because I've never used SceneKit, but since you're generating this procedurally, is it possible the bones are getting assigned to the vertices before you put them in their "default" position? Then to the system, it would look like the bone's resting position is the origin, and when you move it to where you want it to be, it moves the vertices too. I don't know how to fix it, but that's my complete uninformed guess as to what might be causing the problem.
|
|
#
?
Jun 14, 2020 00:37
|
|
|
I also don't know SceneKit, but most things assume that bone weights on a vertex sum to 1. Does it work if you add another bone at 0.5, or set your single bone to 1.0?
|
|
#
?
Jun 14, 2020 01:47
|
|
|
KillHour posted:Total shot in the dark because I've never used SceneKit, but since you're generating this procedurally, is it possible the bones are getting assigned to the vertices before you put them in their "default" position? Then to the system, it would look like the bone's resting position is the origin, and when you move it to where you want it to be, it moves the vertices too. The bones are already in position before they get assigned to the mesh, but I'm pretty sure it doesn't matter either way in this case. For each bone you have to provide its inverse transform relative to the node the geometry is attached to, which is how its default position is determined...I think. I'm still trying to wrap my head around how it works. I appreciate the suggestion though! dreamless posted:I also don't know SceneKit, but most things assume that bone weights on a vertex sum to 1. Does it work if you add another bone at 0.5, or set your single bone to 1.0? Okay yeah this works! I assigned a static dummy bone to each vertex with the missing weight and now the original bone works the way I expected. I hadn't read anywhere that the weights need to add up to 1 but that makes sense now that I think about it. It seems wasteful if you just want one bone to affect a vertex since you have to double the number of bone weights and bone assignment indices per vertex, but I guess in an actual character model you'd end up wanting to use more than one bone per vertex anyways. Thanks for your help!
|
|
#
?
Jun 14, 2020 03:12
|
|
|
dizzywhip posted:It seems wasteful if you just want one bone to affect a vertex since you have to double the number of bone weights and bone assignment indices per vertex, but I guess in an actual character model you'd end up wanting to use more than one bone per vertex anyways. If you only want one bone to affect the vertex, wouldn't you just set the bone weight to 1?
|
|
#
?
Jun 14, 2020 08:24
|
|
|
I’m working on a space shooter and I’m a bit stuck on implementing those cool energy projectile graphics. I want to do TIE Fighter/Descent/etc style laser bolts. Right now I’m taking the projectile’s position and extrapolating it into a textured quad of a certain length. (I grabbed a placeholder texture from Freespace 2.) Now I have something that looks like a laser! Problem is of course that I’m not sure how to orient the quad? Like I just have a flat object sitting in space right now that only looks good from one angle. I did some research and found that I should be using two quads 90 degrees apart to produce an illusion of a solid bolt from any direction? I’ve never actually gotten this far in writing one of these engines so I’m not sure what the right solution is.
|
|
#
?
Jun 14, 2020 11:32
|
|
|
I totally coded this a couple of decades ago for a demo and, yeah, it's "just" orienting the tris towards the camera. One of those things where the resultant code was just a couple dozen of lines but it still took me several days of getting it wrong every which way to get it finally right.
|
|
#
?
Jun 14, 2020 12:08
|
|
|
Luigi Thirty posted:I’m working on a space shooter and I’m a bit stuck on implementing those cool energy projectile graphics. I want to do TIE Fighter/Descent/etc style laser bolts. Doing that works OK in most situations but can have issues when one of the points is very close to the camera, where it stops looking as nice because the texture projection gets flared out to the sides too much.
|
|
#
?
Jun 14, 2020 12:18
|
|
|
|
| # ? May 24, 2024 23:38 |
|
|
Luigi Thirty posted:I’m working on a space shooter and I’m a bit stuck on implementing those cool energy projectile graphics. I want to do TIE Fighter/Descent/etc style laser bolts. Easy mode is to use a rectangular prism or a cylinder. But two quads at right angles should be fine too, basically extruding an X. Just need to make sure the image is visible on both sides of the quad. Set the orientation at instantiation time so it's shooting out of the laser canon.
|
|
#
?
Jun 14, 2020 12:24
|
|
