Game Development Megathread

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

«‹›623 »

Mata: Dec 23, 2003

Suspicious Dish posted:

Assuming you're drawing the same number of primitives you can use glVertexAttribDivisor to advance vertex attribs per-divisor but it sounds like that's not what you want. Consider glMultiDrawElementsIndirect if you're afraid of CPU draw call overhead but that won't let you rebind textures between.

How do you handle separate model/bone matrices between the draws? Do you just not have any animation in your game?

I try to get by with rigid body animations, so that amounts to updating the animating instance matrices on the CPU then sending those over. I think if I were doing this with real animations I would look up the bone matrices from a UBO or something. I imagine it would then be hard to have models that are playing different animations to share the same draw call, but that's a very hypothetical problem for me right now.
If I understand glMultiDrawElementsIndirect, that's pretty much what I'm looking for. My textures are typically pretty small (512x512), i imagine a graphics card that has support for glMultiDrawElementsIndirect is also gonna support texture sizes around 8192, and I can fit pretty much my entire scene's worth of textures into that.

# ? Dec 13, 2018 21:02

Adbot: ADBOT LOVES YOU

# ? May 26, 2024 00:52

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Sounds good then! Try using a texture array for the scene textures instead of an atlas so that you don't see filter artifacts around the edges

# ? Dec 13, 2018 21:31

KillHour: Oct 28, 2007

j.peeba posted:

I don’t recall that Steam has that rule specifically in their terms. I do know that Valve strives actively towards what they call fair treatment of their customers though but then again that’s not unique to Valve either.

I'll just keep it on permanent "sale" then. Nothing wrong with a sale. :colbert:

# ? Dec 13, 2018 22:12

Brownie: Jul 21, 2007; The Croatian Sensation

I'm writing a little renderer using bgfx, and I'm wondering what an appropriate way to abstract/model different "Materials" (the data associated with uniforms in my shader program per mesh/entity). I've tried to avoid using polymorphism + RTTI since I'm trying (perhaps stupidly) to do things the "Data Oriented Design" way, and not use inheritance + pointers since that will make it hard/impossible to ensure data locality. I get that trying to apply DOD for my toy rendered is probably stupid and unnecessary but I think this is defensible...

I don't know how to model the uniform data that's going to be associated with each entity if each shader program expects different uniforms. Currently I just have different structs for each Material, and a generic "Mesh" object that accepts the material class as a template arg, but this means that the Entity (which is associated with the Mesh) is also going to have to care about this. One approach I thought of is just having different arrays for the different types of materials and referencing them by index, but that's also not really going to enable data locality... unless the loop that issues draw calls is moving through arrays sorted by material type.

Right now I'm tempted to just say "gently caress it" and just ignore preserving the data locality for these "material" objects, but before I did that I wanted to see if I was a) making things way too complicated for myself or b) missing something totally obvious.

# ? Dec 14, 2018 02:46

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Welcome to designing and building a material pipeline.

It depends on what you want your artists and VFX people to author in. If you want them to author in shading language, you'll need some way to parse out the shading language and get its input parameters (or match them up in the engine). If you can do this in a shader graph, you can generate the inputs and outputs and parameters yourself.

As much as you can, standardize on inputs and outputs, and only allow customizing through hooks you integrate in your base shaders. So, for a vertex shader, you might have bone matrices and a VP matrix in your uniforms, and that's basically it. Your hook might be allowing pre-bone and post-bone modifications of the vertex position.

In some of my work, I have a cbuffer/UBO named "cb_MaterialVertexParams" which contains all of the artist-controlled parameters special to that material. My shader compiler looks for a buffer of that name, re-packs the cbuffer/UBO for the target platform, and generates reflection data and controls engine-side. So when that material is chosen, those UBOs can be hooked up. Engine just fills in the data in the cbuffer in the right offsets, and it works.

This is divorced from "cb_EngineVertexParams" which contains bone/VP.

It's never *that* clean in practice, and I have several hacks littered throughout, but that's the basic gist.

How this works with bgfx, I don't know. I find that abstraction layers like that mostly get in my way, so I try to avoid them.

