text:
Is "reverse season pass" a thing?
"Reverse Season Pass" is a name I just made up and I want to know if something like this already exists with a better name.
We all know regular season passes: you buy a pass for a game you already paid for, which gives you access to future dlc, which doesn't exist yet, and may or may not be worth the money. AAA publishers love those things and they're pretty BS for the customer, because they are expected to pay for something that doesn't exist yet, or may never exist, or may not even be worth the money. You just have to trust them with your money, and there's no guarantee the base game hasn't been already sliced up into future dlc prior release.
Now lets say you have a story-driven game you want to release in episodes, like I want to do. The game itself is already completely done, all episodes are ready, you just want to pace the content over a few weeks like a show on tv to create discussion and excitement in the fandom for each new episode. The episodes would be added to the base game, meaning the episodes aren't sold separatly, you want to sell the whole experience.
However, if you're like me and you're still a nobody in the gaming industry, charging full price for a game, that's supposedly done (you can't know for sure, right?), which is going to be released in pieces supposedly, seems... very shady. I wouldn't blame anyone if they found that suspicious.
Lets say your game as a whole is worth 30$ and you have five episodes, so 6$ per episode. What I thought of doing, which I think is pretty fair, is to adjust the price depending on how many episodes are already released. When the first episode is released, the game costs 6$. When the second episode is released, the game costs 12$, then 18$ with three episodes, 24$ with four episodes, and at last, 30$ for the full game with all five episodes.
On top of that, when people buy the game early, when only one or two episodes are available for example, they already essentially bought a season pass on top of the game and will receive all other episodes for free. That way, people pay for the game only what it's currently worth and early adopters are rewarded for their early purchase and show of trust.
Has anyone ever done something similair? Is there a name for it?

That's pretty much what most early-access games do: you pay a lesser price for the unfinished version, then the price ramps up at release but you already have access to the full copy then.

@Quentin Good point, I haven't thought of early-access games like that, but it's kind of a different situation, isn't it? With early-access games, you know the game is unfinished and might be buggy, and the developers themselves even say it's unfinished. It also doubles as a testing ground for players to give useful feedback to the developers to improve the game. That's the point of early-access: to get feedback. With my example, however, the game is already completely finished and is just intentionally held back from release and instead released piece by piece. Not quite the same.

Yes, of course. Just mentioning it since it comes close :)

If you're a nobody, then how many players do you have, that you will be able to create a significant amount of discussion between them?

Do you have the whole game ready to be released? If you wanted to, could you just release it in one piece at week 1?

@immibis In an ideal world, if my game is any good, I'd slowly build up the fanbase with each episode released, starting with 0, obviously.

@JohnHamilton Yeah, if I wanted to, I could release it all at once.

This sounds pretty much like the Early Access business model. You start selling your game in a very early development stage. While the game is still mostly incomplete, you offer the game for a very low price. The further you progress, the more you raise the price until you've reached your planned price at release day.
The main difference to your business model is that Early Access games are usually not almost finished when they start going into early access. It usually takes years between early access release and actual release. The purpose is usually to fund the development while simultaneously market-testing the game and building hype.
But in your case, where you already financed the development, there is really no reason to follow that business model. You could just offer the base game for little money (or even for free) and release the individual episodes as paid DLC (just make sure that the total cost of the game is transparent). There is also very little business reason to artificially delay the release of the individual episodes. When they are finished, you can just put them onto the market and let players experience them at their own pace. If you release them with delays, there is a high risk that players will get distracted by a different game and forget about yours.

Sometimes early access games will cost more (Planetary Annihiliation comes to mind) and even be non-free before release and adopt a free to play model afterwards (Battlerite is a recent example).

So what you're saying is that every company creating tv shows (animated or live-action) should air all their episodes at once when they've finished a season? :) I know attention span isn't at an all time high, but it still seems to work well for regular tv series(-es...?). I know I'm making a game and not a tv series, but I don't see why that would be wrong to do with a very story-heavy game that can be segmented into episodes. Btw, the reason I can't sell the episodes separately is because the episodes are interconnected very heavily: you can unlock a new path for ep2 with ep3 for example.

@noclue that is exactly what Netflix does, puts out a full season at once

@RichardTingle Really? So a season, which hasn't been aired before, just gets released fully? All episodes are available immediatly?

@noClue They usually do exactly this with their own productions (Marvel's The Defenders, Orange is the New Black), but with other shows, the episodes are released on a weekly basis (Star Trek: Discovery, Designated Survivor). They are still experimenting with this, apparently.

Hitman (2016) did something similar.
Square-Enix sold the base game, what they called the "Intro Pack", for something like $30usd. This included the basic content and a small set of missions (I believe something like 10). Then they released monthly "Episodes" which included new locations and missions, each episode was sold separately and was independent from each other so you didn't had to purchase the first 3 to purchase the 4rd, for instance. They costed around $7usd each. In the end they released a total of 5 Episodes and thus completing season 1.

Season 1

Sapienza
Marrakesh
Bangkok
Colorado
Hokkaido

After the season is complete they release both the Season1 pack (all episode but no base game) for around $24usd, and the GOY Edition that includes all previously released content including the base game sold at full retail price; $59.99usd.
I think this model works pretty well, however, it was badly received in the beginning as people are used to purchasing "complete" games, so there were several complaints that the game felt unfinished and unpolished. Usually pricing models that are not traditional or not completely straight forward are perceived in a bad light by gamers, so be aware of that.
Im not sure there is a name for that, but looks like you are trying to do is in fact a "reverse season pass", "anti-season pass"?

This isn't the same case as the asker's problem. The asker is talking about a cheaper game at first that gets more expensive later on (you still get the whole game no matter when you buy it). What Hitman did was just a season pass, nothing special.

I disagree Hitman sticks to the traditional season pass model. Most games that are commercialised through that model start with a full game price and subsequent content addons that you buy independently or through a season pass that gives you access to all when they eventually come out. The Hitman Model sells you a cheaper base game with optional content; not an early access as it's a complete product, but it doesnt sell to full retail price. So the model he describes is basically bundling the entire game + content every time new content is released, but giving it away to early adopters.

I guess the question, where your answer either falls apart or not, is: were those individual episodes already finished before the release of the base game?

Arcen Games tried to do something like this with their game In Case of Emergency: Release Raptor figuring they could charge a few bucks for it "as it" and then as it sold, they could use those funds to develop further, incrementally increasing the price to match what the game was at the time.
It didn't go well.
Arcen's press release can speak better than I can, but press didn't like the concept and prospective players (incorrectly) assumed it was YouTube bait (what Goat Simulator is).
So be aware that while that kind of pricing scheme can work, there are problems to be aware of.

I'm sorry but that's not really what I asked for, as their game wasn't finished to begin with.

Looking at the post mortems of Release Raptors gives me the impression that the problem with that project was the game itself and not the business model behind it.

@noClue Yours isn't either, otherwise you'd just release the $30 version.

@Draco18s I specifically mentioned that the game would already be finished, just released in episodes weekly, so it's not really the same.

@noClue If your game is literally finished then releasing the episodes sequentially and letting people pay $6 now for all five episodes is literally kneecapping your income. If people still have to pay the extra $6 later for the next episode instead, you're just making things annoying for your customers who buy early and kneecapping your income as some of those players won't buy episodes 2-5 later. The whole point of "season pass" type sales is to generate the revenue needed to continue development. If you don't have those costs, then you don't need that type of business model.

@Draco18s So what exactly is your point? Whether this makes sense from a business standpoint or not doesn't matter to the question. Your answer didn't address the question I asked.

For over fifteen years, I've been following the games, the game industry and the business models in the industry. I have to say, I've never seen a business model like you're suggesting and I think it might work if you do it well.
The biggest problem you'll have is people not believing that a new developer actually has all the episodes done, but just wants to implement fancy business model.
I think you should have two versions of the game. One where you can present episodes as you want them to be available, and one that has all the episodes readily available. I see two options for this method to work.
The first one is easy, you just release both versions and let people choose whether they want to buy the whole thing now, or buy the episodic version which is cheaper now, but will be the same price as the full version. This can mean that the episodes you haven't released yet for the episodic version will have videos out there and you can't really control this.
Your second option is to only release the episodic version but to give the complete edition to the streamers or Youtube personalities and just ask for them to not release their relevant episodes (in case of Youtube) or play the unreleased episodes (in case of streamers) before you release them. You can do this pretty easily with an NDA (non-disclosure agreement) before sending them the game.
This does mean extra work on your side, but you'll at least have some people that can attest that your game is indeed complete.


text:
Implementing a lexicon for a word-based game with C# or C++
In my game project I have a lot of word existance checks based on some word bank. As usual arrays or map/set are not realy appropriate for this due to their speed/memory usage, I want to use Ternary Search Tree. After some googling I've realised that there's not so much info or code ready to use there. So I want to implement it myself.
Question is - can I write it in C++ and then export to Unity with cross-platform support? To be more precise: will I be able to use this cpp library on Android and iOS? Or maybe I should just write it in C# which, I believe, will be slightly less efficient?

Are you sure a hash map is not good enough for your purpose? How many millions of words do you have? How many thousands of searches do you do in it per second? This really seems like premature optimization to me.

For PC - yes, as developing for smartphones I want to optimize as much as I can to save battery. If hashmap is good though - I can definately use it at least for prototyping and maybe even for a full game. Thank you for your response.

Beware of making performance judgements before you've actually implemented and tested at least a prototype version of the feature. For a basic data structure like a search tree or finite state acceptor, storing static data that's not being re-allocated during queries, there's no particular reason to expect significantly worse performance from C# - especially if you stick to simple arrays under the hood in your implementation. It might be better to try it that way first and measure performance before complicating your project.

As the comments point out, don't prematurely optimize. What this means is either "test it with a prototype" or "do a believable back-of-napkin Fermi estimate based on known implementation features"

Or maybe I should just write it in C# which, I believe, will be slightly less efficient

Why would you believe it is less efficient? What makes it less efficient? Finding out the answers to these questions should be way less effort than writing a Ternary Search Tree in C++ and then figuring out cross-platform native interop in Unity.

Do you actually need it?
I think between two sublinear algorithms, there won't be a noticesable difference. Just for fun, I took the TWL06 Scrabble dictionary as a text file (178,690 words). Linear search with grep takes like 10ms (I can't easily measure the precise time with time) , as measured on the command line and uses 1MB memory. Obviously, this is a terribly inefficient strategy to use repeatedly. But even this is "good enough".

