Any chance on complete engine overhaul?

[Razze]

Is there any chance we are going to be able to fix this games engine? Non fps tied game speed and such. Full sourcecode editing.
I would be interested in having a poke around there, but currently have no idea how I am supposed to open these ascii art looking DLL files.

[Arpente Reves]

That would require an absurd amount of work for what the game is. I'm not saying that it's dead, nobody is buying it anymore, but even for a game with lots of players and bringing lots of money, this is a comicaly big task

[Razze]

Originally posted by Arpente Reves:

That would require an absurd amount of work for what the game is. I'm not saying that it's dead, nobody is buying it anymore, but even for a game with lots of players and bringing lots of money, this is a comicaly big task

Ofcourse, I am not asking for people to do stuff about it, moreso the oppurtunity to be able to do something about it. As far as I understand only some files are moddable. Would be nice if CF would release a full SDK for the game.

[Azure Fang]

I don't think you comprehend exactly what you're asking.

To have total source code editing, the game would need be available as source to begin with, something that is an extreme threat to a retail-centric product; a game available as source could be recompiled by anybody, bypassing the need to buy the game. What is currently exposed to modding is extensive, to the point that there is comparatively little that cannot be modded.

As to an "engine overhaul", I have to laugh every time someone even suggests that in any game. An engine overhaul is no small undertaking. As an example, the Viscera Cleanup Detail engine overhaul is (roughly) expected to take three to five years, and that's just for the engine; once the engine has been overhauled, the assets must then be either overhauled or entirely recreated to conform to the new engine. Engine changes of that magnitude run significant risk of changing system requirements, meaning previous buyers may no longer be able to play the product they've purchased; this is one of the reasons most games add new API support rather than replacing it in an overhaul, and for the most part only macOS users are ever under threat of losing access to software under continual development more due to Apple's disregard for its userbase when "improving" the OS.

Now, going in and trying to fix issues with the existing engine might be possible, but to begin with that should never be the community's job until the game has hit its end of development/support and market viability (EoL - end-of-lifecycle), which Starbound apparently hasn't yet if continued console development news says anything. Releasing a game's source is rarely done, and only after the game is no longer market viable (traditionally 10-20 years after the game ends effective sales, if ever), and fan-made extenders, source patches, and source ports are usually created via legally-ambiguous reverse-engineering prior to source release.