# ? Dec 14, 2018 03:10

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

Epic Store influences developers to pull Steam releases

quote:

Some game developers are pulling their upcoming releases from the Steam page entirely, or choosing to make their titles a timed exclusive with the Epic Games Store.

This comes after Valve announced last month that they're changing up the revenue share rates on the Steam storefront, with the new system introducing a 25 percent (as opposed to the common 30 percent) cut on any revenues a game generates beyond $10 million.

It will be pretty interesting to see if other developers follow suit, considering how the Epic Store only takes a 12 percent cut from game sales.

# ? Dec 14, 2018 13:21

Absurd Alhazred: Mar 27, 2010; by Athanatos

https://twitter.com/abhinav_Demkeys/status/1073523972195737600

Might be useful for the Unity devs here.

# ? Dec 14, 2018 15:21

Nude: Nov 16, 2014; I have no idea what I'm doing.

Absurd Alhazred posted:

https://twitter.com/abhinav_Demkeys/status/1073523972195737600

Might be useful for the Unity devs here.

Wow this is really cool. If I understand it correctly, it could be very useful for quick debugging.

# ? Dec 15, 2018 05:49

Brownie: Jul 21, 2007; The Croatian Sensation

Suspicious Dish posted:

Welcome to designing and building a material pipeline.

It depends on what you want your artists and VFX people to author in. If you want them to author in shading language, you'll need some way to parse out the shading language and get its input parameters (or match them up in the engine). If you can do this in a shader graph, you can generate the inputs and outputs and parameters yourself.

As much as you can, standardize on inputs and outputs, and only allow customizing through hooks you integrate in your base shaders. So, for a vertex shader, you might have bone matrices and a VP matrix in your uniforms, and that's basically it. Your hook might be allowing pre-bone and post-bone modifications of the vertex position.

In some of my work, I have a cbuffer/UBO named "cb_MaterialVertexParams" which contains all of the artist-controlled parameters special to that material. My shader compiler looks for a buffer of that name, re-packs the cbuffer/UBO for the target platform, and generates reflection data and controls engine-side. So when that material is chosen, those UBOs can be hooked up. Engine just fills in the data in the cbuffer in the right offsets, and it works.

This is divorced from "cb_EngineVertexParams" which contains bone/VP.

It's never *that* clean in practice, and I have several hacks littered throughout, but that's the basic gist.

How this works with bgfx, I don't know. I find that abstraction layers like that mostly get in my way, so I try to avoid them.

Hmmm this is something I didn't think about at all, but feels like an enormous project in and of itself. It made me realize how naive my hard coded set of materials + shaders system is!

Fortunately, I think for my purposes, hard coded shaders will work just fine. I've also decided I will be saying "gently caress it" and using ABC + pointers to let me use different material types.

You're right about bgfx. It provides an abstraction on the platform-specific APIs but that also means transpiling shaders and the lack of any sort of DX12/Vulkan style resource binding model for shader resources.

Thanks for the help!

# ? Dec 18, 2018 02:03

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

xzzy posted:

Epic is gonna trigger some kind of reckoning. Either Steam has been taking way too much money and they've got a Scrooge McDuck sized money bin somewhere, or Epic is taking way too little money and they're going to put themselves out of business trying to undercut.

The truth is probably somewhere in the middle but it's going to be an interesting 2019.

The reckoning has already been triggered, Epic is just kind of being louder about it. The doom scenario for Steam isn't that some big competitor comes along, it's that the distribution ecosystem becomes so fragmented that people decide that it doesn't matter where they get their games, because that's the point where everyone that can operate a store drops Steam and everyone that can't starts shopping around.

Third-party sites like itch.io and GOG have become more prominent, Discord announced their own store, most major online PC games had already switched to their own storefront+launcher, most of the major publishers are already operating their own stores, EA bailed completely a while ago, and Activision has started bailing as they shift their catalog over to Battle.net.

The other facet is that Steam is so oversaturated now that it's been doing less and less for the promotion of games, which has become the big bottleneck to selling them, and the more that developers rely on other avenues to promote the game, the less it matters where the game is sold.

