Crush Depth: U-Boat Simulator
Upgrade to Unity 2021.3.27f1
Update to Unity 2021.3.22f1
0.30.28
- Fixed museum interactive display case bug
- Fixed U-Boat periscope bug
Granular object control and interaction hints
https://www.youtube.com/watch?v=z5HOEUe4Ue4
Regular update #71.
Thank you once again for tuning in to one of our updates. In this one, I'd like to take a moment to discuss and provide some context for the last couple of updates. If you haven't seen those, please check them out here:
https://www.youtube.com/watch?v=8iTp9lvm0Qw
https://www.youtube.com/watch?v=4C83mrwuZcE
https://www.youtube.com/watch?v=QOj9rQmF0p4
https://www.youtube.com/watch?v=9---mL8lo0o
https://www.youtube.com/watch?v=W4td4pNn884
Let me first thank you all for your comments and questions regarding these updates. Most of those were very positive indeed, but we've also received some of the (I really can't think of any other way to put this): 'Why are you investing so much time in creating 'Kriegsmarine Kitchen Simulator' rather than [...] ?' nature. That is a fair question indeed and I'll try to answer it to the best of my ability, by going over the main reasons for it.
As I am sure you will recall, one of the other things we are working on at the moment is a new model for the U-Boat interior which will then allow us to implement the firing system of the U-Boat. Making that interior model will take quite some time. The information is sparse, hard to interpret and not exhaustive either, as some of the work done on the interior of the U-Boat was left to the discretion of the craftsmen actually building them at the time. In order to reach the level of accuracy we want for this project, we have to research other contemporary sources as well (descriptions, photographs, etc.) and - together with the technical drawings we do possess - try to make sense of it all. Simply modeling such a massive, complex object is quite a feat in itself already, but doing so at a level of what I think we can best describe as digital archeology is a wholly different proposition altogether. (edited)
When we have finished this model (or rather, when we reach the state were we can roll out a very simple WIP-version on which we can iterate), it doesn't mean we can just move in the firing control system models and that's that. A simile I've used many times before: if you stick a tap into the wall, it doesn't mean water will come out. If we want the firing controls to work the way we want to work, we need to expand our core simulation framework quite a bit. To fire a torpedo, we need (in no particular order here) electricity, pneumatics, hydraulics, the ability to handle dynamic objects, about five-hundred other things still, all at an acceptable level of sophistication.
It goes without saying, but I am going to say it anyway, that this is a massive undertaking.
Another thing to consider: any of you who have ever read a memoir of one of the men that served on U-Boats back in the day (if you want any recommendations in that regard, let us know!) will recall they almost invariably describe the harsh, near unbearable conditions on board. It has been said somewhere that the people who designed these machines 'forgot around forty people have to live in there as well' and of course, all these people need to eat, breathe, sleep and perform all those other glorious bodily functions which we're all too familiar with ourselves. In an environment with constantly changing conditions in terms of temperature, humidity, limited supplies of fresh water, medical and hygienic equipment, this becomes harder and more uncomfortable which each passing day. The machine and the men are inextricably intertwined. Ignoring that would be telling half the story.
The simulation sub-systems (electrical simulation, atmospheric simulation, pneumatic simulation, etc.) have been built to different levels of sophistication at the moment. None of them are fully finished at this stage. To make progress on expanding and integrating them, it is easier and more contained - and therefore also less risky - to take the iterative approach of expanding two or three of them, integrating them, iterating upon that again, etc. While it might look like a trivial, rather silly thing indeed to put a stove on a pot and boil a potato, these are the first steps in integrating the electrical simulation (something we need for the firing system as well), with the atmospheric simulation (which we need for the firing system as well), with the ability to handle dynamic objects (which, indeed, we need for the firing system as well).
The stove uses electrical energy, which it then converts to heat, which is then transferred to both the pot and its immediate environment. There is another heat exchange between the pot, the water in the pot, and between the water in the pot and the potato in the pot. Although one might think the results to be rather trivial, from a developmental perspective, this is exciting, complex, and vital. The assumed triviality here comes from the fact that while most of us have had the experience of boiling a potato, not so many of us have had the experience of firing a torpedo. Without potatoes though, there will be no torpedoes either!
Let me know if I have succeeded in providing a bit more context for the choices we have made, but if you still have any other questions or suggestions, we welcome them of course. For now, I thank you all for your ongoing support!
Usable Objects (pot, stove, potato).
https://www.youtube.com/watch?v=W4td4pNn884
Flatulence and other bodily expulsion
https://www.youtube.com/watch?v=QOj9rQmF0p4
Player blurry vision and heavy breathing in sub-optimal oxygen saturation
https://www.youtube.com/watch?v=qwNkCWZii34
Regular update #70.
In this update, I would like to take a moment to cover what we have been working on as of late and to explain why we have made the choices we made along the way. I hope you find this an interesting and informative progress update.
To recap, our goal is to deliver the most realistic U-Boat simulator possible; we have set the bar incredibly high for ourselves in order to achieve this goal and our approach is aligned to deliver on our vision.
Almost everything we are creating for this project is derived from original construction drawings or other contemporary information. This information must be acquired, researched, reverse engineered, well understood, and transposed to requirements, models, code, etc… Acquiring this information is not trivial nor is it cheap!
Along the way, we must also combat misinformation and competing information (even from authoritative sources). With our rigorous process, we’ve been able to help contribute by correcting inaccuracies that up until recently were widely published and claimed to be accurate. To point out one of the most eye-catching and ubiquitous misconceptions: red lights were generally not used on a U-Boat at all, except for a few bulbs near the hatch in the control room (with some exceptions in rare, individual cases).
Apart from that, our team has uncovered information that has not been touched for years, detailing the functionality of systems in their true complexity. One of the things we are currently working on is the implementation of the rather elaborate firing system of the U-Boat, which is far more complicated than you’ll find anywhere to date. We’ve also started preliminary work on the flood-drain-system of the U-Boat, with special thanks to our contributors Stosstrupp and TheEngineeringGuy for the groundbreaking work they have done researching these subjects.
This means that our project is not only working towards the most authentic digital recreating of a type VII U-Boat ever, but we’ve also been materially contributing to the broader corpus of U-Boat knowledge along the way.
I won’t revisit all of the progress we’ve made (if you are interested you can view all of our updates on our Discord or Steam page. Should you wish to have a look yourself, you can also download our free demo and support our project by either purchasing the tech-demo or considering becoming a patron of the project through Patreon.
What I want to focus on in this update are the three major challenges we are currently working through:
I) The game engine.
Out of the box, the Unity game engine does not supply us with the architectural underpinnings we need to be able to see this project achieve the lofty goals we have. To try and correct this, almost a year ago we investigated moving over Unreal Engine 5 by Epic Games. We went as far as developing a full proof of concept clone in UE 5 and had the engine communicating, side by side, with our back end MMO server topology. We were so sure of the game engine shift, we publicly announced our move 🤦 Hindsight being 20/20, we now know that it was a mistake.
Here is why!
While Unreal Engine 5 is superior to Unity in many ways (graphics fidelity, performance), it lags behind in several key areas that, as a team, we knew we had to address in order for the move to make sense. Why trade one set of problems for another?
Unity uses C#, a beloved and widely used language developed by Microsoft in the early 2000’s. It is widely accessible, offers incredible developer productivity supports, and is easy to use. UE on the other had relies on C++. We won’t go into detail why our developers, and legions of devs around the world, hate C++ but it should suffice to know that using C++ as our core dev language was a non-starter.
In order to fix this glaring drawback with UE, we created a tool we call Code Orchestra. This tool allows us to write C# and have it run inside of UE. Even better, it allows us to write Java, Rust, and almost and other OO language and have it run side by side with extremely interoperability between runtimes. This was a big deal not only for Crush Depth, but for millions of game developers and game studios; suddenly you can use one of the most beloved languages in one of the most technically advanced video game engines with almost no performance penalty!
Here are some videos which prove how well and how powerful Code Orchestra is inside of UE.
https://www.youtube.com/watch?v=8BGi_vVpjk0
https://www.youtube.com/watch?v=hu0bAB5e8D0
After our successful technical proof of concept of moving over to CD to UE was complete, and we announced the move officially, we quickly hit a wall we did not anticipate. Upon moving to release, we were met with Epic’s Draconian and unusual EULA. The EULA explicitly forces any dev creating tooling similar to Code Orchestra to open source their invention 🤨 (yes, free labor for the benefit of Epic Games).
We had calls with Epic Games where their tech staff signed off on our tooling, Miguel de Icaza who faced this exact issue years ago, and lawyers. Our goal was to get approval from Epic Games to move forward with Code Orchestra without being bound to a decade-old clause which is doing nothing but harming UE’s developer opportunities (why prevent your dev’s from using Rust, C#, and other tech in UE?).
After many calls, demos, and lots of $ invested on our end in lawyers pouring over every option we had available at our disposal, attempts at conveying our position to Tim Sweeney, CEO of Epic Games, and having him reconsider his posture on the matter via a petition ultimately failed. We accepted that we were backed into a corner and that our significant time and monetary investment in attempting to use UE to make Crush Depth the best it could be was being shot down by Tim and our only viable option was to move back to Unity.
So back to Unity, an inadequate game engine, it was! This meant we had to revisit the issues we had in the first place which prompted our move. First item on the list, addressing the slow HDRP rendering pipeline and the lack of support for modern features.
To address this, we have been working on a fully custom rendering pipeline we call CRP (cinematic rendering pipeline). CRP is written in the Rust programming language and makes use of DX12 API’s directly by foregoing Unity’s slow, outdated, and limited API catalog. CRP features ray tracing, a custom nanite like virtual geometry mesh format which allows us to dynamically, at runtime, swap out LOD clusters in complex meshes to optimize for performance with no visual fidelity loss (it goes one step further than UE nanite and supports runtime generated meshes), custom shader support, and much more. Essentially it replaces the entirety of the Unity rendering codebase with a custom modern and performant implementation targeted at modern DX12 API’s. We will eventually have lumen like global illumination support that will allow us to scale our visual fidelity significantly further than what HDRP would allow us to achieve.
II) The U-Boat interior.
Over the last couple of months, we’ve created a ton of new assets for inside the U-Boat itself. You can see some examples of those in our previous updates. Special thanks there to Kriegsmarinesammler who has recreated many of these models based on the real items themselves. Many of these items are for sale as well, so if you should be interested, make sure to have a look.
The main challenge we are facing in implementing these is that the model we currently have in place for the interior of the u-boat itself (walls, floors, etc…) was built with limited information. With our recent acquisition of plans and blueprints, we are rebuilding the interior to optimize accuracy and geometry. We have created a modeling pipeline that will allow us to implement a bare-bones version of the interior that will allow us to start implementing the firing system and other control of the U-Boat, while we keep working on the rest of the interior in parallel.
III) The U-Boat exterior.
The same goes for the U-Boat exterior. While we are not unhappy with the model we have in place, it is not quite up to the standard we want for this project. For this, we have partnered with Carlo Cestra who specializes in reconstructions and animations for archeological, historical, technical, and scientific topics and is currently working on recreating the exterior at the same level of detail and accuracy that we want for every item in our project. As you can see from the renders below, we’re making good progress there as well.
That’s it for now!
Thank you for tuning in once more and for your ongoing support. Should you have any questions, feedback, or if you just want to have a chat, always feel free to contact us.
Mid year 2022 update.
As always, thanks for your continued support and should you have any questions or remarks, do let us know! More news to follow soon.