One aspect of the critique I did very much agree with was that while hiring more coders would put timeline pressure on Schine, Schine actually already is under timeline pressure from the reality of their fan base and public reputation. They can choose not to internalize that pressure and willfully ignore it, but the final outcome will be not better than internalizing the pressure with more funding and another coder or two and not meeting the set development goals. Potentially worse, because currently instead of a concretized dev timeline, they have an abstract cloud of vague expectations across the entire spectrum of possible game outcomes that they can never properly fulfill. The pressure is already there, the clock has been ticking this whole time - in 5 or 10 more years something new will have largely obsoleted voxels.
As I've gone over in the past, development isn't as simple as throwing more developers at a project. Ignoring all the other host of issues, each developer added takes a heavy time and money investment to become useful. Additionally, the larger a development team, the larger the infrastructure needed to support it. It doesn't scale linearly. As of right now, we are already at the maximum capacity for developers that we can handle on StarMade. Hiring lots of developers is a good way to say goodbye to StarMade and Schine as a company, we would be running ourselves into the ground. We've had a developer in training for the past two months now (unannounced) and we've had other developers work with us before, as well as some who did not work out and were never announced. It takes a substantial initial investment from us.
I mentioned we would develop for five more years if that's what we needed to do, that's far beyond what we would expect. Two years would be a more reasonable expectation for a full release, and beta release somewhere in the middle. But again, we won't have a good enough idea to make internal estimations until the universe update is finished.
It seems like it should be possible to fork development and could even result in better funding right off the bat if done right, without forcing any distortion of the stated long-term development goals. Schema could isolate the core sandbox "kernel" and continue developing it under the current philosophy, and another (subsidiary) entity could take the SM engine from its current position and move to fast-track it to post-beta within 18-24 months as an actual *game* - not sandbox. That is to say, it may be time to use this engine for something. The sandbox/engine (here) would still be vital and growing, but having an actual playable option would allow Schines currently sizeable fan base to get their actual play fix on a finished version of a game built on this engine (going by a different name and under different colors, obviously). It would literally be two very different games at that point, and could easily be sold separately (perhaps with a package discount). Then in two or three years you push out another finished version.
This is what most companies do when they have a good engine.
This is not what most companies do. Developing a commercial engine is a lot of work and money, it needs to be in a state where other developers can utilise it, with little to no help from the creator. This means fairly clean and robust code, plus extensive documentation. In-house engines are not designed with this in mind. Often, they are designed for very narrow purposes (as in the case of the Schine Engine). It's not as simple as handing off or "forking" development, we're not using a commercial or even an open source engine here. For someone else to utilise it, we'd need to spend a ton of time and money (that we do not have) to either get it in a state where any competent developer could use it relatively quickly, or, send our existing developers to teach new ones how to use it.
There's a good reason why companies that develop commercial game engines are multi-million dollar AAA development companies.
Also the updates to decorative aspects of blocks gives a very strong impression that what we have now is something very close to the end product, because it's unusual to paint & polish an engine itself. For good cause. We usually reserve paint & polish for near the end of a development process in material production as well (cars, toys, etc). It's certainly not something typical for an alpha-phase prototype. Except recently, for a growing class of indie games on Steam.
We are, in terms of framework, very, very close to completion. To a player, it might not seem that way, but from a development standpoint, we've covered most of the ground, we have a few large hills to cross yet, after that we hit beta. Until very recently, we did not have a good idea of when we could expect to reach beta, now that we're at the later stages, we know when we'll have a very good idea.
I would love to see a complete end to any paint & polish updates (this affects someone's RL job, and I apologize) in Starmade, and a push to stabilize the engine as much as possible as is, and use it to publish a game within 18 months featuring plentiful paint and polish on that side. Then in 2-3 years when the engine itself (i.e. Starmade) has been fitted with new features, a new game based on it can be fastracked. No need to "shit or get off the pot," but maybe look at building a second toilet...
As I mentioned before, we have as many developers as we can support, right now. I assume you're talking about textures, 3D and other in-game art. This work does not detract from development. A job for art, does not mean one less job for development. Texturing, music, modelling, all take time to complete. We will be doing all these things eventually, so it makes very little sense to delay them.
We cover as much ground as we possibly can with the resources we have. Changing the configuration of that, or adding onto it, will not speed things up. Creating a game is a complicated process, team structure is an important part of that process, and it's not easy to form. From a consumer perspective, it might seem easy on the outside. However, a lot of thought goes into how teams are formed and how to tackle a development process.