One thing that could really throw a wrench in things is if Unity follows suit and creates their own store.

OneEightHundred fucked around with this message at 17:36 on Dec 18, 2018

# ? Dec 18, 2018 07:55

Stick100: Mar 18, 2003

OneEightHundred posted:

One thing that could really throw a wrench in things is if Unity follows suit and creates their own store.

Oh god, that sounds like a terrible idea! I bet someone is working on it right now.

# ? Dec 18, 2018 18:03

TooMuchAbstraction: Oct 14, 2012; I spent four years making
Waves of Steel
Hell yes I'm going to turn my avatar into an ad for it.; Fun Shoe

Stick100 posted:

Oh god, that sounds like a terrible idea! I bet someone is working on it right now.

Galaxy brain: put the store on the Unity asset store as an asset so anyone can buy it and set up their own digital distribution store. All you'd need is a few text fields for your cloud server API of choice and your payments handler!

# ? Dec 18, 2018 18:30

BabelFish: Jul 20, 2013; Fallen Rib

TooMuchAbstraction posted:

Galaxy brain: put the store on the Unity asset store as an asset so anyone can buy it and set up their own digital distribution store. All you'd need is a few text fields for your cloud server API of choice and your payments handler!

Only interested if I can run my Unity asset store store on top of Epic's new backend services.

# ? Dec 19, 2018 00:35

jizzy sillage: Aug 13, 2006

Does anyone know a rough and easy "importing JSON into Unity" guide?

I've got something working that will create Unity objects from data in a JSON file, but I'd like to have many objects in one file and turn those into a List<> of said objects.

edit: reading more, this seems like a more complex question than I'd originally thought, and people have made paid assets that solve it? I think this is a problem to come back to when I've learned more C#.

jizzy sillage fucked around with this message at 03:10 on Dec 19, 2018

# ? Dec 19, 2018 02:23

Monoclinic: Dec 10, 2005

jizzy sillage posted:

Does anyone know a rough and easy "importing JSON into Unity" guide?

I've got something working that will create Unity objects from data in a JSON file, but I'd like to have many objects in one file and turn those into a List<> of said objects.

edit: reading more, this seems like a more complex question than I'd originally thought, and people have made paid assets that solve it? I think this is a problem to come back to when I've learned more C#.

I was working on this issue myself recently. Unity has a built-in JSON serializer, but I couldn't get that to work with my JSON file. Instead, I just used the free JSON.net for Unity asset (https://assetstore.unity.com/packages/tools/input-management/json-net-for-unity-11347). My JSON-parsing code was this:

code:

    void ReadJSON()
    {
        stuffDataPath = Application.streamingAssetsPath + "/stuff.json";		// set the path of the JSON file
        using (StreamReader r = new StreamReader(stuffDataPath))			// create a new StreamReader and point it to the JSON file
        {
            JsonSerializer serializer = new JsonSerializer();				// create a new JSON serializer
            stuff = (List<Stuff>)serializer.Deserialize(r, typeof(List<Stuff>));	// invoke the reader to deserialize the JSON file into the elements list
        }
    }

This requires use of System.IO and Newtonsoft.Json namespaces. As long as your Stuff object has properties that match the names of the fields in the JSON file, it will populate the list with the objects you have in there. In my case the JSON file was wrapped with [ and ], i.e. the whole thing was an array of json objects.

# ? Dec 19, 2018 04:12

jizzy sillage: Aug 13, 2006

Monoclinic posted:

I was working on this issue myself recently. Unity has a built-in JSON serializer, but I couldn't get that to work with my JSON file. Instead, I just used the free JSON.net for Unity asset (https://assetstore.unity.com/packages/tools/input-management/json-net-for-unity-11347). My JSON-parsing code was this:
code:
    void ReadJSON()
    {
        stuffDataPath = Application.streamingAssetsPath + "/stuff.json";		// set the path of the JSON file
        using (StreamReader r = new StreamReader(stuffDataPath))			// create a new StreamReader and point it to the JSON file
        {
            JsonSerializer serializer = new JsonSerializer();				// create a new JSON serializer
            stuff = (List<Stuff>)serializer.Deserialize(r, typeof(List<Stuff>));	// invoke the reader to deserialize the JSON file into the elements list
        }
    }
