Game Development Megathread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Game Development Megathread

«‹›622 »

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

duck monster posted:

I've *really* been enjoying hacking around on Godot. Unity never clicked with me and Unreal doesn't work on my crusty old mac, though I find myself much more comfortable noodling about in Unreal C++ than I am in C#. The only really serious problem I've found so far is material importings a bit goofy though there are some projectes on to improve that (One of which is translating blender material nodes to godot shader nodes) and the navigation mesh implementation is trash. Cant be edited in the IDE, and the autogenerated one is next to useless [It creates a mesh for walking around on, uh, the roof of the map. Doesnt seem to like convex shapes. Apparently its being rewritten for Godot 4 but I dont know when thats out. But other than that, this things a blast. The 2D stuff is *super* cool though, and I'd argue possibly better than Unitys.The only thing its really lacking in that front is Unitys massive library of prefabs for kitbashing. But thats OK, I'd rather make my own assets anyway.

Godot has a few problems overall but I know what you mean. It feels so good. I just hope development doesn't fall off the rails they've got it pointed in a really good direction, and it does work.

# ? Sep 8, 2020 21:13

Adbot: ADBOT LOVES YOU

# ? May 13, 2024 08:13

Megazver: Jan 13, 2006

It kinda feels to me Godot is picking up steam. I get the same vibe from it as I did from Unity shortly before it really blew up.

Megazver fucked around with this message at 17:51 on Sep 9, 2020

# ? Sep 9, 2020 17:29

Corbeau: Sep 13, 2010; Jack of All Trades

ddiddles posted:

I need to rotate ParentB (the thin piece) using ChildB as the rotation point, and end up where ChildA and ChildB Z axis' are facing each other. Basically I'm trying to build a random generated world full of rooms and connecting hallways.

Thinking about this for a couple minutes, the logical steps I see are:

code:

// Create a rotation that will rotate ChildB to face the opposite of ChildA.
Quaternion difference = Quaterninon.FromToRotation(ChildB.transform.forward, ChildA.transform.forward*-1);  

// Rotate the ParentB object by the above amount.
ParentB.transform.rotation *= difference;

// Move ParentB to ChildA's position minus ChildB's offset from it's parent (accounting for parent object rotation).
ParentB.transform.position = ChildA.transform.position - (ParentB.transform.rotation*ChildB.transform.localPosition);

This should put the children in the same location, facing each other.

Normally I have to run my code and fix the explosions (and I'm only halfway through my morning coffee :v:

), so I'm not surprised if there are errors here, but the fundamental logic should work. The really cool practical thing about quaternions is being able to multiply them with both vectors and other quaternions in order to apply their rotation to the subject of the multiplication.

Corbeau fucked around with this message at 18:42 on Sep 9, 2020

# ? Sep 9, 2020 18:38

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

Megazver posted:

It kinda feels to me Godot is picking up steam. I get the same vibe from it as I did from Unity shortly before it really blew up.

I'm cautiously optimistic. It has a lot going for it, it's one of the first engines where it feels like a proper content creation tool for making games, and it's the first open source engine that's done a good job of focusing on the right development priorities... but it's still an uphill battle against 2 massively entrenched, well-funded commercial alternatives in a field that requires constant adaptation to stay relevant.

Supposedly its most popular use right now is gambling, something to do with the lack of usage restrictions.

# ? Sep 10, 2020 03:22

netcat: Apr 29, 2008

I gave godot a try recently but didnt really enjoy working with it, mostly due to the docs being pretty poor in places and the builtin map editor being a bit lackluster. I did like the scene graph concept though.

netcat fucked around with this message at 21:38 on Sep 10, 2020

# ? Sep 10, 2020 19:20

Catgirl Al Capone: Dec 15, 2007

Godot has a UI and workflow that is very easy to understand quickly and jot out something bare-bones even if sometimes there are still frustrations when you fiddle with the details in GDScript. My one big annoyance was that I don't like the interface for tilemaps, I like the RPG Maker and Tiled style where you have your tileset laid out tightly packed together like it's a palette.

# ? Sep 10, 2020 20:19

Megazver: Jan 13, 2006

I've heard this is pretty good and importable into Godot:

https://led.itch.io/tilesetter

But yeah, they need to work on their tile editor, it's janky.

# ? Sep 10, 2020 22:09

Raenir Salazar: Nov 5, 2010; College Slice