In terms of your reply, we already have access to the "SDK" for Starbound - JSON and Lua were and are written with text editors like Notepad++ and Sublime Text (or, heaven forbid, Notepad), spritework was done in Aseprite but can be drawn in anything from Paint to GIMP at low pixel levels, and micro/dungeons post-PNG generation were and are drawn up in Tiled which outputs dungeons as mostly plain-text JSON. Short of the C+ (++? #? Iunno, one of those three) source, which is out of public reach, there is no dedicated SDK because the whole of the game was created using publicly available tools. This game doesn't have a toolkit like the TES or UDK kits because it literally doesn't need them. Also, don't confuse SDK with source editing. An SDK - Software Development Kit - is a dedicated toolkit for working within a given API; they do not touch the given software's source code and are often comprised of otherwise openly available tools. such as those that I've already mentioned.

[Razze]

Originally posted by Azure Fang:

I don't think you comprehend exactly what you're asking.

To have total source code editing, the game would need be available as source to begin with, something that is an extreme threat to a retail-centric product; a game available as source could be recompiled by anybody, bypassing the need to buy the game. What is currently exposed to modding is extensive, to the point that there is comparatively little that cannot be modded.

As to an "engine overhaul", I have to laugh every time someone even suggests that in any game. An engine overhaul is no small undertaking. As an example, the Viscera Cleanup Detail engine overhaul is (roughly) expected to take three to five years, and that's just for the engine; once the engine has been overhauled, the assets must then be either overhauled or entirely recreated to conform to the new engine. Engine changes of that magnitude run significant risk of changing system requirements, meaning previous buyers may no longer be able to play the product they've purchased; this is one of the reasons most games add new API support rather than replacing it in an overhaul, and for the most part only macOS users are ever under threat of losing access to software under continual development more due to Apple's disregard for its userbase when "improving" the OS.

Now, going in and trying to fix issues with the existing engine might be possible, but to begin with that should never be the community's job until the game has hit its end of development/support and market viability (EoL - end-of-lifecycle), which Starbound apparently hasn't yet if continued console development news says anything. Releasing a game's source is rarely done, and only after the game is no longer market viable (traditionally 10-20 years after the game ends effective sales, if ever), and fan-made extenders, source patches, and source ports are usually created via legally-ambiguous reverse-engineering prior to source release.

In terms of your reply, we already have access to the "SDK" for Starbound - JSON and Lua were and are written with text editors like Notepad++ and Sublime Text (or, heaven forbid, Notepad), spritework was done in Aseprite but can be drawn in anything from Paint to GIMP at low pixel levels, and micro/dungeons post-PNG generation were and are drawn up in Tiled which outputs dungeons as mostly plain-text JSON. Short of the C+ (++? #? Iunno, one of those three) source, which is out of public reach, there is no dedicated SDK because the whole of the game was created using publicly available tools. This game doesn't have a toolkit like the TES or UDK kits because it literally doesn't need them. Also, don't confuse SDK with source editing. An SDK - Software Development Kit - is a dedicated toolkit for working within a given API; they do not touch the given software's source code and are often comprised of otherwise openly available tools. such as those that I've already mentioned.

Very good reply!
I suppose my title is worded pretty poorly. Ofcourse I know you can't just do what is basically re-building the entire game engine from scratch. I was more referring to having access to poke around in it. I do know that game devs aren't just gonna handy dandy give out their own source-code uncompiled. But the points you bring up are very good. Ofcourse making an entire development kit for this game would probably not be in priority of interest for the developers. Modding asset wise is indeed already easy enough. However I do wonder how much modding is able to crack into how the game runs. Optimization mods, graphical mods, and such.
What do you think? Thanks again for your detailed reply :)

[Azure Fang]

Originally posted by Razze:

Originally posted by Azure Fang:

I don't think you comprehend exactly what you're asking.

To have total source code editing, the game would need be available as source to begin with, something that is an extreme threat to a retail-centric product; a game available as source could be recompiled by anybody, bypassing the need to buy the game. What is currently exposed to modding is extensive, to the point that there is comparatively little that cannot be modded.

As to an "engine overhaul", I have to laugh every time someone even suggests that in any game. An engine overhaul is no small undertaking. As an example, the Viscera Cleanup Detail engine overhaul is (roughly) expected to take three to five years, and that's just for the engine; once the engine has been overhauled, the assets must then be either overhauled or entirely recreated to conform to the new engine. Engine changes of that magnitude run significant risk of changing system requirements, meaning previous buyers may no longer be able to play the product they've purchased; this is one of the reasons most games add new API support rather than replacing it in an overhaul, and for the most part only macOS users are ever under threat of losing access to software under continual development more due to Apple's disregard for its userbase when "improving" the OS.

Now, going in and trying to fix issues with the existing engine might be possible, but to begin with that should never be the community's job until the game has hit its end of development/support and market viability (EoL - end-of-lifecycle), which Starbound apparently hasn't yet if continued console development news says anything. Releasing a game's source is rarely done, and only after the game is no longer market viable (traditionally 10-20 years after the game ends effective sales, if ever), and fan-made extenders, source patches, and source ports are usually created via legally-ambiguous reverse-engineering prior to source release.

In terms of your reply, we already have access to the "SDK" for Starbound - JSON and Lua were and are written with text editors like Notepad++ and Sublime Text (or, heaven forbid, Notepad), spritework was done in Aseprite but can be drawn in anything from Paint to GIMP at low pixel levels, and micro/dungeons post-PNG generation were and are drawn up in Tiled which outputs dungeons as mostly plain-text JSON. Short of the C+ (++? #? Iunno, one of those three) source, which is out of public reach, there is no dedicated SDK because the whole of the game was created using publicly available tools. This game doesn't have a toolkit like the TES or UDK kits because it literally doesn't need them. Also, don't confuse SDK with source editing. An SDK - Software Development Kit - is a dedicated toolkit for working within a given API; they do not touch the given software's source code and are often comprised of otherwise openly available tools. such as those that I've already mentioned.

Very good reply!
I suppose my title is worded pretty poorly. Ofcourse I know you can't just do what is basically re-building the entire game engine from scratch. I was more referring to having access to poke around in it. I do know that game devs aren't just gonna handy dandy give out their own source-code uncompiled. But the points you bring up are very good. Ofcourse making an entire development kit for this game would probably not be in priority of interest for the developers. Modding asset wise is indeed already easy enough. However I do wonder how much modding is able to crack into how the game runs. Optimization mods, graphical mods, and such.
What do you think? Thanks again for your detailed reply :)

"Being able to poke around it" unfortunately still relies on either exposed source or reverse-engineering. If Starbound were released as an open project with a retail precompile, such as the way Aseprite is (buy it precompiled or contribute to the github and compile it yourself for free) that would be really cool, but that just generally isn't feasible. That opening up to scrutiny just won't happen is a simple, if unfortunate, fact. Meanwhile, a portion of the industry has traditionally turned a blind eye to the legal ambiguity of reverse-engineering so long as it remains in the realm of fan-patching and extending (Script Extenders, GFWL disablers, etc.), but that has a much higher level of entry in terms of skill.

"Optimizing mods, graphical mods, and such" are already possible and some already exist. Starbound's rendering system literally just mass-loads PNGs which can be losslessly compressed (by nature of the filetype) and further compressed with tools (though you run the risk of damaging palette maps if you don't know what you're doing) which, as proven by OptimizeBound, can improve performance but at the cost of blocking other mods from modifying vanilla art assets. And numerous engine settings are already exposed that can be manipulated to hypothetically improve performance, however many of these (stack size, threads, etc.) are extremely dependent on individual user hardware.

Now, please don't get me wrong. First, thank you for being reasonable in the face of a counter; that's becoming so uncommon that I feel it's necessary to praise. Next, the engine is clunky as hell and I'm not trying to defend it. Running solo play on a local virtual server was a bad idea in terms of extended performance (as shown by the encroachment of "lag spikes" in solo play as the server calculates more and more script results as a save/universe gets larger). Tying calculation rate to frame rate has never been a good idea (though sometimes it's unavoidable). But these are the kinds of things that can't reasonably be changed even if we could dig into the engine's inner workings.

What would be more reasonable would be exposing more engine controls to external configuration and some actual documentation of what's already exposed; there are performance-bearing and engine-altering settings scattered among numerous configs, but next to no documentation for any of it in a game that was built specifically to support mod-culture. I honestly believe that if there was an official API document drawn up and updated, what would go significantly further than opening up the engine to scrutiny and this point.

[Razze]

Originally posted by Azure Fang:

Originally posted by Razze:

Very good reply!
I suppose my title is worded pretty poorly. Ofcourse I know you can't just do what is basically re-building the entire game engine from scratch. I was more referring to having access to poke around in it. I do know that game devs aren't just gonna handy dandy give out their own source-code uncompiled. But the points you bring up are very good. Ofcourse making an entire development kit for this game would probably not be in priority of interest for the developers. Modding asset wise is indeed already easy enough. However I do wonder how much modding is able to crack into how the game runs. Optimization mods, graphical mods, and such.
What do you think? Thanks again for your detailed reply :)

"Being able to poke around it" unfortunately still relies on either exposed source or reverse-engineering. If Starbound were released as an open project with a retail precompile, such as the way Aseprite is (buy it precompiled or contribute to the github and compile it yourself for free) that would be really cool, but that just generally isn't feasible. That opening up to scrutiny just won't happen is a simple, if unfortunate, fact. Meanwhile, a portion of the industry has traditionally turned a blind eye to the legal ambiguity of reverse-engineering so long as it remains in the realm of fan-patching and extending (Script Extenders, GFWL disablers, etc.), but that has a much higher level of entry in terms of skill.

"Optimizing mods, graphical mods, and such" are already possible and some already exist. Starbound's rendering system literally just mass-loads PNGs which can be losslessly compressed (by nature of the filetype) and further compressed with tools (though you run the risk of damaging palette maps if you don't know what you're doing) which, as proven by OptimizeBound, can improve performance but at the cost of blocking other mods from modifying vanilla art assets. And numerous engine settings are already exposed that can be manipulated to hypothetically improve performance, however many of these (stack size, threads, etc.) are extremely dependent on individual user hardware.

Now, please don't get me wrong. First, thank you for being reasonable in the face of a counter; that's becoming so uncommon that I feel it's necessary to praise. Next, the engine is clunky as hell and I'm not trying to defend it. Running solo play on a local virtual server was a bad idea in terms of extended performance (as shown by the encroachment of "lag spikes" in solo play as the server calculates more and more script results as a save/universe gets larger). Tying calculation rate to frame rate has never been a good idea (though sometimes it's unavoidable). But these are the kinds of things that can't reasonably be changed even if we could dig into the engine's inner workings.

What would be more reasonable would be exposing more engine controls to external configuration and some actual documentation of what's already exposed; there are performance-bearing and engine-altering settings scattered among numerous configs, but next to no documentation for any of it in a game that was built specifically to support mod-culture. I honestly believe that if there was an official API document drawn up and updated, what would go significantly further than opening up the engine to scrutiny and this point.

Very well summed up. I have tried looking around for any sort of official modding guide from Chucklefish, but to find pretty much nothing lol. Community guides is much of the only results I find. So a more official documentation of features, and what you are able to actually poke around with would be nice.

I feel really conflicted with what the state of this game currently is, development wise. Checking the Steam's news page for this game, the latest upload of any news by Chucklefish, was in 2019 with their bounty hunter update. I have seen people talking about Xbox support though. But I have not seen much of Chucklefish themselves saying much about it. Is it for a release on the gamepass, or a port to the actual console?

Please soothe my mind. I can't tell wether this game is abandoned by Chucklefish or not. I feel so conflicted. T^T

[Azure Fang]

Originally posted by Razze:

Originally posted by Azure Fang:

"Being able to poke around it" unfortunately still relies on either exposed source or reverse-engineering. If Starbound were released as an open project with a retail precompile, such as the way Aseprite is (buy it precompiled or contribute to the github and compile it yourself for free) that would be really cool, but that just generally isn't feasible. That opening up to scrutiny just won't happen is a simple, if unfortunate, fact. Meanwhile, a portion of the industry has traditionally turned a blind eye to the legal ambiguity of reverse-engineering so long as it remains in the realm of fan-patching and extending (Script Extenders, GFWL disablers, etc.), but that has a much higher level of entry in terms of skill.

"Optimizing mods, graphical mods, and such" are already possible and some already exist. Starbound's rendering system literally just mass-loads PNGs which can be losslessly compressed (by nature of the filetype) and further compressed with tools (though you run the risk of damaging palette maps if you don't know what you're doing) which, as proven by OptimizeBound, can improve performance but at the cost of blocking other mods from modifying vanilla art assets. And numerous engine settings are already exposed that can be manipulated to hypothetically improve performance, however many of these (stack size, threads, etc.) are extremely dependent on individual user hardware.

Now, please don't get me wrong. First, thank you for being reasonable in the face of a counter; that's becoming so uncommon that I feel it's necessary to praise. Next, the engine is clunky as hell and I'm not trying to defend it. Running solo play on a local virtual server was a bad idea in terms of extended performance (as shown by the encroachment of "lag spikes" in solo play as the server calculates more and more script results as a save/universe gets larger). Tying calculation rate to frame rate has never been a good idea (though sometimes it's unavoidable). But these are the kinds of things that can't reasonably be changed even if we could dig into the engine's inner workings.

What would be more reasonable would be exposing more engine controls to external configuration and some actual documentation of what's already exposed; there are performance-bearing and engine-altering settings scattered among numerous configs, but next to no documentation for any of it in a game that was built specifically to support mod-culture. I honestly believe that if there was an official API document drawn up and updated, what would go significantly further than opening up the engine to scrutiny and this point.

Very well summed up. I have tried looking around for any sort of official modding guide from Chucklefish, but to find pretty much nothing lol. Community guides is much of the only results I find. So a more official documentation of features, and what you are able to actually poke around with would be nice.

I feel really conflicted with what the state of this game currently is, development wise. Checking the Steam's news page for this game, the latest upload of any news by Chucklefish, was in 2019 with their bounty hunter update. I have seen people talking about Xbox support though. But I have not seen much of Chucklefish themselves saying much about it. Is it for a release on the gamepass, or a port to the actual console?

Please soothe my mind. I can't tell wether this game is abandoned by Chucklefish or not. I feel so conflicted. T^T

Best to remain conflicted. Chuckles went "full steam" into the console ports before 1.4 was even released, but around the same time shed part of their team and reallocated the rest to other projects like Witchbrook and (at the time) Wargroove. 1.4 itself took significantly longer than expected, appeared to have suffered due to dev transitions, and is still relatively buggy yet ignored as they still try to figure out why the console port attempts are a buggy mess (gee, I wonder why?).

My history with Chucklefish isn't the best and has left me extra cynical, so take that into account when considering anything I post, but I see it as best to assume it's abandoned and be pleasantly surprised when that turns out to be wrong.

[Razze]

Originally posted by Azure Fang:

Originally posted by Razze:

Very well summed up. I have tried looking around for any sort of official modding guide from Chucklefish, but to find pretty much nothing lol. Community guides is much of the only results I find. So a more official documentation of features, and what you are able to actually poke around with would be nice.

I feel really conflicted with what the state of this game currently is, development wise. Checking the Steam's news page for this game, the latest upload of any news by Chucklefish, was in 2019 with their bounty hunter update. I have seen people talking about Xbox support though. But I have not seen much of Chucklefish themselves saying much about it. Is it for a release on the gamepass, or a port to the actual console?

Please soothe my mind. I can't tell wether this game is abandoned by Chucklefish or not. I feel so conflicted. T^T

Best to remain conflicted. Chuckles went "full steam" into the console ports before 1.4 was even released, but around the same time shed part of their team and reallocated the rest to other projects like Witchbrook and (at the time) Wargroove. 1.4 itself took significantly longer than expected, appeared to have suffered due to dev transitions, and is still relatively buggy yet ignored as they still try to figure out why the console port attempts are a buggy mess (gee, I wonder why?).

My history with Chucklefish isn't the best and has left me extra cynical, so take that into account when considering anything I post, but I see it as best to assume it's abandoned and be pleasantly surprised when that turns out to be wrong.

I guess I will have to put "Razzebound ; the better starbound game" on the todo list then!

I can dream atleast

[LedstormXM]

Apparently the source code leaked sometime after this post.