This requires use of System.IO and Newtonsoft.Json namespaces. As long as your Stuff object has properties that match the names of the fields in the JSON file, it will populate the list with the objects you have in there. In my case the JSON file was wrapped with [ and ], i.e. the whole thing was an array of json objects.

Okay, rad, I'll give it a shot later. Thanks very much.

# ? Dec 19, 2018 04:46

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

jizzy sillage posted:

Does anyone know a rough and easy "importing JSON into Unity" guide?

I've got something working that will create Unity objects from data in a JSON file, but I'd like to have many objects in one file and turn those into a List<> of said objects.

edit: reading more, this seems like a more complex question than I'd originally thought, and people have made paid assets that solve it? I think this is a problem to come back to when I've learned more C#.

Oh hey! My theme music started playing!

I rolled my own that I'm not too keen on trying to distribute; the bridging between the standalone code and Unity is fiddly all by itself. Turning a bunch of Unity objects into JSON is far from the hard part in this entire topic. Heck, I think Unity itself can just vomit the whole scene like that, right? But allow me to regale you with some situations to consider that I have paid for in blood already:

Do you want to save multiple scenes?
If supporting multiple scenes, how are you arbitrating data between them?
How do you contrast loading a new scene in an ongoing game versus loading a save?
Have you considered what this might look like if you are already in the game and want to load a new one?
Do you intend to serialize everything?
If so, do you intend to write custom serializers for all of the built-in Unity bits?
If so, have you thought about what it might look like to save the current bit of animation pose something is in so you can reload it?
If not, have you thought about the chance for exploits or such from loading a state that isn't quite what was actually saved?
If you're only serializing part of the data, how do you remix everything together?
Do you plan to reuse some of the original scene data when loading a scene?
If so, have you considered what would happen if you destroyed a game object in the save and don't want it regenerated?
UGLY DEATH DOOM: To change a scene in Unity, you have to wait at least for the next frame, so you need to set up a hook to trigger the rest of your loading process after the scene change, possibly somewhere in the middle of the scene's (original) MonoBehaviours starting to turn out and crap on everything. This is fun!
Have you thought about saving your subsystem data too? I particularly have a timing subsystem with callbacks and yes, I save it. I know it has to be fixed up though because it'll try to fire events from the previous scene after a scene change.
Bonus paranoia: Have you thought about what it might look like if you trigger to save data in the middle of all your Update() calls and half of them haven't run for the current frame?

In very coarse terms, this is some of the stuff I did:
1. I created an API of customer serializers for all serializable MonoBehaviours that are scanned one first use and then assigned to each serializable MonoBehaviour. This is probably the tamest part of this whole thing.
2. I created a scene cache structure from temporary storage. When a scene change happens, the old scene is put in the cache.
3. Saving a game means copying the cache to the assigned save location.
4. Loading a game means loading the assigned location into the cache and changing to current scene to the cache's "active" scene.
5. I have additional metadata on some game objects to determine if they are local or global. Global objects include the player and are saved in a separate section. Global data can migrate between scenes. Local data cannot. So if a serializable, local gameobject is found when I load the original scene, but I have no data for it, that means it's gone. I had to add a mechanism to propagate global/local flag changes so if the player picked up or dropped an inventory item, it would stay or get carried accordingly.

I think I was told that Skyrim does something similar, and that's really a bad thing to say to a single developer here that wants to make a game instead of a serialization system.

Edit: Let's say your not as stupid as me and want to pare this waaay back. Some strong suggestions:
1. Use a fixed save data structure and just save very key bits
2. Save only at prescribed places or points

If you want to save whatever whenever then think about your life decisions first.

# ? Dec 19, 2018 05:13

jizzy sillage: Aug 13, 2006

Yeah, uh, holy poo poo. I only half learned what serialization even is today, so all of that is a long way down the line.

I have a JSON file that defines a bunch of items. I want to import that file, read it, and create a List<> containing those item definitions. I'd like the player (me) to be able to add new items to the bottom of the JSON file (while the game is closed) and have those then get added to the List<> of available items when the game is opened.