If you need to search for words in a lexicon, then simply storing them pre-sorted and using a binary search algorithm can reduce the complexity to O(log2N), that's basically the best you can get.
Similar with the memory. An average english word is around 5.1 letters long, if you store 200,000 word, that takes up around 1 megabyte, which isn't much, even on cellphones.
Searching through these takes 18 checks. You can't even measure that in milliseconds.

You can technically do "better" (asymptotically) than logN with a finite state acceptor. There your upper bound is linear in the length of the word (times a constant that's at most the size of the alphabet), and common prefixes/suffixes can share storage. Significantly more work to set up than a search tree or hash table though, so unlikely to be an important distinction for most game uses.

I haven’t even thought about binary search, that’s a fantastic idea, thank you.

@RiotBr3aker Note that C# already comes with a binary tree implementation supporting O(log n) search.

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

sort: votes


text:
Critical input from server arrives late... it must not!
To preface, my understanding of networking is mostly from Source Multiplayer Networking and 1000 Archers on a 28.8.  For various reasons I have decided to go with a client-server model instead of peer-to-peer.
My C#/Unity multiplayer game is ruled by an authoritarian server, which uses UDP. Each network instruction has a time index, and is inserted into PlayoutBuffer's data collection.  The buffer executes stored commands at the correct local time index, based on a fixed update loop.
The server is slightly ahead of time, and clients will pause if they have not received any regular update from the server, allowing them to catch up.
Each client will simulate object movement and this movement is corrected by the server (ten times a second).  I've got the basic system working, but when I'm testing it in two windows on the same machine sometimes input arrives late, and is dropped.
Usually the late message is 1 time index too late.  The fixed loop is 50 ticks per second.  The server is 5 ahead of time, and commands are scheduled 5 ahead of time (assuming negligible lag, since ping hasn't been implemented yet and is on the same machine).
This is a problem.  Inputs from server are grouped into a few specific channels:
Ping, Serialise, Inputs, Criticals, Corrections.
Ping has yet to be implemented.  Serialise packs and unpacks mostly pregame multiplayer lobby stuff.  Inputs are player commands; select unit, issue move order, etc.  Criticals are essential updates; create unit, shoot unit's weapon, damage unit, etc.  Corrections are mostly movement updates.
All channels are unordered and with the exception of Corrections all channels are "Reliable" in Unity terms (see Unity documentation).  Given that movement updates happen regularly, if a few are dropped or arrive late this is not a critical system failure.  But if a critical is lost, this would effectively result in a desync.
How can I prevent and handle critical data arriving late from the server?
My first thought is to implement a custom ping. This is used to set the time index for the data relative to the time the last ping took to get back from the client, plus server time index.
But I doubt that would be enough... and if it fails?  Should the client pause or catch up based on the difference between local time index and the time index in the late critical?  Does the PlayoutBuffer need to become an AdaptivePlayoutBuffer to resolve these issues to handle CPU and network lag?  If so, how so?  Any other ideas welcome!
EDIT: The reason inputs were arriving one time index too late sometimes was because the buffer's for loop which read inputs counted from 0 to list.count, and removed items as it iterated... when I changed it to reading from list.count to 0, it fixed the issue and no inputs arrived late.  Whoops.

Speaking from my experience as a player, I feel like when client starts missing critical packets game freezes on a client side. It may be "Network problem" message thrown into face. Sometimes, user is still able to perform controls input, but this data is not getting sent(e.g., when connection gets better, player suddenly finds out that he was actually killed 20 meters away from where he is standing right now). If criticals are missed sometimes, guess that is okay. If they are missed constantly, probably some measures are necessary.

UDP and "critical data" is an oxymoron.  UDP does not require delivery or order of packets sent, you may get packets in reverse order or not at all.  You need to layer a custom protocol on top of UDP or use the standard TCP.

@PatrickHughes Actually it is not that difficult to reimplement some of the reliability features of TCP on top of UDP. Many game network libraries do that. You might wonder why these don't use TCP in the first place. The reason is that full-fledged TCP simply has too bad realtime properties for most games. Using UDP and adding some reliability features on top is usually a good middle-ground for games.

@PatrickHughes I agree with Philipp, which is why I have used Unity's network reliability settings... and edited the question to add this link.

If it's just one time index too late, can't you just hold on to the other packets that arrive and process them all in sequence once the packet that was late arrives?

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
How to store the updated score in mysql databse from android?
I want to store the updated score in mysql database. So, what i do for that?
private void updateScore() {
    if (winner.equalsIgnoreCase("You")) {
        tally = 100 - computer.getId();
        MainActivity.userScore += tally;
        if (MainActivity.userScore >= MainActivity.maxEnd) {
            MainActivity.   stat++;
            MainActivity.totTurn++;
            MainActivity.userScore = 0;
            MainActivity.computerScore = 0;

        }

    }
    if (winner.equalsIgnoreCase("computer")) {
        tally = 100 - buddy.getId();
        MainActivity.computerScore += tally;
        if (MainActivity.computerScore >= MainActivity.maxEnd) {

            MainActivity.totTurn++;
            MainActivity.userScore = 0;
            MainActivity.computerScore = 0;
        }
    }
    MainActivity.saveConfig();
}

I assume that mySQL database runs on a server on the internet?

Mysql database runs through xampp server. and i want to store the updated score in php mysql database.

You don't. Accessing an online MySQL database from a client application directly is a really bad idea for security reasons. The permission handling abilities of MySQL aren't refined enough to check what a game client can and can not write to and read from the database. You also can not restrict access to only your game client, because the MySQL server can not detect what software is behind an incoming connection (actually no server application can do that).
What you should do instead is create a server application using your preferred server application development technology. That server receives requests from the Android clients, verifies that they contain something the client is allowed to do, formulates and sends a query to the MySQL database and returns the results to the clients. Your MySQL database should be configured to only process queries which come from that server application.
Each of these steps allows a lot of creative freedom in implementation details, so giving a complete walkthrough would go too far here. If you have specific questions about them, please ask in form of a new question.


text:
Is there a specific name for this type of concept art and the artist who does them?
Let's say you already have the fundamentals of your game: you created gameplay that you and your (possible) playtesters find enjoyable to play, and you think you can flesh out your game more. However, it's all just colorless blocks and cones at this stage. It's still just a prototype and you don't have a clear vision of how you want the game to actually look.
Before you try to glue together something compelling in your game engine, you want to create a mockup of how your game could possibly look like, just like how Bloodstained did on their Kickstarter page:

These aren't ingame screenshots, those were made before the game even started. How are these prototype images called and what are their artists called? What kind of "keywords" do I have to look for if I want to hire an artist to prototype one or multiple possible looks for my game?

maybe mock-ups?

The art itself is a kind of concept art often called a "mockup," although sometimes you see people refer to them as "pre vis" artwork (particularly among those coming from a film background) or "overpaints" (the latter is sometimes used if some hand work is being done over some existing game art versus producing the concept image entirely by hand).
Sometimes people call them "visual bibles" or "art bibles," although that's usually (in my experience at least) in reference to the collection of the mockup shots themselves.
Somebody billing themselves as a concept artist could probably produce these for you. It's not a big enough need, and not too fundamentally different from the goals of other styles of concept art, to have really developed its own dedicated sub-discipline.
The key thing you'd need when finding somebody to produce this kind of material for you is a clear description of what you're after -- that you're looking for some kind of art to represent the idea of what the actual final in-game product may look like. With a clear enough set of guidelines, bolstered by structural examples like you've provided in the question, and a good back-and-forth relationship between the both of you, you should be able to hire any sort of artist with the appropriate skills to produce these.

Comments are not for extended discussion; this conversation has been moved to chat.


text:
How can I speed up slow loading of big levels?
I created a level loader that loads levels saved in an XML format. This means I am using an XML parser to read the levels. It works, but slightly bigger levels take too long to load. So now I am looking for a way to speed up loading. I don't need the whole file to be loaded at once, as the player can't see the whole map anyway, so partial loading would be fine.
I thought about a tile based loading mechanism where there are multiple parts of the map, and the loader only loads the part/tile where the user is standing. But I am not sure if that is a good idea.

45 seconds is very slow to load a file. How big is this file exactly?

What kind of game is it, and what is stored in the levels?  I could see different approaches work better for different kinds of games

Translating values is an expensive operation (as everything you load must be translated from a string to its real binary value). Have you considered using binary files instead? This also has the added benefit of making it hard for the player to make alterations to the file (but not impossible, given the appropriate skill and effort)

In what language are you working? XML parsers vary wildly in speed, so it may be as simple as swapping out your parser for a faster one.

The problem isn't the XML per se. The problem is in your development process, which is looking at the performance implications of architectural and implementation decisions far, far too late. Next time, set a performance budget early, build a performance test suite early, and do performance testing of proposed subsystems like serialization engines early so that you don't get in this mess ever again.

Are we talking single large open worlds with a bunch of smaller levels (dungeons and such), or multiple large non-open worlds?

This is kind of an anti answer, but put up a loading progress bar, it's not actually any faster, but it makes it feel faster emotionally... if it's really bad add a small animation, or quotes popup to distract them, it's smoke and mirrors, but it's surprisingly effective on perceived slowness. But really get profiling to figure out where you real bottle neck is.

We are talking about a simulator game where you shouldbe able too look far away and have big levels with quite some detail.
45 second loading is for a 180mb file.
Lateron i may choose a binary format but i will use xml atleas for the development of the game, i figured it out now and will have several chunks in the file, wich then contain the actual objects.
This enables me to load 1 chunk a tthe time instead off all at the same time.
Thanks you all for your help.

First of all, you should measure where exactly the bottleneck is so you don't waste time improving things which are already good enough. The bottleneck could be any of these:

Reading the XML file from the hard drive
Your XML parser parsing it
Your code which interprets the output of the XML parser and converts it into your internal data structures
The loading of related assets (map tiles, etc.)
Initialization of the game

But your question specifically mentions partial loading of map parts. So for the sake of this answer, let's assume that you did profile your code, found that reading and/or parsing the XML file is the problem and that partial loading is indeed the most obvious solution to your problem.
With XML-based file formats, this is usually not possible. A DOM-based XML parser will need to parse and validate the whole XML document before you can extract any data from it. A SAX-based XML parsers will at least have to read everything up to the node you are looking for. So if you want to allow partial loading, you will have to ditch the XML-based format and invent your own binary file format where map chunks start at known file positions you can selectively seek to without having to read the data in between.
When you really want to keep using XML, you could store each map chunk as a separate XML file.

Hi, thanks for your reply! I am sure it is related to xml loading and i do really want to use xml. The thing is is that the file itself is loaded in 45seconds, or relatively fast. But then reading the parsed data and putting it in a array takes 12min, or way longer. So i would need a way of only reading the data wich i need, then those beginning 45 seconds and then an additional 2min approximately would be axeptable. But if i have to check every node for the right x and y cordinates i could aswell just load the entire file,

.....so i need a way to only read the nodes with the x and y within range. I think it should be possible as it takes a short time for the parser to internally parse the file. So Do you know a way to do that without having seperate files?

@appmaker1358 Is the time taken by the XML parser library included in the 45 seconds or the 12 minutes?

Both are specifick to xml parser, only the 45 seconds is only the reading in part and not the checking its values part.

To Philipp's point about storing chunks as separate files, Minecraft takes this approach. A middle ground would be to have 2 levels of subdivision. a Region file which contains data for 9 Chunks. You would load a Region file into memory, and parse and load the Chunks as needed based on th player location. In this way, at most you'll have 4 region xml loaded at a time (player standing on region corner)

@appmaker1358 I think we need more information about how your XML file is structured. Please add that information to the question. Also mention how far you are able/willing to change the XML format if necessary.

Comments are not for extended discussion; this conversation has been moved to chat.

Despite it being used for virtually everything, and despite it being used even in high-volume, low-latency applications, XML is an abysmal format for almost everything, but in particular for applications that have timely constraints, including games (except maybe for storing the game's settings). Even for live data, a simple binary tagged format which basically does the same as XML, just not human-readable (say, a 16-bit node type, 32-bit length, followed by contents), will be many times faster to read and write.
XML is tempting because it is human readable, and you don't need more tools than a text editor to write an XML file. However, it is also overly verbose, doesn't handle several types of data (binary data, large amounts of numbers, etc.) too well, and it takes a very non-neglegible time to process.
You can speed up parsing considerably by using a different parser, there are many alternatives (rapidxml, pugixml, whatever), however, that does not address the general problem of the format being overly verbose and human-readable to begin with.
While it is acceptable, and not even too uncommon, to use XML in one's production pipeline (though most people would rather use JSON or YAML), normally there is a custom-made tool that runs during the build process and that converts your XML files to a proprietary binary format which can ideally (not necessarily, but ideally) simply be loaded or memory-mapped as-is. No parsing whatsoever, just memory map, and set a pointer.
That same tool (or a similar one) will usually also read in other data such as e.g. textures which are stored in a variety of formats that may also be non-trivial to parse, and also put them into a binary game file in a way so they can just be mapped ready-to-go.
With the correct format, loading should be rather 0.45 seconds than 45 seconds.

While this answer is correct, I think it's important to stress that this only gives a constant factor improvement. This is probably sufficient for appmaker1358's use case; as it would bring the load time down from 45s to something manageable. If the load time of the level map would be 450s, though, (e.g. in an Open World setting) this approach would not suffice, and the original idea of splitting up into chunks would be needed. Note that these ideas are complementary. The different chunks could even be part of the same file if it's in a parse-less binary format with explicit item lengths.

@Thierry: Indeed. The nice thing with a binary (non-text) format where you have explicit lengths of everything is that you can just skip ahead a gigabyte worth of data if you know from the length that the stuff you want is there. XML cannot provide that. Assuming large enough address space (we're not quite in 32-bit-is-history land yet, but hopefully soon) you can even just map one single GB-sized file, and let the VM manager do the work. Touching pages a few frames before actually accessing them (worker thread) so the main thread never sees a fault, this works better than one would hope.

If you can live with an occasional small "hiccup" then you need not even worry about touching pages. Just map and forget.

We've seen almost 100x improvements in speed simply by switching parsers (from Python to C) which was extremely low hanging fruit (import a different module, change 3 lines of code.) In this benchmark, XML was almost twice (+84%) as verbose as JSON when storing the same data. Reducing it to binary would yield even better results. It takes me about that much time to load & parse files which are 4GB in size on disk (~21GB once loaded into python in RAM)...

There are a number of factors to approaching this problem, although you are on the right track.
Single Load
The first approach, as you've already tried, is to load it all at once. This puts all your load time and file I/O up front. As you've already noticed, as a map size grows, your initial load time can become annoying to the user. This also creates an upper bound on your maximum world size based on the minimum required memory of the target platform.
There are two other ways of handling this that I know of: you can chunk the world, and load them off screen as the player moves closer to them(stream loading); and you can have loading zones.
Loading Zones
Loading zones allow you to find a maximum chunk size that performs favorably, and subdivide your world into pieces no larger than that. When the player walks into a transit region (door, cave, map edge), some sort of transition graphic or animation takes place to distract the player. The new zone is loaded from the file system, while the old is saved and unloaded. This is a middle of the road approach. While it allows you to have worlds much larger than the memory capacity of the target device and puts all your I/O effort before the player is given control, this increases I/O operations over your initial approach. This can also break continuity of gameplay, which may or may not be favorable for the style of your game. The Final Fantasy series is probably the most recognizable for this type of approach.
Stream Loading
What I would consider the most recognizable example of stream loading is Minecraft. Chunks are loaded to and removed from memory as the player proximity changes. As with zone loading, stream loading removes the upper bound on world size as well. It also removes the interruptions of the loading effort from the user experience. However, this is the most file I/O heavy approach, as zones may be loaded and dropped from memory many times during a play session. Care must also be taken to load a zone at a closer proximity than they are removed from memory, in order to prevent a player repeatedly walking across a chunk boundary from burying the game in I/O operations. For 3D games, a method called doglegging is often employed which blocks the player's view of the area that is being loaded. This usually takes the form of a hallway with a turn in it, but can be any obstruction that blocks the player's line of sight.
Which of these approaches works best for your game is up to you.

I think i want stream loading and thus have several chunks of my world, but i would like them in a single file. Because parsing the entire file internally in the parser only takes a short time i only need a way to easely indentify wich node is what chunk. I need to do this without checking every node as that would make it take the same amount of time as directly loading every thing in. Could you help with that?

You can either break the file down into smaller segments of your world, or you can structure your nodes to make it more easily searchable. Its difficult to say which is best without seeing what you already have.

Let's have a look at smart... what is smart exactly?
You state that you use XML as a format to store your levels. XML is a hierarchical format that is stored into a file. Thus we have 2 main factors that influence our loading times:

IO speed: That one is a hard constraint. You can't influence the reading and writing speed with your code. At least not too much. You can make use of things such as the processor cache size, etc. but that is low-level stuff and also different from computer to computer.
Your XML structure: This is where you can go wild. You can decide how you store things and what comes earlier, what later. You can even start grouping parts of a level into smaller datasets and then order these datasets in your big XML document, the earlier needed ones being closer to the beginning of the file.

So expanding on the second factor you could store your level in a format something like this:
<level>
    <name>Dragon Boss</name>
    <par-time>45</par-time>
    <sections>

        ...

        ...

        ...

    </sections>
</level>

Each
 containing part of the level so it can be loaded one of these at a time.
Now that we've organized the format into something more useful the next step would be making sure that we can actually make use of this feature. One way is to load the whole file into memory, then breaking it down and only start parsing the level data after breaking it down. Thus you can load additional sections on demand without having to do all the expensive creation of textures, physics objects and what-not before you need them.
If your file is, for some weird reason, too big to load into memory then you could start using a SAX-parser instead of the DOM-parser you're likely using. The advantage of a SAX-parser is that it doesn't need to parse the whole file before you can work on it. It also reads and processes the file inherently different from a DOM-parser, so reading up on both might be good anyways.

Another topic that seems to boil up from your comments on other answers is that of organizing your data. You should in general strive to decouple your game logic from your game-data where possible. E.g. loading a level must not mean to read a file from the disc and create everything that is described in each line of the file. It might be (it actually is) better to, instead, store the data in an in-memory datastructure and then start working on that only where necessary.

1/2: Just a nitpick, but personally I would call things like 'processor cache  size etc.' low-level, not high-level... perhaps these terms are used in opposite ways in different places?

@bendl I think I meant to imply that it's worrying and optimizing on the more specific / high end of the line. Changing it to low-level should imply the same and be more understandable, thank you

2/2: The example you give includes loads of repeats of the tag
.  The loader has to load each of these into memory individually, so shortening all the tags to one or two letters will probably provide a significant speedup assuming there are a lot of tags. (See html tags)

@bendl shortening these to 1 or 2 letters might or might not have a miniscule impact on loading times, but writing out the word section instead of using a 2 letter string has major impacts on understanding the concept and associating it with something one already knows

I agree completely! I only meant that that should be something the OP should consider, as it's a very cheap way to (possibly) cut back on a lot of loading time. Perhaps it should be left as a comment on the question, not on your answer.

Don't change your XML file if you find it a useful format for you to work with.
The trick is to keep the file you like but not have your game use that file directly. Write a simple routine (to run as part of packaging the game) to parse your XML into optimal chunk sizes to be loaded dynamically and at the same time create an index for those chunks that you can load into memory when your game starts.
As a very simplified example if your draw distance is .9km then each chunk file could represent a 1km square of your world grid.
Your parser splits your world into 1km square chunk files
In each chunk file have the parser add the filenames of the 8 chunk files adjacent to it, that way you don't need to hit the index to know which neighbours to load. Also add the top-left coordiate and bottom-right coordinate of the grid chunk so you can easily test if a players location is in that chunk
The parser then creates an index file by going through all the chunks  storing chunk-file-name, top-left coordinate, bottom-right coordinate
Game loads, searches the index to find which chunk the player is in.
Loads the chunk file, reads the adjacent chunk list from that chunk file and loads those chunks too. You now have 9 chunks loaded surrounding your player. As your player moves through the level if your players location goes beyond the current chunk then search the other loaded chunks for the chunk the player is now in. Use the new chunk's list of adjacent chunks to load the newly adjacent chunks and unload ones that are nolonger adjacent.
If the player moves ( teleports ) searching the loaded chunks to find out which one it is in will fail .. at which point you lookup against the index again

This is basically ignoring the suggestions about profiling your load time, evaluating file format complexity, etc. and is I see now a variant on Stephan's loading zones suggestion.
Consider if you had a VERY large level - like an MMO would have.  Realistically you would not load the entire thing in one shot.  Instead, you'd do it in pieces. Or load it at different levels of detail - low level detail (and probably thus smaller data files) for things far away, and only the high level of detail near the player.
So the approach would be something like this...

Break your level up into sections
Model these sections at different levels of detail - from very low detail which is sufficient for the player to view it from a long distance, and very high detail for where the player is.
Only load sections based on what level is required.
Dynamically load (and unload) sections as the player moves.

The assumption is that low level detail sections will load very very quickly, and high level will take more time.
This will help by allowing you to load just what you need, not everything.  It also gives you some control over processor load, as you won't have to render or simulate fine details that are distant - only where the player is.
It's a generalized answer, but it's one that might work for you.  It definitely is an approach for a very large level, but not really practical for a small one.  Maybe your needs are somewhere in between and it will help.


text:
Should a system be able to render things? (ECS)
I'm currently building an entity component system and I just have one question... Should a system be allowed to render things to the screen?
For example, should I make a SpriteComponent that contains a Sprite, and then create a SpriteRenderSystem that renders the sprite to the screen? Or should rendering entities be managed by something else entirely?
The reason I ask is because I've read in many forums that allowing a system to render is a bad idea. But I just don't understand why this is; If game objects in my game are represented using the ECS, how else would I go about rendering objects to the screen?

Perfect systems don't exist. Do whatever you're comfortable with. It'sll get a burden eventually.

Isn't the render system....a system? I'd imagine your system class forwards all of the rendering commands to a render system? You can probably do it directly if you don't have such a setup.

There is no such thing as the ECS. What is you E, what is your C and what is your S? What do they do and how are they related? There is as many definition of ECS as there are developers.

@AlexandreVaillancourt actually no, there are only different definitions of component based architecture, but even then they're just different design patterns. ECS (Entity Component System) is a architectural pattern commonly used in game development programming; https://en.wikipedia.org/wiki/Entity-component-system

@Mathew There are obviously different interpretations / approaches / meanings of the ECS pattern since your implementation is different from my implementation and from the common implementation where an entity is nothing but an ID and a component only holds data and does not have any functionality.

This might not be the best approach, but it works for me:
The ECS is used for logical storage and operations only (or almost only).
The design I use is aiming to separate these two concerns as much as possible. Naturally somehow you need to be able to tell any rendering code how to render a given entity, I do that using a component on my entities that stores a graphical representation of the entity. This representation could be a simple sprite, a whole spritesheet, a bunch of triangles, and so forth.
To decide what I render, my ECS has a Camera-System. This system has a certain box in world-space it sees. Any entities that are located in that box and have a representation-component are picked up by the Camera-System, batched and queued for rendering.
The renderer runs, in my case, on another thread and picks up a snapshot of all cameras every frame - then renders it.

You're overthinking this. There is no definitive "good" or "bad", just what works. I've always used a SpriteComponent and a SpriteRenderingSystem. It's the most simple and straight-forward way and it has worked for all of my games. If you feel like it's not the correct thing to do then change it to be whatever you want / need. Just do whatever feels right and whatever works and it will be fine in the end.


text:
Unity 2d - rigidbody rotating Z axis if hit something
I have problem with my player. I use rigidbody2D on my player and I had fixed rotation on Z, but now i need use rotation with some of my root animation. Ok, i enabled it, but when my player hit something (for example NPC, wall, ...), rotates on the Z axis and falls off. Can you help me? Thanks and sorry for my mistakes.

Please read How to create a Minimal, Complete, and Verifiable example. We will need you to provide your code to help you.

Is it betteer ?

when you say "rotates on the Z axis and falls off", what falls off of what?

Rigidbody - player rotates on Z and falls like human in real world falls - the head falls to the ground


text:
How much detail should I provide in reference material to potential contract composers?
I'm not very good with music, so when the time comes I'll need help from a composer for my game. I'm unsure of how to actually work with one.
Despite my lack of musical understanding, I know what I like. I might listen to some music and think "Hey, this kind of music would be awesome to have in the epic chase scene near the end of the game, where our heroes just barely manage to escape!"
When I go to hire a composer to make music for my game, how much detail and reference music should I provide? Should I provide lots of long descriptions of what I'm after, lots of links to music that I think fits the theme? Or should I just let the composer play the silent game and work it out themselves?

I hope this is not deemed too broad, because it sure is an interesting question.

As worded, this question invites a lot of opinion ("how would you prefer to work?"). Sometimes developers will want to set the tone, other times composers will want to. While who prefers what is a matter of opinion, the fact that decisions about tone will need to be made is matter of fact. I think by focusing on core process, we can keep this on-topic.

Yes; removing the bits of the question about what one prefers is a good first step. I think the best way to make this objective and on-topic is to make it a question about the reference material itself.

I took a stab at it.

I think it's going to vary from composer to composer really.  And whether you are giving them wide creative freedom to compose, or are restricting them by asking for a very specific style or sound.
It's like asking a 3D artist to create something for you.  You might be very vague and just say, "I want the content to convey the idea of great age and decay" and let them ask you questions back and try things out.  Or you might say, "I want a style that is exactly like game X" and they will be more of a copier as opposed to originator of content.
If you're looking for a composer (as opposed to a copier), I would highly recommend you read some interviews with the Grammy-nominated composer Austin Wintory. In many interviews, he talks quite a bit about how he works with game developers.
Here are some links to interviews where he describes the process...
https://www.keengamer.com/article/17144_interview-with-gaming-composer-austin-wintory
https://www.polygon.com/features/2016/2/16/10970474/journey-live-austin-wintory-fifth-house-ensemble-kickstarter
https://popgeeks.net/award-winning-composer-austin-wintory-on-working-in-video-games-interview/
https://www.rollingstone.com/glixel/interviews/a-day-with-grammy-nominated-game-composer-austin-wintory-w471406
http://www.zam.com/article/1493/austin-wintory-on-composing-absolver-a-game-about-friendship-through-fighting
Again it may not be how everyone works, but should give you some good insights into the process as others have experienced it.

I'd say that the answer to this evolves depending on where exactly you are in the game development process. If you're just starting out and are trying to figure out the mood and style of a game, perhaps you would spend more time allowing the composer to experiment, bouncing their music to inspire your concept artists' and writers' work and vice versa.
However, if you have a clear idea of the mood that you want in a game, it's better to be specific. However, I'd say try to avoid direct comparisons to other games, as then your music just ends up sounding like that other composer's and not your team's. What you come up with to fit your own unique world will end up being better if it matches your world and not someone else's. Give them concept art, bits of writing, etc. that define your world, then have them ask you questions. Each person's creative process is different, so some things will help one composer but not others.


text:
How can SDL tell what Xbox360 controller is what player?
I init my controllers like this:
if (SDL_WasInit(SDL_INIT_GAMECONTROLLER) == 1)
    return;
SDL_InitSubSystem(SDL_INIT_GAMECONTROLLER);

int nJoysticks = SDL_NumJoysticks();
numGamepads = 0;
for (int i = 0; i < nJoysticks; i++)
    if (SDL_IsGameController(i))
        numGamepads++;

if (numGamepads > 0)
{
    for (int i = 0; i < numGamepads; i++)
    {
        SDL_GameController* pad = SDL_GameControllerOpen(i);
        if (SDL_GameControllerGetAttached(pad) == 1)
            joysticks.push_back(pad);
        else
            cout << "SDL_GetError() = " << SDL_GetError() << endl;
    }
    SDL_GameControllerEventState(SDL_ENABLE);
}

and I poll events like this:
SDL_Event sdl_Event;
while (SDL_PollEvent(&sdl_Event))
{
    switch (sdl_Event.type)
    {
    case SDL_CONTROLLERDEVICEADDED:
        cout << "DEVICEADDED cdevice.which = " << sdl_Event.cdevice.which << endl;
        break;
    case SDL_CONTROLLERBUTTONDOWN:
        cout << "BUTTONDOWN cdevice.which = "<< sdl_Event.cdevice.which << endl;
        HandleGamepadButtonsDown(sdl_Event);
        break;
    case SDL_CONTROLLERBUTTONUP:
        HandleGamepadButtonsUp(sdl_Event);
        break;
    case SDL_CONTROLLERAXISMOTION:
        HandleGamepadAxis(sdl_Event);
        break;
    case SDL_QUIT:
        _quit = true;
        break;
    default:
        break;
    }
}

With this I have currently two Xbox 360 controllers connected. On these pads there is a LED indicating if it is player 1, 2, 3, or 4.

When I run this my poll loop prints out this when I press a button on this controller:

When I hit a button on the controller with the player 2 LED it prints:

So that is wrong. How can I from inside the code find out what controller corresponds to the controller with the right LED light on?
Also, when I first start it then it prints:

So the controllers are 0 and 1 when I add them but 1 and 2 when I run the game.

First of all, cdevice isn't safe to use on a SDL_CONTROLLERBUTTONDOWN event. It could contain whatever field of a SDL_ControllerButtonEvent happens to overlap the which field of the SDL_ControllerDeviceEvent structure in the union inside SDL_Event.
So the SDL docs are a little confusing on this, but here's what I could gather:
There are two different "instances" that are passed around from the game controller events. There are game controller instance IDs, which is used in the SDL_CONTROLLERDEVICE* events, and then there are joystick instance IDs, which are used for an example in the SDL_CONTROLLERBUTTONDOWN event.
Here's what the docs say about the which field for button events:

Type: SDL_JoystickID - Name: which - Description: the joystick instance id

and here's the same which parameter on a SDL_ControllerDeviceEvent:

Type: Sint32 - Name: which - the joystick device index for the SDL_CONTROLLERDEVICEADDED event or instance id for the SDL_CONTROLLERDEVICEREMOVED or SDL_CONTROLLERDEVICEREMAPPED event

The biggest (and pretty much only) giveaway here is the different types of the fields.
A game controller in SDL is a combination of multiple joystick instances or something, and this is why it all becomes quite confusing.
So here's what I do in my codebase to make sure the correct player instance receives the correct controller events (so that pressing a button on one controller doesn't make all players perform an action):
Since SDL_CONTROLLERBUTTONDOWN events have a joystick instance field, I compare the which field of the event to SDL_JoystickInstanceID(SDL_GameControllerGetJoystick(controller));, where controller is a SDL_GameController* that's supposed to control the player.
I do keep track of the which value of the SDL_CONTROLLERDEVICEADDED event too inside my controller-wrapper class, so that I can properly handle SDL_CONTROLLERDEVICEREMOVED events.
So in conclusion, it's a little messy to get things going, but once you have your bool DoesThisEventBelongToThisController(SDL_Event* event, SDL_GameController* controller); function setup, you shouldn't have to worry about this anymore.

Can you tell me why the cdevice.which id is different in SDL_CONTROLLERDEVICEADDED and SDL_CONTROLLERBUTTONDOWN?

For SDL_CONTROLLERDEVICEADDED cdevice.which is the joystick device index, while with SDL_CONTROLLERBUTTONDOWN cdevice.which probably maps to the same address as cbutton.which (as to how unions work, feel free to look unions up if you're not familiar with them. SDL_Event is essentially one large union.), and cbutton.which is a joystick instance id, not a joystick device index. But as I said, you should not access cdevice in a SDL_CONTROLLERBUTTONDOWN handler.

I get the same problem when I switch everything to jdevice.which

You switch to what? Anyways, I clearly mention in the answer that the values in cbutton.which dont correspond directly to cdevice.which. They're two different types of values, that have different meanings. And don't switch everything, just use cbutton when handling button events, and use cdevice when handling device events.

I accepted this answer even though it was not 100% what I was asking for. If you unplug and replug a lot of controllers making "holes" in the controller order according the LEDs. Then the controller ID in SDL will not reflect the LED on the controller. But this was close enough.


text:
How to do game object perception at scale without some god object?
I've read through this post Interactions between game objects but it doesn't really address my question.
Background assumptions:

Maximum number of possible objects and the game still runs
Maximum sized game world and the game still runs
Game world is partitioned into sectors
Having an object/process at the game loop level to decide what objects are aware of what would be a bottleneck

The goal is feed an arbitrary game object the data it needs to do its thing.
The question is how should i go about doing this without some global god object/process that sits at the game loop level?
What I thought of (simplified):
Method 1 involved a list of all the objects. This would be the god object. Each game loop, determine an objects perception range, and pull the objects that fit.
Method 2 involved an event stream for each sector. A god process would look at the range of the object and put it into the sector's streams that are in range of the event. At each game loop, the god process would feed the object the streams of the sectors that are in its perception range.
Why I don't want a god object: How to avoid the GameManager god object?
Unfortunately, I'm not sure if the solutions outlined in that question really helps, as the "problem" recognized in that post is poor programming habits/design. At its core, the post and all the answers take for granted that the god object must exist. What I am after is to see if there's a way for objects in the world to be aware of each other without the all seeing eye.
In the real physical world, things do not commune with god, or gods, or the akashic record, or some other esoteric entity in order to be aware of and interact with each other. Things will do their thing and each thing relies on whatever method of sensing they were born with to do their thing.
It might be because of my limited imagination/knowledge/experience that I don't know how to replicate how the world works digitally or it might be because this is not possible. I don't know, hence this post.

To confirm: you're looking to somehow maintain/query, for each of a set of entities, the collection of entities that are within that entity's awareness radius? (And entities can have different associated radii, so this relationship might not be mutual, correct?) Can you describe why you've included the "without a god object" constraint? It seems like some shared data/logic could help to reduce redundant/duplicated work in some situations like these.

@DMGregory Yes and Yes. I feel like the god object would be a problem down the line in terms of cost, performance, and maintainability of the program as a whole. This is from my experience as a developer in business systems rather than a game dev. These types of objects tend to be convenient in the beginning but put serious constrains on the flexibility and and agility of the dev team in the long run. As the reliance on the god object grows, inertia builds and it becomes very hard to even think about making changes to the object for fear of the entire system breaking.

and to clarify, the entire purpose is to give a way for the game objects to be aware of their environment and this is how I'm planning on implementing it. I'm trying to avoid reinventing the wheel but I could not find any posts on the subject when googling so this is what I came up with after kicking the idea around with a few colleagues.

Added some clarification to the question itself.


text:
Age Rating: female nipples poking through clothing?
Pretty simple and straightforward question, what rating would a game get for something like this?

From which rating board in which country? Different cultures have very different ideas regarding which grade of lewdness is appropriate for which age group.

I guess ESRB and/or Pegi? Those seem to be the most common.

Ironically, the question is neither simple nor straightforward. Things like context are considered, e.g., whether the depiction is sexualized or not. There isn't a specific rule like "+1 age points per obvious nipple" or anything like that; it's all subjective and can depend on all kinds of factors outside your control, like the mood of the reviewer and how good your team is at arguing appeals to the review board. If you're worried about ratings, don't ask how to toe the line; just stay the hell away from the line in the first place. :)

As far as I know, erect nipples covered by clothing isn't differentiated by sex for rating purposes. But there's almost never any guarantee with the rating review boards: It's very subjective and often depend on the overall context.

The age rating system for games and movies is not just a max() function where the highest offending item sets the rating.
Some things will automatically give you an Adult-Only rating and some will automatically go to PG or Teen, but there's a vague point system for intermediate ratings.
These rules changes often and some of the items are somewhat subjective and will be slightly influenced by the reviewer and the target market. Australia, America, Europe, China, Korea, and Japan to name a few regions all have different rating/point systems. It also depends on cultural factors and current political mood.
The answer is there is no answer: For the final items it's often a back-and-forth with the review board (eg: "tone down one of those 3 items") to reach the target age rating.
Poking nipples (regardless gender) are generally around the everyone/teen (age 10-14) rating range due to the surrounding context and overall tone of the game that often goes with it but adding too many other risqué items can raise the rating and even then it varies by cultural region.


text:
How does ESRB content rating work for new FREE content?
Very similair to my earlier question, however this deals with games that have new free content released later down the line, not paid DLC. Let's say, again like with the last question, you release new content that would push the game's rating to "Mature" when it was previously "Teen". The content is automatically added to the base game for free.
What would happen? Would the base game be pushed to the higher rating, since it now comes with more mature content, or will it not be updated at all? Or do I have to disclose the planned content to the ESRB in advance so they can already give me a higher rating than the base game would get? I don't want to hide anything, so I would give them that info if it was better in the long run.

The ESRB doesn't care about the price of the content. They also don't really care about the distinction between content that a customer can choose to install (free or not) and updates to the game that are automatically applied.
In both cases, the extra content package is treated the same way. The content only needs to be submitted if it would exceed the rating of the base game, otherwise it inherits the rating of the base game.
If the new content changes the rating, and the base game is otherwise made unavailable without the new content, then effectively yes - the base game's rating is changed.

And sometimes the ESRB even re-rates your games based on content you didn't actually release yourself.

@Philipp Technically, they did release the content, it was just inaccessible. Modders just made accessing the game possible.


text:
Procedural planet to sphere texture
I'm making a 4x space game. I have a procedurally generated galaxy with planets in 3D space. The view is above the planet plane at -45 dec y-up i.e 45 deg isometric. I procedurally generate the planet surfaces on a hex grid which can be viewed 2D / 2.5D when clicking on the planets, ala GalCiv etc by placing meshes for mountains, seas, forest and so on on the hex grid.
For realism, I'd like the textures of the planets when viewed from space to (at least roughly) mirror the view you get in the surface view. I'm struggling to think how this might be achieved in Unity.
I figure I could create a render texture after generating the planet's surface and store it on the users HD. This has a few problems though - taking up HD space and not mapping well to a sphere (unless I always make the poles a uniform colour, which doesn't look good as the rest of the surface is quite highly detailed).
Another idea would be to create many generic textures for the space view of roughly each type of planet generated (blue / green / large continent / archipelago etc) and select a texture which most closely fits the procedurally generated map at run time. As long as the same texture isn't used for planets close to each other and the user doesn't compare the 3D view with the 2D view to closely then hopefully they won't notice!
So, any other ideas of how this might be achieved? I'm not looking for code, just a brainstorm of how I might get a procedural 2D map to be represented on a 3D sphere, or at least create a convincing illusion.

Can you include an example of what your planet surfaces look like in your hex grid form? This might help inspire some solutions.

If you are content to not allow full 3D motion around the planet (ie, fly a ship around the planet to arbitrary locations), you might take the approach outlined in this post I did a long time ago...
3D Illusion of a 2D Planet Texture
It creates somewhat the illusion of 3D from a 2D map texture and works fairly well if your camera view is at the equator.   If you want to be able to actually fly around the planet it's not so useful.  You could simulate orbiting around the equator of the planet pretty well, but not pole to pole.

Thanks, I should have mentioned the view is -45 deg y-up isometric. I'll update the post. Maybe though I could billboard the planet sphere to the camera....

@Absinthe I'll also point out DMGregory's answer from a while back. It's side-on as well, but has some different approaches and animated comparisons.


text:
Understanding unknown mesh data structure
I have a large number of old mesh files in a custom, undocumented binary format. I have managed to parse almost everything but am left with one group of structures, described below, that I don't understand. I hope an experienced graphics programmer can explain what is happening.
Here are the structures concerned:
// These types are defined below. We're trying to understand what
// these three arrays are used to achieve.
VertexRef vertexRefs[];
Triangle triangles[];
Unknown unknowns[];

struct VertexRef {
    // Earlier in the file, there are several vertex buffers.
    // The file can contain multiple meshes, either as components
    // of a larger mesh, or as multiple LODs.
    // This value _group_ picks out one of these buffers.
    uint8_t group;
    // Index into the vertex buffer picked out by _group_.
    uint16_t vertexIndex;
};

struct TriangleVertex {
    // Index into the array _vertexRefs_
    uint16_t vertexRef;
    // Index into the array _unknowns_
    uint16_t unknownIndex;
};

struct Triangle {
    TriangleVertex verts[3];
};

struct Unknown {
    // Index into the array _vertexRefs_
    uint16_t vertexRef1;
    // Index into the array _triangles_
    uint16_t triangleIndex1;
    // Another index into the array _vertexRefs_
    uint16_t vertexRef2;
    // triangleIndex2 can be 0xffff, while triangleIndex1 never is
    uint16_t triangleIndex2;
};

The array of VertexRef is straightforward. It picks vertices, potentially from multiple meshes, to form a composite mesh.
The array of Triangle is formed by vertices from the array of VertexRef. Each vertex is also associated with an Unknown.
I am out of my depth in understanding what Unknown is doing. Member triangleIndex2 sometimes being 0xffff (or invalid, or nonexistent?) might indicate it is a leaf node of a tree? Perhaps the structure comprising the arrays vertexRefs, triangles and unknowns is some kind of collision detection tree?
I'd be very grateful for any hints. Please ask questions if I've failed to be clear enough about something.
Edit: In answer to a request in comments, I am attaching a sample file and code to load it. The code should run on any likely system. The file is a mesh of a pair of boots. The file is hosted at uploadfiles.io: https://ufile.io/w66mh

it could be defined quads. - an index of triangles that are attached together or something. other than that, I can't think of a reason to relate two random triangles on a mesh.

Would it be useful to you to see a dump of some sample data? For example, I could find a very simple mesh, then include a picture of the mesh and do a text dump of the associated vertexRefs / triangles / unknowns.

Can you post an example file or how you load the data into these?

@Bálint, I have attached an example file and code to load it. I hope this helps. Thanks for the interest.

the 0xffff I have seen where it defines the end of a triangle strip.  That's my previous experience.  That would be inline with API standards I have seen or similar.


text:
Multiple rendering back ends architecture
so I've been thinking about designing a rendering engine with multiple back ends in C#.
Well, let me rephrase; I wish to design an engine that can be easily extended upon to support multiple back ends. My primary goals is to use OpenGL, but maybe later I might to add support for DirectX or a software renderer.
So i was thinking about how I might achieve this and think I've come up with a pretty decent design, here it is (in code, just cause it's best to see the design visually)
Firstly, the interfaces
/// <summary>
/// Defines an interface for low level rendering methods.
/// </summary>
public interface IRenderContext
{
    void Clear(bool colorBuffer, bool depthBuffer, bool stencilBuffer);

    // One a side note, should all the methods below be in some kind of resource manager???

    // Now for each type of resouce that can be used by the render context, lets
    // create and return an interface, rather than an object so that users don't have
    // to see an ugly class like "OpenGLMesh" or "DirectXRenderTarget".

    IMesh CreateMesh(Vertex[] vertices, int[] indices);

    ITexture CreateTexture(int width, int height, char[] pixelData);

    IShader CreateShader(ShaderType shaderType, string shaderSource);

    IRenderTarget CreateFrameBuffer(int width, int height);
}

/// <summary>
/// Defines an interface for high level rendering functions.
/// </summary>
public interface IRenderDevice
{
    // Lets contain the render context to make our lives easier
    IRenderContext RenderContext { get; }

    void DrawMesh(Transform transform, IMesh mesh, ITexture texture);

    // and other methods that are on more of a higher level would go here
}

and finally the way it would be used is like this:
IRenderContext renderContext = new OpenGLRenderContext();
IRenderDevice renderDevice = new OpenGLRenderDevice(renderContext);

ITexture texture = renderContext.CreateTexture(640, 480, pixelData);
IMesh mesh = renderContext.CreateMesh(vertices, indices);
renderDevice.DrawMesh(transform, mesh);

Is this a bad design? Am I missing something? What can I do to improve the architecture.

Largely echoing Josh, I think this is very difficult to do. After all, if we could generalize abstractions that allow us to write code against any kind of backend while still being able to express what we want to do at the low-level of what primitives to render and so forth, we'd all be writing code against such an abstraction and there'd be little point to writing code specifically for OpenGL or DirectX or anything else.
Instead a much easier thing to do typically is abstract your game state instead of the renderer. Then you can have multiple concrete rendering backends that render such state, and such implementations would be free to do whatever since they don't have to conform to any abstraction.

It looks incomplete and/or overly-simplified. It consequently probably won't scale up very well to more complex rendering scenarios. It probably won't work well for anything but the first rendering backend you build for it, either.
Texture and buffer resources are pretty similar, conceptually, across most rendering APIs: they're the easy part. State management beyond those resources are usually where things get complicated and fiddly to port between APIs, and your abstraction doesn't account for that at all. Even with the resources you're not accounting for all the varied usage modes and behavioral control flags a robust API is going to want - can this be read on the CPU, can it be bound as a render target, where does it exist in GPU memory, et cetera.
It's a reasonable start, and continuing along this path will be very educational for you. I suggest you simply proceed, keeping aware that you'll have to refactor the design as you want to write more complex rendering code, and as you port it. I'd also suggest that if you really want to make this kind wrapper you immediately being implementing it in more than one backend (say, OpenGL and D3D). Pick one you like better, build parts of your API in that backend first, and then try making it work with the other backend. You should discover pretty quickly where there are interesting differences that challenge your assumptions and force you to refactor your design, and that will ultimately lead to a much better API.
It will also make it much less daunting (and more likely that you'll actually finish) to have it work on two different rendering backends if you can develop them mostly in lockstep.
You may want to take a look at other API abstractions; sokol is in C, but it's a pretty good, minimal example you can look at. BGFX is a bit more complex.

After allot of searching, I've found something scales nicely and is quite simple to expand.
Here's a link, if you follow it you'll also a few articles on the topic and how it was designed, it's pretty much a tutorial.
https://github.com/amesgames/RenderDevice/tree/develop


text:
How does OpenGL know which buffer to draw?
I have been trying out some OpenGL things and was wondering something:
How does OpenGL know which buffer to draw when glDrawElements is called (since there are three)?
Here's a code snippet (from a tutorial):
    // Use our shader
    glUseProgram(programID);

    glm::vec3 lightPos = glm::vec3(4,4,4);
    glUniform3f(LightID, lightPos.x, lightPos.y, lightPos.z);
    glUniformMatrix4fv(ViewMatrixID, 1, GL_FALSE, &ViewMatrix[0][0]); // This one doesn't change between objects, so this can be done once for all objects that use "programID"

    glm::mat4 ModelMatrix1 = glm::mat4(1.0);
    glm::mat4 MVP1 = ProjectionMatrix * ViewMatrix * ModelMatrix1;

    // Send our transformation to the currently bound shader,
    // in the "MVP" uniform
    glUniformMatrix4fv(MatrixID, 1, GL_FALSE, &MVP1[0][0]);
    glUniformMatrix4fv(ModelMatrixID, 1, GL_FALSE, &ModelMatrix1[0][0]);

    // Bind our texture in Texture Unit 0
    glActiveTexture(GL_TEXTURE0);
    glBindTexture(GL_TEXTURE_2D, Texture);
    // Set our "myTextureSampler" sampler to use Texture Unit 0
    glUniform1i(TextureID, 0);

    // 1rst attribute buffer : vertices
    glEnableVertexAttribArray(0);
    glBindBuffer(GL_ARRAY_BUFFER, vertexbuffer);
    glVertexAttribPointer(
        0,                  // attribute
        3,                  // size
        GL_FLOAT,           // type
        GL_FALSE,           // normalized?
        0,                  // stride
        (void*)0            // array buffer offset
    );

    // 2nd attribute buffer : UVs
    glEnableVertexAttribArray(1);
    glBindBuffer(GL_ARRAY_BUFFER, uvbuffer);
    glVertexAttribPointer(
        1,                                // attribute
        2,                                // size
        GL_FLOAT,                         // type
        GL_FALSE,                         // normalized?
        0,                                // stride
        (void*)0                          // array buffer offset
    );

    // 3rd attribute buffer : normals
    glEnableVertexAttribArray(2);
    glBindBuffer(GL_ARRAY_BUFFER, normalbuffer);
    glVertexAttribPointer(
        2,                                // attribute
        3,                                // size
        GL_FLOAT,                         // type
        GL_FALSE,                         // normalized?
        0,                                // stride
        (void*)0                          // array buffer offset
    );

    // Index buffer
    glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, elementbuffer);

    // Draw the triangles !
    glDrawElements(
        GL_TRIANGLES,      // mode
        indices.size(),    // count
        GL_UNSIGNED_SHORT,   // type
        (void*)0           // element array buffer offset
    );

I have absolutely no idea how it would possibly know that the first buffer is the one that contains the vertices, and the others non-drawable information like UVs.
Can someone help me with this?
Thanks

How does opengl know which buffer to draw when glDrawElements is called(since there are 3)?

It uses all three; it uses all the buffers you enabled, bound and referenced. They're all "drawable information."

i have absolutely no idea how it would possibly know that the first buffer is the one that contains the vertexes, and the others non drawable information like UV's.

It doesn't. What OpenGL knows (because you tell it, via glVertexAttribPointer's first argument) is that the first buffer is assigned to attribute 0, and the second to attribute 1, and so on.
You also need to ensure these attributes match up with how you use the corresponding variables in your shader (the in-qualified variables). Generally you do this via glBindAttribLocation in your C++ code or by using layout(location = X) in the shader code. If you do neither of those, OpenGL automatically assigns them, which is somewhat brittle.

