Hey everybody time for another weekly update. This week I’m going to start with the art update because I’m going to spend a lot of time discussing some of the engineering stuff we’re doing. The art team is beginning to wrap up the final geometry pass for the interceptor, bomber, corvette, and large station pieces. This week’s screen shots show off the latest progress for the bomber and corvette respectively.
Final geometry for the bomber exterior is almost finished
Unfortunately we haven’t been able to release our new pledge upgrade system yet because the legal review of the new Terms of Service isn’t done. This week is a major holiday here in the U.S. which is likely slowing things down for our attorney but the review will hopefully be completed soon. We’ll make an announcement once the pledge upgrade system is available.
For those of you who’ve been with us for a while you may recall that Flavien originally started building our technology around 2004/2005. That’s a long time ago and it was just before dual core CPU’s became a thing. What this means is that our game engine was originally designed around being single-threaded. Over the intervening years between then and now we’ve optimized specific portions of the engine for modern multi-core CPU’s however this was done with the knowledge that at some point we’d have to bite the bullet and upgrade the rest of it. With our goal of supporting 200 players in massive space battles that bill has now come due.
The final geometry for the corvette exterior is also nearly complete
To that end we actually began this process over the summer when we upgraded our physics engine to be multi-threaded. Unfortunately that still leaves entity/actor/scene updates and rendering. Coincidentally both of these are being upgraded at the same time, right now, because of dependencies in the networking code that Flavien is writing and the new UI system that I’ve started writing.
Flavien is nearly finished with his new entity/actor/scene code and will soon be getting back to the remainder of the networking improvements. This includes client-side prediction (hides latency) and a challenging problem with server-side collision detection against planet terrain that recently popped up. I’m writing our new UI system using an experimental implementation of the new Vulkan graphics API which is designed around multi-threading. Once the UI system gets far enough along that I’m confident in its new rendering abstractions I’ll replace Vulkan with D3D11 to finish it.
This means for the Alpha the game will have 2 rendering systems. The bad old single-threaded renderer which will draw most of the game and the brand new multi-threaded renderer that will draw the UI. Only D3D11 will be supported at launch so the experimental Vulkan implementation will just hang out until we have time to finish it once the game ships to retail. After the Alpha gets released we’ll begin iteratively moving the rest of the game over to the new rendering system so we can make maximum use of all of your CPU cores. We expect that by the time that all of this is done we’ll have about 1 - 1.5 months left to implement the majority of the gameplay for the Alpha. Needless to say the release of the Alpha is going to come in hard and fast, it probably won’t be pretty, but if you’ve been following these updates with any regularity that shouldn’t come as a surprise.
That’s it for this week and for those of you in the U.S. enjoy your Thanksgiving!
Awesome stuff! Is the next patch going to be the one with networking etc. improvements (so not in the next weeks) or can we expect a patch inbetween, for example with the updated ship models?
Interesting stuff! I’m assuming the gradual upgrade to multithreading will have a significant impact on performance? Will it also shorten the initial loading time? Because it still takes me a good 5-10 mins to load the prototype (admittedly from a standard hd).
There will be intermediary patches. We’re months away from the networking/architecture patch ( which will be a major release ).
[quote=“Sab1e, post:3, topic:4501”]
Interesting stuff! I’m assuming the gradual upgrade to multithreading will have a significant impact on performance? Will it also shorten the initial loading time? Because it still takes me a good 5-10 mins to load the prototype (admittedly from a standard hd). [/quote]
Loading times will be addressed later on, maybe after alpha. It’s a matter of moving a bunch of things ( especially materials ) that get recompiled every time and to pre-process those. It’s not terribly hard, just time consuming.
As for multithreading performance it’s hard to say. It’ll mostly help with CPU overhead; but on most video cards the bottleneck is actually in lighting & shading & bandwidth, which won’t be fixed until we do shader optimizations later on. It’s however very important to be able to process a high number of objects on the CPU, and if we ever want to have large scale battles it’s definitely top priority.
Wonderful work on those ships, nice to see the art team on schedule. I have a few clarification questions @INovaeKeith.
First off, why couldn’t the legal work for the pledge upgrade system be done in parallel with the implementation, even if it did rely on your implementation, couldn’t an outline have been made that would speed up the process, instead of doing this sequentially?
Second question is concerning an update from about 2 months ago (#34th weekly update), you claim that all these systems are in finishing up state and only last pieces need to be done, yet here we learn that networking will take aditional few months from now, incremental patching has supposedly been scrapped, the only thing that sort of got finished is the pledge upgrade system. I know you guys have an explanation for all the issues, was wondering if you are maybe considering giving yourself more time for tasks in the future and reporting them as such. It might help with the perception of INS and deadlines.
And finally, you claim that you will have 1-2 months to implement Alpha, however the target date is not mentioned, can we assume first quarter of 2017 for this, so around about April?
Because then the lawyer would have to do a first version, and then revise it afterwards I guess. Sounds like much more work (and the lawyer needs to be paid twice).
Well, if what was going to be implemented was planned and known before it was finished, then what you guess would be an issue, I guess wouldn’t be an issue.
I did it sequentially, could have done it in parallel, but I didn’t as I’ve got plenty of other stuff going on in parallel.
New problems are discovered, things take longer than expected, etc. This is all just part of software development and with only 2 coders any sort of unexpected problem has a significant impact. We’re doing the best we can but it’s unlikely any of this will be mitigated during the development of this game - at least not if we’re going to be talking about what we’re doing and thinking at any given moment in time. If we go dark and just say it’ll be ready when it’s ready then problem solved.
My concern is more that you use phrases and a method of communication that comes across as borderline lies after a few months, in what I guess is a desperate attempt to always pain a positive picture. Using words like finishing up and last pieces is just so blatantly wrong with hindsight, whatever the reasons for delay were they don’t explain how you could have possibly believed that the amount of work left was so disconnected from reality.
The words used are based on the information I have at that moment in time. We’re pretty transparent with what we’re thinking and doing in our weekly updates at that moment, to the point that other ppl have suggested we be more “professional”. We’re doing the best that we can with limited resources.
Once again, the issue is not with the delays, but rather with the constant misrepresentation of the current state of development and the required time to do tasks. It’s very hard to believe that you are so far from reality when it comes to time required to do things. For instance if someone says that there is 10% of the work needed and it turns out that 500% is actually required and this happens continuously with many issues, then there is something wrong with the forecasting and the perception of the current state of progress.
All I’m asking for is for you to take this into account in future updates when you think of claiming required development time, it would be great if you actually learned to forecast development accurately, but this might be a large ask. So please, just think twice about how you approach communicating the current and future development time.
Yeah I feel like the misinterpretation is all in your head bro. The language used is casual as you’d expect from a normal development team. It’s clear that there will probably be delays but I don’t expect a gantt chart every week.
Right, I don’t think it’s a dishonest method of communication. You’re interpreting it as dishonest based off knowledge of what will happen. If anything, it shows the plans aren’t accounting for issues that arise. Perhaps the planning process needs to be revised. The rhetoric is totally fine. These are separate possible causes and lumping them together and getting angry isn’t productive.
@INovaeKeith one sentence I’d suggest either: making promises and deadlines more ambiguous, and f there is room for improvement in planning, trying to account for more issues before starting the next month/week/cycle-time-period’s dev cycle.
Look, if a person gets a prediction wrong, once, twice, three times, it’s understandable, but after that you would expect him to learn either to make those predictions better or avoid making those predictions publicly.
The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.
I’m sure they are not throwing out inaccurate dates to annoy or confuse us, after all what would they gain by it?
I prefer getting current estimates over getting no estimates or super conservative estimates.
I’d suggest an almost Scrum-like approach to tech updates, in a way.
Just say:
What you did in the last week
What you’re doing for the next week
If 1 and 2 are the same, a brief explanation of why it’s taking a longer time than expected.
That’s it. Only what you’re currently working on. No estimates on delivery, but if you know things are going to take more than a week, it may be worth mentioning.
Part of the reasoning behind this approach is to break a larger thing you’re doing (for example, netcode refactors) into a smaller explainable chunk that is actually deliverable in a week. But it also means stuff like if Flavien’s stuff isn’t actually finished in the next week, we won’t expect him to be working on netcode stuff in the next announcement.
I’d also like to think that this is what’s going on in your internal comms.