Currently the game doesn't exist, I'm just practicing a few different solutions to features I'd like to include (this one being the ability to add new items manually).

# ? Dec 19, 2018 05:58

Triarii: Jun 14, 2003

Unity's json deserializer has the peculiar limitation of not being able to read an array of objects at the root level of the json file. You can make it work by putting the array inside of another serialized object, like this:

code:

public class ItemReader : MonoBehaviour
{
    [System.Serializable]
    public class ItemList
    {
        public ItemEntry[] ItemEntries;

        [System.Serializable]
        public class ItemEntry
        {
            public string ID;
            public int Quantity;
            public float Durability;
            //whatever else you need to define an item
        }
    }

    void Start()
    {
        ItemList itemList = JsonUtility.FromJson<ItemList>(System.IO.File.ReadAllText("InputFile.json"));
    }
}

Then your json file would look something like this:

code:

{
    "ItemEntries": [
        {
            "ID": "Item1",
            "Quantity": 3,
            "Durability": 1.0
        },
        {
            "ID": "Item2",
            "Quantity": 1,
            "Durability": 0.8
        },
        {
            "ID": "Item3",
            "Quantity": 45,
            "Durability": 0.2
        }
    ]
}

You can also then save that ItemList object out to a json file pretty effortlessly:

code:

System.IO.StreamWriter stream = System.IO.File.CreateText("OutputFile.json");
stream.Write(JsonUtility.ToJson(itemList));
stream.Flush();
stream.Close();
stream.Dispose();

# ? Dec 19, 2018 06:27

jizzy sillage: Aug 13, 2006

Wow, that's cool! Turns out I was getting pretty close to that solution, so thanks very much for laying it out

# ? Dec 19, 2018 07:16

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

jizzy sillage posted:

Wow, that's cool! Turns out I was getting pretty close to that solution, so thanks very much for laying it out

Yeah if you're data and the points where you have to work with it are very regular, then the amount of shenanigans you have to undergo goes way down. You'll still have to worry about the scene transition if you have to load a new scene, and the timing problems that might arise from it. You're better off seeing what that's like early if you know you're going to be moving back and forth between scenes in Unity; some people don't even bother using Unity's scenes and just do everything within technically one scene.

# ? Dec 19, 2018 21:44

leper khan: Dec 28, 2010; Honest to god thinks Half Life 2 is a bad game. But at least he likes Monster Hunter.

Most things I�ve seen use additive scene loading.

# ? Dec 20, 2018 03:08

jizzy sillage: Aug 13, 2006

Is there a goon gamedev discord where I can ask short and stupid questions, like this one?

# ? Dec 20, 2018 10:27

Synthbuttrange: May 6, 2007

the goon game jam discord: http://discord.gg/UwXZtgJ

# ? Dec 20, 2018 11:53

jizzy sillage: Aug 13, 2006

Great, thanks. I've joined, and will start asking stupid questions post haste.

# ? Dec 20, 2018 23:37

xgalaxy: Jan 27, 2004; i write code

xzzy posted:

Epic is gonna trigger some kind of reckoning. Either Steam has been taking way too much money and they've got a Scrooge McDuck sized money bin somewhere, or Epic is taking way too little money and they're going to put themselves out of business trying to undercut.

The truth is probably somewhere in the middle but it's going to be an interesting 2019.

Steam has a Scrooge McDuck sized money bin. You do realize Gabe is a multi-billionaire right? And it's not because Half Life was successful.

# ? Dec 22, 2018 18:06

LordSaturn: Aug 12, 2007; sadly unfunny

Unity question:

I'm working with a simple 2D turn-based game where there's units on a map, each unit has individual properties I have to save and load, etc. The units use SpriteRenderers. The problem I'm having is that different units have different sprites. Like, the Sprite type, each unit has its own graphic file it needs to display so that it looks like what it is.

The problems are twofold:
1) There are no good ways to save/load Sprite data. Everyone on the first page of Google recommends using the Resources folder and saving/loading the path to the appropriate asset, which Unity explicitly tells everyone not to do.
2) I want to have unit recipes as ScriptableObjects, but the code that creates a new battle doesn't live anywhere near a MonoBehaviour, and so can't easily get a reference to the right ScriptableObject without doing Resources stuff.