Thanks! But is okay if i let OpenGL assign them automatically?
Or will that cause problems?

As noted in that link, GL assigns them arbitrarily at program link time, so you may get unexpected results, particularly when you add a new attribute and now have to manually re-arrange everything to make sure they match up. It's probably okay for quick-and-dirty code, or whatever, but I don't recommend it. The effort involved in manually binding them via the "layout(location)" syntax is trivial and well-worth the peace of mind, in my opinion.

Ok, so where would i put that layout(location) in my file?
Or how do i use the glBindAttribLocation?

"layout(location = X)" goes in front of the variable in the shader, as noted in the link. The docs for glBindAttribLocation are here.

I took a look inside teh StandardShading.vertexshader that came with the tutorial and it contains this:
layout(location = 0) in vec3 vertexPosition_modelspace;
layout(location = 1) in vec2 vertexUV;
layout(location = 2) in vec3 vertexNormal_modelspace;
does that mean it is all ok?

Yes, that looks like it aligns with what you are using in the C++ code.

When glVertexAttribPointer is called opengl looks at the buffer bound to GL_ARRAY_BUFFER and associates that buffer to the attribute you are setting.

There is a second method to associate the buffer with the attributes using separate vertex format. (available from opengl 4.3+ or with the associated extension)
constexpr int vertexBindingPoint = 0;
constexpr int uvBindingPoint = 1;
constexpr int normalBindingPoint = 1;// free to choose, must be less than the GL_MAX_VERTEX_ATTRIB_BINDINGS limit

