New UI

I understand that due to lack of design patterns like MVC and probably spaghetti code written in C++, it turned out it required much more effort. That's a reasonable excuse. Usually you can only estimate real effort once you started working on it. But S397 kept promising new UI is coming long long time ago. Once S397 said it will also be delayed because they wan't to already include online competition system with the release. I think it's no longer true( which I think was a good decision).
I completely agree with what Marcell said on RD interview (IIRC) that hopefully people spend majority of time on driving not with UI and actually don't care that much about UI, as long as it's functional. Car setup screens are fine etc. The only problem is that there are many long stating issues i.e.
- no FFB strength graph (seems simple)
- No minimap/track map (coming)
- no way of knowing what's AI player count on server in multiplayer window(very frustrating for beginners who just want quick race)

This last thing is finally fixed in new UI, but was actually not fixed in early screenshots presenting new UI, despite many requests and complaints about this specific issue. From what I read the first release of the new UI will have mostly maintain the same functionality, except few things like track map. But thanks to new code, MVC etc. future changes will be much easier and S397 will be able to apply them according to community feedback.

 

Yes, wonderful (even if it may discourage many potential new players away), the catch 22 is that because they are developing the new UI (I wonder why, if they now say that is not so important after all), they have no time to solve bugs nor finish half developed options.
Cheers.

 