The absolute best idea I have at the moment is to put a public reference to the SO on my singleton MB so I can access it through static space, but then I'm stuck adding new public fields every time I make a new type of unit. I've considered an array of structs, but that involves tracking the correct index for the unit, which seems prone to misery. Is there some smarter way of doing this that I haven't considered?

# ? Dec 24, 2018 01:56

Whybird: Aug 2, 2009; Phaiston have long avoided the tightly competetive defence sector, but the IRDA Act 2052 has given us the freedom we need to bring out something really special.

https://team-robostar.itch.io/robostar; Nap Ghost

LordSaturn posted:

I've considered an array of structs, but that involves tracking the correct index for the unit, which seems prone to misery. Is there some smarter way of doing this that I haven't considered?

There's a library you can get that lets you create scriptable Dictionaries -- if you use that, you can use this solution, but have a Dictionary with an enum for the keys and your struct for the values, so you don't have to track the index any more.

That's the approach I'm taking, though caveat emptor I'm only on my first Unity project too so this might be a terrible idea for reasons I don't yet understand.

# ? Dec 24, 2018 09:46

leper khan: Dec 28, 2010; Honest to god thinks Half Life 2 is a bad game. But at least he likes Monster Hunter.

LordSaturn posted:

Unity question:

I'm working with a simple 2D turn-based game where there's units on a map, each unit has individual properties I have to save and load, etc. The units use SpriteRenderers. The problem I'm having is that different units have different sprites. Like, the Sprite type, each unit has its own graphic file it needs to display so that it looks like what it is.

The problems are twofold:
1) There are no good ways to save/load Sprite data. Everyone on the first page of Google recommends using the Resources folder and saving/loading the path to the appropriate asset, which Unity explicitly tells everyone not to do.
2) I want to have unit recipes as ScriptableObjects, but the code that creates a new battle doesn't live anywhere near a MonoBehaviour, and so can't easily get a reference to the right ScriptableObject without doing Resources stuff.

The absolute best idea I have at the moment is to put a public reference to the SO on my singleton MB so I can access it through static space, but then I'm stuck adding new public fields every time I make a new type of unit. I've considered an array of structs, but that involves tracking the correct index for the unit, which seems prone to misery. Is there some smarter way of doing this that I haven't considered?

I don�t think you want a singleton MonoBehaviour.

Separately, the thing you probably are looking for is a prefab per unit type. Then hook up the ScriptableObject to the associated prefab and have a MonoBehaviour on that prefab load relevant data, including the texture, from the SO.

If you want something a bit more generic, you could have a SO that maps an enum type to other SO�s and reference the mapping object on your prefab. Then you don�t need to maintain a bunch of prefabs for each unit. All you need to do is pass the correct enum value to initialize the MB.

# ? Dec 24, 2018 15:00

LordSaturn: Aug 12, 2007; sadly unfunny

Whybird posted:

There's a library you can get that lets you create scriptable Dictionaries -- if you use that, you can use this solution, but have a Dictionary with an enum for the keys and your struct for the values, so you don't have to track the index any more.

That's the approach I'm taking, though caveat emptor I'm only on my first Unity project too so this might be a terrible idea for reasons I don't yet understand.

Is it this? I'm don't want to solve this problem the way you did, if only because it'd mean maintaining an enum and a dictionary in parallel, which I don't love, but this looks really useful for other problems I have.

leper khan posted:

I don�t think you want a singleton MonoBehaviour.

Separately, the thing you probably are looking for is a prefab per unit type. Then hook up the ScriptableObject to the associated prefab and have a MonoBehaviour on that prefab load relevant data, including the texture, from the SO.

If you want something a bit more generic, you could have a SO that maps an enum type to other SO�s and reference the mapping object on your prefab. Then you don�t need to maintain a bunch of prefabs for each unit. All you need to do is pass the correct enum value to initialize the MB.

I don't think we're on the same page about what I'm trying to do, but I'd feel rude not acknowledging your post. Thanks anyway!