// 1rst attribute buffer : vertices
glEnableVertexAttribArray(0);
glVertexAttribFormat(
    0,                  // attribute
    3,                  // size
    GL_FLOAT,           // type
    GL_FALSE,           // normalized?
    0                   // attr offset
);
glVertexAttribBinding(0, vertexBindingPoint);

// 2nd attribute buffer : UVs
glEnableVertexAttribArray(1);
glVertexAttribFormat(
    1,                                // attribute
    2,                                // size
    GL_FLOAT,                         // type
    GL_FALSE,                         // normalized?
    0                                 // attr offset
);
glVertexAttribBinding(1, uvBindingPoint);

// 3rd attribute buffer : normals
glEnableVertexAttribArray(2);
glVertexAttribFormat(
    2,                                // attribute
    3,                                // size
    GL_FLOAT,                         // type
    GL_FALSE,                         // normalized?
    0                                 // attr offset
);
glVertexAttribBinding(2, normalBindingPoint);
//at this point the VAO is set up

//this can be done per mesh that uses the same vertex format while reusing the same VAO
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, elementbuffer);
glBindVertexBuffer(vertexBindingPoint, vertexbuffer, 0, 3*sizeof(float));
glBindVertexBuffer(uvBindingPoint, uvbuffer, 0, 2*sizeof(float));
glBindVertexBuffer(normalBindingPoint, normalbuffer, 0, 3*sizeof(float));

