|
Xik posted:I was listening to a roguelike radio episode on Jupiter Hell and the dev describes how in the future there are plans for high score boards. He described how the engine can be given a seed and the list of inputs and the game will be exactly reproducible every time. So an uploadable high score would actually just be like, engine version + seed + history of all inputs and it will be played back in a headless version of the engine to verify the score. Yeah, it’s a fairly common approach. I think the networking things should be applicable too but searching for ”deterministic game replay” gave me more specific hits. Be aware that if you’re using Unity you won’t be able to depend on its existing systems or assets as much since they may not be deterministic.
|
#
?
Sep 24, 2019 10:59
|
|
|
|
| # ? May 12, 2024 13:31 |
|
|
j.peeba posted:searching for ”deterministic game replay” gave me more specific hits. Yeah that's the ticket thanks, looks like it will give me some initial reading. I remember it being very briefly touched on in the context of a command stream and undo/redo in game programming patterns, but if anyone has anything like this with more design tips/gotchas etc that would be cool.
|
|
#
?
Sep 24, 2019 11:07
|
|
|
Xik posted:Yeah that's the ticket thanks, looks like it will give me some initial reading. Also check out “lockstep networking”
|
|
#
?
Sep 24, 2019 11:41
|
|
|
grate deceiver posted:Thanks for the suggestions. I have tried Godot before, but for some reason found aligning all the UI elements was super annoying. Maybe I should try to revisit it. Has anyone made a chromium plugin for Unity? 
|
|
#
?
Sep 24, 2019 13:48
|
|
|
dupersaurus posted:Has anyone made a chromium plugin for Unity? https://github.com/gree/unity-webview
|
|
#
?
Sep 24, 2019 13:53
|
|
|
yaaaaas I say, with complete sincerity, that webdev+React is the platonic ideal of a game UI framework, and if I had that back in the day my job would have been loving glorious
|
|
#
?
Sep 24, 2019 14:20
|
|
|
There's also this thing that does Flutter in Unity: https://assetstore.unity.com/packages/tools/gui/uiwidgets-146398
|
|
#
?
Sep 24, 2019 14:25
|
|
|
Xik posted:I was listening to a roguelike radio episode on Jupiter Hell and the dev describes how in the future there are plans for high score boards. He described how the engine can be given a seed and the list of inputs and the game will be exactly reproducible every time. So an uploadable high score would actually just be like, engine version + seed + history of all inputs and it will be played back in a headless version of the engine to verify the score. Yes it's doable, as an example look at Devil Daggers. https://store.steampowered.com/app/422970/Devil_Daggers/ When you complete a game it submits your score plus your inputs. Steam already supports this as part of it's leader boards API. The game is deterministic (single seed) so it can easily create a replay, this is why you can click the eye and watch anyone else's play. If you wanted a semi random game the only thing you'd have to do differently is to submit the initial seed and continue to make sure everything is deterministic from the initial seed. Then it would be easy for the community to watch replays and flag the ones that didn't hit the score suggested. But you could also rig up the headless score-checking system pretty easily and remove and scores that didn't match submitted score to score created by running sim+inputs. Stick100 fucked around with this message at 21:33 on Sep 24, 2019 |
|
#
?
Sep 24, 2019 21:30
|
|
|
Xik posted:Yeah that's the ticket thanks, looks like it will give me some initial reading. My big lesson from shipping multiple lockstep-networked AAA titles: your biggest problem is going to be error/desync detection. The approach I've used in the past is to make a system that can record lightweight log entries (__FILE__/__LINE__) and generate a CRC of the new logs every frame. Record the CRCs (and, in debug, the logs themselves) in your replay file and during playback compare them (for networked games the equivalent is to send the CRC over the wire and compare it) -- if they're different, dump the logs so you can diff them and find where it went wrong. 95% of them will be either uninitialized/uncleared statics or improper usage of rand(), at least if you happen to be working on a title that still has code ported from 90s arcade machines and a lead gameplay programmer who literally never tests the game online.
|
|
#
?
Sep 26, 2019 01:31
|
|
|
more falafel please posted:My big lesson from shipping multiple lockstep-networked AAA titles: your biggest problem is going to be error/desync detection. The approach I've used in the past is to make a system that can record lightweight log entries (__FILE__/__LINE__) and generate a CRC of the new logs every frame. Record the CRCs (and, in debug, the logs themselves) in your replay file and during playback compare them (for networked games the equivalent is to send the CRC over the wire and compare it) -- if they're different, dump the logs so you can diff them and find where it went wrong. 95% of them will be either uninitialized/uncleared statics or improper usage of rand(), at least if you happen to be working on a title that still has code ported from 90s arcade machines and a lead gameplay programmer who literally never tests the game online. The least-paranoid solution is use a fixed implementation and only ever feed consistent object IDs into a hash function, the most paranoid solution is to use RB-trees or something instead.
|
|
#
?
Oct 1, 2019 01:19
|
|
|
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 have a big performance issue with my VR game. It's running almost smooth as butter... except for occasional jumps. Which is bad normally, but super mega ultra bad in VR. The profiler has tracked the occasional spike in CPU use on single frames to one function within Unity itself: UpdateRendererBoundingVolumes I have no idea what the implications of this are, nor how to what to change so that my game doesn't paint the walls in vomit. Has anyone encountered performance issues related to this?
|
|
#
?
Oct 1, 2019 22:42
|
|
|
Corbeau posted:I have a big performance issue with my VR game. It's running almost smooth as butter... except for occasional jumps. Which is bad normally, but super mega ultra bad in VR. The profiler has tracked the occasional spike in CPU use on single frames to one function within Unity itself: Do you have a canvas in there? UI performance can tank the whole engine when it needs to redraw stuff on every update.
|
|
#
?
Oct 2, 2019 07:40
|
|
|
Xik posted:I was listening to a roguelike radio episode on Jupiter Hell and the dev describes how in the future there are plans for high score boards. He described how the engine can be given a seed and the list of inputs and the game will be exactly reproducible every time. So an uploadable high score would actually just be like, engine version + seed + history of all inputs and it will be played back in a headless version of the engine to verify the score. I remember someone saying that is how the roguelike brogue handles saving but I've also heard that it is very buggy.
|
|
#
?
Oct 10, 2019 14:03
|
|
|
Floor is lava posted:I remember someone saying that is how the roguelike brogue handles saving but I've also heard that it is very buggy.
|
|
#
?
Oct 11, 2019 01:12
|
|
|
roomforthetuna posted:One big danger of doing saves as replays is that it can make it very difficult to have a save file still work in a newer version of the game. For a simplistic example, if your save starts with a random seed so all random decisions can be replayed the same, and you have a moment where a random monster from the 10 available monsters is generated, when you do an update that makes it so you have 11 monsters, and load that save file into the new version, the result of that random selection retroactively changes, which screws up the entire rest of the replay. If you saved an index of the monster type, maybe you inserted in the list, now you've got another wrong monster. Or if you changed the AI behavior, now that monster turns out to be no longer standing next to the player when the replay says "player hits that monster". That's why you need a forwards compatible serialization format like protobuf.  Wait, you're worried that as all Google projects it will get abandoned? Don't be silly, that will neve-
|
|
#
?
Oct 11, 2019 02:46
|
|
|
Absurd Alhazred posted:That's why you need a forwards compatible serialization format like protobuf. I'm neck deep right now in various neural network frameworks and it's insane how much they're all in bed with protobuf. Maybe it has to do with tensorflow compatibility, but it looks to be lingua franca of the serialization format for all of them. It's scary how pervasive it is this protobuf library.
|
|
#
?
Oct 11, 2019 02:51
|
|
|
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
|
|
|
Absurd Alhazred posted:That's why you need a forwards compatible serialization format like protobuf. Also if you're saving by recording every action and consequence then you've pretty much lost the entire point of replay-based saves, in that now you're back to saves that can be faked, where it's hard to detect that it was faked because the behavior can't ever diverge on replay. Basically, replay-based saves are good for making replays and for validation, but very bad for being compatible across versions.
|
|
#
?
Oct 11, 2019 03:16
|
|
|
Essentially, you need to include the version in the replay, and also ship every old version of the game logic so it can load the replay using the appropriate version. And you also need to handle the case where someone plays a bunch on version A, saves, then loads it up in version B and carries on from there. Probably with some sort of "switched game versions" special action.
|
|
#
?
Oct 11, 2019 03:26
|
|
|
roomforthetuna posted:Protobuf is good for addressing the problems of save state in general being forward compatible, but doesn't address any of the things I was talking about with respect to specifically replay-based saves. If you do the replay by recording every action and consequence then it will maybe still work after a version change, but if you're doing replay-based saves it generally makes more sense for the format to be, e.g. timestamped player decisions, or inputs, and if you do that then it doesn't matter how forward-compatible your data format is if the game's behavior changes across versions. (And if it doesn't then why do you even have a new version!) One game I studied a bit the replay format of was Starcraft 2. I did that back in 2010-2012 but I think it behaves the same way today. That game only recorded the actions of the player: move action at X, selected unit Y, attack move at Z. What that means is that a replay can only be played with a particular version of the game. If I select a marine and tell it to shoot a zergling, the game only records "Unit X attacks unit Y". The outcome is not registered. On version 1 of the game the marine wins. On version 2, the zergling may win. And that essentially changes the entire path of the game. And is the same format they use for multiplayer play. It only sends the actions of your opponent to your game, nothing else. Your game plays the opponents actions and records and sends to your opponent your actions. And this mandates that both players have the same version, as it cannot work otherwise. Therefore, in SC2 if I want to play an old replay, the game downloads that engine version the replay was made in and it plays it.
|
|
#
?
Oct 11, 2019 04:03
|
|
|
That's all true, but a high score board doesn't really need to worry about compatibility, it just needs to validate it once when the score is registered. It's kind of similar to, say, Mario Maker clear validation in that respect... but also has a similar problem: If the high score depends on an exploit or strategy that gets patched out or something, then you have to figure out if you want to keep the score, or annotate it, or delete it.
|
|
#
?
Oct 11, 2019 04:54
|
|
|
Any recommendations for language-neutral game programming tutorials? I really enjoyed Ray Tracer Challenge for graphics programming because it allowed me to bring my own tools and would enjoy something similar for interactive stuff.
|
|
#
?
Oct 12, 2019 17:02
|
|
|
I'm pretty sure I need to do some shader nonsense for this but I don't know much about those so I'm hoping somebody can point me in the right direction. This is Unity if that matters. I have a mesh which for the sake of the example let's pretend is a cube. It is UV mapped etc., but the texture used is shared with other meshes. I would like one and only one face of this cube to replace its texture every N seconds, repeating. Producing one texture for each frame of animation is possible but impractical as there are multiple such animations and that would quickly lead to hundreds of these textures trying to achieve a least common multiple of number of frames. Same problem with trying to produce one copy of each static texture for each animated one. I assume what I want to do is animate the UVs to switch what texture they're mapped to but I don't really know where to start with that. The examples I've seen seem to be "animate every vertex" and/or "the entire texture is a sprite sheet". Is this something shader graph can do? Is there an example of this out there somewhere? Flipbook seems close but again that seems to be for the entire mesh at least by default, and I'm not sure how to encode into the mesh how many frames it needs to use as the examples seem to assume that you only have one set of sprites in your texture as opposed to several in different locations, so they can just make that data into constants.
|
|
#
?
Oct 12, 2019 18:36
|
|
|
Use the second material slot in the texture map editor and have a script change this texture only for this object?
|
|
#
?
Oct 13, 2019 08:01
|
|
|
I'd be tempted to just stick a quad or plane over that face and give it a separate texture. Would simplify things to some extent.
|
|
#
?
Oct 13, 2019 17:44
|
|
|
A shader based solution would probably be to store texture array layer with the UV coordinates, and change the layer for the affected vertices when you need the different texture.Sedgr posted:I'd be tempted to just stick a quad or plane over that face and give it a separate texture. Would simplify things to some extent. Be careful to put it over the face and not on it though, or you'll get some Z-fighting artefacts if you go with this technique. And at a distance that will be inevitable. I am prone to recommend this solution though, rather than making a new shader just for this one object. That is also very similar to how some people do celshading, where they'll redraw geometry slightly larger, color it black and do front face culling in stead of back face culling. Joda fucked around with this message at 18:57 on Oct 13, 2019 |
|
#
?
Oct 13, 2019 18:50
|
|
|
Joda posted:Be careful to put it over the face and not on it though, or you'll get some Z-fighting artefacts if you go with this technique. And at a distance that will be inevitable. I am prone to recommend this solution though, rather than making a new shader just for this one object.
|
|
#
?
Oct 13, 2019 18:58
|
|
|
Yeah I really meant replace the face with the quad rather than place it directly over the face but I think the general idea came across.
|
|
#
?
Oct 13, 2019 19:48
|
|
|
The idea is to instance these things and adding additional quads like that would run up the draw count since they'd be new meshes (and in the real version it might be more like 8 faces per mesh, not just one; theoretically I could pull off just those parts into a separate mesh but ugh). Switching the texture at runtime might work, I don't need nearly as many of these as I thought I did so it won't need an obscene amount of memory like I was worried it might. Joda posted:A shader based solution would probably be to store texture array layer with the UV coordinates, and change the layer for the affected vertices when you need the different texture. I kind of want to try this just to say I did, though, since this is largely just an excuse for me to learn stuff and I have no idea how to do that yet.
|
|
#
?
Oct 13, 2019 21:24
|
|
|
An extra draw call for an extra material is fine. I don't quite understand what exactly you're trying to do, but for a first pass, that's OK. For a second pass, use two texture slots and some extra vertex attribute (e.g. red channel in vertex colors) to blend between them. That's the more optimized approach.
|
|
#
?
Oct 14, 2019 17:14
|
|
|
That post finally made some bell ring in my head for how shaders actually do their thing. It was surprisingly easy to emit a second texture containing the animation data and then use that as another input to the shader. I can guarantee the animated textures are all in a row and the frames are all the same size, so all I need is the width of each frame and how many there are total. Now I just need to get the math right (doing this all in floating point is hurting my head) but it actually did roughly what it was supposed to, which is pretty sweet given I've never tried to actually write one of these things before this evening. Thank you all!
|
|
#
?
Oct 15, 2019 04:20
|
|
|
Optimization and weird syntax/architecture/framework footguns aside, shaders are pretty straightforward even when you get slightly more complex than what you're doing. The primary way you need to break your brain to get them working property is just to invert the usual thinking of "I have a <thing>, where do I put it?" and instead frame it as "if I'm at this spot, what am I going to put here?" When I say inversion I mean it, when you write an effect in-shader you tend to actually invert functions a lot compared to the typical "forward" way of modelling something you'd do in, say, a simulation. Again, this is putting aside optimizations, dumb things like "oh I guess this variable name is actually a reserved keyword but only on AMD because ???" (lol glsl), whole-pipeline things like lighting and shadows, and galaxy brain tier engineering feats like ubershaders... but it'll get you surprisingly far as far as '"I want to make a simple effect happen" goes.
|
|
#
?
Oct 15, 2019 05:15
|
|
|
Linear Zoetrope posted:Optimization and weird syntax/architecture/framework footguns aside, shaders are pretty straightforward even when you get slightly more complex than what you're doing. The primary way you need to break your brain to get them working property is just to invert the usual thinking of "I have a <thing>, where do I put it?" and instead frame it as "if I'm at this spot, what am I going to put here?" When I say inversion I mean it, when you write an effect in-shader you tend to actually invert functions a lot compared to the typical "forward" way of modelling something you'd do in, say, a simulation. Again, this is putting aside optimizations, dumb things like "oh I guess this variable name is actually a reserved keyword but only on AMD because ???" (lol glsl), whole-pipeline things like lighting and shadows, and galaxy brain tier engineering feats like ubershaders... but it'll get you surprisingly far as far as '"I want to make a simple effect happen" goes. I never thought about it that way, but I guess that's kinda true. Its almost like functional programming, where you start with where pixel_color = ... and you derive it functionally instead of imperatively. Not exactly, but kinda. The thing for me is just remembering that whatever you're writing is going to be executed like 2~4 million times in parallel all at once. Under those conditions of insane hyper-threading, things that would be "inefficient" in a single-threaded CPU renderer become the right way to do things. But like you said, most of it is pretty simple and its just the extreme "how do I optimize this" or "how syntax for GPU" that you end up fighting with usually.
|
|
#
?
Oct 15, 2019 05:34
|
|
|
Went through another one of those phases where I work really hard on a project, coding and making assets a couple hours a day and even thinking about ideas while I'm driving or trying to fall asleep. Keeping a notebook handy and taking notes in a Google doc. I do this everyday for a few weeks until I end up doing maybe an hour of work on the project every OTHER day and then I just...stop. And by stop, I mean i find myself forgetting about it and and not launching Unity for months. Collaborating with someone else on something would probably encourage me to stick with it but I am self-taught and do this all in my free time so 'd feel like a dead weight. Working with friends would be ideal but none of my friends are interested in this kind of stuff at all. I've done this many times over the years but it's a real bummer every time it happens. Unperson_47 fucked around with this message at 07:41 on Oct 15, 2019 |
|
#
?
Oct 15, 2019 07:35
|
|
|
Zaphod42 posted:I never thought about it that way, but I guess that's kinda true. Its almost like functional programming, where you start with where pixel_color = ... and you derive it functionally instead of imperatively. Not exactly, but kinda. I figured it out fairly early, because one of the first projects I ever did was write a simple software renderer for a rotating bitmap image (no it wasn't on some computer where that was relevant or anything it was with glSetPixel and non-committal enough I even used glClear lol). It's actually a pretty good project for wrapping your head around this stuff early, and I recommend it even if I kind of gave the solution away. If you try and directly apply the rotation matrix to the image pixels you end up with holes and gaps when the image rotates, if you iterate over every screen pixel and do an inverse rotation to get the pixel to put there it works. This is really only because images are made up of discrete pixels and aren't continuous, if you were to do this with like a texture and simple polygon the interpolation would fix it for you for free, but it's a neat exercise. Regardless, as an early exercise it kind of motivates how fragment/pixel shaders work, since they basically do the same thing in massive parallel with some extra bookkeeping/optimization (fragment discarding, alpha blending etc). Obvious disclaimer that this is a trash way to write a real software renderer, and I'm slightly simplifying fragment shaders and such, it's just a neat toy exercise that can teach a surprising amount.
|
|
#
?
Oct 15, 2019 07:42
|
|
|
Unperson_47 posted:Went through another one of those phases where I work really hard on a project, coding and making assets a couple hours a day and even thinking about ideas while I'm driving or trying to fall asleep. Keeping a notebook handy and taking notes in a Google doc. I do this everyday for a few weeks until I end up doing maybe an hour of work on the project every OTHER day and then I just...stop. And by stop, I mean i find myself forgetting about it and and not launching Unity for months. 
|
|
#
?
Oct 15, 2019 08:32
|
|
|
Unperson_47 posted:Went through another one of those phases where I work really hard on a project, coding and making assets a couple hours a day and even thinking about ideas while I'm driving or trying to fall asleep. Keeping a notebook handy and taking notes in a Google doc. I do this everyday for a few weeks until I end up doing maybe an hour of work on the project every OTHER day and then I just...stop. And by stop, I mean i find myself forgetting about it and and not launching Unity for months. According to my whiteboard at home I've gone through this process 6 times this year. I've even been trying to keep my scope small recently, but if I get excited by an idea it's hard to not want to keep expanding and improving on it.
|
|
#
?
Oct 15, 2019 16:44
|
|
|
Yep. I have a similar issue where I start a project, figure out how to implement it, and then my interest drops off a cliff because mentally I've got the problem mostly figured out, so actually taking the project to completion just sounds like...work.
Sedgr fucked around with this message at 18:49 on Oct 15, 2019 |
|
#
?
Oct 15, 2019 18:46
|
|
|
|
| # ? May 12, 2024 13:31 |
|
|
Sedgr posted:Yep. I have a similar issue where I start a project, figure out how to implement it, and then my interest drops off a cliff because mentally I've got the problem mostly figured out, so actually taking the project to completion just sounds like...work. I've tried avoiding this situation by doing the boring poo poo work (like menus and junk) before I finish solving the interesting problem, but then I just get sick of the whole idea, so it doesn't help.
|
|
#
?
Oct 16, 2019 01:13
|
|