For now I've gone with the Resources folder, because it'll probably be fine for the scope of this particular project. Also, someone in the other thread mentioned Addressable Objects, which sound like exactly what I want, but aren't in the version of Unity I have.

# ? Dec 25, 2018 20:04

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

I'm thinking of making a little something for gamepad-specific tooltip icons to embed in my Unity GUIs as a guide on what to hit to do what. I'm thinking I should use a GameObject with an Image or a Sprite as a base but I wonder if there's anything else. Can I integrate something with TextMeshPro to detect tags and convert them into the little button images I would use as guides?

I'm pretty sure the image/sprite thing is the way to go but I want to know if there's any other neat things I should explore.

# ? Dec 27, 2018 09:07

Triarii: Jun 14, 2003

Rocko Bonaparte posted:

I'm thinking of making a little something for gamepad-specific tooltip icons to embed in my Unity GUIs as a guide on what to hit to do what. I'm thinking I should use a GameObject with an Image or a Sprite as a base but I wonder if there's anything else. Can I integrate something with TextMeshPro to detect tags and convert them into the little button images I would use as guides?

I'm pretty sure the image/sprite thing is the way to go but I want to know if there's any other neat things I should explore.

TextMesh Pro has that functionality built in: http://digitalnativestudios.com/textmeshpro/docs/sprites/

# ? Dec 27, 2018 10:09

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

Triarii posted:

TextMesh Pro has that functionality built in: http://digitalnativestudios.com/textmeshpro/docs/sprites/

Hmmm that is half of the solution; I still need to translate my controller action to the actual Sprite. It sounds like I have to hack at TextMesh Pro to do that, but it seems possible to give it a custom tag that I can then translate.

I want the indirection since I'd like to take a stab at remapping controls and supporting multiple platforms.

# ? Dec 27, 2018 15:06

Pseudo-God: Mar 13, 2006; I just love oranges!

I am having an issue with my collision resolution code for my 2D platformer. I am using only AABBs for by objects, and in case of a collision, I calculate the penetration vector and translate the player object along the smallest axis of the penetration vector. This works very well, but there is a literal edge case that I am having trouble solving. If a player hits the ground from the top with enough speed, he will be embedded in the ground such that the smallest axis will actually be the horizontal one, and will slip on the side.

I have tried dividing the penetration vector with the velocity value at the time of the collision, and this fixes this particular problem, but also brings other more serious bugs.

Am I missing something obvious, or will I have to use an entirely different way to resolve this issue?

GIF provided where the problem is seen, around the end of the video. The console is displaying the penetration vector during each collision in each frame. The player box turns red when there's a collision, and the green line is the velocity vector. The thicker it is the higher the magnitude.

# ? Dec 27, 2018 15:30

leper khan: Dec 28, 2010; Honest to god thinks Half Life 2 is a bad game. But at least he likes Monster Hunter.

Rocko Bonaparte posted:

Hmmm that is half of the solution; I still need to translate my controller action to the actual Sprite. It sounds like I have to hack at TextMesh Pro to do that, but it seems possible to give it a custom tag that I can then translate.

I want the indirection since I'd like to take a stab at remapping controls and supporting multiple platforms.

Different platforms require different builds. It�ll be easier to swap a couple assets at build time than do the thing you�re thinking of.

# ? Dec 27, 2018 15:39

TooMuchAbstraction: Oct 14, 2012; I spent four years making
Waves of Steel
Hell yes I'm going to turn my avatar into an ad for it.; Fun Shoe

Pseudo-God posted:

I am having an issue with my collision resolution code for my 2D platformer. I am using only AABBs for by objects, and in case of a collision, I calculate the penetration vector and translate the player object along the smallest axis of the penetration vector. This works very well, but there is a literal edge case that I am having trouble solving. If a player hits the ground from the top with enough speed, he will be embedded in the ground such that the smallest axis will actually be the horizontal one, and will slip on the side.