// Draw the triangles !
glDrawElements(
    GL_TRIANGLES,      // mode
    indices.size(),    // count
    GL_UNSIGNED_SHORT,   // type
    (void*)0           // element array buffer offset
);

this has the advantage of letting the driver know that the format doesn't change and it can avoid patching the vertex shader each time you change the vao.


text:
calculate the offset between a quad and the mouse position Opengl
I am working on a very simple "GUI framework" for my game.

As you can see from the GIF, i have a window object that can be selected when the mouse is inside of it and dragged, when the left mouse button is being pressed.
I tried to solve the problem this way:

Basically i calculate the x and y component of the distance between the center of the window and the mouse cursor. I then add the component values to the window function, which looks something like:
//mousePosition is a Vector2() that stores the mouse position
//x_component is a float, calculated by doing:
//float x_component = mousePosition.x - window.getPosition().x;
//same for the y_component variable.

window.setPosition(Vector2(mousePosition.x + x_component, mousePosition.y + y component));//set position takes in a Vector2

But for some reason, this is not working. I think that it's because we are not taking in consideration the fact that the x or y component could be negative, in relation to where we press the mouse inside the window.
Can someone help me?

Your .gif link appears to be broken.

If the idea is to click and drag the window then you are assuming that the coordinates of the mouse cursor relative to the upper-left corner of the window will be the same before and after the mouse moves.  So when you get a mouse-down event, record that offset: offset_at_grab_time = mouse_position_in_screen_coordinates - window_position_in_screen_coordinates.  Then, when the mouse moves you can update the window position to have the same relative offset to the mouse as when you grabbed it by setting the position such that  new_window_position_in_screen_coordinates = new_mouse_position_in_screen_coordinates - offset_at_grab_time
Ignore the center of the window; rather, you are interested in the position of the window in the same coordinate system as the mouse coordinates.