So really - when you read what you have said - what you're actually complaining about (I'm not having a go at you - just saying) is a communication problem, which is quite possibly a fair comment.
All I will say (and i'm kind of repeating myself here), is that unless you know exactly what has been occurring internally within Studio 397 and their development team(s), your comments may or may not be fair criticisms.
eg: some people have made comments about the release of cars and tracks, rather than bug fixes or the UI updates. That sounds fair in some respects, but none of us on the forum understand the company's financial situation, their cash flows or all of the reasons behind why various content has been released. Were there internal or external pressures that meant that work priorities had to be changed ?
How many people were working on the content releases, versus the bug fixes ? Are they the same people, or is there an overlap in resources that mean that the developers can't work on one thing, while working on another in the background.
My main point is people are commenting from the outside, without any real knowledge.
What are people's opinions based on - press releases (road maps etc) and interviews...? - how much detailed information is in those...?
We can't expect the developers to treat customers as if we are part of their organisation and go into really detailed explanations of why there are delays and document every single issue that comes up - that's not a fair expectation, so in reality, customers are making judgements based on a limited amount of information.
I just think that should be kept in mind, before people criticise a software developer that apparently we all like (we are on their forum after all).
...and lastly - how much are we paying for the UI work, bug fixes and updates to online features... to the best of my knowledge it's costing us nothing. And what have we lost as a result of the delays ? - to me the answer to that, is we have lost the opportunity to use new features as soon as we would like. Given the cost - I think it's a fair trade.
...complaints are probably in some respect a compliment. You wouldn't complain if you didn't care would you... ?

 

Here's a couple of other things for people to consider with Studio 397.
Just to be clear - I have no relationship what so ever with the company, other than owning rFactor 2 and a couple of the DLC content items (the first GT3 car pack and the Nurburgring track releases) - so I'm commenting based on information I can gather.

Based on their LinkedIn profile (source: https://www.linkedin.com/company/studio-397/about/) - the company has at the most around 50 staff total (LinkedIn states 11 - 50 total staff, with 14 being on LinkedIn). Note I said "total staff" and not the number of developers.
So from my own personal work experience - that is a very small company. I have regularly worked with companies with more than 10,000 staff. If this was a New Zealand company (where I come from) - I could pull up their public tax information and confirm what they are submitting in tax, but I'm not sure if that information is available for companies in the Netherlands - if anyone knows where to find it - I'd be curious to look at it.



Secondly - how large is their user base ? - well steam can tell us that very easily (in ascending order of users) - i.e. rFactor is the least popular one in the list - purely based on Steam numbers.

rFactor 2: https://steamcharts.com/app/365960 - peak concurrent users = 1418
Assetto Corsa Competizione: https://steamcharts.com/app/805550 - peak concurrent users = 4122
Project Cars 2: https://steamcharts.com/app/378860 - peak concurrent users = 6726
Assetto Corsa: https://steamcharts.com/app/244210 - peak concurrent users = 6954

rFactor 2 (steam spy info): https://steamspy.com/app/365960 - Owners: 200,000 .. 500,000
Assetto Corsa Competizione(steam spy info): https://steamspy.com/app/805550 - Owners: 200,000 .. 500,000
Project Cars 2 (steam spy info): https://steamspy.com/app/378860 - Owners: 500,000 .. 1,000,000
Assetto Corsa (steam spy info): https://steamspy.com/app/244210 - Owners: 1,000,000 .. 2,000,000

...so the statistics seem to back up the fact that we're dealing with a small company, with a small user base.
That will directly translate to their finances and resources (human and other wise).
The fact is we're all using a racing simulator that is a niche product, even in the world of racing simulators - which on its own is a niche game category.

...that might put some perspective into why they have the odd delay or two with releases. And being honest - I'm impressed they have done what they have to date, since taking over ownership of rFactor 2.

 

True, but also isn't S397 a part of bigger company Luminis. I suppose it could be possibly that it is not only rf2 that takes it. The Grand Tour game for example.

Anyway, I think that smaller companies are the best. Kunos were really small when they did AC, though almost certainly that's less demanding software. Anyone knows how many people worked on rf2 in ISI originally? What about Reiza?

As for bigger companies goes, there is several examples of them going majorly wrong way. Badly managed big companies are the worst. Also they might not always guarantee super fast fluid development, as there might be just too few people able to manage the code, at least that's what has been told during development of dayz game, but they did release side projects based on dayz though, such as vibor game..

 

ISI was even slightly smaller I reckon. However, back in the days ISI made great F1 sims year after year for EA and then released rF1 few years later, so I agree it can be done with a smaller team. One change is that content now needs more sheer work than back in rF1 days. With rF1 standards even a modder could finish a track during his free time in a couple of months. Now it takes several developers and many full working months to build a track.

 

I mostly agree and usually defend S397 using similar arguments. I'm happy there were significant improvements in some areas. There are some long standing issues or bugs, some of them acknowledged by S397. I'm aware they are rather small company, but on the other side as @mantasisg said that's not uncommon in simracing. But in case of UI it's definitely not just a common delay... I was reminded that S397 repeatedly said UI development is in advanced stage.
In AUG 2017 they said about the new UI:
"In the last couple of months we have shown you various bits of the new UI. We are now at a point where we have basically incorporated all features of the existing user interface into the new one, with a few extensions. In the upcoming weeks, we will be testing the first beta of this user interface with our testing team. During that phase we not only intend to focus on bugfixing, but also usability testing, so depending on how our testers respond, we might make further changes to parts of the interface. Obviously we can’t predict yet how long this phase will take, but it should tell you that we’re pretty close to a first public beta release."
https://www.racedepartment.com/thre...updates-in-august-development-roadmap.139762/

Apparently there are some people that care about UI. At least that's what we usually see in first comments anytime S397 releases something

 

if I can say my personal point of view, when the UI is deployed to us and it is broken then there is no excuses for not complaining.
I am happy to wait till this is done right and works!
To be honest , no sofware company in racing simulation is hitting the delivery dates as promised so we should be really used to it at this point.

 

I do agree that it will be nice when the new features appear and I would like to think that the UI update and hopefully improvements to the online components might happen in the near future - but I'm just guessing based on the amount of public comments the developers have made about them.
I'm sure you appreciate though that a beta test is exactly that - a beta test (which would initially be very limited in scope - i.e. not released to the public). Who knows how the first rounds of beta testing went - I sure as hell don't. But based on the time that has passed, perhaps that didn't go too well, or additional issues were found that meant large changes had to be made. Again - I'm just speculating.

My feeling is the work that was being done on feature changes and updates (the UI and networking stuff etc), may have been put down to focus on the content releases. That is purely a guess on my part and may be completely wrong.
But a couple of reasons I can imagine for that to happen are external constraints (eg: I can't imagine a company like McLaren deciding to work with a developer and just saying "finish the release of the McLaren content whenever you get around to it.."). I can imagine that a car brand would have assisted with content development with a pretty specific contract and time frame in mind. And for financial reasons - i.e. generating more cash flow to keep the company going - a scenario like that would be very hard to turn down. So would things like the Nurburgring. It's a great track to have and if it helps generate more income, all the better for the developer in the grand scheme of things.

If you consider the the number of sales for rF2 over its life span and when S397 took over - my guess is that it's probably not the most lucrative title to develop - unless you can spin off additional revenue in some way - eg: content.
So delays with doing things that are nice and work towards an end goal in the bigger picture (bug fixes, UI updates and feature additions), but that won't result in much additional revenue (if any), are very likely to get put on hold if a project comes along that does create revenue. A business needs cash flow to keep going (salaries for one) and without cash, the developer will close shop.

...in short I'm saying it wouldn't surprise me in the least that a small developer would have to work on projects that don't result in cash, around other projects that do provide income. If additional random projects become viable, then that means additional delays to get back to the feature updates.

Coming back to your quoted comment from S397 - which was dated August 2017 - I wondered to myself - how many releases have S397 made since August 2017. i.e. how many potential interruptions have occurred, which may have delayed the release of feature updates (remembering that the feature update work could be very time consuming) - I checked racedepartment.com, used the Studio 397 tag to filter to just rF 2 news, then copied all the headlines since Aug 2017 into a text file (attached), then filtered it down, read through the filtered list and tried to remove any duplicates - I came to a total of 30 items.
That is quite a few more than I had thought. I would have grabbed the data from Steam, but couldn't see it listed easily and wanted to do this quickly, rather than spend much time on it.

Both of my text files are attached - the unfiltered dump and then the filtered list with each item on one line - and the lines are truncated around the 300 character mark.

But in a perfect world I agree with people's sentiments that it would have been nice to see feature updates when they were originally planned to be released - but it's easy to see how things have been delayed - as annoying as that might be to the end users (us).
I think I have made enough comments in this thread and I probably am defending them, but by the same token I am trying to be pragmatic and explain what I think has likely been going on behind the scenes - based on my knowledge of software development and with a bit of realism around priorities in terms of things that generate cash and things that don't.

 

One of thousands of quotes on software development:
"It is better to define your system up front to minimize errors, rather than producing a bunch of code that then has to be corrected with patches on patches" Margaret Hamilton of Apollo Guidance Computer fame.

 

...a very true statement of course.
Another obvious observation (which I have personally seen with a large scale business application multiple times) is - ideally you don't want to inherit someone else's code.
That always results in a mess at some point. I've seen applications written in old languages get to the point where you are running them a decade or 15 years later on hardware and software that bears no resemblance to what the software was originally written for, the maintenance becomes very time intensive and on multiple occasions I have seen large organisations say things to the effect of "we know we have major problems with xyz application, but it's so hard to maintain now, that we need to rewrite the whole thing from scratch in a modern language to make it work as well as we would like to". i.e. we can't fix it, we need to start again from square 1.
ISI released rF 2 in 2013. Who knows when it was actually developed - my guess would be in the preceding year or two - so it's likely got code in it that goes back about 7 or 8 years at least (assuming nothing was carried over from rFactor 1).

 

Quite a-lot was carried forward from rF1. However, a large portion of that code was assumed to be working rather than brought up to date.
(imho)

 

I guarantee that's exactly what they thought, or they would not have spent the money to buy the game, wholesale and then spend the money to do the work. If they could go back and decide if they wanted to simply license the physics engine and build upon that they may have made a different choice. But maybe I am wrong. None of the Luminis guys are saying.

 

ISI surely worked for at least few years before 2013 release. Yes I'm pretty sure some code was carried over from rF1, I think often slightly improving/modifying it. Also some code is result of earlier experience gained after working on other projects like rF Pro. I don't know about their unique tire model development, but I wouldn't be surprised if it wasn't result of like 5 years of R&D.

 

I'm sure I read Marcel saying the UI code was from rF1 and something about a massive text file full of "magic" that provided the data to configure it.

 

You're probably right - I was being as optimistic as I could be with my comments - based on the public information available, but I wouldn't be surprised in the least if some of the code dates back to rF 1 (released 31 Aug 2005). If that is the case, then the age of some of the code may be closer to 15 years plus!

 

I can assure you code got carried over from rF1, probably most of it. This is how software development works and there is nothing wrong with. Well written C code for example doesn't need to get updated, just like Ferrari doesn't redesign the drivetrain for every new road car they release if the old one already does the job well. Windows 10 for example is mostly based on code from several years, even decades back. You can even see this on the UI side with things like the old control panel still existing today. If the technology doesn't change, there is no reason to rewrite code. With front end coding the tech has changed much quicker, so 15 years old code isn't such a good idea, but it depends on the case and program.

 

Age of the code doesn't matter if it is written well.
If it uses some old tech and libraries that could be a problem.

 

Well yes and no. Refer to this quote from the referenced article and you might get the point I was making with references to old code.

"New code is fun but fixing old code is often seen as drudgery. However, if you have a large, legacy codebase, the new code you're writing is, by definition, a large project and large projects are very high risk (emphasis mine):"
source: https://ovid.github.io/articles/a-simple-way-to-fix-legacy-code.html

 

But I think something like physics engine should never be re-written to higher level languages like Java. It needs to be really optimized, work in real time and can't wait for GC. I know often game engine's algorithms didn't even use standard C++ libraries or Boost, because they are not optimized for their task (even these don't change that much). Instead they use custom memory allocation, bitwise shift operators, or even some clever assembly code, so in result code can be 10x faster. I used to do some basic optimizations in C/C++ (but unfortunately never did any kind of game programming - it's too hard).
Now UI can be coded in any kind of language, including HTML + JS, with tons of libraries. Yes such tech gets old quickly, you have new frameworks every year Javascript performance in IE6 was probably >20x slower than in modern Chrome