|
KRILLIN IN THE NAME posted:What's a designer's day to day like? I get the prototyping/hashing out different concepts and mechanics bit in the pre-production stages, but during production what role does a designer fill? Do most designers tend to do additional stuff when there's less gameplay-specific design work to do on a title (e.g. filling in for level design). Game design - or good game design, at any rate - is inherently an iterative process. In preproduction, you hash out rough ideas about what the game will be about, what the basic gameplay loop will be like, and get a rough idea of what features you want. Then you start making a prototype, and whoops: half the poo poo we came up with is bollocks. So we change it. And that's bollocks too, so we keep changing it - that part wasn't fun, this part needs tweaking, the numbers on this weapon aren't balanced at all, this feature is only a shell of a design and needs fleshing out before the programmers can even start implementing it, here's an idea for a new feature that we think would make the game more fun... The rest of the team are working hard, meanwhile. You don't need a fully complete design to start writing code, or producing artwork. Sometimes that means a designer has to come in and ruin someone's day by announcing that a feature has been cut, or worse, that they want to try a new feature that has no prepwork done for it at all. But that's life, you know? No one in the history of game design has ever nailed the final design of a game in pre-production, usually not even close. In SWD2 our designers were cramming new features into the game way, way late in the development cycle, sometimes to the consternation of the programming team (including me). (Now the foot is on the other shoe and I get to be the one who makes up features for programming to do! ... except, oops, I'm still the programming lead so I'm just giving myself more work. Oh well.) Hyper Crab Tank fucked around with this message at 12:51 on Jan 26, 2018 |
#
¿
Jan 26, 2018 09:51
|
|
|
|
| # ¿ Apr 25, 2024 21:59 |
|
|
Cheating is always going to be with us one way or another. What we can do is mitigate as much as we can. * Secure what can reasonably be secured. Don't trust clients if you don't have to; a lot of the time it doesn't even cost you anything, it's just a matter of recognizing when you're about to trust something you shouldn't be trusting. * Make it difficult enough to cheat to deter casual cheaters. Determined cheaters will still do it, but most would-be cheaters aren't determined, they're lazy and don't want to put a lot of work into researching how to cheat in your game, let alone spending money. You can go a long way by making it hard enough that Li'l Bobby Tables can't trivially do it. The bike lock principle, basically. * Design your game so cheats don't have as much impact. If your game has 15 minute matches, then if you run into a cheater then at least it will be over soon. Same if your game has come-and-go gameplay where honest players can just leave games with cheaters in them at-will. * Make it possible to detect inconsistencies after the fact, or by human inspection. If you can't detect it while it's happening, then being able to detect it later on will at least make it possible for you to punish/ban people who do it a lot.
|
|
#
¿
Feb 2, 2018 14:50
|
|
|
It would help if you could give an example of the kind of thing you mean, but usually when an issue goes unfixed for a while it's some combination of:
|
|
#
¿
Feb 6, 2018 22:24
|
|
|
I'll second most of what the above posters said and add: Hearthstone: What Trick Ed says is completely true, and thanks to Wizards of the Coast and Mark Rosewater being so open about their process we have a lot of insight into how they think about their game. However, I'm personally of the opinion that Blizzard are nowhere near as good at managing their card game that Wizards is, and Brode is no Rosewater. Frankly I'm as baffled as you are about some of their decisions, and strongly disagree with their priorities. If I were to speculate about what they're thinking, it's some combination of "nerfing popular cards will hurt our bottom line too much" and "we're too busy working on the next set to change old stuff". Plus their patch cycle is horrendously slow due to wanting to have the game on phones, which consistently have awful patch mechanisms. Xenoblade 2: Sounds like it's just a matter of the designers feeling the feature will be enjoyed by a significant enough portion of players that it's worth doing. Maybe you don't fall into that category, but someone else does. MTX: I've never met a designer that explicitly planned for microtransactions as a gameplay feature. Usually it's part of the economic pitch. See, when you're making a game, step two or three is convincing someone with money to give you money so that you can give them money back later. And part of that process is convincing them that the game will make enough money. (Investors/producers are notoriously deaf to the idea of just doing a game for fun or art or whatever.) And there is a lot of money in microtransactions if your game is big and popular enough. That's all it is, the people paying for development wanting to maximize their returns. And usually, the decision isn't "game with MTX" or "game without MTX" - it's "game with MTX" or "no game at all". Difficulty: See the Xenoblade 2 answer above. Hyper Crab Tank fucked around with this message at 08:41 on Feb 7, 2018 |
|
#
¿
Feb 7, 2018 08:38
|
|
|
hey girl you up posted:I've heard horror stories about the console certification process, but I was under the impression Apple/Google were a comparative walk in the park. What's so rough about those stores? Google has no certification process at all, for good and bad. Apple's certificiation process takes maybe a week? It varies a lot. It's not hard to get through. No, the problem is Unity games don't support incremental patching on phones, which means every Hearthstone patch is a giant, multi-gigabyte download. This deters Blizzard specifically from patching this game more frequently. They have occasionally mentioned working on a way to patch card data without needing to go through the app store, but so far that hasn't materialized to my knowledge. This is compounded by the fact that a lot of people don't have unlimited data plans, and typically downloading large updates over 4G is disallowed by the app stores. Necessitating wifi to patch is another hurdle that Blizzard don't want to inflict on users too often. Hyper Crab Tank fucked around with this message at 09:12 on Feb 9, 2018 |
|
#
¿
Feb 9, 2018 09:09
|
|
|
Avalerion posted:One recent example I came across would be how the AI in Civ 6 apparently won't ever take a city, because it priories not taking heavy looses too much. Can that be put down to incompetence, or can the devs here think of some legit reasons why that's not being fixed as a priority that I'm not considering? The AI definitely conquers cities in Civilization VI. The "problem" is that the AI in that game has different priorities depending on nation, and some nations are really risk averse. And even at the best of times, the Civ AI is really bad at using military units effectively. But the Civilization series has always had bad AI, to the point where it's almost a trope that Firaxis can only be consistently counted on to put out games that 1) are extremely buggy immediately after release, and 2) have lovely AI. As always, the likely answer is that they consider it not bad enough of a problem that it takes priority over working on things that are actually going to earn their next paycheck.
|
|
#
¿
Feb 9, 2018 17:12
|
|
|
What they're saying is that the games are delivering the expected average 30 frames per second, but those frames are not evenly distributed across that second. Let's try an example. I'll use 50 fps rather than 30 because it makes it easier to understand, but the principle is the same. 50 fps means an average frame time of 20 milliseconds. What you want is for a frame to be presented to the user at t=20ms, 40ms, 60ms, 80ms, 100ms...960ms, 980ms, 1000ms. But you screwed something up, so each individual frame isn't arriving at the right time. The first few frames show up at 20ms, 40ms, 60ms, but the next one comes in at 90ms. Then the next one at 100ms. Then one at 105ms, then the next takes until 130ms to arrive, then the next at 140ms, 160ms, 180ms... What happened there was a kind of micro-judder. You delivered all the frames you were supposed to in the given second; your framerate is a solid 50. But the actual frames didn't arrive evenly spaced, so the end result looks like a jittering mess.
|
|
#
¿
Feb 12, 2018 19:26
|
|
|
ninjewtsu posted:Do bugs ever happen that are a weird mess of previous frames jumbled out of order/being repeated in with current frames So, first, yes, this can happen. Doing triple buffering wrong, for example, or doing something exotic/wrong with effects like temporal antialiasing or motion blur where you need to hang on to previously rendered frames. But 1) problems like this are extremely noticeable when they happen, 2) they tend to either happen for everything in the game or not at all, and 3) it's a fundamental part of your rendering pipeline so once you've got your implementation right it doesn't show up again. Until you decide to port your engine to a new platform and you're not quite solid on all the details of that platform's rendering API and you mess up again... but it's fairly unthinkable to release with that kind of bug in your system precisely because it's so egregiously awful to look at. It's not the kind of bug where, oh, this particular scene is handling 50% more geometry than the rest so it starts having this kind of problem. But it could happen if, say, you've got a cool new fullscreen shader effect you want to apply and that shader holds on to old framebuffers for some reason and it's only turned on in one particular scene and maybe the user has a buggy graphics driver and the game kind of shits itself and starts showing unprocessed old frames instead of new ones.
|
|
#
¿
Feb 14, 2018 12:14
|
|
|
I mean, it depends on how exactly you hosed it up. It's not a common bug to see because, well, it requires screwing up in a way that's very obvious and usually easily fixed. It's not some corner case that happens when physics intersects in just the right way or anything like that. But it'd probably just look really jittery, like objects on screen were rapidly moving back and forth slightly every other frame. Have you ever had your computer bluescreen in the middle of playing a game and the screen just jitters back and forth between two frames? Imagine that except the game is still running.
|
|
#
¿
Feb 14, 2018 21:51
|
|
|
Also remember that games need somewhere to store savegames, configuration files (remember how you always had to tell the setup program you had a Sound Blaster 16 compatible sound card at 220h?), etc. On gaming consoles, you have a dedicated mechanism/save cards for that, but on ye olde PCs, you needed to know where on the user's harddrive you could store that stuff. A lot of games supported a "Minimal" install mode that needed the CD to load all the big data files from, but kept a directory somewhere for savegames and sundries. Usually you could also opt for a "Full" installation that improved load times by placing it all on your disk, as already explained.
Hyper Crab Tank fucked around with this message at 20:21 on Mar 5, 2018 |
|
#
¿
Mar 5, 2018 20:19
|
|
|
We don't show progress bars at all because literally no one has ever asked to have it and it's an annoying amount of work for a feature almost no one wants. (We just do animated loading screens.) We just throw a bunch of function calls in a queue on a separate thread, then wait until it's all finished and move on. Optimally, all loading should happen on a separate thread during load screens; we still can't predict how long it will take for reasons already explained, but at least it avoids frame stutters since the main thread is dedicated to painting a pretty loading screen for you while the other thread does the work. Except, some things can't always be done on the other thread, usually because they require some graphics context poo poo that's only available on the main thread (texture uploading is a great example). Usually those operations are fast enough that you don't notice, but that's one reason why you could see a frame hitch during a loading screen.1337JiveTurkey posted:Speaking of progress bars, do you have any sort of special API for tracking the progress? I'm used to getting a setProgress() method that takes an integer percentage and sets the bar to that amount. In practice getting the progress bars to do anything useful is near impossible when there's three different developers implementing different parts. It usually ends up going 0%, 33%, 66% and then 100%. I imagine adding in multithreading makes it even messier. Multithreading doesn't really complicate things much; you should be loading assets on another thread anyway, like I said. Figuring out a clean way to split the loading task into a number of sub-tasks that make sense is the greater problem and requires writing a lot of annoying code that's rarely worth it and no one wants to do because we have better things to do with our time. But if you forced me to, I'd make it mandatory for your "job that loads a thing" class to have some kind of progress getter that indicates how far along it is and make the main thread poll as required.
|
|
#
¿
Jun 29, 2018 22:51
|
|
|
Many (most?) games these days don't have loading screens long enough to warrant minigames, anyway.
|
|
#
¿
Jul 1, 2018 21:36
|
|
|
OneEightHundred posted:This is also one reason that unskippable intro movies can exist (to act as a flashy loading screen, essentially). Also elevators. Have you played the new God of War, for example? The realm travel room is just a glorified loading screen, and so is the Realm Between Realms, but it really helps improve the immersion. It's especially bad for games that read off of disc; but even then, it's pretty much only photorealistic AAA games that need to load that much stuff. The main thing you can do to reduce load times is to ensure you don't unload things unnecessarily, but keep it in memory once loaded and reuse it.
|
|
#
¿
Jul 2, 2018 07:36
|
|
|
Yeah, whenever a game can predict with reasonable accuracy where the player is going to go next - usually because there is only one way to go from a given spot - it can do a lot of loading in the background. This is also one reason why some games with a open-world-like style make you go through chokepoints, usually interiors, to get to certain parts of the world; it's so that they can load the rest of the world while you're indoors and can't see it being loaded. The main reason for things like the realm travel room in God of War is because the game can't predict where you're going until you've pressed the button to select your destination, so it needs some kind of loading screen and chooses to hide it behind a pretty light show and some banter between the main characters.
|
|
#
¿
Jul 7, 2018 14:44
|
|
|
Nice piece of fish posted:Asking a probably stupid question that may have been asked before, because I'm out of the loop on this one: What's your opinion on gaming for linux, and what's the real difficulty making games linux compatible/making linux games from a dev perspective? If it wasn't for gaming, I would absolutely be using linux on most of my home computers, but gaming and linux seems an impossible combination and I don't see why that doesn't change. Not that I'm expecting it to. I'd love your opinion on this as actual computermen. Haven't looked at this for ages. The long and short of it is that the Linux market for gaming is so tiny that it's pretty much never worth actively pursuing. Look at the Steam Hardware Survey, for example; only about half a percent of players are on Linux. The crossing point on the effort/profit graph for that one is insanely low. Heck, we sometimes discuss whether it's even worth it to go after Mac players with their 3% market share. (The Mac App Store is complete garbage for games, by the way.) We do make Linux ports, but not as a primary target and frankly no one is pushing very hard for it. Now, we're not close to an AAA studio, so for us porting games to Linux is not very difficult. We have an in-house engine and still use OpenGL on SDL for the Windows and Mac ports, so porting to Linux is cheap, especially since we settled on versions of all our third-party libraries long ago and don't intend to upgrade unless we really need to. It's a few days of fiddling around and testing near the end of the dev cycle to get it working, so, you know, why not? But I don't think we expect to make any significant cash on that market segment. It gets far more difficult if your game is more demanding, like a AAA title. Traditionally, Linux systems have had pretty lovely drivers, for example, and the bigger your engine the harder it is to ensure everything works on a brand new platform. Add to that all the testing, bug fixing, post-release support etc., and the idea of dedicating valuable time at a slow behemoth like a AAA studio to go after a miniscule 0.5% market share is so unpalatable that almost no-one bothers to do it. It's worth it to port for the big platforms like PS4 and Switch (both of which are FreeBSD-based, by the way), but that's because their market shares are literally several orders of magnitude bigger. Digirat posted:What languages do you write the most? I'm not sure how to interpret this question. Programming languages? At our shop it's mostly C++, Python and (recently) Lua, with several in-house tools being written in C#/.NET. Hyper Crab Tank fucked around with this message at 12:47 on Jul 12, 2018 |
|
#
¿
Jul 12, 2018 11:14
|
|
|
OneEightHundred posted:Re: Linux, IIRC another complication is that most Linux users that play games dual-boot Windows already, so that reduces the benefit of porting even further. ... and many who care about gaming also have a console of some kind, so it's likely you're covering the same audience already anyway.
|
|
#
¿
Jul 14, 2018 19:12
|
|
|
Nice piece of fish posted:Guess it's not gonna change either any time soon. Probably not. With dual-booting being easy, and home consoles being affordable, there are just easier ways to get games into the hands of Linux users who want to play them than to make Linux ports. Are you thinking of doing this as a game jam type of thing or more like a two month project?
|
|
#
¿
Jul 28, 2018 10:17
|
|
|
Nessa posted:A two-three month project, likely with everyone getting together every few weeks and also chatting on our Discord channel. We were thinking of gathering at an Internet cafe. My #1 piece of advice is: Have an online task/issue tracker and insist that everyone use it. I would use Trello if I were you; it's free and does what you want. My #2 piece of advice is... if you want to do a 2-3 month project, expect it to actually take a year. Hmm, there's a lot of stuff to be said about project management. There's a reason it's an entire profession and a full-time job. The best I can do is explain how we do it, but that's probably not too useful for someone not doing it 8 hours a day.
|
|
#
¿
Jul 28, 2018 20:34
|
|
|
I more realistic answer to the whole server browser question; first of all, as others have said, what's been going away is not server browsers but privately hosted servers. And there are a couple of reasons for that. I'd say the primary one is a desire to present customers with a single, cohesive multiplayer experience that demands as little as possible from the user in terms of wrestling with the system just to get into a game experience that suits them. This necessitates features like ranked matchmaking, one-click "find quick game" options, guaranteeing a certain minimum threshold for performance and bandwidth, preventing cheaters and hackers, and streamlining the user interface so players don't have to browse through potentially confusing lists of servers just to play the game. This is especially the case as console gaming expands to include more markets, including younger players and less technologically savvy and less patient players who just want to play the drat game. And guaranteeing features like that is somewhere between hard and impossible if 99% of servers are run by Unreliable Joe Schmo from his basement. Add to this some platform owners being very restrictive about who you're allowed to let players play with, a general desire to offload these kinds of things to the facilities provided by the platform owners, and a few tangential issues like preventing Joe from naming his server something virulently racist and catching flak from media that can't tell the difference between Joe and DeveloperName, and you get a general reluctance to allow third parties to host servers. The value proposition just isn't really there anymore for most companies.
|
|
#
¿
Oct 16, 2018 16:31
|
|
|
Catpants McStabby posted:while not calling out (ok, i am I guess) fallout76 specifically, one of my problems with games is knowing a game sucks and watching devs who are just working to feed their families get caught in the backlash over a game that critically fails. I always see "the devs suck" etc when a game tanks, but the ceo or whatever gets the praise when it sells a billion copies. How do devs stay in this career path knowing their job is so thankless and abusive from the very people they're making games for? The gaming community in an overgeneralization is pretty lovely, but when Todd Howard would have gotten all their praise (had it not been poo poo) makes me sad. If I wasn't enjoying the process, I wouldn't be doing it. The audience response is secondary... and ultimately marketing/publishing's problem, not mine. My job is getting the game done and as good as it can be, and there's nothing I'd rather do, even if it's hard and stressful sometimes. That being said, I don't work for a big AAA studio, but a small (25-ish) operation where everyone has a chance for creative input and the CEO would rather see the company go under than make anyone work the kind of ridiculous overtime hours you hear about from other studios. I don't think I'd be nearly as happy at a big studio. Rather be a big fish in a small pond than small fish in a big pond, you know? Especially when all the fishes around here are pretty big.
|
|
#
¿
Nov 24, 2018 20:58
|
|
|
It's hard to pick a single game since I like different games for different reasons. God of War was great not only for its action but for the storytelling and theme and I think if I had to choose, this is the one I'd go for as the most solid overall pick). Return of the Obra Dinn was the first detectivin' game I've played in a long time that actually felt like I was figuring something out and not going through rote motions to satisfy the game enough for it to show me another cutscene. La-Mulana 2 was something I'd been anticipating for a very long time and delivered exactly what I wanted out of that sequel.
|
|
#
¿
Dec 9, 2018 21:12
|
|
|
CJ posted:How does draw order work with respect to particles and effects? So as you already seem to know, real-time rendering often employs what's called a depth buffer (or z-buffer). Simply put, it's an extra screen-sized buffer that keeps track of normalized depth, which you can think of as how far "into" the screen fragments (pixels) are, so that if later in the frame you try to render another fragment that would be behind the existing one, instead it's simply discarded. As long as all you've got is opaque geometry, it's a great way to make sure things appear in the right order on screen, no matter what order you actually draw stuff. You draw an opaque fragment, everything that would be behind it is occluded. Nice. Not so nice for transparent planes, though, as they end up occluding as if they were opaque. The depth buffer just stores a depth value, and writing a semitransparent pixel or an opaque one makes no difference to the depth buffer as long as they're at the same depth. Furthermore, transparent planes typically depend on correct ordering in order to composite correctly. So, if you want something transparent to look right, you have to do two things: sort your geometry back-to-front, and disable depth writes when drawing them. They should still respect the depth buffer though; a puff of smoke should still be hidden if it's behind a wall. So depth test needs to stay on, but depth write gets turned off. It may have occurred to you that if we're sorting stuff anyway, it might be useful to make use of the depth buffer to reduce fill rate by rendering opaque geometry front-to-back; that way, the depth buffer fills up more quickly by rendering geometry that's likely to occlude the most before rendering geometry that's further back. Lots of engines do this. Naturally, sorting costs CPU time, so it's a tradeoff you have to decide if it's worth it or not and how finely to sort. So the basic algorithm is: Sort opaque geometry front-to-back, sort transparent geometry back-to-front, render opaque geometry with depth test and depth write on, render transparent geometry with depth test on and depth write off. But we have a problem. Sorting transparent geometry is not as easy as it sounds. For starters, a modern game can have millions of planes on screen at any one time, so transforming to screen space and sorting every single plane 60 times per second is often not feasible. Worse yet, there are pathological cases where intersecting geometry cannot be consistently sorted at all. And on top of that you have another problem: draw calls. Even if you could somehow sort every individual particle in the same pass as everything else in the scene, you'd run into a problem when you go to render them because all these little particles are likely to be using separate materials. Long story short, switching materials is expensive and every time you do it means a new draw call. With potentially hundreds or thousands of particles in a scene intersecting, this can tank performance just on draw calls alone as your game switches back and forth between the orange and blue materials just because the orange dust cloud is in the same spot as the stupid blue dust cloud. So we do what we always do - we cheat and hope nobody notices. Most engines have some rough concept of an "object" in the game world; it could be a player character, a wall, a switch on a wall, or a particle system, or whatever. There can be hundreds of these in view at any time; but hundreds is several orders of magnitude better than millions, and we can sort that in real time. Unfortunately, this means intersecting/overlapping objects sometimes glitch out, if they're transparent. It's much easier with opaque geometry, where the depth buffer saves our asses by cleanly allowing geometry to just intersect without any obvious problems - remember, the order in which you draw opaque geometry doesn't matter for the outcome. Particle systems typically sort their own particles internally, but care naught about other nearby particle systems. Most of the time this looks fine and nobody notices for long enough to care. If an effect is too egregiously off, you might put in a special case flag on that particular particle effect to make it take the costlier path and sort alongside other systems. But typically we just work around it, or just don't put that effect near other effects that it's not playing nice with. You might be surprised how much of game design only works because you strategically avoid putting problematic things next to each other. So, in short, the answer is: We only approximately draw planes in order, by sorting them as objects rather than individual planes. It looks good 90% of the time and has the benefit of actually being doable in real time, which is good enough to ship. Hyper Crab Tank fucked around with this message at 20:54 on Dec 28, 2018 |
|
#
¿
Dec 28, 2018 20:35
|
|
|
Flannelette posted:Can anyone explain the effect where you have a flat image at the front of the render that is an overlay or outline of a 3d model in the frame, it used to be used a lot for x-ray vision for seeing people through walls or highlighting things it's like a stencil but positioned right over the 3d model. You just disable depth test, set a different material/shader and draw the model again. Nothing fancy.
|
|
#
¿
Jan 23, 2019 16:24
|
|
|
Yeah, you probably want to do something like that if you want to be able to draw like, a character that's partially hidden by cover and only highlighting the part that's in cover.
|
|
#
¿
Jan 23, 2019 19:57
|
|
|
Really hard to say without specific examples. Some people are very productive. Others aren't. Some teams have larger budgets than they seem. Some have smaller than they seem. No one generally wants to give precise numbers on that sort of thing.
|
|
#
¿
Jan 25, 2019 15:21
|
|
|
Besides hard capabilities your hardware/driver has to support or the game won't run (like minimum DirectX/OpenGL versions, shader capabilities etc.), we kind of just wing it, tell you the truth.
|
|
#
¿
Feb 8, 2019 18:32
|
|
|
Akuma posted:Whatever you choose, people will try and run your game on lower spec machines and complain if it doesn't work at all (hello, anything newer than SSE2.) Checks out. Like 99% of our error reports are people trying to run the game on some integrated Intel graphics chipset on a laptop computer from 5-10 years ago.
|
|
#
¿
Feb 9, 2019 23:10
|
|
|
I find myself in the opposite situation more often, I think; oftentimes we're faced with some problem that needs to be solved that other games have solved before. My instinct is usually to just do what everyone else is already doing, because I tend to think they're doing it for a reason. Granted, that's not always the case. But there seems to be an instinct among creative people (and I've been guilty of this myself) to want to do something new and untested and unexplored way more often than we should because the standard solution seems, I don't know, boring I guess. But the problem with new and untested solutions is that some number of times out of ten they turn out to not work very well... and when you've tried a couple things and end up doing the standard solution in the end anyway, I sometimes feel like we wasted a lot of time. Yes, you do need to push boundaries now and then because that's how you move forward, but I think you should be judicious about what you experiment with so that the potential payoff is big enough in the event that you do come up with something that's new and crazy and really good. Reserve it for the core experience, not for all the little functional supporting elements that make the core work. Because if you don't, you'll spend a lot of your time designing doors that people have to stand in front of for five seconds because the standard way where doors just open was too boring and you wanted a more cinematic experience. Hyper Crab Tank fucked around with this message at 17:56 on Feb 25, 2019 |
|
#
¿
Feb 25, 2019 17:54
|
|
|
We use Blender! 
|
|
#
¿
Feb 26, 2019 16:17
|
|
|
cubicle gangster posted:For full time salaried game positions are studios really that reluctant to invest in people with good work? Nah. But if you're going to start learning from scratch, might as well learn the more likely one to be immediately useful, right?
|
|
#
¿
Feb 26, 2019 17:38
|
|
|
happyhippy posted:What's wrong with Blender for game making? If you want a serious answer, there's nothing wrong with Blender besides the fact that the interface designers seem to have wandered in from a parallel universe where standard hotkeys and understanding of UX are radically different. But most 3D artists learn to work with either Maya or 3DSMax, or maybe something like MODO. Going from that to Blender might be a bit jarring and takes a while to get used to. Hyper Crab Tank fucked around with this message at 22:50 on Feb 28, 2019 |
|
#
¿
Feb 28, 2019 22:48
|
|
|
I feel like we have to be more clear what we mean by "video" here. If you're talking about a fairly small sprite on screen that you need to flip between frames - say something like the main characters in Cuphead - then atlasing is the industry standard solution. In that case we're talking about a moderate amount of graphical data, probably no more than what fits inside a single 4096x4096 texture. Putting every frame in an atlas is a clean way to solve a variety of problems, but most of them aren't really about memory bandwidth - atlas or not, the textures are all going to be in GPU memory before you draw your first frame anyway. It's more about eliminating draw calls than anything else. But if you're talking about full screen, full motion video, you run into real issues with memory. A single frame of 1080p video, DXT5-compressed, is upwards of 2.5 MB (uncompressed would be a hideous 8 MB). Leaving aside the fact that you're not going to be able to fit 50 of those in a single texture, you can't fit more than a few seconds of video in the GPUs memory to begin with. This means if what you want to do is full-screen video, you're not going to be able to preload an entire video even if you're willing to accept the loading times, and streaming is your only option.
|
|
#
¿
Mar 25, 2019 11:07
|
|
|
2D skeletal animation is a great way to reduce the amount of textures you need to get smooth animation and is used in a lot more than visual novels. It's what we've used in our games for a while now; Heist and Dig2 use rigid skeletal animation, Quest has vertex-blended skeletal animation, both with texture switches at appropriate times to do things like perspective or facial expressions or whatever.
|
|
#
¿
Mar 25, 2019 11:40
|
|
|
Flannelette posted:Game question about game dev for a change of subject: Do you have a more specific example of a game you feel behaves this way? The question is a little confusing to me, because "frame time" can mean different things and memory has nothing to do with it. It's also worth mentioning that FPS dips can cause wonky behavior no matter how your timing works.
|
|
#
¿
Apr 17, 2019 12:26
|
|
|
Well, there's a couple of things going on there. One of which is what I alluded to earlier: most engines that support variable timesteps may still have problems with things like physics. There's no excuse for writing your code so badly as to not care about how long the timestep actually is. But even if you do, doing physics simulation twice as often is still going to affect how your physics works. Now, generally, the more physics ticks you do the better your simulation is likely to be, so this isn't really a problem. Dips are far more damaging in that regard - that's how you get stuff clipping into walls and whatnot. Because no matter how your timesteps work, physics engines are approximations at best and are generally built with assumptions about the limits of the kind of things will usually happen in the game, and tend to go wonky when those limits are violated. There is some value to always running fixed timesteps, though, assuming again that you didn't write your code so badly that you ignore what the actual timestep is. In particular, it's generally thought that a consistent 30 fps is better than an inconsistent 45, say. This isn't strictly what you're asking, but it is kind of in the same area of... timing stuff. But in general, poo poo like that Fallout 76 things is just bad, lazy code. There's no excuse. I don't even think there are any valuable performance gains to be had.
|
|
#
¿
Apr 17, 2019 14:39
|
|
|
Interpenetration is a problem you have to solve regardless of how big or small your timestep is. Simulated physics are by necessity discrete, since time is divided into chunks and not smoothly continuous (not to mention that our computers are fundamentally discrete). Consider a simple situation with two boxes, one static and the other moving towards the static one. There will at some point be one frame where the moving box is separated from the static box, and in the next frame it is intersecting the static box, assuming its motion were to simply continue. This is where the physics simulation has to decide what to do with the two objects in order to resolve the collision. The core issues are basically to determine 1) the point of collision, i.e. how the moving object needs to be offset to avoid interpenetration, and 2) the impulses to apply to the objects to simulate the transfer of kinetic energy involved in the collision (i.e. bouncing, knocking things over etc.). Leaving the second aside, there are a number of approaches to solving the first problem, of varying degrees of complexity and performance impact. Some systems try to figure out how far the objects have interpenetrated and simply pushes them apart. Others try to back up time and re-simulate the moving object with a smaller timestep to get a better estimate of where the collision occurred. If you want to be really accurate you have to do it for the entire scene, which is very complex and expensive. And some allow the objects to interpenetrate and try to apply forces over time hoping it will be enough to separate the two quickly enough. What solution is best for your engine is largely a matter of knowing what the limits are of what you're trying to simulate, and balancing that with the time and expense of finding a solution. If you know you never have to simulate irregular rotating objects and multiple rigid body collisions in the same vicinity, you can get away with a simpler solution and that's probably what you should do - simulating physics is hard at the best of times. Here's a lovely diagram I drew to explain a potential problem that could arise with unexpectedly high timesteps/velocities.  In the left scene, the object is moving slowly enough that the solver can correctly push the objects out of each other so they don't interpenetrate and all is good. In the second scene, the delta is too large, so the solver might get the idea that the best way to solve the collision is to move the object out the other side (being the shortest path and all). Worse yet, imagine what happens if the object is moving so fast that there isn't a collision at all in the timestep. This is the typical way objects tunnel through each other: the timestep or velocity get too large to correctly solve the collision, or even detect it at all. I'm sure you've seen examples of objects shooting away at high speed after interpenetrating, too. That's a result of trying to work out the correct impulses needed to separate objects, especially if you're using a spring-like model where interpenetration is temporarily allowed while you apply a force based on how much things are interpenetrating. An object has gotten stuck in the ground somehow far enough that the system thinks it needs an outrageous amount of force to separate them, and... the object, once dislodged, gets freaking launched. It can be especially dramatic if the system is built to accumulate force over time in this way if the object stays stuck for longer.
|
|
#
¿
Apr 18, 2019 08:30
|
|
|
The answer to all these questions really is "yes, sometimes". The fundamental thing to understand about computer games is that we cheat as much as we can get away with. Because even though computers are much faster now than they were say 20 years ago, we've also been pushing the envelope a lot and it's just not possible to simulate physics accurately in real time on consumer hardware while also doing all the other stuff that's part of a modern video game. So we use whatever tricks we can get away with. Most of them revolve around trying to do as little work as possible by figuring out what absolutely needs to be done now with any semblance of accuracy and what we can cheat with. That process is part automatic and part manual. You might be surprised how often the answer to a complaint (from, say, a level designer) like "the physics wig out if I put this object near this other one" is "then don't put those objects near each other". But there are automatic things too. Spatial data structures for early rejection, heuristics, doing rough physics for things first and fine grained stuff if it seems like some particular object needs more attention - especially if it's close to the player. If the player isn't looking at an object, it makes no sense to simulate it with high precision, right? The player doesn't care exactly how the box fell of the shelf if they weren't there to see it, they just want it to be on the ground somewhere roughly nearby. Then again, these fast, dirty cheats are what gets us into trouble, too. Because we're trying to somehow solve all these problems all at once, and it's not always boxes moving straight at other boxes. A lot of the time it's a rotating irregularly shaped object moving in a curved path towards a pyramid or some other nonsense and now the clean mathematical solutions don't work, or are too hard to implement, or too hard to get to be performant. So things slip through the cracks, and we (programmers) talk to the level designers and tell them to set things up so the player isn't likely to encounter a situation where it all breaks down. And it works... most of the time... until some very persistent player manages to ram a car into a swing set to hilarious results that show up all over youtube and we all get to have a good laugh about it while sweating profusely inwardly. (By the way, I should say my primary work is not physics programming, although I am a programmer. I haven't had to wrestle with the really tough problems personally.) Hyper Crab Tank fucked around with this message at 16:04 on Apr 19, 2019 |
|
#
¿
Apr 19, 2019 15:55
|
|
|
Flannelette posted:I've asked about collision for 3d/modern 2d games but anyone know how different it was is back in ye olde days with sprites (where everything was explicitly just a grid of pixels)? Old 80s/early 90s games tended to have integer movement on a tile map or something that was also on integer coordinates (with subpixel movement usually handled specially). It makes collision detection and response significantly easier if you know movement is always going to be exactly aligned with the boundaries of tiles and other sprites. All you have to do is move a pixel at a time and reject the movement if the moving object would intersect something else after moving (and since we're talking about axis-aligned bounding boxes, detecting overlap is fast and trivial) and you can be sure objects will be flushly aligned without having to figure out how to separate them and whatnot. You can still tunnel through things by moving fast enough, of course. Some games still did a lot of the same operations we're talking about here, though, such as pushing objects out of solid walls. But the constraints were much tighter and assumptions made so that the checks could be vastly simplified. The biggest advantage is arguably not having to worry about rotating or irregularly shaped objects. Hyper Crab Tank fucked around with this message at 07:52 on Apr 21, 2019 |
|
#
¿
Apr 21, 2019 07:50
|
|
|
mikemil828 posted:Question: Everyone probably has heard that Game Freak isn’t including all the previous Pokémon anymore in the Main Series instead having just a curated number of the past ones. It was announced that the reason was due wanting to focus on animation quality, but’s not just that is it? What challenges would envision occurring when you have ~900 playable characters in a single game? Most likely they did some math and realized that if they want to up the quality of their games in general going forward, there is no way in hell they can keep supporting the full roster of Pokemon while also adding new ones every generation. Animation is part of that, sure, but this is something that affects every part of production. Modeling, audio, game design, level and encounter design, you name it, everything takes twice as long if you need to complete 900 Pokemon instead of 450, or 300, or however many you've got in your game. Beyond a certain point, the value added by including one more Pokemon also drops off pretty sharply - to be blunt, there are a lot of trash mons in the list that people don't care that much about. It's possible that they could keep the full list going a while longer, but realistically, this is something they needed to do sooner or later. The list can't keep growing every year. If every successive generation of games is more and more expensive to make, sales need to keep going up and up and this isn't an equation that's going to balance out forever.
|
|
#
¿
Jul 16, 2019 11:59
|
|
|
|
| # ¿ Apr 25, 2024 21:59 |
|
|
Yes, you request keys via the steamworks dashboard. You can even request keys with different kinds of access, e.g. if you want keys for testing purposes that can only access a particular branch. Steam generally let you request as many keys as you want, within reason, as long as they can still sell the game.
|
|
#
¿
Jul 17, 2019 16:20
|
|