Okay, thanks for the answer! I'm going to test this out as soon as possible. Is there a particular reason why we store the position of the cursor relative to the upper left corner of the window instead of its center?

@GabrieleVierti No, It doesn't really matter.  It just makes the calculation of where the window postion all that much easier.  If the client rectangle is offset relative to the position of the window, then that's yet another offset you will have to take into consideration - and often mouse coordinates are given in client coordinates (relative to a point that is in the interior "client" portion of the rect, below the titlebar).  Whereas the window position itself is often (0,0) in window coordinates (relative to the top left corner outside the window - above the titlebar).


text:
How can I round out the corners of a quad in OpenGL?
Even though I think the image is pretty self-explanatory, I'm going to explain what I am trying to achieve:

I was working on a game, and I needed a GUI framework, that I decided to build myself. As a first thing, I tried rendering a simple 2d quad with an orthographic projection. I was not satisfied with the boxy shapes windows had, so I tried fixing the problem by adding a texture; all this worked until I tried implementing resizing: whenever I changed the window size, the texture was warping, and it did not look good. Now I'm trying to use more than just two triangles, to smooth the corners of the windows. Now, my question is: how can I determine the number of triangles each window should have to have in order to obtain smoother corners? I would like to have some sort of "smooth" variable, that specifies how smooth(how many triangles are used) the window is. Thanks everyone for the help
EDIT:
I was thinking about this: do you guys think that generating the vertices of the window based on a condition in real time would be a good idea?
something like(proto code):
if(smooth == 1)
{
    //define quad vertices
    float vertices[] =
    {
       bla,bla,
       bla,bla,
       bla,bla....
    }
}

