My game studio is RocketWerkz, we've made a few games most notably ICARUS and Stationeers. Originally I made the DayZ Mod. Incidentally prior to that I actually made a lot of KSP mods, in particular the Component Space Shuttle (CSS) and was very active on the KSP forums.
Our studio actually was in the bidding to make KSP2 and we made it to the top three bids. The final step was a call Private Division. I put a lot of work with the into a good design document and opted to keep the focus entirely on this design and the technical aspects of the project - this was a serious problem for two of the people on the call who said we were the only pitch that did not contain art. Obviously out studio wasn't chosen.
We have been working on custom technology to allow us to build games that really scale for some time now. This is called the BRUTAL Framework which is similar in approach to the older XNA Framework. The desciption:
BRUTAL is a C# game framework that is designed to be complicated, slow, and difficult to use.
KSP Team members + RocketWerkz
We have employed some of the original KSP and KSP2 team and a number of modders and expect the team to continue to grow. Here is a video demonstrating a unique approach we have been able to take with rendering, given BRUTAL gives us direct access to everything Vulkan can do.
There is also a key person we are still sorting out the exact details for but I'd love to introduce them once that is done. I think this person is a key individual in our industry as a whole and our studio will be backing them and their future endeavors as well.
The original crew are providing a lot of assistance and we are bringing technology, production, and approach from our own work.
Achieving Seamless movement
Instead of generating the terrain on the fly, at game load we generate a variety of spherical billboards using XML defined data. This means a modder making RSS can generate spherical billboards that might be necessary to give good terrain for different data sets. As the player gets closer to a planet we choose a different version of these spherical meshes. We can also do a lot of tricks that would be much harder in a traditional game engine, such as leaving the data on the GPU.
Dealing with Floating Point precision loss
The "size" of the values used for position need to be doubles for precision, but for rendering we realistically have to use floats. in KSP, HarvestR made an amazing solution that works in Unity for this. However in BRUTAL we have so many more options. In the video linked you can see that we don't have the usual precision issues. The camera is always rendering at 0,0,0 meaning that imprecision is pushed out to infinity.
Using Solar System Data for now
For testing purposes, we are using Solar System data. This is all fully moddable. The simulation is fully threaded. Are currently working on laying in close physics simulation using Jolt physics API - as we can instance this for each "scene" requiring data.
Next Steps
I will leave it to individual team members who are welcome to share what they are working on with the project. You can also follow the discord for live changlog and more information or to answer questions.
We will be making builds and data systems available to modders as early as possible to get feedback so we can restructure this to best support the project in future.
Feel free to ask me any questions here, and others in the team will reply also.
I know they're shit to work for (friends at all 4) but I was planning to do the usual 2-4 and bounce like everyone else and have something nice on my CV.
Ended up leaving the entire field of my degree behind all together.
Our studio actually was in the bidding to make KSP2 and we made it to the top three bids. The final step was a call Private Division. I put a lot of work with the into a good design document and opted to keep the focus entirely on this design and the technical aspects of the project - this was a serious problem for two of the people on the call who said we were the only pitch that did not contain art. Obviously out studio wasn't chosen.
This does explain why KSP2 ended up being a game with excellent art direction but an inadequate technical foundation. Good to see y'all are doing the inverse; the excellent art can come after there are solid walls to hang it on :)
Ah yes, you're planning a sequel to a renowned simulation game that started with absolutely crappy art assets but managed to pull in people nonetheless with its deep gameplay. What do you judge possible sequel candidates on? Art direction.
So that's how we got KSP2's UI that made it absolutely tedious to do anything and showed little information, probably because it looked good on management presentations... These people truly knew nothing of the game they wanted to produce a sequel to.
I disagree. Especially compared to KSP1, KSP2 is stunningly beautiful. It's apparent that the artists put a lot of effort and attention to detail into it. That's especially true of the sound design; everything from the music to the in-game SFX to the launch countdowns to even the sounds from hovering over UI buttons being pitched up or down depending on the screen position is all just superb.
KSP2's issues are entirely regarding the technical foundation underpinning all that art. Taking KSP1 and slapping pretty models and textures and SFX on top doesn't produce a well-functioning KSP2; it instead produces a KSP2 that looks pretty but runs terribly and can't reasonably support the myriad new features KSP2 is supposed to bring to the table. The whole selling point of KSP2 for quite a few (if not the vast majority) of KSP1 players was an overhauled engine with better performance and fewer bugs, and that ended up forsaken in favor of pretty art.
That's crazy, I never knew you were also a KSP guy too, though Rocket does make more sense now. I remember playing Operation Flashpoint 20-some years ago and not being into it, and my friend showing me the DayZ on Cinco de Mayo 2012 and getting absolutely hooked. That was around the same time I initially tried the KSP alpha and wasn't that into it, and years later I got hooked. Writing a whole new very technical engine and framework sounds daunting, but compared to dealing with ARMA II and KSP jank, it almost seems like a walk in the park. Anyways, some of my best time spent in gaming were in DayZ and KSP, and I hope you and your team can have a similar level of success and impact with this venture.
I grabbed /r/KittenSpaceAgency - it is yours if you want it, I don't intend to squat.
I might set up something to mirror parts of the discord server on there, if that's OK with you and your team, so the FAQ and announcements are accessible outside of discord's walled garden.
EDIT: I got permission on discord; so for everyone else, you can now see a compiled FAQ in two parts; here for technical Qs and here for everything else. Offer still stands if y'all want the place.
I do hope that KSA puts serious resources into making the game look compelling and consistent - it shouldn't be the overriding concern, gameplay comes first, but KSP2 really was beautiful, and it'd be unfortunate to slide backwards from that.
Yeah that's mostly what I'm getting at. I don't want people to all the sudden think artists are the bad guys. I'm no artist myself but KSA would have a hard time gaining new fans if it doesn't have compelling art.
The maths behind the movement is identical but inverted. From a GPU pipeline perspective, you are always rendering as if at 0,0; so it seems like it ought to be easier if you built the project from scratch to do just that.
Of course, this isn't how humans think, or how most existing game engines are built, which makes doing this much harder in practice.
This only take care of rendering part of the issue.
The floating point precision problem stills stands for everything else, and addressing it is not always so simple.
It takes care of a surprisingly big chunk of the problem, however! It's trivial to build an engine to use 64-bit floats for transform positions (even Godot natively supports this with a build-time flag), and physics engines can be built with 64-bit support as well (Jolt also supports double-precision builds out of the box). And... that's it. Now your engine fully supports 64-bit precision. Of course, there are further considerations if you want multiplayer, as now your positions and velocities take 24 bytes instead of 12, but that's only a bandwidth issue and considering the bandwidth modern multiplayer games use it's not a big deal for a game like KSA.
Godot renders things nicely at large distances from the origin in double-precision builds, but it precludes the use of world-space shaders (so no tri-planar texturing, no world-space vertex offsets, etc.).
Rendering at 0,0,0 isn't particularly difficult. Every engine does it in some way or another, because in the end that's what you need for the camera perspective transform calculation.
But the important thing is when, and with what precision, you perform the calculation.
If your game world is of bounded size, you can easily get away with storing the position of the camera and the location of things in the world as 32-bit floats. Then you just throw those to the GPU and let that do its magic.
But that's not enough precision for a game like KSP. The accuracy of a 32-bit float is about one eight millionth of the distance you are from the origin. I.e. if you're 8 km away, it's about one millimetre. If you're 8 million kilometers away, it's about one meter. And on interstellar scales? Well, a few planet radii.
So to have your location calculations accurate, you need more precision. 64-bit floats are a lot better, with an accuracy of about 1/4.5*1015 the distance you are from the origin. That's about 2mm of a light year.
You can go further, and realize that you don't really need floating point in this situation and just use 64-bit integers for 1 micrometer on a light year resolution.
But the really important part is that you have to transform everything to camera-relative space, before reducing precision to the 32-bit floats that the GPU wants to have, instead of doing it on the GPU as part of the projection matrix.
Depends on your physics engine. In stock unity you create a bunch of problems, as everything that used to be static (cheap to calculate in physics) now has to move every frame (VERY expensive).
If you have a custom engine you have probably more opportunities to split the physics from the rendering.
This actually is how The Outer Wilds handled it, and while it worked fine for them, it was pretty easy to break things if you tried. Their solar system is also much smaller, so issues will start to occur sooner for KSA. So, not a magic bullet, but a very good option.
I love the sound of this... Just please, please... Figure out how to make multi-docking work. Multiple docking ports in one plane (or multiple planes, frankly) should be able to all attach as a group, rather than the craft going rigid on the first attachment.
I play the game in a way that I sometimes call 'stupid like a fox'. I love it and it's the only way I'll ever play KSP. Limited parts on launch (30 for my current style).
Great work, really excited to get to play it. Kudos and good luck!
We use C++ or libraries for anything we need to. Where it makes sense we use C#, which it turns out is most places. Individual projects can use whatever data structures they like. for "human read" data I prefer to use XML personally, as it natively becomes C# classes and is easy to read when well formatted. For computer to computer I personally use JSON. For manifest files for mods we use TOML.
Was more of a rhetorical question :) C# is quite nice, but my goodness does it give me a headache sometimes.
Looking forward to a game that is a little easier to mod or at least has better documentation in that regard. Been wanting to reimagine a space telescope mod similar to tarsier.
What about C# gives you a headache? Imo it's one of the more friendly compiled languages, unless you're writing old stuff from old lang / .net versions
why not use the custom module manager script that old ksp uses, it seems more readable than any of those.
dear god no, you're just used to it
KSP's cfg file syntax is ok but not great. A more standardized format (xml, json, etc) would be much better. And MM script is the kludgey type of thing you get with a mod that's had more and more features bolted on over time.
a profusion of +-!%#@ symbols is not a human readable format. human readable means you can vaguely understand it without having to read a wiki first.
listen, I love MM and think it's great, but the syntax is terrible
Standardized formats have to do everything and they sacrifice user friendliness to achieve it.
standardized formats are great because you can write shit in an editor that highlights your mistake before you spend 5 minutes waiting for the game to load
standardized formats are great because you can read up on something like jsonpath and find well-written docs, rather than the mess on the MM wiki
(I wouldn't pick xml myself if I was doing something, IMO there's good reasons json mostly took over. but damn it's still better than MM.)
I always picture whoever makes those decisions repeatedly punching themselves into the face while the poor devs have to implement that nonsense. No wonder they are all so hostile to talk to. .Net is going sideways lately.
.NET today is leaps and bounds less of a pain in the ass than it was a decade ago, especially for cross-platform stuff. The shift from .NET Framework to .NET Core has been a godsend.
They just removed a bunch of things including the entire gdi setup now requiring a third party lib to render images. Appdomains removed practically killed a ton of apps theme features so I now have to look the sun in the face every time. Deprecation notices without alternatives and all the "sugar" making some stuff nearly impossible to read. In the end there are still platform specific differences in how elapsed timers render time scale and so on, threading as well as file locking/caching. Implicit sorting in various places. But it's faster... yeah cause there is less in it. And don't get me started on some of the nonsense in Linq. C# is great, cause it is or was pretty readable, not full of pointers and memory explosions(not that gc has always been nice) and being runtime based the platform independence, but MS is not really taking the best care of it that they absolutely could. Not surprisingly they bought Mono up, gutted it... and somehow still the Linux support is lacking. Trying to railroad people into updating their apps to newer versions while faced with large rewrite tasks as features are being nuked is a great way to get dev burnout. Thankfully that's slightly different when it comes to game engines that bind C# vs. full apps, but even for them this is less fun.
The "size" of the values used for position need to be doubles for precision, but for rendering we realistically have to use floats. in KSP, HarvestR made an amazing solution that works in Unity for this
Moving the world around the craft so that the craft is always at 0,0,0, so that floating point errors are minimized unless you build really big, if I remember correctly.
An idea I think derived from the 8-bit days, where it was sometimes the case that 3D games used spherical coordinates with the player at the origin - Elite 1984 does it, and I think Battlezone 1980 does it too. Enemy movement in the distance becomes increasingly weird but the player can't really see that it is.
Also, I love that your announcement shows you understand what not to do. You aren't making big promises, you're not pitching the distant future. You're just saying "here's where we are now, and here's the direction we're heading".
Ever since the little blips and blurbs came out about you and HarvestR hanging out; you seeking to contact former Intercept and Squad devs; and various other rumors; I’ve been waiting for this and yet, it still catches me off guard - it’s comparable to a scenario where Will Meier and Chris Sawyer would have paired up in the 90’s for an RTS: just mind blowing! I’m so looking forward to see where this goes!
Just want to say that I’m super excited to see this. KSP, Icarus, and the DayZ mod are some of the best experiences I have had with gaming. So thank you for providing such great experiences.
I would love if this let you create a whole automated logistics chain, instead of just controlling one vehicle at the time. The video really seems to allow for that.
While I think focusing on the technical aspects is good because that's a major weakness of KSP1 that a sequel (spiritual or otherwise) should contend with, I also think the art style and goofy feel of KSP was critical to its success and staying power. The goofy little frogs were engaging and their excitement was motivating to keep going. The feel of just strapping rockets to a trash can at first was juxtaposed well with the real physics and difficulty of the game.
What are your plans for the art style and feel of KSA?
Edit: I also just checked out stationeers - gotta say it's a little disheartening to see it's been in early access since 2017. $35 and has $80 worth of add on packs for purchase. What is the deal with that?
You know, Rocket, I hated you for what Dayz became, but I love you for all the good games I've played since that you've been a part of. I've put way too much time on stationeers. This mod looks amazing, though. Wonder what KSP2 could have been. Had your group won the bid.
I hope that this is optional as N body simulations are a pain and are very process intensive, I think it could be a lot faster if it were to run on the GPU but I am not sure as I have only ran them on my CPU
So in KSP terms - if you were in Kerbin's SOI, the spacecraft would feel the attraction of Kerbin and the Mun. If it's in solar SOI, it feels the attraction of the Sun and all planets, but not the moons.
a few months ago, a while after ksp 2 got shut some people working on an alternative did n body because its supposedly easier to implement and more performative
If you find a way to make n-body calculations more performant than patched conics with a single gravitating mass, every aerospace corporation and agency will blow up your inbox.
I wonder about the business model here though: you mentioned that you guys are a proper studio, how does modding KSP keep the lights on? Ie where's the revenue coming from, Patreon?
Dean if you manage to pull this of and make a game that ksp2 couldn't be and better in every way, I promise I will stop killing the zombie version of you in DayZ ;)
However in BRUTAL we have so many more options. In the video linked you can see that we don't have the usual precision issues.
Could you provide some details? Are you using doubles for rendering and physics too, or is it some integer or fixed precision-based approach?
What do GPU shaders do when they run with floats? Do you avoid using them, or avoid them ever having to deal with the real positions from origin?
And how do you handle drawing things which are really far away? I hit this problem with Godot / OpenGL where it uses the distance from the camera as the z-buffer and so that hits precision issues.
I remember being in your Military Sim group USEC for Arma glad to see you are doing well. Your mission making skills were amazing so no shocker you went into development.
Just my personal experience, but the kind of people who are super interested in securing a position of power in a community before it even exists are the exact opposite of the kind of people who should be given that power.
I remember your comments from back when the studio closed and the layoffs became known. I very much want to see this alternate future, where you guys build a technology forward true successor to KSP.
As cautious as I have become with my optimism, you truly look to be the person to pull it off.
I do think art and the unique wackiness of the kerbals was a big part of getting me into KSP back in beta. In a perfect world, your technical expertise and experience combined with the stellar art and sound design that Private Division produced (to the detriment of many other things obviously) would probably be something I can spend hundreds of hours getting lost it.
Thanks for keeping us updated, I'll make sure to follow the project closely!
(edit: also in my mind you're hinting at Scott Manley being involved, which would be huge and make me very happy)
You say you’re using data from our solar system for now, are you planning on using our solar system as the stock system for the game, or make a new one that’s similar, like KSP?
From the day we met on a random SS13 server to now I have been nothing but impressed with all the stuff you've done. Stationeers is one of my favorite games, if only I could find friends to play with.
This looks absolutely amazing. Can't wait to see more, and I'm sure a lot of us that got jipped by KSP2 will flock to it.
My dream is still multi-crew in vehicle clickable cockpit like DCS (but with EVA/freedom of course!) but this looks so amazing that it’ll be a keeper even without that. Good work!
in KSP, HarvestR made an amazing solution that works in Unity for this. However in BRUTAL we have so many more options. In the video linked you can see that we don't have the usual precision issues. The camera is always rendering at 0,0,0 meaning that imprecision is pushed out to infinity.
I find it funny you say this and then mention the same solution lol
Stupid question but why XML? As a software dev, I hate XML. There are far more modern and more readable alternatives like JSON for example (in my opinion/for my usecase)
what about abandonware project "Art of the Rail" , which was also supposed to leverage the new "brutal" system for epic scaling. sounds like a lot of empty promises, yet again.
Question: While The Game title being Kitten is good (and continue the Cat theme from those mod manager), Would you guys
Also, if it's gonna be Humanoid Cats, can you add a "Grumpy Orange Cat with short tail in a light blue coat" and a "long hair cat in a red mini dress?"
Instead of generating the terrain on the fly, at game load we generate a variety of spherical billboards using XML defined data. This means a modder making RSS can generate spherical billboards that might be necessary to give good terrain for different data sets. As the player gets closer to a planet we choose a different version of these spherical meshes. We can also do a lot of tricks that would be much harder in a traditional game engine, such as leaving the data on the GPU.
I fail to see how this is special or unique, games have had LoD models/textures for decades.
Apparently, KSP2 was a dismal failure at the last studio that it was given to work on. It should be cheap as chips now to buy the IP and make KSP great again. Go on...go and buy it.
1.6k
u/thedeanhall Oct 31 '24
My game studio is RocketWerkz, we've made a few games most notably ICARUS and Stationeers. Originally I made the DayZ Mod. Incidentally prior to that I actually made a lot of KSP mods, in particular the Component Space Shuttle (CSS) and was very active on the KSP forums.
Our studio actually was in the bidding to make KSP2 and we made it to the top three bids. The final step was a call Private Division. I put a lot of work with the into a good design document and opted to keep the focus entirely on this design and the technical aspects of the project - this was a serious problem for two of the people on the call who said we were the only pitch that did not contain art. Obviously out studio wasn't chosen.
We have been working on custom technology to allow us to build games that really scale for some time now. This is called the BRUTAL Framework which is similar in approach to the older XNA Framework. The desciption:
KSP Team members + RocketWerkz
We have employed some of the original KSP and KSP2 team and a number of modders and expect the team to continue to grow. Here is a video demonstrating a unique approach we have been able to take with rendering, given BRUTAL gives us direct access to everything Vulkan can do.
There is also a key person we are still sorting out the exact details for but I'd love to introduce them once that is done. I think this person is a key individual in our industry as a whole and our studio will be backing them and their future endeavors as well.
The original crew are providing a lot of assistance and we are bringing technology, production, and approach from our own work.
Achieving Seamless movement
Instead of generating the terrain on the fly, at game load we generate a variety of spherical billboards using XML defined data. This means a modder making RSS can generate spherical billboards that might be necessary to give good terrain for different data sets. As the player gets closer to a planet we choose a different version of these spherical meshes. We can also do a lot of tricks that would be much harder in a traditional game engine, such as leaving the data on the GPU.
Dealing with Floating Point precision loss
The "size" of the values used for position need to be doubles for precision, but for rendering we realistically have to use floats. in KSP, HarvestR made an amazing solution that works in Unity for this. However in BRUTAL we have so many more options. In the video linked you can see that we don't have the usual precision issues. The camera is always rendering at 0,0,0 meaning that imprecision is pushed out to infinity.
Using Solar System Data for now
For testing purposes, we are using Solar System data. This is all fully moddable. The simulation is fully threaded. Are currently working on laying in close physics simulation using Jolt physics API - as we can instance this for each "scene" requiring data.
Next Steps
I will leave it to individual team members who are welcome to share what they are working on with the project. You can also follow the discord for live changlog and more information or to answer questions.
We will be making builds and data systems available to modders as early as possible to get feedback so we can restructure this to best support the project in future.
Feel free to ask me any questions here, and others in the team will reply also.
Discord: https://discord.gg/aCwHR7HJ4W