Work continues. We are moving forward and this game is worked on, and discussed daily in WGS meetings. We also have had to pivot, as individuals, in 2025, due to circumstances, to keep the lights on and food on the table.
Has our velocity decreased on NetSim? yes;
However we are coming to the end of a large project that will hopefully finance the company and vastly accelerate the work on NetSim. One guiding principal we are trying to govern ourselves by, is not to ingest large $ amounts from our community or big corps, during development, and only release a prototype of a game, version after version. Some of you may know that reference. We are not interested in that business model. We don't want to sell "pre-release packages", and other "things", before we release a game.
We want to create content, publish it, and hopefully it is what people want to enjoy. Old school business model. That requires us to sometimes take on real world work to keep gas in the tank. So, we appreciate everyone and we understand if there are some that are upset by the timeline. Reality, unfortunately is reality. We will work on better communications , and we definitely understand your desire for this game.
We look for ways to speed up our dev work, and as an example, we are now modeling code outside of Unreal and c++ , in another language, c#, so that we can compile it very quickly, without the UI and Unreal code, and then run unit testing very quickly.
Once we prove code we convert back to c++ and place it back into the game. We have been able to vastly increase back end model development (non-UI classes) and testing. What would take a day to work on now takes just an hour or two. This is not a negative comment on Unreal. We love Unreal. It has to do with compile time and loading the game everytime we want to test a small change.
So now the Network logic, from the Ethernet Frame all the way up to the L2/L3/Host devices and NET-OS is modeled and tested in a black box console app and we can iterate changes very quickly. Case in point this weekend, we coded for VLANs in the ethernetframe and we were able to test rapidly in many scenarios. We have also worked on reducing the memory needed for the Ethernet Frame buffers. We have reduced the memory needed to the size of the frame and the needed OS overhead to manage that byte array. We refactored the support functions as static functions in a static helper class.
Thank you all for your continued patience!