This is one of many reasons why I advise people to not write their own physics if they can possibly avoid it. Collision response is a super complicated issue and you're never going to get all the kinks ironed out. For your specific issue, you can try things like sweeping the AABB along its velocity vector and using that as the collision polygon, though of course it's no longer an AABB if you do that. You can also say "ok, there was a collision, I'm going to back the colliding objects out along their velocity vectors and then step forward in smaller increments to get a minimal overlap."

But invariably you're going to find other edge cases where your collision response glitches out. About the best you can hope for is to get it to the point where all of the glitches are possible only with specific arrangements of colliders that you can simply omit from your game.

# ? Dec 27, 2018 15:53

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.'

Pseudo-God posted:

I am having an issue with my collision resolution code for my 2D platformer. I am using only AABBs for by objects, and in case of a collision, I calculate the penetration vector and translate the player object along the smallest axis of the penetration vector. This works very well, but there is a literal edge case that I am having trouble solving. If a player hits the ground from the top with enough speed, he will be embedded in the ground such that the smallest axis will actually be the horizontal one, and will slip on the side.

I have tried dividing the penetration vector with the velocity value at the time of the collision, and this fixes this particular problem, but also brings other more serious bugs.

Am I missing something obvious, or will I have to use an entirely different way to resolve this issue?

GIF provided where the problem is seen, around the end of the video. The console is displaying the penetration vector during each collision in each frame. The player box turns red when there's a collision, and the green line is the velocity vector. The thicker it is the higher the magnitude.

That�s when you say things like �if the player is falling the depenetration vector is always up�

# ? Dec 27, 2018 16:03

Pseudo-God: Mar 13, 2006; I just love oranges!

TooMuchAbstraction posted:

This is one of many reasons why I advise people to not write their own physics if they can possibly avoid it. Collision response is a super complicated issue and you're never going to get all the kinks ironed out. For your specific issue, you can try things like sweeping the AABB along its velocity vector and using that as the collision polygon, though of course it's no longer an AABB if you do that. You can also say "ok, there was a collision, I'm going to back the colliding objects out along their velocity vectors and then step forward in smaller increments to get a minimal overlap."

But invariably you're going to find other edge cases where your collision response glitches out. About the best you can hope for is to get it to the point where all of the glitches are possible only with specific arrangements of colliders that you can simply omit from your game.

The reason I am doing everything from scratch is to experiment with a novel networking model for web apps (UDP in JavaScript), and none of the existing engines fit my needs. The physics in the game will be very simple, and the existing engines had behavior that was unsuitable or too complex.

Instead of sweeping the AABB continuously, I can generate a fixed number of them along the path from the old position to the new, and use the results of the earliest collision as the "true" result. This will not fix the problem definitely, but will push the speed at which the slipping occurs beyond the one that is available ingame.

# ? Dec 27, 2018 16:08

Triarii: Jun 14, 2003

Rocko Bonaparte posted:

Hmmm that is half of the solution; I still need to translate my controller action to the actual Sprite. It sounds like I have to hack at TextMesh Pro to do that, but it seems possible to give it a custom tag that I can then translate.

I want the indirection since I'd like to take a stab at remapping controls and supporting multiple platforms.

I would say that, rather than hacking TextMesh Pro to understand that <button="attack"> translates to some particular sprite, instead have a method in your input manager that says "get me the sprite tag corresponding to the attack button" (probably pass in the action in as an enum) which would return <sprite="SquareButton"> if you're using a PlayStation controller with square bound to attack, or <sprite="AButton"> if you're using an XBox controller with that as your attack button, etc. Then call that function and insert it into your string when you want to tell the player how to attack something.

# ? Dec 27, 2018 16:10

Adbot: ADBOT LOVES YOU

# ? May 26, 2024 00:52

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

The simplest way to do this is to project movement separately for the horizontal and vertical axes. Project from the two edges of your player character in the vertical direction, and if you bump, you lose all vertical momentum. Do similar from the horizontal direction. Don't use shorthands like "the smallest penetration vector", they have no physical analog.

The "correct" way to do this is to project each edge of the character along the velocity vector. Grab a copy of Real-Time Collision Detection if you're serious about building this sort of thing, it's the best tome on the subject.

# ? Dec 27, 2018 18:06

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

«‹›623 »