|
xgalaxy posted:1) Math In particular, geometry and trigonometry. As a dabbler, I've never needed them, but being able to use quaternions might also be helpful, though don't feel that you need to understand them because few do.
|
#
¿
Sep 15, 2018 03:25
|
|
|
|
| # ¿ May 5, 2024 19:20 |
|
|
The lerping should be applied by some fairly low-level component to anything that moves in your game. It's just doing display_pos = prev_position[-2] + (prev_positions[-1] - prev_positions[-2]) * (dt / timestep size), if I remember correctly. So yes, for every object you have to store two positions, being the positions you lerp between, and you have a temporary third position which is the lerped position that doesn't generally need to be stored because you just use it immediately in your draw logic.
|
|
#
¿
Oct 19, 2018 20:45
|
|
|
Position (which includes rotation, scale, etc.) is the most crucial to get right, because it's extremely obvious when your objects don't move smoothly. We're pretty used to sprites that jump between animation frames, but it's pretty painful to watch a sprite stutter across the ground because its draw position is its physics position which only updates 20-30 times per second.
|
|
#
¿
Oct 19, 2018 21:36
|
|
|
Now I want to see Sink the Bismarck except set in the mid-18th century. EDIT: goddamn, wrong thread. I was wondering where this post got to when I didn't see it in the PYF historical fun fact thread. TooMuchAbstraction fucked around with this message at 18:35 on Nov 17, 2018 |
|
#
¿
Nov 17, 2018 02:48
|
|
|
Nolgthorn posted:For some reason scrollbar performance in the Epic Games Launcher is horrendous on macos. Other than that I'm thrilled there's a competitor, I didn't realise Steam was taking 30% of revenue. Reminds me of the Apple store. I honestly don't think this is likely to improve all that much -- I doubt Epic is going to drive down the distributor's share by more than a few percentage points at most. Services like Steam or the Apple Store or whatever are doing an awful lot of work that nobody really thinks about any more but still needs to be done -- poo poo like processing payments, managing accounts, doing customer service (which includes an awful lot of people getting very angry at you over ridiculous things), maintaining a storefront, and on and on. Noted luminary and indie gamedev Official Old Fart Jeff Vogel was perfectly happy to switch to Steam when the opportunity arose, despite having run his own online store for something like 15 years. He said "I know the value of what they're providing for [the revenue cut]...and more to the point, they do too." (relevant video, which any indie game developer should watch) Of course it's possible that Epic can do all that more efficiently than Valve can, and can therefore afford to take less of a cut. But probably not by much. And they're not going to take a loss on it since this is where the money to run the business comes from.
|
|
#
¿
Dec 13, 2018 16:33
|
|
|
...huh. That's kind of shocking. Well then!
|
|
#
¿
Dec 13, 2018 18:33
|
|
|
Stick100 posted:Oh god, that sounds like a terrible idea! I bet someone is working on it right now. Galaxy brain: put the store on the Unity asset store as an asset so anyone can buy it and set up their own digital distribution store. All you'd need is a few text fields for your cloud server API of choice and your payments handler!
|
|
#
¿
Dec 18, 2018 18:30
|
|
|
Pseudo-God posted:I am having an issue with my collision resolution code for my 2D platformer. I am using only AABBs for by objects, and in case of a collision, I calculate the penetration vector and translate the player object along the smallest axis of the penetration vector. This works very well, but there is a literal edge case that I am having trouble solving. If a player hits the ground from the top with enough speed, he will be embedded in the ground such that the smallest axis will actually be the horizontal one, and will slip on the side. This is one of many reasons why I advise people to not write their own physics if they can possibly avoid it. Collision response is a super complicated issue and you're never going to get all the kinks ironed out. For your specific issue, you can try things like sweeping the AABB along its velocity vector and using that as the collision polygon, though of course it's no longer an AABB if you do that. You can also say "ok, there was a collision, I'm going to back the colliding objects out along their velocity vectors and then step forward in smaller increments to get a minimal overlap." But invariably you're going to find other edge cases where your collision response glitches out. About the best you can hope for is to get it to the point where all of the glitches are possible only with specific arrangements of colliders that you can simply omit from your game.
|
|
#
¿
Dec 27, 2018 15:53
|
|
|
Nolgthorn posted:I am not a lawyer but you agree to ToS at the point that you start using unity. Those ToS that you agreed to should remain in place until you agree with a new ToS. I imagine Unity might be able to prevent you from using a new version of Unity without agreeing to the new ToS but otherwise couldn't in development/released games continue to do what they're doing? You'll note they said the games would continue to run for the time being. I bet what they can't do is update the engine they're running, because that would require agreeing to the new ToS. It's like being stuck using Windows 7 -- you may be okay for now but eventually your poo poo's gonna break because you can't update to a more recent OS.
|
|
#
¿
Jan 11, 2019 00:01
|
|
|
Absurd Alhazred posted:ToS have some kind of clause in it saying they can change it at any time, I think. Yeah, but that doesn't mean you automatically agree to the new ToS. They have to present the new terms to you and get you to agree to them again. Being able to retroactively change a contract and add whatever terms you like and then force the other party to hold to them would be...bad.
|
|
#
¿
Jan 12, 2019 03:35
|
|
|
Most old games just make a slightly small bounding box and don't fuss much about minor inaccuracies. In general, if you err towards being generous to your players, they won't complain.
|
|
#
¿
Feb 8, 2019 03:33
|
|
|
Suspicious Dish posted:There are plenty of bootstrapped tech companies that hum along quietly and profitably, but the VCs need to be paid, and to them, a success is to make their money on 10x returns, not 2-3x returns. This is presumably because most VC-funded startups fail, having a 0x return on investment. So it's not just the VCs being greedy here.
|
|
#
¿
Feb 13, 2019 16:51
|
|
|
Schneider Heim posted:What kind of programming languages do game developers work on nowadays? Unity et al seem to be all the rage right now. Is there purely backend work or are you expected to do graphics programming in some capacity? What really matters is the availability of tools to do stuff for you. Unity's big in no small part because they have their asset store where you can buy shaders and models and controller libraries and a million other little things that you could do yourself, or you could just subcontract out to the asset store. Plus of course the Unity engine itself does a ton of crap that you don't want to deal with yourself if you can at all avoid it, like physics, cameras, scenes, loading and managing assets.... You could write games in Java if you wanted to, but you'd be handling all that stuff yourself because there's no ecosystem to speak of to support you. I haven't worked for a gamedev company, but I'd expect that, like in most software shops, everyone has a few areas they're really good at, a few more they're okay at, and some stuff they really just don't ever touch. It wouldn't surprise me if you could make a career out of gamedev without ever having to deal with how things are displayed on-screen, just sticking to the data that represents how the game world functions under the covers.
|
|
#
¿
Mar 14, 2019 04:44
|
|
|
The Fool posted:I'm building a model of the solar system with the idea that I'd put a small game on top of that. I wanted to have semi-realistic orbital patterns and did not realize how hard (for me at least) the math was going to be. My brain is melting. Are you simulating gravitational forces, or just using prescribed paths? Absolutely use the latter if at all possible IMO. We still haven't solved the three-body problem, i.e. be able to come up with a perfectly accurate simulation of how three massy bodies affect each others' movement due to gravity. So any simulationist approach is going to be necessarily inaccurate and can easily be unstable. Prescribed paths are much easier. The sun has its little wobble, then planets move in circles which are parented to the sun (technically to the sun's average position, but who cares?), then moons move in circles that are parented to their planets, etc. So if you want to find the position for a body, it'll be something like x = r * cos(orbital period) + parent_x, where parent_x is the X position of the body the thing rotates about, or 0 for the sun.
|
|
#
¿
Mar 15, 2019 18:40
|
|
|
xzzy posted:Breaking off and trying to come up with a better way of doing things is a cool and good idea, but with programming languages it's basically that xkcd standards comic. The world don't need another. All of the languages you listed have tradeoffs that make them less appealing in some circumstances. Lua has a tiny standard library and some kind of weird language concepts (in particular "everything is a table" and 1-based indexing). Python has weak typing and using it for game scripting poses technical challenges as, as far as I'm aware, it's basically impossible to sandbox outside of putting everything in a VM or something. C++ and C# are comparatively heavyweight languages, requiring a compilation step and lacking the expressiveness of higher-level languages. All of which is to say that sure, inventing a new language is kind of dumb and silly, but it's still not surprising to see it happen. People want to improve on what's out there, and they don't always just want to improve things by incrementally adjusting the existing tools.
|
|
#
¿
Apr 2, 2019 16:05
|
|
|
A good understanding of data structures so you can handle your game data in a way that's not a total clusterfuck. Basic graph theory is useful for relating data and for things like A* pathfinding. Trigonometry is useful if you ever get anywhere near physics (including e.g. if you want to calculate headings/trajectories/etc.). Matrix math is useful for understanding transformations and cameras. I'd also throw in some runtime ("big O") analysis, just on the basis that it's surprisingly easy to make awful runtimes if you aren't paying attention and decide to e.g. read a 5MB file on every single frame, or try to relate every one of 10k objects to every other of those objects.
|
|
#
¿
Apr 11, 2019 15:35
|
|
|
It's absolutely helpful to just dive in and start making things. You learn way more when you're working on a project that you care about than when you're just doing coursework. That said, it's also easy to get stuck in your personal projects because you don't know how to solve a problem, because of lack of training in standard software development techniques. Software being as flexible as it is, you'll probably be able to figure something out, but it'll take a lot more work and frustration, and not work as well, as what you could easily produce if you had more background. Basically you have to figure out what your tolerance level is for studying vs. doing. And if you do get stuck with something, ask questions. Odds are good someone will say "oh yeah, you just need to apply This Algorithm You've Never Heard Of", and once you know the name you can go read how it works and it'll make your life way easier.
|
|
#
¿
Apr 11, 2019 17:39
|
|
|
If your goal is to get a reasonably-spaced set of vertices and edges, look up Delaunay triangulations. They're closely related to Voronoi diagrams, which leper khan already brought up.
|
|
#
¿
Apr 14, 2019 21:38
|
|
|
Doc Block posted:Yes, this is exactly what I needed. Thank you! Nice! If you want to make it more retro, you could try to get rid of the mush of very closely-spaced lines near the horizon. I think something like "fixed horizon line, draw 7 mobile lines starting from the bottom" would probably do the trick.
|
|
#
¿
Apr 21, 2019 02:00
|
|
|
Whybird posted:Well, I understand this, and you understand this, but I really wish Unity understood this. Use the long-term-support versions. No API changes or new features, just bugfixes.
|
|
#
¿
Aug 13, 2019 17:37
|
|
|
BarbarianElephant posted:Yeah, this caused me a problem when the older version of Unity I was using for a project simply refused to function on the latest version of OSX. That's Apple's fault, not Unity's, IMO. Apple has no shame whatsoever about breaking everyone with their OS updates.
|
|
#
¿
Aug 13, 2019 20:30
|
|
|
Concurred: nobody will pay any attention to a pitch document, regardless of how well-crafted it is, unless they have significant reason to believe that the person behind the pitch is able to deliver. That means that either you're one of a very small number of well-known figures in the games industry, or you have something concrete to show along with the pitch document. Consider a music analogy: if I tell you I have an idea for a song about teenage love, are you going to pay any attention to me? Maybe if I'm a well-known pop star, but otherwise probably not. If I can sing you that song, and you can tell, yeah, it's a bit rough but with some polish it'd get attention, then I have much better odds of gaining your interest. I'd guess that right now, games are if anything even more overloaded with "ideas people" than music is overloaded by people who want to be stars but have no musical skill.
|
|
#
¿
Aug 22, 2019 03:09
|
|
|
Absurd Alhazred posted:How likely is it for the "visionary" to be more of an art or modeling person, or a composer or sound technician, or a writer, than a programmer? Yoko Taro is more of a writer and clearly makes his mark on the Drakengard/Nier games, so it's clearly possible at least for writers to take the role.
|
|
#
¿
Aug 23, 2019 15:21
|
|
|
Crosspost from the Making Games Megathread, because to be honest I'm not clear on what the difference is between that thread and this one. I'm working on implementing wakes for my ships, and while I'm at it I'd like to keep the ocean waves from appearing on top of the ships like this:  My best guess for how to do this is something like:
So first off, does this sound plausible? Assuming it passes that test, how would you handle a) keeping the special camera from seeing things it's not supposed to, and b) making it render things in grayscale colors where the color corresponds to what direction to push the water in? I can make a grayscale camera easily enough, but one that says "you're a ship, therefore you push water down; you're a wake particle, therefore you push water up" I don't know how to do. If I do get this working though, you can bet I'll be trying for effects like this where the shockwave from the guns firing causes the water to displace.
|
|
#
¿
Sep 10, 2019 20:56
|
|
|
Nolgthorn posted:I dunno if this is even possible but the first thing I thought was have an invisible cylinder around the ship. Have any water in that cylinder just not render at all. Then have some special computationally expensive water attached to the ship that fills in the area. The water flowing over the ship isn't a huge deal, it's just mildly aesthetically displeasing. The lack of wakes though is IMO more significant, since it makes it feel like the ships aren't actually interacting with the ocean (which they aren't, really). Fortunately, Reharakhti linked this tutorial they wrote on how to do ripple effects, and I have basic water displacement working. Now I just need to fine-tune it and set up the appropriate particle emitters on the ships to create wakes. They also mentioned using something called a "stencil buffer" to prevent water from overflowing the ships, so that's something for me to research. KillHour posted:Rendering to a texture sounds like a lot of unnecessary computation. Why don't you just pass the bounding box direction and speed of the ship into the shader? The main reason is that then the shader has to be able to convert direction+speed of potentially many ships into a set of wake waves, which sounds like a pain in the rear end to write. Whereas with the render-to-texture approach, I can fine-tune the wake waves by adjusting a particle emitter.
|
|
#
¿
Sep 10, 2019 23:19
|
|
|
It's a possibility. I'm a bit scared of upgrading and ruining everything, but I probably should; there's a fair amount of potentially useful stuff in Unity 2018 that I can't use. Very preliminary wake effect:  I need to tone down that color gradient, it's way more garish than I'd intended and doesn't really do the job I want of highlighting the peaks of the waves. Too bad GIMP's gradient editor is such trash.
|
|
#
¿
Sep 11, 2019 01:39
|
|
|
Yep, you're right on both counts. Like I said, this is super-preliminary, basically the result of four hours' worth of fiddling with shaders. It proves that the concept can work, now I need to fix the aesthetics. For what it's worth though, the Colorado-class battleship's upper deck is, if I'm reading this diagram correctly, about 5 meters above the ocean's surface. Smaller ships would be even closer to the water. Depending on how rough the waves are they absolutely could wash over the deck. So yeah, most of the time, the waves would be smaller, but not always.
|
|
#
¿
Sep 11, 2019 01:51
|
|
|
Does this mean that I shouldn't worry about using sqrt inside of a shader? At least, not any more than I'd worry about doing multiplication or division? I have a conical falloff effect in one of my vertex shaders that I couldn't figure out how to do without a square root, and it bugged me at the time.
|
|
#
¿
Sep 14, 2019 22:17
|
|
|
That's what I thought at first, but both images are ortho, just one's from a flatter angle. Given the content of the images, I assume the ortho projection is an intentonal stylistic choice to mimic 3D TRPG games (or some similar aesthetic).
|
|
#
¿
Sep 15, 2019 04:10
|
|
|
If your game is entirely fake-OS type stuff, you might want to consider using a UI widget library like Qt or wxWidgets instead of a game engine. Unity's UI layout stuff is weird, to be frank. Probably a side-effect of them trying to make everything editable both in the UI and via scripting, but it ends up making positioning and sizing things difficult and clunky. However, if your game involves any physics or fancy graphical effects, this becomes less of a good idea. Widget libraries will typically allow you to embed an OpenGL texture into them which you can draw to using GL library calls, but that's not exactly easy compared to what a modern game engine lets you do.
|
|
#
¿
Sep 22, 2019 15:59
|
|
|
OneEightHundred posted:Hash tables and hash sets can also be a problem. Using pointer values or other non-deterministic values as keys can change the traversal order, as can implementation differences if you're using an implementation supplied by the language runtime instead of your own. The fact that the Go programming language explicitly randomizes iteration order over maps to gently caress over your unit tests is something that I grew to love about it, precisely for catching bugs like these. It might possibly be worth making your own randomized-iteration-order dictionary for your own tests to catch that kind of problem.
|
|
#
¿
Oct 1, 2019 01:28
|
|
|
I think out of all the technologies that Google has put out there, protobuf is one that's extremely unlikely to disappear in the next couple of decades. It's heavily-used internally, and the problems it solves aren't the kind of problems that are likely to have some sexy new product come out and do a sweeping "everything must now run on $new_tool" revolution. You'll probably see proto4 and proto5 come out, but I very much doubt they'll be more painful than, say, the Python 2->3 transition. (Three years from now I'll be standing in a ruined city surrounded by angry devs waving printouts of this post in my face)
|
|
#
¿
Oct 11, 2019 02:55
|
|
|
Stick100 posted:If you want a look at Unity/proc-gen look up the talk about Dungeon of the Endless and the talk about the top-down rouge-like spaceship game with 80's cartoon aesthetic that I can't remember the name of. I want to know more about this, because the only top-down spaceship roguelikes I know of are FTL and Transcendence and I don't think either of them quite fits your description. My own game, in Unity, isn't procgen but is heavily data-driven -- I'm reading mission files and then spawning in assets based on those files, instead of having scenes populated with GameObjects that I load. It works fine, and it's not much of a stretch to imagine replacing the files with an algorithm.
|
|
#
¿
Nov 11, 2019 21:47
|
|
|
Stick100 posted:Galak-Z. I had to look through my steam library to find it. They did Unite talk about the proc gen and did a thing similar to Dungeon of the Endless that had a bunch of set pieces then the proc gen would using rules and match them up to build a cohesive level. Ahh, thanks. I played that some awhile back, but don't remember much about it beyond a vague feeling of annoyance. Oh well.
|
|
#
¿
Nov 12, 2019 02:06
|
|
|
Odin Inspector is worth picking up if you don't already have it.
|
|
#
¿
Dec 7, 2019 22:22
|
|
|
Is there something in particular you're trying to do? I could maybe answer some questions based on what I've figured out from trial and error. Unity's UI system is bizarro-world compared to most sane layout systems.
|
|
#
¿
Dec 11, 2019 05:13
|
|
|
Tip posted:Right now I'm trying to generate text dynamically and animate it up the screen. OK, use TextMeshPro for your text. You can write scripts to adjust character transparency on the fly or do things like make it bounce, change color, etc. For UIs in general, generally it's possible to make Unity's current UI system do what you want, it just may not be very intuitive. Read up on the layout components and how anchors work. My approach is to make a prefab for the overall thing I want to control (e.g. a dialog box, a radar HUD, etc.), make a script that has public properties for each of the things I want to adjust in code ("a public TMP_Text for the weapon's name, another one for the ammo count, an Image for the border"), stick the script on the prefab, and use the inspector to drag the relevant UI item into each slot in the script. Then I can hand the prefab off to whatever code needs to instantiate it, and it can access the script inside the prefab and tell it what to do. This is of course for instances where I need multiple copies of the prefab; if there's just one then I slap it into the scene directly and enable/disable it as needed. That saves the overhead of creating GameObjects at runtime.
|
|
#
¿
Dec 11, 2019 17:59
|
|
|
Tip posted:Thanks for the overview, I'm probably making this harder on myself by wanting to create everything in code. If nothing else, you're increasing your iteration time by having to run the game each time you want to look at your UI. Being able to visualize things in the editor is pretty nice. But it is possible to create UI entirely from code. Make an empty GameObject, add a layout controller to it like VerticalLayoutGroup or GridLayoutGroup, add items as children to the panel's gameobject, set those items' pivots/sizes/anchors (some of these will be set automatically by the layout controller, depending on its settings).
|
|
#
¿
Dec 11, 2019 20:04
|
|
|
Make a prefab with an attached script that knows where the text, button, etc are. Hand the prefab to another script, and have it instantiate the prefab once per bit of lore.
|
|
#
¿
Dec 22, 2019 02:32
|
|
|
|
| # ¿ May 5, 2024 19:20 |
|
|
Nolgthorn posted:So lets say I have a camera 25m in the air at a 45 degree angle with a raycast as a child, and I want to calculate how far away from the camera I need to move the raycast so that it doesn't collide with anything higher than 1, 2, 3, 4, 5, or 6 units above the plain. Where a unit is 1.7m. How would I calculate that? I don't understand the question. First off, to me a raycast is a verb (or a function call), not an object in the world, so I don't know what it means for a raycast to be a child of an object. But secondly, you haven't defined the length of the ray, which is critical for determining whether it will hit things a set distance away. If your goal is to position the camera a fixed distance away from whatever object is directly in front of it, I'd be doing something like code:
|
|
#
¿
Feb 8, 2020 03:48
|
|