Members see less ads - sign up now for free and join the community!
At this point, until SE flat out says this is the final build, I'm just going to assume it's one of their million other dev builds. It's gotten to the point that I play bingo with the emotional roller coaster this game causes every time something new comes out, lol. (double points for every time someone says "jaggies")
Likes:
LeonBlade
Yea I am with you on this. It's kind of ridiculous that they can't just come out and show us some of the final build. I don't think I have ever seen a game developer have so many builds of a game and not show off the final one this close to release before. This game has had the strangest development structure I have ever seen.
Likes:
LeonBlade
This is not really correct. Developers create new builds of the game many times when working on a project, even up until the release the game will still be undergoing many builds, especially towards the end because they will be doing a lot of play testing and a lot of bug fixes and optimizations. To say that they should have a "final" build by now comes from ignorance about development. That is not meant to be an insult to you by any means, it just means that you are not aware of how these things operate.
What a build is referring to is when you compile the code for your project and it creates a single executable that can be run, that's referred to as a "build". Let's say you just ran the most current build on the stable branch of the game and suddenly you noticed that whenever you used this one ability in the game that you're getting this huge performance hit over time. So, you open up some profiling tools and realize there's a memory leak happening, so you start debugging the build and you realizing that the ability was made wrong and none of the memory that get allocated from using this ability was ever freed and so every time you use the ability it just eats more and more memory. So, you fix the code and you create a new build for the game, and now you fixed the bug.
This scenario is just simplified to make it easier to understand, in reality this sort of thing likely wouldn't happen specifically for reasons I won't get into due to the complexity of the explanation, but I think you can understand how this workflow breaks down. It's very common to create thousands of builds of a game, especially one this large, and isn't at all uncommon in game development.
The reason you often see a lot of different older builds being shown off is because they are more stable, I made a reference to something I called "stable branch", what I was alluding to was a branch from the repository for the game's engine. A repository (repo for short) in development is version control software, commonly used versions are GIT and SVN for example. The way you use a repo in development is by "committing" changes from your codebase to this repo which stores only the changes in the files to cut down on how much space it takes up.
For example, if you refactored a huge chunk of the engine, but it ultimately was only changing a few names of specific words or a couple line changes here and there across 1,000+ files, instead of saving a copy of 1,000+ files somewhere, you only save the exact changes additions or removal of lines etc.
Commonly, when working on experimental changes or big changes to the engine which might break other parts without further testing, you create something called a "branch". If you wanted to make large changes to let's say the AI, you would create a branch for this so that you could commit your changes and have them saved, then later on when they become more stable, you can merge them into the main branch so that it can be apart of the main project.
What this means is for many presentations and public appearances, you will see older more stable builds being used as they are less likely to crash and are known to be stable, but may not have all the new features that are currently being worked on. It's very possible that you will see a build of the game that is actually somewhat behind what is being worked on in development that is mostly stable but has yet to be merged.
The point of me explaining version control software and technical things like this is to show you and others who might be unaware that having many builds in a project is a part of development, in fact, the less builds you have of a game, the more likely it's going to be a failure as that means you are not using version control software properly, or you are not doing much development on the game at all.
I hope that I made sense with my technical explanations and that you might understand a little more. The big difference between FFXV showing off their development more than other games has to do with the game's origins when we would go entire years without even reading about the game let alone seeing it. Ever since the rebranding, there has been a major shift within SE to show this game as much as possible and to be very upfront about the development. Tabata has done a lot for this game, and even has radically changed the way many current Japanese business structures operate in order to bring new life into BD2 to achieve a more productive work environment, and showing off their technology so openly and even admitting things like frame drops and performance is a testament to their passion for this game and to always be upfront and honest.
For me, I really love seeing the behind the scenes look at video games, it's something I miss from back in the day from things like PlayStation Underground where they would show games in development or a look at a game dev studio where you can see all their software on screen and learn about how these games achieved their technical accomplishments.
I'm going to stop rambling now...
What a build is referring to is when you compile the code for your project and it creates a single executable that can be run, that's referred to as a "build". Let's say you just ran the most current build on the stable branch of the game and suddenly you noticed that whenever you used this one ability in the game that you're getting this huge performance hit over time. So, you open up some profiling tools and realize there's a memory leak happening, so you start debugging the build and you realizing that the ability was made wrong and none of the memory that get allocated from using this ability was ever freed and so every time you use the ability it just eats more and more memory. So, you fix the code and you create a new build for the game, and now you fixed the bug.
This scenario is just simplified to make it easier to understand, in reality this sort of thing likely wouldn't happen specifically for reasons I won't get into due to the complexity of the explanation, but I think you can understand how this workflow breaks down. It's very common to create thousands of builds of a game, especially one this large, and isn't at all uncommon in game development.
The reason you often see a lot of different older builds being shown off is because they are more stable, I made a reference to something I called "stable branch", what I was alluding to was a branch from the repository for the game's engine. A repository (repo for short) in development is version control software, commonly used versions are GIT and SVN for example. The way you use a repo in development is by "committing" changes from your codebase to this repo which stores only the changes in the files to cut down on how much space it takes up.
For example, if you refactored a huge chunk of the engine, but it ultimately was only changing a few names of specific words or a couple line changes here and there across 1,000+ files, instead of saving a copy of 1,000+ files somewhere, you only save the exact changes additions or removal of lines etc.
Commonly, when working on experimental changes or big changes to the engine which might break other parts without further testing, you create something called a "branch". If you wanted to make large changes to let's say the AI, you would create a branch for this so that you could commit your changes and have them saved, then later on when they become more stable, you can merge them into the main branch so that it can be apart of the main project.
What this means is for many presentations and public appearances, you will see older more stable builds being used as they are less likely to crash and are known to be stable, but may not have all the new features that are currently being worked on. It's very possible that you will see a build of the game that is actually somewhat behind what is being worked on in development that is mostly stable but has yet to be merged.
The point of me explaining version control software and technical things like this is to show you and others who might be unaware that having many builds in a project is a part of development, in fact, the less builds you have of a game, the more likely it's going to be a failure as that means you are not using version control software properly, or you are not doing much development on the game at all.
I hope that I made sense with my technical explanations and that you might understand a little more. The big difference between FFXV showing off their development more than other games has to do with the game's origins when we would go entire years without even reading about the game let alone seeing it. Ever since the rebranding, there has been a major shift within SE to show this game as much as possible and to be very upfront about the development. Tabata has done a lot for this game, and even has radically changed the way many current Japanese business structures operate in order to bring new life into BD2 to achieve a more productive work environment, and showing off their technology so openly and even admitting things like frame drops and performance is a testament to their passion for this game and to always be upfront and honest.
For me, I really love seeing the behind the scenes look at video games, it's something I miss from back in the day from things like PlayStation Underground where they would show games in development or a look at a game dev studio where you can see all their software on screen and learn about how these games achieved their technical accomplishments.
I'm going to stop rambling now...
I appreciate the response and yes it has been helpful in understanding a bit more about it. I am not completely ignorant on this subject but you clearly know more about it. They have said they were showing the final build at E3 which is why I said what I said. I am pretty sure they said this also for the Uncovered event but that ended up not being the case. It just seems that they keep saying they will show it and then when we think we are seeing it they say to wait for another event for the final build.
Likes:
LeonBlade
I mean, in general people work on different features on different branches. There are multiple repositories for any large project, and each of those have a huge working tree to avoid any conflicts with what someone else might be working on. It's not unreasonable to have different version through source control. It's very common.
Likes:
LeonBlade
Someone on Twitter asked them a while back if they were showing the final build soon and they replied with "wait for E3". Just to clarify when I say "build" I'm talking about the build of Luminous they are using. Remember when they weren't done transfering the assets from the Ebony Engine to the Luminous Engine?. Duscae build was called Luminous 1.0 and they aimed to get it to 2.0 for the final game. I think what you are thinking of as "final build" is the complete finished game and that wasn't what I was really referring to. We should at least have some picture of what the final build would look like this close to release. The quality of the footage and screenshots we have gotten in the last couple years have fluctuated a lot in my opinion and it's really hard to see what we are actually getting. I usually don't see other games go through this as much is all I was saying before.
It's cute now, but just wait until it's grown...
Likes:
Koozek
