You usually dont add 2.0 unless you overhaul major features.
Why are we talking about Spark 2.0 when Subnautica hasn't is not even in alpha yet? Just curious.
They are improving it. Overhauling major features as just mentioned in this same thread.
We talk about spark 2.0 because we are interested as it is the future of UWE. You see several people very interested in spark 2.0 in this thread, including a faultline dev who use spark 1.0.
You usually dont add 2.0 unless you overhaul major features.
Why are we talking about Spark 2.0 when Subnautica hasn't is not even in alpha yet? Just curious.
"Spark 2.0" is more of a community moniker, it's not really a term we use internally. But we've been working on a new project that uses the Spark engine for a while now. We brought it up when Subnautica was announced because people were concerned we were abandoning Spark.
You usually dont add 2.0 unless you overhaul major features.
Why are we talking about Spark 2.0 when Subnautica hasn't is not even in alpha yet? Just curious.
"Spark 2.0" is more of a community moniker, it's not really a term we use internally. But we've been working on a new project that uses the Spark engine for a while now. We brought it up when Subnautica was announced because people were concerned we were abandoning Spark.
@Squeal_Like_A_Pig
I was wondering, have you guys thought about bringing in key people from the community mainly the modders out there to take feedback on Spark 2.0 at the appropriate time?
I imagine many people such as myself are interested in making something using it at some point and who knows maybe even license it if possible, of course if its all around good to work with.
I'm guessing that its super early in development, but are you guys planning on going open development with it in the future like UE4 has been doing lately?
Yeah, we have talked about it. For the next Spark project want to get something in the hands of people outside the studio as soon as possible (although we don't yet have a timeframe for that).
Personally I don't expect it to be as open as UE4 seems to be (I can't see us having people vote on engine features for example), but we'll make a decision on that sort of thing when we get closer to "going public". Whatever we choose to do will be based on whatever works for the next game, since we aren't developing the engine in a vacuum.
I would love the chance to provide early feedback on the tools. So many times I say to myself "now if only there was a way to... etc etc."
Soul_RiderMod BeanJoin Date: 2004-06-19Member: 29388Members, Constellation, Squad Five Blue
I really hope not.... Unless it's HL3!!
UWE need space to explore other things rather than jumping straight into NS3. I wouldn't expect it for another 5-10 years as a minimum.
I am sure UWE have a million more ideas to work on other than just NS, however, it is probably likely they will return to the NS universe, but I just wouldn't expect NS3 for a long time.
You usually dont add 2.0 unless you overhaul major features.
Why are we talking about Spark 2.0 when Subnautica hasn't is not even in alpha yet? Just curious.
"Spark 2.0" is more of a community moniker, it's not really a term we use internally. But we've been working on a new project that uses the Spark engine for a while now. We brought it up when Subnautica was announced because people were concerned we were abandoning Spark.
Unfortunately, the majority of the work being done on Spark 2.0 will not be able to make it back to NS2. NS2 would pretty much have to be rewritten from the ground up to take advantage of the changes that are being done.
this is what i'm curious about. is spark 2 gonna be largely incompatible with spark 1? if spark 2 is just gonna have some incompatibilities with ns2's lua codebase, shouldn't the modding community just be able to modify ns2 lua to fit the spark 2 changes? and i don't see how it could be a majority rewrite. all of the game logic stuff should be mostly untouched i would think, maybe asset handling is gonna change significantly? if spark 2 couldn't load up and use any of spark 1's assets i could see that being a problem. but if each lua class needs to be rewritten to interface with the engine differently that would probably be really straightforward in most cases. lots of copy / paste type stuff i imagine.
anyway, i hope that uwe can try and work with us on this stuff, at least be open and maybe field questions about how the new engine iteration works after release. you've got people here who are ready and able to do the work on the lua codebase if it's remotely possible. i mean, the whole thing is basically a glorified lua interpreter with various libraries attached for asset pipeline, networking, etc. give us the exe and let us worry about whether or not it can be done.
Unfortunately, the majority of the work being done on Spark 2.0 will not be able to make it back to NS2. NS2 would pretty much have to be rewritten from the ground up to take advantage of the changes that are being done.
this is what i'm curious about. is spark 2 gonna be largely incompatible with spark 1? if spark 2 is just gonna have some incompatibilities with ns2's lua codebase, shouldn't the modding community just be able to modify ns2 lua to fit the spark 2 changes? and i don't see how it could be a majority rewrite. all of the game logic stuff should be mostly untouched i would think, maybe asset handling is gonna change significantly? if spark 2 couldn't load up and use any of spark 1's assets i could see that being a problem. but if each lua class needs to be rewritten to interface with the engine differently that would probably be really straightforward in most cases. lots of copy / paste type stuff i imagine.
anyway, i hope that uwe can try and work with us on this stuff, at least be open and maybe field questions about how the new engine iteration works after release. you've got people here who are ready and able to do the work on the lua codebase if it's remotely possible. i mean, the whole thing is basically a glorified lua interpreter with various libraries attached for asset pipeline, networking, etc. give us the exe and let us worry about whether or not it can be done.
I think we'll be plenty open with whatever we release on Spark 2.0. And yeah, a lot of the "porting" would be rather tedious API-touching changes. Some small, some big.
Here's a big one, for example: the OOP features. Yeah, we basically implemented OOP things like class inheritance, right? You can subclass things. Rifle.lua is a subclass of ClipWeapon.lua, etc. This requires some back and forth with the engine, I believe for networking reasons, and it is complete ass for performance. In all likelihood, we won't do this at all for Spark 2.0. So, it'll be kinda like porting code from C++ to C. It surely is possible, and not ALL the code would need to be re-written. But...it sounds like a huge pain in the ass.
Man I feel like we should just write a FAQ for "why NS2's performance is probably not gonna get much better: come sit down and learn a thing or two about API design" :P
Man I feel like we should just write a FAQ for "why NS2's performance is probably not gonna get much better: come sit down and learn a thing or two about API design" :P
Actually a good idea. Please do it! I'm really interested in the details and I'm sure it would clear up alot of assumptions some people seem to have about the dev team and building ns2.
But at the same time, this sentiment will always remain:
Man I feel like we should just write a FAQ for "why NS2's performance is probably not gonna get much better: come sit down and learn a thing or two about API design" :P
Man I feel like we should just write a FAQ for "why NS2's performance is probably not gonna get much better: come sit down and learn a thing or two about API design" :P
Maybe it's time for an hour-long Q&A session regarding performance and design and such.
Man I feel like we should just write a FAQ for "why NS2's performance is probably not gonna get much better: come sit down and learn a thing or two about API design" :P
anything you can give us on the topic is great, but personally i think that a topic like "if we were gonna improve ns2's performance (but we won't because it's not cost effective) then this is what we think the key problem areas are and what our strategy would probably be" would be most productive
right now i for one am just not sure why performance is such an issue as it stands right now. i mean, does lua get processed every frame? or just at some arbitrary tick rate? i guess floats like assorted entity positions and vectors are probably updated every frame, so that likely goes through lua. is it unlikely that any noteworthy performance gains can be had from refactoring the current lua codebase? like if we were to flatten out the lua inheritance tree, incorporate all these mixins or something? do all of the inheritance lookups slow down the lua interpreter? or will the only thing that improves performance in a meaningful way be iterating on the spark engine? and hypothetically if ns2 were made to run on some future iteration of the spark engine based on whatever internal development goals uwe has for subnautica or whatever current projects, is there any reason to believe performance would improve?
sorry for being difficult and thanks for putting up with me :P
I think we'll be plenty open with whatever we release on Spark 2.0. And yeah, a lot of the "porting" would be rather tedious API-touching changes. Some small, some big.
Here's a big one, for example: the OOP features. Yeah, we basically implemented OOP things like class inheritance, right? You can subclass things. Rifle.lua is a subclass of ClipWeapon.lua, etc. This requires some back and forth with the engine, I believe for networking reasons, and it is complete ass for performance. In all likelihood, we won't do this at all for Spark 2.0. So, it'll be kinda like porting code from C++ to C. It surely is possible, and not ALL the code would need to be re-written. But...it sounds like a huge pain in the ass.
Man I feel like we should just write a FAQ for "why NS2's performance is probably not gonna get much better: come sit down and learn a thing or two about API design" :P
I am really interested by a description of the structure of the game. What does become the lua code during a loading from the game, and how does it interact with Spark ?
When you speak about performance issue with class inheritance, does it means if we rewrite the whole game to a non inheritance code, the game would be quicker ?
In fact, I find the lua code quite difficult to read as an OOP language (or as a language itself by the way, C/C++ looks cleaner from my point of view).
I am really interested by a description of the structure of the game. What does become the lua code during a loading from the game, and how does it interact with Spark ?
When you speak about performance issue with class inheritance, does it means if we rewrite the whole game to a non inheritance code, the game would be quicker ?
In fact, I find the lua code quite difficult to read as an OOP language (or as a language itself by the way, C/C++ looks cleaner from my point of view).
the objective of the whole lua thing was certainly not any type of "cleanliness" of code or purity of paradigm. using a loosely-typed, interpreted, high-level language like lua has several strengths and weaknesses:
1. loose typing, lenient syntax, and garbage collection eliminate several whole classes of errors. segfaults for example can't happen in your lua code, they can only occur in engine code or if there's a bug in your lua VM.
2. the expressiveness of the language, the lack of boilerplate type / memory management (due to the language being higher level than an alternative like c++), and the targeted, less generalist mentality of a scripting language usually means less code overall, and therefore less code to maintain and have bugs. more code almost always means more bugs, as each line is a statistical opportunity for failure.
3. a codebase in an interpreted language is easy to iterate quickly on, as you can simply save a file and run your game. let's say you used c++ for a shared library that holds all game logic and gets linked into the engine at runtime. if you want to, say, change skulk wall jumping a bit, you would have to recompile and relink that library between each test. obviously there are smarter ways to deal with this problem, but a compilation step is just generally onerous.
4. if they used a compiled language for game logic modding would be a mess. they would probably have to define some really complex API with a ton of hook points. right now you can just override any methods you want in lua, it's really easy. in a lot of other games developers end up doing both, implementing most of the game in c++ then also embedding an interpreter just for modding. spark's system is very flexible in this regard and you wouldn't see the deep mods you do if this were not the case. instead of all the documentation and api work you would need in order to open your game up for modding, they can just distribute all of the game logic code with the game itself and let people have at it.
5. any portion of your game you decide to implement in your embedded interpreted language is going to be subject to the various limits of your embedded interpreter, be those performance limitations, resource limitations, or methodology limitations. this is the problem uwe presumably has with performance. embedding an interpreter is complicated.
6. lua is a semi-wacky choice. it doesn't seem like the most mature option and is a bit geared toward the lowest common denominator, but it probably doesn't make that big of a difference. lua seems popular in the games industry for some reason.
a really easy way to think about how the spark engine works is as a lua interpreter. you basically have this exe which can take in lua code and process it. it also exposes a big set of functionality around the render pipeline, probably asset loading and management, networking, interfacing with the os, effects, etc. which are all basically just for the lua game code to utilize as it sees fit. spark is effectively a toolkit which you can use to build a game in lua.
Comments
I don't even
They are improving it. Overhauling major features as just mentioned in this same thread.
We talk about spark 2.0 because we are interested as it is the future of UWE. You see several people very interested in spark 2.0 in this thread, including a faultline dev who use spark 1.0.
"Spark 2.0" is more of a community moniker, it's not really a term we use internally. But we've been working on a new project that uses the Spark engine for a while now. We brought it up when Subnautica was announced because people were concerned we were abandoning Spark.
Does this project have a "3" on the end of it???
I would love the chance to provide early feedback on the tools. So many times I say to myself "now if only there was a way to... etc etc."
UWE need space to explore other things rather than jumping straight into NS3. I wouldn't expect it for another 5-10 years as a minimum.
I am sure UWE have a million more ideas to work on other than just NS, however, it is probably likely they will return to the NS universe, but I just wouldn't expect NS3 for a long time.
Yes, HL3 confirmed.
this is what i'm curious about. is spark 2 gonna be largely incompatible with spark 1? if spark 2 is just gonna have some incompatibilities with ns2's lua codebase, shouldn't the modding community just be able to modify ns2 lua to fit the spark 2 changes? and i don't see how it could be a majority rewrite. all of the game logic stuff should be mostly untouched i would think, maybe asset handling is gonna change significantly? if spark 2 couldn't load up and use any of spark 1's assets i could see that being a problem. but if each lua class needs to be rewritten to interface with the engine differently that would probably be really straightforward in most cases. lots of copy / paste type stuff i imagine.
anyway, i hope that uwe can try and work with us on this stuff, at least be open and maybe field questions about how the new engine iteration works after release. you've got people here who are ready and able to do the work on the lua codebase if it's remotely possible. i mean, the whole thing is basically a glorified lua interpreter with various libraries attached for asset pipeline, networking, etc. give us the exe and let us worry about whether or not it can be done.
HL3 confirmed.
EDIT: @coolitic. lol, I posted this then read your post.
I think we'll be plenty open with whatever we release on Spark 2.0. And yeah, a lot of the "porting" would be rather tedious API-touching changes. Some small, some big.
Here's a big one, for example: the OOP features. Yeah, we basically implemented OOP things like class inheritance, right? You can subclass things. Rifle.lua is a subclass of ClipWeapon.lua, etc. This requires some back and forth with the engine, I believe for networking reasons, and it is complete ass for performance. In all likelihood, we won't do this at all for Spark 2.0. So, it'll be kinda like porting code from C++ to C. It surely is possible, and not ALL the code would need to be re-written. But...it sounds like a huge pain in the ass.
Man I feel like we should just write a FAQ for "why NS2's performance is probably not gonna get much better: come sit down and learn a thing or two about API design" :P
But at the same time, this sentiment will always remain: The community's already done some pretty impressive things to support your small team. I wonder how deep this rabbit hole of love goes
Maybe it's time for an hour-long Q&A session regarding performance and design and such.
Hey, I know what you're referring to. Tehehehe
PS - don't get ban, @joshhh.
anything you can give us on the topic is great, but personally i think that a topic like "if we were gonna improve ns2's performance (but we won't because it's not cost effective) then this is what we think the key problem areas are and what our strategy would probably be" would be most productive
right now i for one am just not sure why performance is such an issue as it stands right now. i mean, does lua get processed every frame? or just at some arbitrary tick rate? i guess floats like assorted entity positions and vectors are probably updated every frame, so that likely goes through lua. is it unlikely that any noteworthy performance gains can be had from refactoring the current lua codebase? like if we were to flatten out the lua inheritance tree, incorporate all these mixins or something? do all of the inheritance lookups slow down the lua interpreter? or will the only thing that improves performance in a meaningful way be iterating on the spark engine? and hypothetically if ns2 were made to run on some future iteration of the spark engine based on whatever internal development goals uwe has for subnautica or whatever current projects, is there any reason to believe performance would improve?
sorry for being difficult and thanks for putting up with me :P
I am really interested by a description of the structure of the game. What does become the lua code during a loading from the game, and how does it interact with Spark ?
When you speak about performance issue with class inheritance, does it means if we rewrite the whole game to a non inheritance code, the game would be quicker ?
In fact, I find the lua code quite difficult to read as an OOP language (or as a language itself by the way, C/C++ looks cleaner from my point of view).
the objective of the whole lua thing was certainly not any type of "cleanliness" of code or purity of paradigm. using a loosely-typed, interpreted, high-level language like lua has several strengths and weaknesses:
1. loose typing, lenient syntax, and garbage collection eliminate several whole classes of errors. segfaults for example can't happen in your lua code, they can only occur in engine code or if there's a bug in your lua VM.
2. the expressiveness of the language, the lack of boilerplate type / memory management (due to the language being higher level than an alternative like c++), and the targeted, less generalist mentality of a scripting language usually means less code overall, and therefore less code to maintain and have bugs. more code almost always means more bugs, as each line is a statistical opportunity for failure.
3. a codebase in an interpreted language is easy to iterate quickly on, as you can simply save a file and run your game. let's say you used c++ for a shared library that holds all game logic and gets linked into the engine at runtime. if you want to, say, change skulk wall jumping a bit, you would have to recompile and relink that library between each test. obviously there are smarter ways to deal with this problem, but a compilation step is just generally onerous.
4. if they used a compiled language for game logic modding would be a mess. they would probably have to define some really complex API with a ton of hook points. right now you can just override any methods you want in lua, it's really easy. in a lot of other games developers end up doing both, implementing most of the game in c++ then also embedding an interpreter just for modding. spark's system is very flexible in this regard and you wouldn't see the deep mods you do if this were not the case. instead of all the documentation and api work you would need in order to open your game up for modding, they can just distribute all of the game logic code with the game itself and let people have at it.
5. any portion of your game you decide to implement in your embedded interpreted language is going to be subject to the various limits of your embedded interpreter, be those performance limitations, resource limitations, or methodology limitations. this is the problem uwe presumably has with performance. embedding an interpreter is complicated.
6. lua is a semi-wacky choice. it doesn't seem like the most mature option and is a bit geared toward the lowest common denominator, but it probably doesn't make that big of a difference. lua seems popular in the games industry for some reason.
a really easy way to think about how the spark engine works is as a lua interpreter. you basically have this exe which can take in lua code and process it. it also exposes a big set of functionality around the render pipeline, probably asset loading and management, networking, interfacing with the os, effects, etc. which are all basically just for the lua game code to utilize as it sees fit. spark is effectively a toolkit which you can use to build a game in lua.
i mean performance was related to client side framerate, and server side things like tic and etc?
could be glorious!
I'll be looking into subnautica as well and any other future games because I like uwe a lot
nom nom nom engine.. Very fun to play with.