if(smooth == 2)
{
    float vertices[] =
    {
       bla,bla,
       bla,bla,
       bla,bla....
    }
}

In a way, this would work, but I'm pretty sure there is a much better way to do this...

Do you want to do this with geometry, or would 9-slicing be an option?

@Tyyppi_77 i'd like to do it with the geometry

@Tyyppi_77 but slicing could be an option :D haha

Geometry is generally not such a great idea. Tiny triangles cause useless fragment processing and ROP and as such are just as expensive (or more expensive) than having a fragment shader with discard or just using a simple texture as alpha mask in a 9-slice (which is much more flexible and easily skinnable without technical knowledge, or computional overhead). Use a distance field texture if you want to be fancy and feel like corners must be super, super round and perfect regardless of resolution.

This is not technically an answer to your question, but is a better work around in my opinion.
You can pass the dimensions of the boxes and the radius of the corners to the fragment shaders and round the corners that way.
Basically, you take the current texture coordinates, multiply each coordinate of it by the dimensions of the window to get the coordinates of the current fragment relative to the window. Then if the distance between this position and each of the edges is less, than the radius of the corner, then you throw it away.
This way you don't need to upload separate vertices for each window.
Sample code in GLSL (I don't know what you're using)
in vec2 a_uv;

uniform vec2 u_dimensions;
uniform float u_radius;