So currently I'm struggling a lot with layered noise for procedural terrain generation.

Primarily because when I think "layered" I mean taking say two different noise results and then combining them like a photoshop layer. However google has layered noise most closely associated with octaves. I got octaves for making procedural noise, but if I have one layer be of ridged noise, and another layer be my simplex noise I wanted to combine them together so my simplex noise result combined with the ridged noise result to have more ridged looking mountains.

All of the layers get calculated per point like so (Borrowed from Sebastian Lagues tutorials):

code:

    public float CalculateUnscaledElevation(Vector2 pointOnMap)
    {
        float firstLayerValue = 0;
        float elevation = 0;

        if (noiseFilters.Length > 0)
        {

            firstLayerValue = noiseFilters[0].Evaluate(pointOnMap, width, height);
            if (shapeSettings.noiseLayers[0].enabled)
            {
                elevation = firstLayerValue;
            }
        }

        for (int i = 1; i < noiseFilters.Length; i++)
        {            
            if (shapeSettings.noiseLayers[i].enabled)
            {
                float mask = (shapeSettings.noiseLayers[i].useFirstLayerAsMask) ? firstLayerValue : 1;
                elevation += noiseFilters[i].Evaluate(pointOnMap, width, height) * mask;
            }
        }
        
        elevationMinMax.AddValue(elevation);
        return elevation;
    }

And then I scale the final result like so:

code:

    float[,] GenerateScaledHeightMap(float[,] unscaledHeightMap)
    {
        float[,] scaledHeightMap = new float[Width, Height];
        // normalize the value at each pixel from 0 to 1
        for (int i = 0; i < Width; i++)
        {
            for (int j = 0; j < Height; j++)
            {
                /*
                scaledHeightMap[i, j] = Mathf.InverseLerp(shapeGenerator.elevationMinMax.Min,
                                                    shapeGenerator.elevationMinMax.Max,
                                                    unscaledHeightMap[i, j]);
                                                    */
                scaledHeightMap[i, j] =
                    (unscaledHeightMap[i, j] - shapeGenerator.elevationMinMax.Min)
                    / (shapeGenerator.elevationMinMax.Max - shapeGenerator.elevationMinMax.Min);

            }
        }

        return scaledHeightMap;
    }

However my problem is that the ridged layer doesn't really "appear" all that well.

Example:

Generated Simplex Noise using "domain warping":

The above image but with a ridge layer added on:

My ridge layer+some of my settings:

So I can kinda see some ridges appearing, but probably due to the scaling or some other nature of the process it's not all that apparent. I'd ideally like a means of "strengthening" the effect of noise, but multiplying the returned height value by a strength value doesn't do anything.

If I maybe add to or multiply the post-scaling result I feel like it will blow out the contrast (and make large blobs of white where the mountains are) but scaling the result (so everything is between 0 and 1) seems to also heavily restrain my ability of making a particular layer standout more.

At the end of the day I presumably will have between 1 and some number, probably at most 4 layers, I am hoping for a solution that works for any n number of layers.

Currently it adds all layers together (possibly multiplied by the first layer as a form of mask). I am debating maybe separating the layers into their own individually scaled layers, and then reverse engineering photoshop blending algorithms and seeing if that gives a better result. Because if I output the layers individually and put them into Paint.net the results using its Blend layers *seem* like what I want, but is it what I want?

# ? Sep 10, 2020 23:17

xzzy: Mar 5, 2009

I think anything based on a noise function is going to be more trouble than its worth and will always have that too-random minecraft look.

My approach would be to identify the high points of your elevation map and play with a koch curve or an l-system or something to connect them. Or build a voronoi diagram out of the peaks to make ridges. Or maybe explore for an erosion function to build the mountains "properly." Your heightmap gives you a giant island of mud, now cut it up with some water.

# ? Sep 11, 2020 00:23

Raenir Salazar: Nov 5, 2010; College Slice

xzzy posted:

I think anything based on a noise function is going to be more trouble than its worth and will always have that too-random minecraft look.

My approach would be to identify the high points of your elevation map and play with a koch curve or an l-system or something to connect them. Or build a voronoi diagram out of the peaks to make ridges. Or maybe explore for an erosion function to build the mountains "properly." Your heightmap gives you a giant island of mud, now cut it up with some water.