void main(void) {
    vec2 coords = a_uv * u_dimensions;
    if (length(coords - vec2(0) < u_radius ||
        length(coords - vec2(0, u_dimensions.y) < u_radius ||
        length(coords - vec2(u_dimensions.x, 0) < u_radius ||
        length(coords - u_dimensions) < u_radius) {
        discard;
    }
    // Do everything else otherwise
}

I will definitely try this out, thanks ;) i was trying to imitate dear Imgui, which uses triangles, instead of smoothing corners via fragment shader(that's why I wanted to use vertices :P)

this works, but what if i don't want to use textures?

This approach doesn't use textures?

@GabrieleVierti  There are no textures, you don't need a texture to have texture coordinates associated with vertices.  In vec2 a_uv; would be a vertex attribute for each vertex corner of your gui box, IE (1,1) (1,0) (0,1) (0,0).  GLSL tells the gpu to automatically interpolate between those values for each sub-rectangle position.

Sure haha i wasn't thinking :D

Nice answer! This is great because it scales nicely and allows further improvements like anti-aliasing on the edges.

How does this generate rounded corners? Doesnt this generate a "mirrored" rounded corner? Shouldnt all the < signs be changed to > ?

The main problem with drawing round 2D objects using 3D geometry is that there's no real fixed mapping between the pixels on the screen and the 3D world-space. Making sure they look at all resolutions and various transformations can get really tricky real fast, and you don't really want to spend time on something that doesn't really improve the game quality. But you're right that you can't stretch a single texture and get a good effect either.
One typical way this is done in 2D GUIs is 9-sliced scaling. Instead of having one logical texture, you have nine - one for each corner, one for each edge and one for the rest. The corners aren't scaled at all, only moved to their proper place. The edges are repeated (or sometimes scaled) in their proper direction (e.g. the top edge will be repeated in the X-direction). The center is repeated in both directions. This allows you to resize the window at will.
If you want to keep 3D geometry, pixel shaders sound like the best way to go - after all, you're trying to scale the effect to the screen, not the world-space. Drawing a simple circle section is trivial with just a bit of math, though making sure you get good looking anti-aliasing etc. can make this trickier. The main advantage over the texture method is you can arbitrarily scale it without stretching the textures; the main disadvantage is that you'll only ever do very simple patterns (and the more complicated the pattern, the more taxing to the GPU). Of course, you can also combine both approaches - have a texture that's applied to the "solid" parts of the window but not the transparent parts, and repeated as needed.

See https://gamedev.stackexchange.com/a/153787/99481, where none of this is actually a problem and using what you propose is both more computationally expensive and more complicated.

Thanks for the asnwer! I might try this out, i just have one question though... how would i go for applying textures to the edges and corners of the window? Shouldn't i use more textured quads? Or have more texture coordinates relative to the window?

@GabrieleVierti Multiple textured quads work great, yeah. You can also simulate it in the pixel shader, but that's probably more trouble than it's worth.

@snb I have no idea what your point is - he's also using a pixel shader, not geometry. Are you saying I should copy other answers' solution? Are you trying to say that drawing simple 2D quads is an overkill for rendering a 2D UI, while using 3D geometry is the perfect solution? Or that I should only present one solution? The 9-slice approach is a lot more flexible - it allows arbitrary window graphics. Maybe Gabriele needs that flexibility, maybe he doesn't. The answers are there for other people too anyway, though.

@snb Mind you, I wouldn't have included the PS example at all if I realised that's what's Bálint describing - a bit of a terminology mixup, I've never worked much with "modern" OpenGL. But given that it's right there in my answer, your comment is all the weirder - you're pointing to the exact same solution and complaining I dismissed it...

I'll extend on Bálint's excellent answer by adding my own idea of a possible fragment-shaded approach:
in vec2 vUV;

uniform vec2 uExtents;
uniform float uRadius;

float calcDistance() {
    vec2 coords = abs(vUV) * (uExtents + uRadius);
    vec2 delta = max(coords - uExtents, 0);
    return length(delta);
}

void main() {
    float dist = calcDistance();
    if (dist > uRadius) discard;
    /* ... */
}

Here I take as inputs the vertex UV vUV ∈ [-1, 1] × [-1, 1], rectangle extents uExtents = (width/2, height/2), and the corner radius uRadius. From these we produce a distance to the rectangle where 0 represents inside and all other (positive) values represent outside.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
How do i set up 9-slicing in Opengl?
What is the ideal way to set up 9-slicing?
(for the people who don't know what 9-slicing is)
Let's say we have a quad, with a texture applied to it.
9-slicing is basically a way of dividing a texture in 9 parts.
The reason why we do this is to have a quad with a texture, that can be resized without the issue of having the texture all warped. we divide the edges, the corners, and the main body of the texture:

As can be seen in the pictures, we have a quad that can be scaled without warping the texture

which would look something like this(no 9-slicing):

Now, to come back to my question: How should i set up 9-slicing? should i have a multiple quads(one for the center part, one for the right edge, one for the left edge....) but then how do i specify the different texture coordinates for each quad? Another way would be to just create the quads with their texture coordinates and relative textures and then move them all toghether like a whole object. I hope someone explain me a little more about this "9 slicing" approach, since I've never used it before. Thanks everyone for the help
EDIT: (to answer HolyBlackCat)
"Another way would be to just create the quads with their texture coordinates and relative textures and then move them all toghether like a whole object."
What i wanted to say is this: I create separate quads, attach separate textures to them, render and move them at the same time:

This is, in my opinion, the most logical way to do this. Despite that, I still want to know what would be a better, faster way to do this, without having to have too many vertices for a quad

Surely you need 9 quads. "how do i specify the different texture coordinates for each quad" What do you mean? It's no different from drawing a single textured quad 9 times. "Another way would be to just create the quads with their texture coordinates and relative textures and then move them all toghether like a whole object" I don't understand this part, can you elaborate?

@HolyBlackCat (to answer the first thing) Textures coordinates range from 0,0 to 1,1 right? even if I do specify the texture coordinates for each quad, how do i assign the different textures to the correct quad?

Replying to the edit: Either way you end up with 9 quads. Making 9 textures looks like a waste to me, I would use a single one. Also it's easier to draw it this way. "how do i assign the different textures to the correct quad" I still don't understand the question. Are you asking how to convert pixel coordinates for a texture to the 0,0 .. 1,1 range? Or do you understand how to do that, but rather ask how to compute those coordinates for 9-slicing? Or do you ask how quad corners should be positioned?

@HolyBlackCat i want to understand how to conpute the texture coordinates for 9 slicing. Otherwise, i would have to define both vertices and texture coordinates by myself. Once i am able to compute the texture coordinates, how do i use multiple textures? I mean, how do i wrap to each qua a different texture? And how should i pass it to the fragment shader? At this point i think using 9 different quads would be the easies way...

Again, you have to use 9 quads. You can write an intricate shader that will do it on a single quad instead, but that seems like an overkill. "how do i use multiple textures" Again, don't use multiple textures, use a single one. Do you understand how draw a single textured quad, but using not an entire texture, but rather an arbitrary rectangular portion of a texture?

I've never used just a portion of a texture, only a whole texture on a single quad. Could you explain me the overkill way, of creating a shader that'd get the job done on a single quad?

Let us continue this discussion in chat.

The 2 methods (using 1 quad or using 9 quads) is basically a trade-off between using extra CPU time (9 quads) or using extra GPU time (1 quad).
In my opinion the 1 quad method is much better, so I'm going to include it here, if you want the other solution, then I'll add that too.
So, you'll need a border width on the 9-slice texture, the border width on the GUI and the texture coordinates. Before doing anything, you'll need to project the border width of the window to the UV coordinates. This would look something like this:
uniform vec2 u_dimensions;
uniform float u_border;

// Later before other operations
vec2 borders = vec2(u_border) / u_dimensions.xx;

// Use borders.x for the x axis and borders.y for the y axis

So, you should deal with the 2 axes separately, because they are largely the same. First, if the coordinate on the current axis is less, than the width of the window's border,  then you can leave it as it is. If it's less, than 1 - borders.x if you're dealing with the x axis or 1 - borders.y if you're dealing with the y axis, then you'll need to scale it a bit. Here's where the border size on the 9-slice texture comes into play. Basically, you'll need to map the values between textureBorder and 1 - textureBorder where textureBorder is the width of the border on the 9-slice. And lastly, if the coordinate on the axis is more, than 1 - borders.[x/y], then you'll need to map it between 1 - textureBorder and textureBorder. Since the map function doesn't exist in glsl, here's a replacement:
float map(float value, float originalMin, float originalMax, float newMin, float newMax) {
    return (value - originalMin) / (originalMax - originalMin) * (newMax - newMin) + newMin;
}

You use it as a traditional map function. So, together, the code would look like this:
// Helper function, because WET code is bad code
// Takes in the coordinate on the current axis and the borders
float processAxis(float coord, float textureBorder, float windowBorder) {
    if (coord < windowBorder)
        return map(coord, 0, windowBorder, 0, textureBorder) ;
    if (coord < 1 - windowBorder)
        return map(coord,  windowBorder, 1 - windowBorder, textureBorder, 1 - textureBorder);
    return map(coord, 1 - windowBorder, 1, 1 - textureBorder, 1);
}

void main(void) {
    borders = vec2(u_border) / u_dimensions.xx;
    vec2 newUV = vec2(
        processAxis(a_uv.x, u_textureBorder, borders.x),
        processAxis(a_uv.y, u_textureBorder, borders.y)
    );
    // Output the color
    o_colour = texture(sampler, newUV);
}

Quick note: if you define your GUI windows, as 3 units wide and 2 units tall and you want the border, to occupy the 1/30 of the horizontal space, then you need to pass 0.1 as the windows border width.