There are a lot less resources and step by step tutorials for how to generate terrain with l-systems while simplex/perlin noise has at least a few really good video tutorials. An erosion function I imagine would be kinda slow so ideally I'd prefer this to be real time as the end result is something of a procedural world map generator mod thing for the Paradox Interactive series of games.

Using a voronoi map ala Red Blob Games is promising except for the fact that I want to output the final map as a series of textures to define provinces/terrain/climate in the format the Paradox games wants and the RBG article doesn't at a glance seem conducive to the desired workflow.

The noise map generation I have is mostly good enough, I just want to figure out how to fix the one thing I don't like about it, which is that I can't really seem to crank up the influence of one layer over the others in a way that's intuitive to me. So it seems like it would be a lot of work and a lot of risk to pursue a different method at this point, maybe that's sunk costs in action but I feel like the current results are like 80% to 90% there, another 5% and it's good enough.

# ? Sep 11, 2020 00:39

xzzy: Mar 5, 2009

Maybe one of the blend modes that photoshop/gimp can do on layers will work for you then. I think multiplication is your best bet but you're going to want to normalize the values in your textures so they don't clip, or expand the range beyond 255. Make the source texture relatively dark then multiply the ridges on top (maybe with a configurable boost) and it should amplify the effect.

But some of the other blend modes are worth considering. Divide or soft light are interesting.

# ? Sep 11, 2020 02:02

Raenir Salazar: Nov 5, 2010; College Slice

xzzy posted:

Maybe one of the blend modes that photoshop/gimp can do on layers will work for you then. I think multiplication is your best bet but you're going to want to normalize the values in your textures so they don't clip, or expand the range beyond 255. Make the source texture relatively dark then multiply the ridges on top (maybe with a configurable boost) and it should amplify the effect.

But some of the other blend modes are worth considering. Divide or soft light are interesting.

Yeah that's the approach I'm currently taking before I take another crack at L-systems, currently I am going to separate all of my Noise layers into their own scaled height maps and then try applying photoshop like blend operations on them.

I think another issue is that simply uniformly multiplying the height value of a pixel before scaling it of course will do nothing; I need to have the "strength" value somehow be different per pixel so it isn't uniform so that the "high" height values get shifted "higher" relative to the other pixels so that when I do scale it it actually results in a different result.

I nope'd hard out of L-systems originally because it seemed like it was mostly just a lot of scientific papers but nothing really oriented towards say someone who just wants to make something that works in Unity3D and I wanted to implement something a little more quickly; but I did find one approach that looks like I could implement in a manner similar to cellular automata on a 2D grid and potentially get results I want, but that can wait.

# ? Sep 11, 2020 02:29

xzzy: Mar 5, 2009

l-systems are super cool as long as you're okay with recursive functions. Not the only way to do them, but it's the most obvious. The code is a point in the grid making a choice on where to place the next point based on a set of rules (do I turn left? do I turn right? or go straight? or pick two and make a fork?) and then running that function again on whatever new points are generated. Real good for branching systems which is why it's so popular for tree generation.

But for making a ridge line you could make it a single loop that picks the angle towards some destination peak and randomizes that angle by some amount. It might make a convincing ridge.

# ? Sep 11, 2020 02:48

Raenir Salazar: Nov 5, 2010; College Slice

xzzy posted:

l-systems are super cool as long as you're okay with recursive functions. Not the only way to do them, but it's the most obvious. The code is a point in the grid making a choice on where to place the next point based on a set of rules (do I turn left? do I turn right? or go straight? or pick two and make a fork?) and then running that function again on whatever new points are generated. Real good for branching systems which is why it's so popular for tree generation.

But for making a ridge line you could make it a single loop that picks the angle towards some destination peak and randomizes that angle by some amount. It might make a convincing ridge.

I've also heard L-Systems perhaps might be good for things like specifying the number of "continents" a map might have, akin to Civ. Which is something natively a noise system can't do. My work around for that is to probably just generate a bunch of "continents" separately (suppose my game map is like 5,000 by 2,000 pixels, and if I want 8 continents I just generate islands in like a 500 by 500 area and then overlay them at random points of the map).

Do you happen to have any links handy as to be the definitive (preferably C#) scripting guide to L-systems for procedural generation? I mostly see things like generating trees when I google. So something geared towards terrain would be snazzy.

# ? Sep 11, 2020 02:56

xzzy: Mar 5, 2009

No, it's been like 10 years since I dug in to them. They aren't really good for terrain anyways in terms of generating a heightmap. They're just adaptable for any situation where you have a "I want to go from A to B with some number of twists and turns." So rivers and maybe mountains are good candidates.

# ? Sep 11, 2020 03:15

Raenir Salazar: Nov 5, 2010; College Slice

That's a shame! As L-Systems seem interesting. But maybe Voronoi regions might be better then as there seems to be a little more resources on the subject.

So anyways, as it turns out reinventing Photoshop Blend modes actually gives me interesting results!

Currently I've implemented Additive, Difference, Multiply, Divide, Screen, and Overlay. Normal just returns the "top" layer. Playing with them gives interesting results. I re-scale the resulting blend according to that blend's max/min values and this seems to generally work out well. Divide seems to give me all black, I am not sure if this is a bug or not, because if I don't normalize the divided result that I wouldn't think would be all black when scale so I suspect a bug.

Different/Additive and Multiply all give useful results.

Additive.

Difference.

Multiply (Above is with the fall off map applied)

Screen gives weird results, like underwater gas clouds.

Overlay is not too shabby but its contrast is too blown out at least with the current falloff map settings, I need to play with those more.

As it turns out Overlay with a better fall off map seems to look not bad:

e: Forgot divide, unscaled looks like this:

But when normalized becomes just black, so I don't think that's right.
fake edit: Stupid clipboard.

Raenir Salazar fucked around with this message at 06:58 on Sep 11, 2020

# ? Sep 11, 2020 06:42

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

With divide, you're going to have some huge values where a large number was divided by a very tiny one, and that's going to screw with your scaling. Try using a logarithmic normalisation instead of a linear one, or something like that.

# ? Sep 12, 2020 08:01

Raenir Salazar: Nov 5, 2010; College Slice

Jabor posted:

With divide, you're going to have some huge values where a large number was divided by a very tiny one, and that's going to screw with your scaling. Try using a logarithmic normalisation instead of a linear one, or something like that.

Wouldn't it be all white in that case? Because the "big numbers" are white pre-scaling.

# ? Sep 12, 2020 16:54

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

Raenir Salazar posted:

Wouldn't it be all white in that case? Because the "big numbers" are white pre-scaling.

The very biggest number is going to be white, but it's so much bigger than every other number (even the moderately-big ones) that using a linear scaling, the whole rest of the picture ends up black.

# ? Sep 12, 2020 17:27

Raenir Salazar: Nov 5, 2010; College Slice

Jabor posted:

The very biggest number is going to be white, but it's so much bigger than every other number (even the moderately-big ones) that using a linear scaling, the whole rest of the picture ends up black.

Yeah this seems very likely the case, my Min/Max values I thought were like -3.4 to 3.4 but it turns out that's -3.4......E+38 and +3.4.....+E+38. I did some googling about Logarithmic scaling but nothing entirely instructive has come up. Do you happen to have a handy link as to what I should do to sanitize my data here?

# ? Sep 12, 2020 19:35

Raenir Salazar: Nov 5, 2010; College Slice

So far I'm working on preventing the near infinity results.

code:

    static float[,] Blend_Divide(float[,] mapA, float[,] mapB, int width, int height, WorldMinMax blendMinMax)
    {
        float[,] blendedMap = new float[width, height];
        for (int i = 0; i < width; i++)
        {
            for (int j = 0; j < height; j++)
            {
                float b = mapB[i, j];
                float a = mapA[i, j];
                float v = 0;

                if (b < 0)
                {
                    b = Mathf.Min(-0.01f, b);
                }
                else if (b > 0)
                {
                    b = Mathf.Max(0.01f, b);
                }

                if (a < 0)
                {
                    a = Mathf.Log10(Mathf.Abs(a));
                    a *= -1;
                }
                else if (a > 0)
                {
                    a = Mathf.Log10(a);
                }

                // WHY IS THIS HAPPENING!? Somehow b is still zero or very near zero/epsilon?!
                if (Mathf.Approximately(b, 0.0f))
                {
                    b = 0.01f;
                    v = a / b;
                }
                else
                {
                    v = a / b;
                }                

                if (v < 0)
                {                    
                    v = Mathf.Log10(Mathf.Abs(v));
                    v *= -1.0f;
                }
                else if (v > 0)
                {
                    v = Mathf.Log10(v);
                }

                blendedMap[i, j] = v;
                blendMinMax.AddValue(v);
            }
        }

        return blendedMap;
    }

The new result is kinda interesting but I suspect isn't right.

It seems kind of like multiply but with way higher contrast.

The results when scaled are also fairly lacklustre.

# ? Sep 12, 2020 23:01

Stick100: Mar 18, 2003

OneEightHundred posted:

I'm cautiously optimistic. It has a lot going for it, it's one of the first engines where it feels like a proper content creation tool for making games, and it's the first open source engine that's done a good job of focusing on the right development priorities... but it's still an uphill battle against 2 massively entrenched, well-funded commercial alternatives in a field that requires constant adaptation to stay relevant.

Supposedly its most popular use right now is gambling, something to do with the lack of usage restrictions.

Makes sense, last I knew Unity was pretty huge in gambling. They offer a custom lisc. for gambling I have no idea how much it costs, but it's probably pretty expensive, while Godot would be free. Unities current lack of direction and constantly changing business model/IPO is probably terrifying for someone looking to put millions of dollars into development. While Godot while probably more challenging to startup/get devs has no counter party risk.

If I was looking to startup a gambling project with significant funding it would def. be a tough decision between the two even without knowing how much money Unity wants.

# ? Sep 14, 2020 16:47

more falafel please: Feb 26, 2005; forums poster

I imagine it would be much harder to get your stuff approved by the Nevada Gaming Commission/whatever similar entities if it's on an engine they're not familiar with. If you're using a binary Unity build they've already audited, it's probably much easier.

# ? Sep 14, 2020 17:21

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

quote:

// WHY IS THIS HAPPENING!? Somehow b is still zero or very near zero/epsilon?!

Uh, well, if b is exactly zero, then neither the (b < 0) nor (b > 0) checks will succeed, so it will remain zero...

OneEightHundred fucked around with this message at 20:09 on Sep 14, 2020

# ? Sep 14, 2020 20:06

duck monster: Dec 15, 2004

netcat posted:

I gave godot a try recently but didnt really enjoy working with it, mostly due to the docs being pretty poor in places and the builtin map editor being a bit lackluster. I did like the scene graph concept though.

Yeah they aren't perfect (although better than a lot of other Open Source things). I believe they've hired the guy who runs the GDQuest channel , which is *excellent* by the way, to run a project of getting the docs up to scrap.

I ended up doing the Udemy course by the gamedev.tv people which was excellent, although like a lot of those things theres a few hours of boredom packed in the start where they go over pretty basic stuff aimed at non programmers. The C# stuff is skippable, as that whole subsystem is a moving target right now, but the GDScript stuff is on point.

Re GDScript, I ..... actually like it..... its for the most part a python-like with a few changes around static typing and the like. The $<scene-tree-path> syntax is super useful, although it does reveal one weakness in the system around hardcoding scene paths into the script. But I found my python skills translated into a pretty immediate ability to just "get" what was going on.

The 3D system is definately weaker than its 2D system, however its still capable of visual fireworks, and the basics are all there (PBR metalness workflow, bone based animation, node based GLSL shader generator, baked and GI probe and Reflection probe lighting, etc) and theres a lot of stuff going into v4 that the authors claim will bring it up to snuff with UE4 although I'll have to see that to completely believe it.

For 2D games, this things a powerhouse however.

Actually my only real gripe is dividing by zero makes for INF rather than an exception or UNDEFINED. Which admittedly so do tonnes of other things, but my math brain still hates it, and I get that for certain categories of problem doing it this way is more performant than doing it correctly. I still hate it.

# ? Sep 18, 2020 04:43

duck monster: Dec 15, 2004

CYBEReris posted:

Godot has a UI and workflow that is very easy to understand quickly and jot out something bare-bones even if sometimes there are still frustrations when you fiddle with the details in GDScript. My one big annoyance was that I don't like the interface for tilemaps, I like the RPG Maker and Tiled style where you have your tileset laid out tightly packed together like it's a palette.

I hope they revisit this. The system they have is functional but theres some underlying flaws particularly with the 3D "gridmap" version. The 3D version produces a grid of 3D meshes, but not 3D 'scene' objects, meaning you cant attach animations or state, or things like Area probes or lighting or whatever. The idea is that for these you'd manually place them in the world, but its still a huge pain in the neck. My understanding is the current system is designed to improve batching for performance, and it is indeed very performant, but theres surely a compromise somewhere that would allow you to somehow say "Hey whenever theres a door, instantiate a door scene-object instead". I gather the 2D one is similar.

# ? Sep 18, 2020 04:49

Spatial: Nov 15, 2007

duck monster posted:

Actually my only real gripe is dividing by zero makes for INF rather than an exception or UNDEFINED. Which admittedly so do tonnes of other things, but my math brain still hates it, and I get that for certain categories of problem doing it this way is more performant than doing it correctly. I still hate it.

Incorrect: Following the floating point standard / maths in general
Correct: Emulating the hardware design of a 1970s pocket calculator

:v:

# ? Sep 18, 2020 13:17

Ghost of Reagan Past: Oct 7, 2003; rock and roll fun

duck monster posted:

Yeah they aren't perfect (although better than a lot of other Open Source things). I believe they've hired the guy who runs the GDQuest channel , which is *excellent* by the way, to run a project of getting the docs up to scrap.

I ended up doing the Udemy course by the gamedev.tv people which was excellent, although like a lot of those things theres a few hours of boredom packed in the start where they go over pretty basic stuff aimed at non programmers. The C# stuff is skippable, as that whole subsystem is a moving target right now, but the GDScript stuff is on point.

Re GDScript, I ..... actually like it..... its for the most part a python-like with a few changes around static typing and the like. The $<scene-tree-path> syntax is super useful, although it does reveal one weakness in the system around hardcoding scene paths into the script. But I found my python skills translated into a pretty immediate ability to just "get" what was going on.

The 3D system is definately weaker than its 2D system, however its still capable of visual fireworks, and the basics are all there (PBR metalness workflow, bone based animation, node based GLSL shader generator, baked and GI probe and Reflection probe lighting, etc) and theres a lot of stuff going into v4 that the authors claim will bring it up to snuff with UE4 although I'll have to see that to completely believe it.

For 2D games, this things a powerhouse however.

Actually my only real gripe is dividing by zero makes for INF rather than an exception or UNDEFINED. Which admittedly so do tonnes of other things, but my math brain still hates it, and I get that for certain categories of problem doing it this way is more performant than doing it correctly. I still hate it.

I've started loving around with Godot and GDScript seems fine but I also can't really figure out a good way to write inheritable facades and interfaces that can put the $scene-tree-path syntax behind a more stable interface. As a Python developer professionally it mostly clicks but I'm kind of annoyed by this. Does C# for Godot have this same quirk/flaw? Not sure why they didn't opt for straight Python though, would probably have worked just fine.

# ? Sep 18, 2020 13:20

Catgirl Al Capone: Dec 15, 2007

Ghost of Reagan Past posted:

I've started loving around with Godot and GDScript seems fine but I also can't really figure out a good way to write inheritable facades and interfaces that can put the $scene-tree-path syntax behind a more stable interface. As a Python developer professionally it mostly clicks but I'm kind of annoyed by this. Does C# for Godot have this same quirk/flaw? Not sure why they didn't opt for straight Python though, would probably have worked just fine.

The syntax is extremely similar but the similarities end abruptly there. GDScript is designed very specifically for the domain of interfacing with the Godot engine.

# ? Sep 18, 2020 13:38

Troutpack: Dec 29, 2008; He wants to watch him suffer.

duck monster posted:

I hope they revisit this. The system they have is functional but theres some underlying flaws particularly with the 3D "gridmap" version. The 3D version produces a grid of 3D meshes, but not 3D 'scene' objects, meaning you cant attach animations or state, or things like Area probes or lighting or whatever. The idea is that for these you'd manually place them in the world, but its still a huge pain in the neck. My understanding is the current system is designed to improve batching for performance, and it is indeed very performant, but theres surely a compromise somewhere that would allow you to somehow say "Hey whenever theres a door, instantiate a door scene-object instead". I gather the 2D one is similar.

I think the general advice is to write a script that checks which tile/mesh is placed in a certain point of the grid and then create instances during runtime. Or you can make a tool script that places the nodes for you in the editor. It can be a bit cumbersome, for sure, but there are ways around placing stuff manually.

# ? Sep 18, 2020 13:44

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

duck monster posted:

it does reveal one weakness in the system around hardcoding scene paths into the script.

The way I dealt with this when messing with it was pull the strings from attributes instead, which I think you can use metadata to make the editor treat the attribute as a reference to another scene object in the UI. I'd have to dig up the example though, it's been a while.

# ? Sep 18, 2020 16:29

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

I wanted to post about something that's pretty contextual and unique but I've avoided it because of that, and because I'm not really fishing for any one particular thing. The basic thing of starting the game, entering the game, ending the game, and moving around these states with things like pausing and inventory GUI management has caused a bunch of bugs after not maintaining that for a long time. The way everything is composed so distributed is normally nice but all kinds of hell with timing and state come up when you have to grab them all by the face and say, "the game is over." I'm half rubber ducking here and half just seeing how other people dealt with this complexity. I'm not really looking for a solution since I think I'm not really stuck.

Some examples of problems I've had:
1. Starting from a blank starting screen no longer worked due to assumptions of starting in a level that all my subsystems were set up to do. I'll give two fun examples here. First, my player programmer art rectoid would get spawned on the title screen and fall through the world because the subsystems expect a player and make one. The second, less fun example are classic Unity null pointer exceptions in Start() in various places since I'm not showing a normal level.
2. Arresting control when the game ends (whether a game over or a good end or whatever). First the player would be moving after game over. Whoops. Then I could save the game after a game over, so I had to add logic to prevent that.
3. Starting a new game from a game over. Having solved #2 suddenly you to starting a new game and the player isn't moving because control is still arrested from #2. Or after restarting, the save button is still disabled.

I'm generally unimpressed with the scattered conditional logic I've had to put in various places. It all looks like a state machine but implementing one doesn't really do anything. In my case, a lot of the problems and solutions look like they come down to finally standardizing these subsystems I've been making. I'm not doing a formal ECS thing; I basically just have a stash of classes with the suffix "Subsystem" that don't particularly implement any common thing stashed under a global GameObject that is set not to be destroyed between scenes.

For #1, I'm thinking it's time I formalized all these subsystems I'm putting into global state so I can give them a hook to initialize with some context. I already had a bug from a subsystem not starting up since it's put under a GameObject that starts disabled (GUI related). Having a hook into all of the subsystems for initializing at the start would have fixed that.

# ? Sep 18, 2020 16:57

FuzzySlippers: Feb 6, 2009

I think good Unity game organization is all about limiting your GOs and monos. That doesn't mean avoiding them entirely, but I try to limit them to just art/fx/level related scripts like making a ParticleSystem easily accessible. Actual config data is better stored on ScriptableObjects and you can also pipe debugging logic to them if you want a nice easy way to check things that aren't a mono. SOs also get rid of the oops am I in play mode and lost my changes problem of GOs since their data persists. With silo'd mono and GOs its a lot easier to handle errors related to them.

Like a more full ECS approach avoids some of the problems you describe but importantly none of these things should be Unity gameobjects or mono scripts. You can have component data that is pulled from a gameobject, but none of the Systems or important stuff should be mono scripts that need to be stuck on a gameobject that's marked as DontDestroy. That helps with loading issues because you can easily have your entire System setup completed immediately when play starts and can't get stuck in some goofy position because of scene loading hick ups or disabled GOs.

I also find that explicit state machines handle some of the GameController kind of logic and I think a fall through stack works well. You have a very basic controller on the bottom and you pile states on top and when one is removed it falls to the one below. It gets rid of your MenuController needing to tell gameplay systems to stop working their logic (though a universal GamePause that isn't tied to Unity time functions is useful here too). This was especially important for my game that is strongly modal because when combat is ending we might be returning to the overworld or an exploration map or some dialogue event. The combat controller just removes itself when done and it falls to whatever is below. I was doing that with an event bus but there was some messiness I cleaned up when it went state.

# ? Sep 19, 2020 00:41

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

Yeah I have to agree with you about purging the GameObjects used just for the sake of subsystems. I'm going to end up chewing on the refactor revolving around formalize subsystems to kill GameObjects for awhile.

This is the part where we make that joke about improving one's Unity project by removing as much Unity stuff from it as possible.

# ? Sep 19, 2020 18:34

Fashionable Jorts: Jan 18, 2010; Maybe if I'm busy it could keep me from you

Sorry in advance if this question has been asked a dozen times already. I'm looking at working on a game idea I've had rolling around in my head for some time now, a third-person shooter with some rpg elements. I know practically nothing about coding, but am currently going through some tutorials.

The question I have, is which engine should I use? I'm deciding between Unity and Unreal, since those seem to be the big ones with a lot of assets and support available. Graphics are of little importance to me, since I know I won't be doing anything fancy for some time, but one of my objectives in the game is large groups of enemies (I'm talking about hundreds at a time). Is one significantly easier for new people who are learning as they design?

Edit: from what I've heard Unity uses C# which is much friendlier than Unreal's C++, but unreal seems to have a lot of drag-and-drop basic stuff to skip most basic programming needs.

# ? Sep 20, 2020 18:08

Zaphod42: Sep 13, 2012; If there's anything more important than my ego around, I want it caught and shot now.

Fashionable Jorts posted:

Edit: from what I've heard Unity uses C# which is much friendlier than Unreal's C++, but unreal seems to have a lot of drag-and-drop basic stuff to skip most basic programming needs.

Yep, that's literally what I was typing. They're similar engines in some ways but C# is easier to work in, but also as you said both engines have ways to get a lot done with little or no custom coding. I know Unity has a visual scripting system, and a ton of free or marketplace code you can reuse.

# ? Sep 20, 2020 18:13

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

Fashionable Jorts posted:

Edit: from what I've heard Unity uses C# which is much friendlier than Unreal's C++, but unreal seems to have a lot of drag-and-drop basic stuff to skip most basic programming needs.

My impression of the two (which might be a couple years out of date) is that Unity is more friendly to people who don't already have a programmer way of thinking of things, but also Unity tends to lead to situations where it's quite easy to get something that kinda mostly works how you want but is really hard to figure out what's wrong, whereas Unreal's approach means you have to learn to use it properly, which is harder, before you get anything, but as a consequence you're less likely to be unwittingly burying yourself in a pile of garbage.

(If you *do* already have a programmer way of thinking of things then Unity will keep getting in your way and is really annoying, and you should choose Godot even for 3D which still isn't its forte.)

# ? Sep 20, 2020 22:36

xzzy: Mar 5, 2009

Unity also has that critical mass where you can google search almost every problem and find the fix. But I think the suite is a disaster, they relentlessly hype up amazing new features that are in beta for two more years and don't work with any of their other new features. So it's really drat hard to figure out best practices.

But if you just wanna make a simple platformer or whatever you might never run into those issues.

UE always feels too AAA when I fire it up. I just got no loving clue what to do with any of it.

(I'd go with Godot)

# ? Sep 20, 2020 23:08

Raenir Salazar: Nov 5, 2010; College Slice

I am taking a crack at Voronoi diagrams, I have found a library, Triangle.net that despite its utter lack of documentation or tutorials online I have managed with some trial and error managed to figure out everything I need to do, almost.

Unbounded voronoi looks like this

Bounded voronoi looks like this

However my hack so far is to manually add four points for the corners

However I feel like since the corner vertices are also acting as "sites" I think it might be messing with the voronoi diagram. Ideally I'd basically like it to draw like a box around the outer edge accounting for the corners without needing the actual corners. Any ideas for anyone who used the library before?

I'd basically like unbounded voronoi with a square/rectangular outline and then rely on better site distribution to avoid the weird looking alleys going to the edge in the unbound version.

Another example here, as we see the corners are little weird.

Raenir Salazar fucked around with this message at 00:15 on Sep 21, 2020

# ? Sep 21, 2020 00:01

Adbot: ADBOT LOVES YOU

# ? May 13, 2024 08:13

dupersaurus: Aug 1, 2012; Futurism was an art movement where dudes were all 'CARS ARE COOL AND THE PAST IS FOR CHUMPS. LET'S DRAW SOME CARS.'

roomforthetuna posted:

My impression of the two (which might be a couple years out of date) is that Unity is more friendly to people who don't already have a programmer way of thinking of things, but also Unity tends to lead to situations where it's quite easy to get something that kinda mostly works how you want but is really hard to figure out what's wrong, whereas Unreal's approach means you have to learn to use it properly, which is harder, before you get anything, but as a consequence you're less likely to be unwittingly burying yourself in a pile of garbage.

(If you *do* already have a programmer way of thinking of things then Unity will keep getting in your way and is really annoying, and you should choose Godot even for 3D which still isn't its forte.)

Unity is a perfectly fine programmer�s platform. The problem with Unreal is that you�ve got 1) blueprints (which are fine) or 2) super custom and idiosyncratic C++ (which gently caress that)

# ? Sep 21, 2020 00:07

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Game Development Megathread

«‹›622 »